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!
Sajna nem találtam csak TSOP1736-ot itthon, azzal nagyon nehézkes a távirányítás.?
Nekem meg pont csak 38-asom van.
![]()
Most a próba módosított hex van benne s egy URC22B távival megy, majd ha lesz TSOP1738-am akkor kipróbálom azzal is köszi szépen!!
Sziasztok!
Készítettem egy programozható motorgyújtás vezérlőt. A gyújtás-időzítési értékek a programban vannak tárolva egy táblázatban. Csináltam egy C# programot, amivel az időzítési értékek egyszerűen kiszámolhatóak. Eddig, ha frissíteni akartam az időzítési értékeket, a forráskódban kicseréltem a táblázat adatait, és újraégettem a mikroprocit ISP programozóval. Szeretném fejleszteni az eszközt, és praktikusabb lenne, ha közvetlenül a C# programból tudnám UART kommunikációval írni az AVR-t. Addig eljutottam, hogy ehhez kell egy bootloader az AVR-be, de viszont az homályos, hogy közvetlenül az applikációmmal tudnám-e frissíteni a flasht. Átnyálaztam már megannyi fellelhető infot a neten, találtam kész bootloadereket (blips, fboot, stb), de egyiket sem tudom használni. Tudna valaki segíteni, aki közérthetően elmagyarázná ennek a lépéseit, hogyan kellene megoldani (egyeltalán lehet-e)?
És mi lenne, ha UART-on kommunikálnál a procival a főprogramon belül? Tehát nem az egész flasht írnád újra, csak a táblázatot a program futása közben. A táblázat meg tárolódhatna pl az eepromban.
Ha Atmega168-328-at használsz, akkor ott van az alap Arduino bootloader, és akkor újra tudod írni a flash-t soros portról. De ami neked kell, azt szerintem Ricsi89 ajánlása.
Sziasztok!
Köszönöm a válaszokat, de sajnos az eeprom nem elég, mert rengeteg adatról van szó. Már többen is javasolták a kész bootloadereket, de ebből egy újabb kérdésem született. Ennyire komplikált és nehéz összehozni egy bootloadert, vagy más oka van, hogy mindenki ennek az irányába terel?
Akkor ne az eepromban tárold a táblázatot, hanem a memóriában, ha elfér. Ha nem fér el, marad a pgmspace, 3s akkor valóban újra kell programoznod az iC-t mindig.
A bootloadert is meg kell érteni, nekem bele telne legalább 20 órába, hogy megértsem, kipróbáljam, tesztelgessem. Minek töltsek vele ennyi időt, ha más már megírta, és az nekem tökéletesen használható? Ha a későbbiekben nem lesz megfelelő az Arduino bootloader, akkor is inkább módosítanám, minthogy egyedül írjak egy újat nulláról. Hogy mennyire nehéz, az emberfüggő. Próbáld ki, vagy már az is elég, ha belekukkantasz egy Arduino bootloader-be. Tele van asm parancsokkal... A hozzászólás módosítva: Aug 14, 2015
Sziasztok, a SS lábnak van valami kitüntetett szerepe? Csak mert atmega8-nak azon van az egyik PWM lába ami kéne, viszont jelenleg egy RF vevő modul lóg rajta. Ha egy másik lábat kimenetnek állítok az is ellátja a SS szerepét?
Igen, ha az AVR a master, akkor az SS barmelyik labon lehet. Persze a programot megfeleloen modositani kell hozza.
A hozzászólás módosítva: Aug 14, 2015
Az RC szervoknak elég, sok RC vevő is csak 3.3V-ot ad ki.
"Ennyire komplikált és nehéz összehozni egy bootloadert, vagy más oka van, hogy mindenki ennek az irányába terel?"
Annyira azért nem nehéz. 3-4 részre lesz hozzá szükséged. 1, Belépni a frissítő módba. Egy lábon lévő jumper állapotát ellenőrzöd, ha nincs jumper indítod a fő proramot (0x0000 címen), ha fent van várod a parancsokat a soros porton. Másik megoldás, hogy olvasod a soros portot és ha adott időn belül valami spec adat (pl. 4db 'b' betű, vagy "boot", stb.) érkezik akkor lépsz frissítő módba egyébként szintén ugrasz a 0x0000 címre. 2, Page-enként írni a flash-t. Bővebben: Link A fenti oldalon van egy kis példa program részlet hogyan kell írni (erre keress rá):
Ez a page címre írja a buf tartalmát. Amit hozzá kell tenned az, hogy beolvasod soros porton a címet és page adatait amit ki akarsz írni. Amikor végzett visszaszól soros porton, hogy várja a következő parancsot. 3, Flash olvasása. Opcionálisan bele tehetsz egy olyan parancsot, amivel olvasni tudod a flash-t, ekkor a frissítő programod le is tudja ellenőrizni, hogy azt írta-e ki a flash-re amit kellett. 4, Főprogram indítása. Amikor vége a frissítésnek, akkor ezzel tudsz kilépni a bootloader módból. A lényeg, hogy ez a 4 rész és a soros kommunikáció elférjen a bootloader számára fenntartott helyen. Ha van helyed még bővítheted a funkciókat (pl: eeprom irás/olvasás). A hozzászólás módosítva: Aug 16, 2015
Egy terheléses kérdésem lenne. Atmega328P-vel szeretnék 16 LED-et meghajtani (20 mA per darab). A LED-ek úgy vannak bekötve, hogy 2 pinre 2 LED megy. Ha 'A' pin alacsony, 'B' pin magas, akkor az egyik világít, amikor meg fordított feszültséget kap, akkor a másik. Ha lebeg valamelyik PIN, akkor egyik LED sem gyullad ki. A bekötésből következik, hogy egyszerre max 8 LED világíthat.
Két adat van: egy pin max 40mA lehet, a VCC/GND-n meg max 200mA. Ebben a felállásban 160 mA lehet max, de mind a chipen megy. 160 mA megy a földön és 160 megy a VCC-n is. Túllépem-e a specifikációt, vagy nem? A hozzászólás módosítva: Aug 17, 2015
Nem leped tul, mert sem a VCC-n, sem a GND-nem nem haladod meg a 200mA-t. Es a pineken sem a negyvenet.
Pár tipp...
Váltott LED kapcsoláshoz nem fontos két mcu láb. Egyik LED-et a VCC-re kötöd, a másikat a GND-re és a lábat váltogatod ki1-ki0-bemenet állapot között. Másik, hogy nem feltétlen kell a LED-et 20mA-el hajtani. 10mA-el szinte észrevehetetlen a különbség. Esetleg használj nagyobb fényerejű LED-et és még kisebb áramot, ha kell.
A váltott LED más okból kifolyólag történne.
Ha egy oszlopra felszerelek 4 LED-et, akkor a legegyszerűbb nyákot ebben a felállásban kapom. Ahhoz 4 vezeték elég, nem kell hozzá 5. Persze még átgondolom.
Es hogyan kapcsolod ki mindket LED-et? Mert bemenet allapotban mindket LED vilagitani fog halvanyan.
Merre folyik elég áram, hogy a LED világítson?
A bemenet felé még akkor sem folyik elég, ha a felhúzó ellenállás be van kapcsolva. A két LED pedig egymással szembe van, tehát azok is lezárnak.
A felso LED anodja a tapon van, az alsó LED katodja a foldon. A kozos pont megy a portra. Ha a kozospontra nem teszel semmit, akkor a ket LED siman sorba van kotve. Vagy nem jol ertelek?
Kicsit félrefogalmaztam... de így lesz a legtisztább.
Baloldali, ha különböző nyitófeszültségű LED-ek vannak, jobb oldali akkor ha egyformák.
És ezek mitől világítanak? Hogyan lesz a port láb pozitivabb, mint a táp, vagy negatívabb, mint a fold? Hát záróirányba feszíti elő a LED-eket. Ez így nem világít, az biztos.
Igazad van, a rajz hibás, és a többiben is...
Én az alábbi bekötést használtam és jól működött. Csak nem vettem figyelembe, hogy nálam 3.3V táp volt és kék/piros led volt sorba kötve. Így bemenetnél nem világított, mert a kettő nyitófeszültsége már magasabb volt mint a táp. Bele se gondoltam, hogy azért vannak korlátai ennek a megoldásnak. Köszi a kiigazítást.
Üdv!
Beszereztem egy atmel ICE programozót, de már első alkalommal sem akar működni. Atmega8L-et akarok vele programozni, a device programing ablakban be tudja kérni az azonosítóját, meg tudom nézni a fuse biteket, de amikor rányomok a Start without debugging gombra a buildelés után ezt a hibaüzenetet dobja: "Failed to launch program Error: Failed to start programming session before chip erase with eeprom preserve:Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xcc, expected 0x00 (Unknown status message)" Hogy lehetne működésre bírni? Előre is köszönöm! A hozzászólás módosítva: Aug 18, 2015
Szia!
Köszönöm a felvilágosítást ![]()
A bootloaderben így akarom elérni:
Vicces, de elsőre engem is megetetett a rajz. Olyan logikusnak tűnt, most már látom, hogy tényleg nem menne.
Épp egy ATXMEGA128A1U-t programozok. Van egy érdekes problémám. Dupla pufferelt módban használok két DMA csatornát (külső SRAM-ból 8 byte-os burst-el pufferbe, majd pufferből új címre a külső SRAM-ban; látszólag értelmetlen, de kb. 10%-al gyorsabb mintha egy DMA-val közvetlenül másolnék a két cím között, mivel sok időt spórolok így az ALE1 láb húzogatásán [egyszeresen multiplexelt a cím port]).
Kipróbáltam a repeat módot (192kB-ot másolnék egy tranzakcióval) de úgy tűnik nem működik helyesen ilyenkor (egyszer lefut egy blokknyi, aztán vége; egy DMA esetén viszont tökéletesen működik), találkozott már valaki ilyesmivel? Ha a transaction complete megszakításban újra engedélyezem a dma csatornákat és küldök nekik újraindítást, akkor szépen folytatja a másolást, ahogy kell.
A hozzászólás módosítva: Aug 18, 2015
|
Bejelentkezés
Hirdetés |