Tomi! Én a Harmony-t kb másfél éve tanulom, most már nagyon jól tudom használni, rengeteg drivert és system alkalmazást beintegráltam a saját projectekbe (pl. legutóbb sikerült egy SQI Flashről futó WEB szerver mellett egy SD kártyára mutató FTP szerver mellé egy USB MSD drivert tenni, ami szintén az SD-t nyitja be a fájlkezelőkben.) , de ami még fontosabb, hogy saját drivereket és rendszer alkalmazásokat illesztettem az MHC-be a régi rutinjaimból kiindulva és módosítottam a gyári drivereken is, ahol kellett (nem jellemző a túl sok hiba, de azért nem hibátlan és nem minden van kidolgozva teljesen), azaz használható környezetet leltem benne. Nem állítom, hogy könnyű, bár ha valaki tudott volna segíteni annyit, mint amennyit most tudok róla, néhány hónap alatt elérhettem volna idáig. Angolommal én se dicsekedhetek, de átküzdöttem magan a helpen is, ami ~800 oldalas csupán és nem túl bőbeszédesek a példákban.
Jelenleg a 2.02b verziót használom, ami béta, de ugyanazok az állományok vannak benne némi újabbakkal, mint ami az 1.x-eknél volt, úgy hogy nem nagy a kockázat. Hogy a harmony biztos támasz-e minden megoldáshoz? Nem. De mint írtam simán integrálhatóak a saját régi rutinok, ha tudod hogyan kell csinálni és egy kis rutin után a gyári részeket is át lehet írni.
Ha ezek után érdekel a harmony, akkor nyithatunk egy ilyen topicot és amit tudok segítek. Lehet, hogy nem csak ketten leszünk...

Akkor ne hasznalj IDE-t! Hasznalj szovegszerkesztot (xemacs, jEdit), forditot (gcc) es make-et, meg a tobbi UNIX utility-t. A beprogramozashoz meg csinalj magadnak egy programozot, a programozasi algoritmus minden PIC-re publikus. En 21 eve programozok Linux alatt kulonbozo mikrokontrollereket (profi szinten) es soha semmilyen IDE-t nem hasznaltam, soha nem vasaroltam semmilyen programozot.

Teljesen igazad van, de jelen esetben nem hiszem, hogy nekiállnék egy USB vagy egy TCPIP driver megírásának PIC32MZ-re akkor, amikor megtették ezt helyettem, igaz úgy ahogy (egyszerűen nincs már rá elég idő, olyan gyorsan változik a világ). Tapasztalatom az, hogy működőképesek ezek a driverek, nekem csak a lényeget kell megírnom mellé. Nem állítom, hogy bevállaltam volna egy éve egy melót harmony-re támaszkodva úgy, hogy nem próbáltam le mindent, ami kellhet, ezért eddig nem is tettem, hanem teszteltem folyamatosan egy évig. Most már azt hiszem nem tartanék tőle, hogy bedőlne egy project, igaz nem tenném rá az életem!

killbill IDE ről beszélt nem LIB ekről. A kettő nem ugyanaz. Én is linux alatt cross fordítok sok mindent. Nem használok mást csak MC editet.

Na ezt figyeljétek!
Egy dsPIC33EP512GP806 UART1 perifériája 115200 baud-dal üzeneteket kap. Küldeni egyébként semmit sem küld de ez lényegtelen. Jön egy karakter, erre a PIC belép az U1RX megszakításába. Ott törlöm a flagbitet, majd egy helyi változóba kimásolom a vett karaktert:

Az "rx" tartalma ennek hatására egy "S" betű lesz, tök mindegy hogy milyen karakter érkezett valójában! Ez még hagyján, de ha kimásolom még egyszer:

Akkor jó lesz! Másodjára már a valós karakter lesz az "rx"-ben! Elképesztő...

Folyamatosan ez van,vagy csak az elején?

Tenyleg csak az IDE-rol beszeltem, de a lib-eket illetoen ertem Wezuvot. Tobbnyire sajat lib-eket hasznalok, vagy olyanokat, amiket a batyam megirt, mert kellett valamihez, es aztan publikussa tette oket. De pl. TCP/IP-nek az uIP jelentosen (altalam) atirt valtozatat hasznalom. De minden mast megirtam eddig magamnak.

Folyamatosan. Ha egy tömbbe másolgatom bele akkor az tele lesz "S"-betűvel.

PIC32MZ-hez nincsenek lib-ek, ezért MPLAB X és Harmony nélkül tök alapról kellene indulni, ezért az IDE elkerülhetetlen, hacsak nem írsz meg mindent alapról, ami azért is nehéz, mert nincs meg minden infó. Így aztán még is csak összefügg a lib és az IDE.

Csak egy teljesen kósza ötlet: mi van ha a flagbitet a kiolvasás után törlöd?

En is akkoriban, a slackware 2.x-el kezdtem valamikor 94 vegen Marmint a linux alatti programozast, altalaban.

Hiába voltam hosszú, csak nem sikerült tökéletesre a fogalmazásom. IDE-t írtam, alatta egy-egy komplett fejlesztő környezetet értettem.

Szívesen használnám az mpIDE-t, vagy a mostani változatát, amivel az Arduino IDE-t lehet pic32-re felokosítani. Sokkalta egyszerűbb, mint az MPLAB. Lényegében egy szövegszerkesztő, ami képes a bootloader segítségével a lefordított programot beégetni. Ezen kívül mindössze egy terminál ablaka van, amihez van megfelelő library, hogy kommunikálni lehessen a megírt programmal, már ha beleírok megfelelő kommunikációt.

Az MPLAB bármennyire is böszme, gyorsabban fordít, mint az előbb említett környezet. És azért - főleg kezdőként - jól jöhet néha a nyomkövetés lehetősége.
A Harmony-t addig gondoltam használni, míg el nem lesem belőle (feltéve, ha el lehet), hogyan kell beállítani egy-egy kimenetet, bemenetet, hogy az működjön is, mert az elég sötét ló nekem. Az mpIDE azt ugyan olyan egyszerűen elintézte, mint az Arduinoban lehet. (Gondolok itt arra az előző hozzászólásomban írtra, hogy ugyan az a panel, mégis a B regiszter egyik bitjén az egyik rendszerrel tudtam villogtatni a LED-et, a másikkal nem.)
Itt egyelőre a libekkel gyűlt meg a bajom. Feltettem a legújabb (3.60) MPLAB X-et, hozzá a legújabb xc32-t (1.43). Include-ban plib.h, és a mostani plib-ben nincs más, csak további libek include-jai. Azok viszont nincsenek ott, ahonnan be szeretné húzni. Megtaláltam, hogy ezt külön le lehet tölteni, csak az 1.40-es könyvtárba megy. OK, átmásoltam. Akkor meg a következő liben akadt meg, mert az is máshonnan akart behúzni libet, mint ahol volt. Lehet, hogy a telepítésben böktem el valamit, de én csak követtem, amit a telepítő mondott. Vagy lehet, hogy a Microchip nem jól hangolta össze a komponenseket?

Amúgy én is jobban szeretem a szövegszerkesztőt, mint az egérrel programozást. A web oldalakat is szövegszerkesztővel írtam, nem egérrel. Írtam én még valamikor megfelelő módon bekockázott papíron is programokat, majd lejukasztottam lyukkártyára, mert kevesebb hibát vétettem, mintha kiadtam volna lyukasztani. Sőt még régebben írtam egy nyúlfarknyi programot egy Videoton R10 mérnöki pultjának kapcsolóin is, ha egyáltalán az itt többségben lévő fiatalok tudják, egyáltalán mi is volt az.

Programozóm egyébként van, az nem gond, egy picKIT 3-as.

Olvasva itt az új hozzászólásokat, felmerült bennem még valami. Most az MZ-ket favorizálják? Nekem még MX van, konkrétan egy pic250mx128b. De a projekt paraméterekben minden további nélkül ki lehet választani, és a harmony is azt jeleníti meg.
Lehet, hogy az MX-hez valami más könyvtárat is fel kéne tölteni? Vagy hülyeségeket gondolok?

2 beállítást nézzél meg.
Nagyobb sebességnél a BRGH = 1 -nél állítod be a brg-t(vagyis a baudot),akkor elcseszi a sebességet, BRGH = 0 -nál jó volt.
A másik az URXISEL beállításánál lehet.Itt lehet beállítani,hogy mikor legyen megszakítás,ha 0 ,akkor elméletileg minden bejövő adatnál beruccan a megszakításba.Bár van még pár beállítás,ami befolyásolja,de ez a kettő ami kell .

Az MZ-ket favorizálni egy kicsit erős kifejezés. Valamikor volt egy bejáratott és megszokott fejlesztői környezet (mplab, c8/c30/c32 fordítók), ami kb jól sikerült, mint a windows xp (jó tudom, te utáltad azt is ), de aztán szerencsére kiadták az xc fordítókat, meg az mplab x-et, és azóta már minden rendben: üzemszerűen sza* az egész @Wezuv vette a fáradtságot, hogy szenvedjen a káosszal, megnézze, lehet-e belőle valamit meg is emészteni, vagy 100%-ban az, ami, és nekem eddig annyi jött le, hogy ha neki ezután csak abból szabadna jóllaknia, még ő is aggódik, hogy bizony éhen fog halni, pedig egy egész évet rászánt. Szóval az XC terepen még mindig özönvíz van, és nem csak a 32MZ-ket illetően. Még akkor is, ha 1-2 dologra véletlenül használható valamelyik verziós fejlesztői környezet valamelyik összetevője, fényév távolságban van attól a szitu, hogy azt mondhassuk, bármit töltesz le, bármire használnád, megszokható hibamentességet találsz mindenütt. A helyzet sokkal inkább az, hogy ha megpróbálsz az XC-khez hozzászokni, egyesével pusztulnak el az idegszálaid, és a végén valami olyasmi érzés lesz, hogy már nem fogod tudni a különbséget a "nincsen hiba, mert nem világít a hibajelző" és a "már a hibajelző is hibás, azért nem világít" között

Idézet:
„már nem fogod tudni a különbséget a "nincsen hiba, mert nem világít a hibajelző" és a "már a hibajelző is hibás, azért nem világít" között”

Erre van egy Murphy-törvényem, saját alkotás: Csak hibák léteznek. Ha valami mégis működik, akkor hibás a hiba.

Az MZ minden tekintetben jobb választás. Nem drágább jelentősen, sokkal nagyobb a teljesítménye és a perifériái is fejlettebbek és több van benne. Tokozás ugyanaz, lábkiosztás(mért is lenne) nem azonos. van már olyan széria, ami használható szinten mentes a hibáktól (EF). Az MZ-khez nincs library szerkezetű állomány kiadva, helyette van a harmony. A harmony alap ötlete jó, nagyon jól összefogja a drivereket és rendszer alkalmazásokat, amikhez magad is hozzá tehetsz bármit. (Jelenleg ha szükségem van MODBUS protokollra, vagy a TFT vezérlőmre, akkor beteszek néhány pipát és befordítja az MHC a szükséges kódokat. Igaz, nem teljesen illeszkedik a gyári struktúrába, de ha ezt tudod (mivel magad írtad) abszolut nem okoz problémát). A gyári driverekhez PIC típusonként *.lib állományt rendel, ami nem publikus és bináris, de nem nagyon van bennük hiba. A driverek használatát a help nem túl bőbeszédűen, de leírja. Sok példa van, amiken keresztül gyorsan (lassan) rájön az ember, hogy mi hogy működik. A végén olyan érzésed van, mint ha PC-t programoznál...
Az MX-ekhez még headerek vannak, illetve libeket adtakm ég ki, a régi megszokott módon. Utólag azt mondom a harmony a követendő út, de sokat kell javulniuk. Most várom a következő 2.xx verziót és remélem, hogy még több megoldást kínálnak még kevesebb hibával. Bár azért azt meg kell mondjam, hogy igazi hibát nagyon keveset találtam, sokkal inkább ott volt a probléma, hogy nem ismertem a hogyanokat, mert azért valjuk be van mit megismerni!

A tisztán látás miatt még szeretném jelezni, hogy a 8bites PIC-eket és az 32MX-eket is ugyanúgy lehet programozni a régi Cxx fordítókkal X alatt, ahogyan azt teszem is. Itt csak a PIC32MZ-ről szól a harmony történet leginkább, de az MX-eket már lehet vele kezelni, ha úgy döntünk.

Nekem '96 decemberben, 35 fokban mutatta a batyam a RedHat-et. Amugy a nick-ed mindig is emlekeztetett a /dev/cua0-ra.

De van egy részlet, amit nem értek, hogy hogyan tudná magától egy IDE- legyen az bármilyen is, hogy egy lábat minek kell konfigolni, ha nem mondod meg neki!? A PIC32-kön három feladat van. 1. TRISx, 2. ANSELx, 3. PPS kiosztás. Ezeket a harmony-ben pár kattintással be lehet állítani, ha tudod hol kell. Az eredmény a system_config.h -ban kerül dekarálásra hexa kód formájában és a fordításkor érvényesül.

Mert abbol szarmazik

Előjött egy másik hiba az UART-al kapcsolatosan:
Veszi a karaktereket az UART 115200 bad-dal szépen. Aztán néhány perc múlva egyszer csak, látszólag teljesen magától kiakad valamiért. Az történik hogy mindegy hogy milyen karakter érkezik, mindig ugyan azt a karaktert lehet kiolvasni az U1RXREG-ről. Mondjuk "b"-betűt vagy egy vesszőt vagy amit épp kitalál magának. Onnantól hogy meghülyült, örökké ezt a karaktert adja vissza az U1RXREG. Debuggerben megnéztem az U1STA és az U1MODE regisztereket, ezek tartalma a jó és a rossz állapotoknál is ugyan az. Illetve amikor kiakad akkor előfordul hogy az U1STA regiszter OERR bitje 1 lesz, de csak néha. Kipróbáltam hogy ilyenkor mikor kiakad, a debuggerben manuálisan átállítom az UARTEN bitet nullába majd vissza 1-be. (Ki, majd bekapcsolom a perifériát.) És ettől megjavul! Utána megint megy szépen az UART1 ameddig megint kiakadni nem támad kedve.

Ugyan ebben a PIC-ben az UART3 is fogad üzeneteket ugyan úgy 115200 baud-dal és az nem csinál ilyet. Mondjuk ő jóval kevesebb karaktert kap és ő küld is üzeneteket nem csak fogad az UART1-el ellentétben.

Ott más gond lehet.Valamiért túlcsordul a vevőd.Mik a beállításaid?

Itt van hogy miket állítok be és hogy mi ténylegesen a regiszterek tartalma. Ez a kép még az UART jó állapotakor lett kimentve.
Az UTXEN-t máshol tettem 1-be. (Bár igazából feleslegesen mert nem ad a PIC semmit az UART1-el.)

Kínomban megcseréltem az UART1-et és az UART3-at, de pontosan ugyan azt csinálja az UART3 is.

Na szóval... én eddig nem is tudtam hogy az UART periféria FIFO-ba dolgozik.. Most már tudom.
Az URXDA bit jelezte hogy még van kiolvasni való a FIFO-ból, az OERR pedig azt is mutatta hogy túl is csordult valamikor a FIFO. Az egész függvényt amely a vett karaktereket feldolgozza, beletettem egy do-while ciklusba ahol a feltétel az URXDA bit. Ezt mindkét UART periféria megszakításával megtettem. Így úgy néz ki hogy működik, egyenlőre még nem sikerült kiakasztanom.

Próbáld ki a BRGH = 0 ,és hozzá a brg = 18. Ha jól látom 70 megán megy a procid

Mindenkinek köszönöm a segítséget.

Rászántam egy napot, csináltam egy teljesen tiszta 32 bites linuxot, és telepítettem/töröltem.... telepítettem/töröltem a különböző verziókat. Próbáltam megkeresni a legmagasabb verziókat, amivel még hibátlanul lefordul a 2 évvel ezelőtti projekt. Így végül az MPLAB X a 2.35-ös lett, az XC32 pedig 1.31-es. Utána ugyan ezeket a verziókat telepítettem a napi használatú gépemre, a 64 bites linux alá. A rövid próba során megy, aztán majd meglátjuk.

Találtam egy-két jó doksit is, ezúttal végre sikerült hibátlanul összerakni a LED villogtató programot! Mehetek tovább. Biztosan lesznek kérdéseim, maradhatok itt, vagy tűnjek a kezdőkhöz?

A harmonyt egyelőre hanyagolom. Wezuv fórumtárstól megtudtam, hogy binárissan teszi hozzá amit generál, így pont nem jó arra, amiért érdekelt: hogyan kell beállítani a pineket a kívánt funkcióra.

Ma találtam még egy fejlesztő környezetet, kicsit majd megnézegetem azt is. Találkoztam vele már régebben is, kicsit játszottam is vele, de akkor még pic18-assal. Pinquino a neve, és szintén az Arduino környezetre hasonlít. De anno aztán abbahagytam, mert rájöttem, nem C++, csak sima C, és csak trükkökkel oldották meg, hogy elsőre C++-nak látszott. Fejlesztik, a legújabb verzió alig pár napos. pic18-hoz telepíti az xc8-at, pic32-höz gcc-t használ. Feltelepítettem, de még nem próbáltam.

Valamit félreértettél, nem binárisan teszi hozzá a generált fájlokat, sőt a saját driverek írásakor pont azt teszi be és pont oda, ahová te azt akarod!
Hogy mire kell beállítani egy lábat, azt neked kell tudnod! A harmony pedig tényleg nagyon megkönnyíti a beállításokat és végül a kutyát nem érdekli, hogy hogyan oldja meg a háttérben, ha jól működik. Ha meg érdekelnek a részletek, azt is megtalálod a megfelelő fájlban, amit említettem. Az említett *.h fájl nem bináris, olvasható. A lib bináris, de az nem az amire te gondolsz. A *.h fájlok nem lib-ek, azok headerek! Valami keveredés van a fogalmakban nálad! A library sok forrásfájl együttes értelmezése, ha így veszük, akkor a harmony is tartalmaz libraryt, de például a PIC-hez tartozó egyes hardver leírókat *.lib-be tették, nem *.h-ba mint régen, de vannak *.h állományok is hasonló tartalommal. Ez semmilyen hátrányt nem jelent, mert ezek a lib-ek hibátlannak tűnnek, miért is ne lennének azok, miután régen se ezekben a *.h-kban volt a hiba, ha volt is. Tehát ettől nem kell tartani, nem szükséges belelátni, ezek nem programok, inkább hivatkozások a regiszterekre. Ha PIC32-kkel akarsz foglakozni és nem akarod rá áldozni az életed, hogy meghajtókat írogass minden alap nélkül és hiányos információkkal, akkor nem tudod elkerülni a harmonyt...

Igatad van, tényleg félreértettem. Ezek szerint amit generál, az "c" forrás file?

Mit is akartam megnézni? A régi próbálkozásnál volt, hogy az egyik LED nem villogott, holott ugyan úgy csináltam, mint a többinél. Az egyértelmű volt, hogy a "hardware" jó, mert az mpIDE-vel az a LED is tudta a dolgát. Most megoldódott ez a dolog, mert találtam egy nagyon jó leírást a konfig bitek beállításáról, most úgy látom, ott volt a hiba. Egyelőre most ki akarom próbálgatni a plib lehetőségeit, aztán majd jelentkezem nálad harmony "tanfolyamra".

Ami a fogalmak keverését illeti, azért nagyjából tisztában vagyok velük, inkább csak pongyolán fogalmazok. Mentségemül szolgáljon, amikor én kezdtem programozni, ezeknek a fogalmaknak jó része még nem is létezett. Az első programomat a "mérnöki pult" kulcsain írtam hexában, aztán pár évig assemblereztem. Más hozzám hasonlónál is láttam, hogy az elején kicsit nehezen fogja, fogjuk fel az objektum orientált programozás mikéntjét. Bár C-vel a 90-es években is foglalkoztam valamennyit, tetszett is nagyon, de messze nem használtam ki a lehetőségeit, meg az objektum orientált lehetőséget sem.

A 90-es évek PC-jének hardware-t nagyjából ismertem, volt kis programom, amiben BIOS eljárást is hívtam. Most meg kell ismernem a PIC hardware-ét is, anélkül ez nem megy. De ez nekem már csak hobbi, nem muszáj rohannom!

Miért "erőltetem" a pic32-t, mikor a terveim jó részében "ágyúval verébre"? Árban nem nagy a difi, és csábító a nagyobb teljesítmény.

A C nem objektum orientalt nyelv.