Ha a pisztoly pákákra célzol, azok kb 0.5V feszültséggel hajtják a szekundert, de ha szétégetted a szerencsétlent fél órán keresztül, akkor az nem sokat számít.

A pisztolypákáknál az égetés mellett az ESD védelem hiánya is okozhat meghibásodást ( de ez a többi, nem földelt pákánál is előfordulhat, főleg, ha a nyele sem antisztatikus )!

Talán egy PIC-em halt meg(a sok százból) ESD-től, pedig soha nem törődtem a probléma megelőzésével. Igazából nem is tudtam mitől halt meg, talán ettől...

Én is így vagyok vele...

Az IC-t (SMD) cekászos kispákával ültettem be rettenet óvatosan. Csak a külső, panelhez csatlakozó bizbazokat csináltam pisztollyal. Az az érdekes, hogy először minden működött. Aztán nem tudom mi történt. A lényeg, minden flottul működik, csak a 24-es lábán a DAC nem ad ki frekit. Helyette pozitív és negatív 1-mV-os tüsik vannak.
Igazából ezt pickit 3-al lehetne programozni, de nekem csak kettesem van. Így kénytelen voltam meghekkelni a dolgot. Így a medium 1,8V családba sorolta be a pickit 2 programmer progi. A lényeg, másik hex-et töltöttem be, előtte töröltem a tartalmát működés közben, tápfesz alatt. Lehet ez volt a végzetes hiba ?

Sziasztok!

Egy észrevétel.
Én úgy látom azért egyre többen próbálgatják a 32mz/mx/mm családokat.
Ez az apróság nem is inkább memória méret miatt lehet hasznos, hanem ahol nincs idő még egy utasításra se időt pazarolni.

Azt vettem észre hogy pl.: LATAbits.LATA0 = 1 az 3 sor, de ha LATASET = _LATA_LATA0_MASK; az csak 2 sor.
És feltétel tesztelésnél a LATAbits.LATA0 == 1 (vagy 0) az 5 sor, ha LATA & _LATA_LATA0_MASK csak 4 sor.

Tudom kicsit nevetségesen hangzik, de valahol hasznos lehet (és ez az info 3 vagy s optimalizáción tesztelt).

Próbáld beállítani a PK2-n, hogy 5V a táp (ha 5V-os tápot használsz a panelen), mert lehet, hogy nem programozza fel rendesen, ha 1,8-ra korlátozódnak a jelek.

Ha TFT-t vezérelsz pl. akkor minden szösszenet számít, ha gyors kezelést akarsz, ezért nem hangzik nevetségesnek semmiképp, legalább is nekem nem.

Igen a TFT és SD miatt írtam mert ott számít/számíthat az idő, bár a DMA sok mindent orvosol csak ugye a DMA csak 16 bitet tud címezni és az SD-hez lenne igazán hasznos, de ott nem igazán tudom még, hogy a protokollhoz, hogy kapcsoljam a DMA-t.

DMA-t még nem használtam, de az SD sajnos 1 biten lassú DMA ide-vagy oda, 4 bites támogatása meg nincs, ezért SQI Flast gondoltam használni a gyors háttérkép és egyéb objektumok megjelenítéséhez. De még nincs kiforrva...

Kicsit el vagyok keseredve. Röviden: A Harmony TCP/IP webszerver stack-be próbálom integrálni a TFT rutinjaimat. Leírtottam a harmony-s konfigokat és a project legelejére betettem a sajátomat. Minden lefordul, de "természetesen" nem fut a kódom. Egyik függvényt lépésenként hajtanám végre, de azt látom, hogy a sorok nem egymás után hajtódnak végre, hanem össze vissza! Lépeget, csak nem sorban. A változók értékei nem látszanak. Természetesen az én kódomban minden sorban megy és vannak a változóknak értékei. Nem tudom mit és hogyan állítottak be a projectben a nagyszerű microchippék, de ez egyszerűen vicc kategória. Az optimalizáció a két projecben egyébként azonos szintű és szinte semmi eltérés a project setup-ban(a heap size van megadva, de az beállíottam a másikban is és fut). Ilyenkor gondolom azt, hogy jobb lett volna más szakmát választani (vagy másik mikrochippet inkább?). Na mindegy, ez van, gondolom nem fogtok tudni segíteni...

Milyen optimalizáció van beállítva 0-ás felettinél nálam is össze vissza ugrál debug-ban?

Idézet:
„gondolom nem fogtok tudni segíteni...”

Csak együttérezni !

Igazad van, 1-es volt beállítva a gcc ++ alatt! Fut a kódom is! Köszi! Hogy hibázhat ekkorát az optimalizálás?

Szerintem nem hibázik..
Csak nem az fordul amit te látsz, mivel alapvetően elég szemetelősen fordít 0 optimalizációban és felette azért nem látsz rengeteg változót, mert az nem "új terület a RAM-ból", hanem az egy Akkumulátor a 32-ből. Amiért össze vissza ugrál szerintem azért van mert a valóságot próbálja visszaadni, biztos így fut disassembly-ben a kód.

Oké-oké, de nem fut a kódom a vason csak 0 optival!?

Egyébként most hepi van, mert vissza engedélyeztem a TCP/IP stack-et a TFT mellé és elsőre úgy tűnik zavartalanul futnak egymás mellett. Nem erre számítottam.

Még annyit, hogy 0-s opti mellett a kód mérete kétszer akkora...(200k helyett 400). Próbálom más optikkal, hátha valamelyik jó lesz. Ha nem, akkor viszont nem tudom min kéne módosítanom, hogy ne törjön bele a bicskája...

Viszont az létezhet, hogy optimalizációval nem működik a program egyszer egyszer előfordult nálam, de ez viszont tényleg a szeretett Microchip-ünk hibája valamint, hogy a 32 bit meg a c++ még nem egy agyon használt dolog.

Most a v1.40 van fenn, megpróbálom az v1.42-t...

Természetesen fogadd együtt érzésemet. Ha úgy alakul, hogy jön ki ethernettel is normálisan szerelt mz board emberi áron (ami továbbra sem létezik), azzal meglepem magam karácsonyra, én is beleásom magam a harmony-ba, és utána egy kicsit többet fogok tudni segíteni hasonló kérdésekben. Tudom, sovány vigasz, mert az még hónapok kérdése, de jelenleg csak annyi vígaszt tudok nyújtani. Apropó a harmony nem sorfolytonos végrehajtású, hanem multitaszkos. Ott bármikor bármi beszakíthat timer alapon is, a végrehajtási sorrendet felejtsd is el.

Előre is örülök, hogy lesz még valaki, aki MZ-vel fejleszt!
Egyelőre nem kavar be a multi task(nem is vélem felfedezni a jelenlegi szálon), pedig a TFT-t kb. 20MHz-el tolja a PMP. Most próbáltam a legújabb XC32-vel, másképpen rontja el, mint eddig. Csak 0 opti-val működik továbbra is. Most hozzá illesztem még a touch, RTC, még egy UART, EEPROM részeket és egy SQI flast és ha együtt tud működni minden, akkor nyugodt leszek. Talán mégy egy SPI SD és egy USB is kéne, de ezt csak teszt szinten, mert igazából TCP-n akarok modbuszt hasznáni majd, nem kell az USB. Köszi a szándékot előre is!

A Harmony-s körbe én is egyszer be akarok szállni a Graphics Composer miatt, háta egyszer VS hasonlóan lehet majd fejleszteni, de sajna még az életerő nem vitt rá, hogy szívjak vele.

A harmony-ban az a gond, hogy sok az infó. Ha van idő rá, akkor egyre világosabb. Sokkal könnyebben haladtam volna, ha valaki már előttem járt volna! Most állok neki az I2C, touch, RTC és EEPROM rutinok átlapátolásának, remélem nem akadok el nagyon...
Van egy módszer, ami lehet, hogy csak nekem új, ez a Package. Ezzel sikerült "saját" projectet leválasztanom a harmony-tól. Igaz, még nem uninstalláltam a harmony-t, lehet, hogy szükség van rá, majd ezt is kipróbálom (rengeteg a hivatkozás, még nem értem rá átböngészni). Jó lenne mozgatható projectet létrehozni.

Próbálgattam a harmony-kat. 1.07.01 fut a kódom, 1.08 nem fut, a 2.0béta nem is működik, mert hibákkal indul el az IDE-ben(3.40). Bámulatos!

Múltkor bele akartam én is fogni asszem a 1.40-es IDE nem megy harmonyval legalábbis a 2.0 bétahoz 1.34-et írtak, de nekem a 1.40-el nem is lehet projektet létrehozni.

Sziasztok!

Egy elég érdekes problémába futottam bele. Tegnap újratelepítettem a gépemet és az mplabX-et valamint az XC16-ot. A programjaimat assemblyben írom és amikor egy egyszerű villogó programját kezdtem megírni és tesztelni nem akart menni. A gond a delay szubrutin hívásával van. Csatoltam egy képet ahol a jobb oldali programkód működik, de a bal oldali nem és nem tudom hogy hol lehet a probléma. Valaki találkozott már ilyen problémával?

Ugye az a felhasznált call / return páros összeillő utasítások a vermet rendbe rakni?

Lépésenként hová ugrik a végrehajtás? Mit jelent egyébként az, hogy nem működik?

Megfelelően inicializáltad a vermet? (W15, SPLIM)

Sziasztok!

A verem inicializálása volt a gond. Elolvastam az adatlapban a veremről szóló részt ahol megtaláltam hogy inicializálni kell, aztán rátaláltam az asm linker user manualban hogy hogyan is kell azt. Azután már működött is a program.

Köszönöm a segítséget.

Pár tipp:
- Rövid ugrásokhoz használj inkább RCALL utasítást!
- Ha lehet, RAM helyett regisztereket használj változók tárolásához!
- A sok egyedi globális címke helyett használhatsz lokális címkéket.
- A címkéket nem kell külön sorba írni, úgy tömörebb a kód.