Ez lesz. De szerintem nem úszom meg hogy 32 bitesre váltsak, vettem is már egy PIC32MK1024GPD064-et.

a 32mx1-2 családokban nincs 5 UART, illetve DIP tok nálam szóba sem jöhet! Ezen a panelon kellene lecserélnem a 64 lábú TQFP-s PIC-et, itt szóba nem jöhet a DIP tok.

Nem igazán... Akkor azt is külön programozni kellene és messze nem lenne olyan kényelmes a fejlesztés mint így:

Készíts egy string táblát a debug üzenetek szövegeivel és hozzá egy rutint, ami az indexével megadott szöveget írja ki az üzenetbe.
Előny:
- ugyan az a szöveg nem foglal többször helyet magának (pa-electronika.hu),
- a paraméter átadáskor a szöveg nem másolódik a stack -re.
Hátrány:
- egy kicsit bonyolultabb lesz a debug_kuldes() eljárás.

A 32mk családdal egyenlőre óvatosan, nagyon új darabok még. Egyéb iránt, én nem néztem meg az adatlapjaikat. Lábról lábra kivezetés-kompatibilis a dspic-el?

Én meg arra gondoltam hogy létrehozok egy külön C fájlt amelyben karakterláncokat hozok létre a programmemóriában. A karakterlánc-konstansokat (nem is tudom helyes-e ez a megnevezés) melyek jelenleg a függvények bemeneti paraméterei közt aposztrófok közt szerepelnek, kicserélem az újonnan létrehozott C fájlban lévő megfelelő const char tömb címére.
Azaz, a C fájlban:

Az eredeti fájlban pedig:

Igen aggódom is egy kicsit... Természetesen nem lábkompatibilis, nem tudom egy az egyben kicserélni őket. Át kell terveznem a panelt hozzá, de ez más okokból amúgy is esedékes.
Az errata-ját néztem, vannak benne durva dolgok (sleep nem működik és nincs is rá megoldás!), de azért remélem hogy jó lesz. UART-okat, I2C-ket, SPI-t és két OC-t használok PWM-re, ezekkel talán nem lesz gond.

Miért az i2c? Két válasz is van, bár nem egyforma súlyúak.
1. Szeretnék szépen sorban menni, már megvan a karakteres LCD kezelés, most az I2C-vel játszadozom, majd jöhet az SPI, grafikus kijelző, érintő panel....
2. Van olyan tervezett projektem, amihez csak I2C-s megoldás van, egy IC-s FM rádió, Arduino Nanoval már megy. Ez utóbbinál használtam egy óra IC-t, hömérséklet szenzort, EEPROM-ot tartalmazó kis gyári modult, ennek EEPROM-jával szerencsétlenkedek most.
+1. Érdekesnek találom a Microchip ERAM-ját, és ez egyelőre ha jól tudom, csak I2C interface-szel elérhető.

Egyelőre megoldom a dolgot az egy byte írás/olvasás ciklusba rakásával, aztán majd talán valamikor később visszatérek a dologhoz, hátha később találok működő megoldást.

Én inkább PIC32MX470F512H választanám van benne PPS, USB 4 UART ha jól láttam láb kompatibilis (ha nem kell usb a 370-es kell). Az errata kicsit hosszú, de túlélhető.
Vagy a másik lehetőség ha mész az MZ felé abból az EFx sorozat egész tűrhető.
Én eddig egy 32MZ2048EFG100-at használtam minden működött benne. A kvarc-ot leszámítva mert ezekhez, ha nem internal clock-ot (FRC) használod akkor EC-ben megy csak vagy 8,12,24 MHz kvarcal egy adott revízió fölött viszont itt ugrik lábkompatibilitás, viszont ebbe annyi string-et írsz amennyit akarsz .

A szintaktikát ne kérjétek számon rajtam, mert nem tudok C-ben programozni, de azért remélhetőleg érthető, mit javasolok.)

Javítás: ERAM = EERAM

Nekem mindenképpen 5db UART kell, a PIC32MX470F512H-ban pedig csak 4db van ezért nem jó számomra. A PIC32MX5...-ös sorozattól felfelé van ennyi (6db) UART. Ezekben viszont sajnos nincs PPS.

Amit vettem PIC32MK1024GPD064-nél is van gond az elsődleges oszcillátorral az errata szerint, de azt írja van rá megoldás: az OSC2 lábbal sorba kell kötni egy ellenállást.

Uartból ha nem kell túl gyors, azt szoftveresen is meg lehet csinálni.

Bogarászom az XC32 doksiját. A következő két információt egymás után találtam:
ISO Standard: "The definitions for __DATE__ and __TIME__ when respectively, the date and time of translation are not available (C90 6.8.8, C99 6.10.8)."
Implementation: The date and time of translation are always available.

De sehol nem sikerült ráakadnom, valójában hogy lehet elérni a fordítás dátumát és idejét. Próbáltam keresni az MPLAB-X users guide-ban is. Tud valaki segíteni?

MpLab megoldás:
Egy programmal kell írni egy include állományt, amiben az időt és a dátumot hordozó szimbólumokat a gép idejéből definiáljuk. Ezt a programot beállítani pre build command -nak, az include állomány hivatkozását beletenni a kérdéses forrásokba. Eztán lehet használni a szimbólumokat.

Kössz!
Értem a menetet, de ehhez még sokat kell bogarásznom, hogy meg is tudjam csinálni. Eddig ilyennel nem foglalkoztam.

Es kiprobaltad, hogy egyebkent a __TIME__ es __DATE__ mukodik-e? Mert linux-on nativ gcc-n ez mukodik. Azt csinalja a fordito, mintha ez lenne a forrasodban:
Termeszetesen az aktualis forditasi datummal, idovel. Szoval, ha egy printf-be beirod:
akkor ki is irja.

A DS1307-hez igyekszem megírni a kezelést, mintának az Arduinohoz lévő class-t vettem. A __DATE__ és __TIME__ fordítási hibát okoz ('__DATA__' was not declared in this scope), azért is keresgéltem a doksiban.

A előzőleg kapott megoldás használhatónak tűnik, az include file elkészítése egy scripttel nem tűnik bonyolultnak, csak aztán nem tudom, hová, és hogyan kell befűzni a scriptet, hogy a fordítás elején lefusson.

DATA vagy DATE?

__DATE__ és __TIME__ a sztenderd C-ben a fordítási időt adja. Az XC-kben nincs ilyen a doksi szerint. Az Arduino példa programban ha nem megy az RTC, akkor ezt alapján beállítja.

Arra próbáltam rávilágítani, hogy DATE helyett DATA -t írtál, szerintem ezért hisztizik a fordító, nem? Nálam lefordul a __TIME__ és a __DATE__ XC16 1.26- ban, bár hogy mi lesz az eredmény, azt nem próbáltam ki.

Jogos az észrevétel, az egyik hozzászólásomban valóban elírtam. De a fordító a helyesen írtra sikítozott. Arduinóban működő forrást próbáltam fordítani, sok más hiba mellett kidobta a __DATE__-t is, meg a __TIME__-ot is. Utána kezdtem keresgélni a doksiban, és találtam a fentebb írt két infót erre vonatkozóan.

Hátha segít: A "C:\Program Files (x86)\Microchip\xc32\v1.44\bin\bin" könyvtárban található "pic32mx-gcc-4.8.3.exe" fájl tartalmazza a __DATE__ és __TIME__ karakterláncokat.

Vannak a mindenféle 1 tokos wifi kapcsolatok, mint például az esp8266 és társai. Amiket én találtam mind 2.4 ghz-es sávban dolgoznak csak. Van 5 ghz-es kütyü is?

Direktben nem segített, tekintve, hogy lassan 8 éve - mióta nyögdíjas vagyok - nem bosszantom magam window$-al. De mégis segített, mert futtattam egy keresést, és kiderült, jó néhány file-ban szerepelnek. Ezért aztán nekifutottam még egyszer.

Mea culpa, hibáztam. Az eredeti próbában (Arduinos DS1307 library) valóban kidobta a fordító, hogy ezek nincsenek deklarálva. De számtalan más hiba is volt, nem voltam elég figyelmes.
A lényeg: ismeri a fordító!

A másik gubancom - több byte folyamatos olvasása/írása EEPROM-ba - szintén megoldódott. Kénytelen voltam vele foglalkozni, mert a következő terv a DS1307 RTC kezelése a doksit böngészve szintén igényli több byte folyamatos írását/olvasását, és még nem tudom, ott is lesz-e hasonló gond.

A megoldás - hátha másnak is segít - egy neten talált példaprogram alapján jött. Az EEPROM-ba történt írás után volt egy kis várakozás (10 msec), a comment alapján, hogy az EEPROM "megnyugodjon". Kipróbáltam a folyamatosan olvasott byte-ok olvasása között is, és bevált. A folyamatos írásnál is beraktam, mert az e nélkül hol ment, hol nem, határeset lehet, a várakozással működik mindig. A várakozási idő hosszával majd még kísérletezem.

Hali!
szerintem az eeprom dokujában le van írva mennyi időt kell várni, mennyi idő alatt hajtja végre az írást...
vagy használj FRAM-ot, abba döntheted az adatot, nem kell várni, "korlátlanszor" írható

Jó tipp! Erre látod nem is gondoltam, majd nekiugrok a doksinak.
De a tapasztalat azt mutatta, nem csak az írás után kell várni, hanem több byte folyamatos olvasásakor az egyes byte-ok olvasása közt is. Nagyon "nyugtalan" eszköz lehet ez az EEPROM, hogy folyton "nyugtatni" kell!

Ezt az FRAM-ot nem ismerem. Nem az EERAM-ról van szó? Ha igen, már van itthon, készülök annak a kipróbálására is.

Milyen EEPROM-rol van itt szo? Mert en meg eletemben nem lattam olyat, amire olvasaskor varni kellett volna, pedig talalkoztam eleg sokkal. Az I2C-s EEPROM-ok irasanal sem kell varni a byte-ok kozott, csak azutan, hogy a STOP kiment. Ugyanis az EEPROM csak akkor kezdi irni az addig megkapott adatokat.

Ez egy kész "gyári" modul, van rajta egy DS1307 RTC, egy Atmel 24C32 4k-s EEPROM, és helye egy DS18B20-nak, amit én tettem is rá. Én nem itt vettem, de így néz ki.

Én most vacakolok először EEPROM-mal, könnyen lehet, hogy nem tökéletes a programom. Jó pár mintát kerestem a neten, de alapvetően a Microchip oldaláról letöltött - egy byte kiírása, majd visszaolvasása - mintával indultam el. Nem működött helyből. Nem volt benne várakozás az írás után, és a visszaolvasáshoz nem címzett, csak olvasott egy byte-ot. Vagyis az írt utánit olvasta, és hasonlította ahhoz, mit írt ki. Több byte folyamatos olvasására nem volt benne minta, azt a netről keresett minták alapján kínlódtam össze.
Tehát nem biztos, hogy "tökéletes" a programom, de legalább működik. Az nem lehet, hogy az Atmel gyártotta nem egészen úgy működik, mint a Microchip gyártotta EEPROM?