Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ
Szia!
Nem vagyok benne biztos, hogy a
sorból a forditó olyan kódot fordit, ami a flash-ből veszi az adatot. Én igy szoktam csinálni és ez működik is:
Nézd meg a mellékleteket! A hozzászólás módosítva: Márc 7, 2022
Üdv!
A tömb célzott "megcímzésével" nincs baj.
Ez mindig jól működik.
Ezzel van a baj. Ha változót használok a címhez, és a cím nagyobb mint 3 (for loopban i < 4), akkor jön a "szemetelés".
Nos, ez is egy megoldás...
Egyébként van itt mellettem egy olyan AMD K6-os gép, amibe még beletehető 3 db ISA kártya. Cserélhető winchivel: ha akarom XP, ha akarom 98SE.  (Ha sok időm lesz, csinálok DOS-os winchit is, mert miért ne... )De ezek szerint nincs megoldás a MicroChip Studio + AT90S.... problémájára... 
Vmware. Olyan oprendszert futtattok benne, amilyet akartok.
Szia!
Nézd meg az .lss fájlban (ott van, ahol a .hex is) milyen utasitást találsz
Ha nincsen benne olyan, ami a flash-ből olvas (LPM mnemonic [Load Program Memory]) akkor az a hiba.
Nem olvas a flash-ből, ha nincs pgm_read. Írd át a te verziódra és látni fogod. Lpm, ahogy Istvanpisti írta.
Bővebben: Link
Üdv!
Nem általánosságban van bajom a flash-ben tárolt string kiolvasásával. A pgm_read_byte-ot használom és a .lss-ben is megvan a lpm utasítás.
Ez jó ez működik:
Ez nem:
Csak akkor van baj, ha strmx[változó]-t használok for() ciklusban. Most már egyik for() loop sem megy. És az UART-hoz használt egyik rutin is vacakol inicializálás során. Úgy viselkedik, mintha csomagot kapott volna és válaszol. Ez a két jelenség nem lehet hogy arra utal, hogy a címzési hiba van a háttérben? Elfogy a RAM/túlcsordul? A fordításkor 13KB(76%)-os a kihasználtság. SB
Üdv!
A kódomban a változót megváltoztattam, ahol eddig (const unsigned char*)strmx[i] szerepelt, ott most a (const unsigned char*)esp8266_cmd_ptr[i].cmd_ptr vette át a helyét. Megnéztem az lss-filet, amikor működik, és akkor amikor nem. Ezt a filet még eddig nem használtam, vizsgáltam úgy igazából szóval csak tippelek: Úgy vélem, hogy a fordító, a működő kódban, ahol i < 4, ott nem valódi for() ciklust használ, hanem 4x futtatja le a kódot:
Amíg a nem működő kódban, ahol i < 6, ott már valóban egy ciklust hoz létre:
Mellékeltem a két lss-t. Ez nevezhető fordító hibának? SB
Régebben próbálkoztam vele, és volt, amikor típuskonverzió kellett a "változó"-ra, ebben a sorban (vagy a tartalmára!) pl:
DEBUGGER_UART_TXFS((const unsigned char*)strmx[változó]); Oka, hogy a tömb címzéséhez egész szám kellene, talán az se mindegy, hogy byte, integer, unsigned vagy signed a változó típusa. Egyikkel működött, másikkal nem. Ilyen úton indulj el, próbálgatással akár. Vagy használj ideiglenes változót, amibe átraksz értékeket (pl. változó), és ennek az ideiglenes változónak próbálgasd a típusát változtatni (először használhatsz konstantot is). Nekem így sikerült egy komplex dolgot megoldanom, ha jól emlékszem, integer típussal működött csak.
Szia!
Mivel az első két hozzászólásodban nem mutattad meg a DEBUGGER_UART_TXFS függvény belsejét, emiatt gondoltam arra, amire. Most talán annyi ötletem lenne, hogy próbáld meg a ciklusban stringgé alakitani a flashben lévő karaktersorozatot és utána átadni a módositott DEBUGGER_UART_TXFS fv-nek, az alábbiak szerint:
A hozzászólás módosítva: Márc 9, 2022
Üdv!
Nem ment. Ha a USART0_TX_Flash_String()-et módosítom, akkor az AVR az inicializálást sem tudja elvégezni (UART error). Ha strcpy_P()-t használok, a for() ciklusban, akkor egy végtelen dump jön létre, amit a wdt szakit meg, AVR restart-al. Ergo ez is egy rossz végtelen ciklus. Kipróbáltam mindent ami eszembe jutott a esp8266_cmd_ptr[i].cmd_ptr helyén:
Semmi sem jött be. A for() ciklusba még megpróbáltam egy cím összehasonlítás is végezni, valahogy igy:
Semmi. A címek/értékek nem egyeztek. 9000 évvel később: Szóval hosszas szenvedés után észrevettem, hogy az a másik for() ciklus, amire ezt alapoztam, nem PROGMEM-es változót használ.   Az a ciklus azért megy mert a tömb RAM-ban van tárolva nem pedig Flash-ben. Kivettem a változó elől a const és a PROGMEM-et (attribútumnak hívjuk?) és a for() ciklus már megy is....... De mégis miért?  Egy egy csúnya "patch"-mivel így a kívánt tömböm, nem a Flashben van hanem RAM-ban van(ram pazarlás). A szituáció nem hagyott nyugodni, így a MXA_Test()-et átírtam, hogy készítsek róla egy részletes LOG-ot, amit mellékelek. Az eredmény még mindig nem hagy nyugodni. A DEBUGGER_UART_TXFS(string) simán visszaadja mind a Flash-ben, mind a RAM-ban tárolt tömb(tömbben tárolt címek) értékeit. Igen IS-IS. Miért, hogyan? Csak 1 módon nem kapom vissza(az eredeti probléma): Ha a Flash adatot akarok bármilyen ciklussal kiolvasni:
Igen még más ciklusokkal is próbálkoztam, while(i < 3), do while(i < 3)... Még egy tesztet végrehajtok, mégpedig a compilert cserélem le a mostani: avr-gcc (GCC) 11.1.0 innen egy régebbire, 10.2 vagy 9.2-re. Hátha. SB
A stack méretét próbáltad növelni?
Hátha, csak az csordul túl.
Üdv!
Azt nem tudom, hogy kell. Neten is csak annyit találtam, hogy az avr-gcc elvileg alapértelmezetten a maximumot engedélyezi. Hirtelen csak annyit tudtam csinálni, hogy létrehoztam egy másik projektet, amibe csak annyit raktam bele, ami feltétlen ehhez a kódhoz kellett, de a hiba így is fennáll. SB
Szia!
Még az jutott eszembe, hogy ebben
próbáld lecserélni a
Oké nem ez az oka. De játszottam vele egy kicsit és rájöttem.
Ha flash-be teszel string-et, akkor azt a pgm_read_byte-tal tudod kivenni, ezt meg is teszed, viszont te a flash-ben lévő string-ekre mutató pointerek tömbjét is a flash-be teszed. Annak kiolvasása pedig így menne:
Azaz meghatározod az i. elem címét, és onnan pgm_read_word-del kiveszed a flash-ben lévő string-ed címét. Ezek után persze nem tudom megmagyarázni, hogy a
például miért is működik.
Esetleg mert a "strmx[5]" egyenértékű a tárolt elem címével (nem az értékével!) ? Pontosan ezért tudsz egy tömböt túlcímezni, mert a strmx[i++] akár random memóriacímeket is el tud érni! Ezzel szórakoztam sokat. A tömb az alapból mint egy cím működik, sima változónál a változót kell csillaggal címmé változtatni, meg persze a vissza irány is működik. Tömbnél ha átadod, akkor címet adsz át, ha az egész tömböt akarod egy függvénynek átadni, akkor még az elemszám is kell, mert különben a fv. nem tudhatja, mennyi eleme van a tömbnek.
A hozzászólás módosítva: Márc 12, 2022
Nem erről szól a probléma. A stringek és a rájuk hivatkozó 16 bites mutató tömb is flash-ben van tárolva. Ha hozzá akarsz férni a pgm_read_word vagy a pgm_read_ptr jöhet szóba.
Bővebben: Link
Sziasztok!
Egy kávéőrlő elektronikát javítok éppen, amelyben elszállt a mikrovezérlő. A panelon van egy gomb ami nem működik, nem reagál semmire, de egyébként a kontroller működik, csak ez az egy bemenete nem jó, amire a gomb kapcsolódik. A panelon mindent kimértem, csak az Atmel mikrovezérlő lehet a rossz. Egy Atmega 88V kontroller van a panelon. Az volna a kérdésem, hogy kimenthető-e belőle a program, illetve hogyan, és mi kell hozzá? Van egy jó panel is, ha az segít, arról is le lehetne menteni a programot, ha megoldható. A hozzászólás módosítva: Márc 12, 2022
Általában be szokták kapcsolni a kiolvasás védelmet, de egy próbát megér.
Igen, erre én is gondoltam, ha be van kapcsolva, akkor annyi, de mégis, hogyha nem, akkor hogyan lehet kiolvasni a programját, illetve mi kell hozzá?
Ha megnézzük mi is a fordítás eredménye akkor mindjárt minden világos lesz:
Ha közvetlen számmal indexelek, akkor a fordító fordítási időben ezt kiszámolja, és valójában az index által kiválasztott string flash-ben lévő címével hivja fel a soros küldést.
Ha változót használunk indexre, akkor (ez már -O1 optimalizációval) az Y regiszter a strmx első elemére mutató cím a flash-ben (0x0062). Majd ezt növelgeti a ciklusban. De az ld és ldd utasításokkkal nem a flash-ből, hanem a RAM-ból olvassa ki a string címét, ami vak szerencse, hogy a 0..4 indexekre működött.
Itt pedig Y-ban lévő címet (ami a strmx i. elemére mutat) átteszi a Z-be, majd a Z-vel ténylegesen a program memóriából, azaz az strmx-ből olvas az lpm utasításokkal.
Kell hozzá egy programozó, például egy Atmel ICE
Igazad van! Így már megy.
Ami valóban a nagy zavart okozza, hogy ez mitől megy jól for()-on kivül: akár csak ez: Nem találom az eredeti C/C++ vs Pointersverziót, imaging. De, akkor is, miért???
Sziasztok,
Szükségem lenne valakire, aki fel tudna nekem programozni pár darab ATTINY24-et. Van itt rá vállalkozó személy? Jutalom forintban sörben csokiban sütiben
Sziasztok!
Remélem jó helyre rakom fel a kérdést. Van egy ilyen programozóm. A kérdésem az lenne hogy van egy ATmega 16 és ezen a programozón keresztül melyik programmal érdemes felrakni rá a Hex. fájlt. Néztem videót és használ benne még egy ledet meg egy ellenállást, de hogy melyik lábra köti a led polaritást, meg az ellenállás milyen értékű legyen azt nem értettem. Esetleg erről valami infót ha kaphatnék. Megköszönöm!
Köszi!
Néztem még egy pár videót ott 2 db 100nF kondit, és egy 10K ellenállást használ. Nem tudom melyik az aktuális, vagyis melyik a jó. Vagy mindkettő?
Köszi!
Ha jól értelmezem itt úgy van mint a PIC Programozón, hogy a pozitív ,negatívot megkapja az USB-ről? ,vagy külön kell adni neki +; - 5V-ot?
Szerintem ez egyszerűbb mint az avrdude:
https://www.fischl.de/usbasp/ ha megnézed a kapcsi rajzot van egy táp jumper... de mérd ki a te kínai paneleden hová megy a tüskesor 2-ről a kanóc... Vagy ha avrdude, akkor kattogtatós felület: https://blog.zakkemble.net/avrdudess-a-gui-for-avrdude/ |
Bejelentkezés
Hirdetés |
