Fórum témák

» Több friss téma
Fórum » AVR - Miértek hogyanok
 
Témaindító: pakibec, idő: Márc 11, 2006
Témakörök:
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
Lapozás: OK   684 / 837
(#) lajos1969 válasza Balázs hozzászólására (») Aug 13, 2015 /
 
Szia!
Sajna nem találtam csak TSOP1736-ot itthon, azzal nagyon nehézkes a távirányítás.?
(#) Balázs válasza lajos1969 hozzászólására (») Aug 13, 2015 /
 
Nekem meg pont csak 38-asom van. De valószínűleg ez lesz a baj. Esetleg próbálgasd meg más távirányítókkal.
(#) lajos1969 válasza Balázs hozzászólására (») Aug 13, 2015 /
 
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!!
(#) yoman917 hozzászólása Aug 13, 2015 1 /
 
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)?
(#) Ricsi89 válasza yoman917 hozzászólására (») Aug 13, 2015 /
 
É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.
(#) Kovidivi válasza yoman917 hozzászólására (») Aug 13, 2015 /
 
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.
(#) yoman917 válasza Kovidivi hozzászólására (») Aug 14, 2015 /
 
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?
(#) Kovidivi válasza yoman917 hozzászólására (») Aug 14, 2015 /
 
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
(#) k3gy3tl3n hozzászólása 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?
(#) killbill válasza k3gy3tl3n hozzászólására (») Aug 14, 2015 /
 
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
(#) k3gy3tl3n válasza killbill hozzászólására (») Aug 14, 2015 /
 
Köszönöm a választ! Szerencsémre be tudtam tenni egy atmega328-at az atmega8L helyett, ennek már 6 pwm lába van és ez is eljár 3.3V-ról, az lesz a következő érdekesség, hogy a servo motornak elég lesz e a 3.3V-os PWM magas szint (a servo tápja 5V-lesz).
(#) killbill válasza k3gy3tl3n hozzászólására (») Aug 15, 2015 /
 
Az RC szervoknak elég, sok RC vevő is csak 3.3V-ot ad ki.
(#) k3gy3tl3n válasza killbill hozzászólására (») Aug 15, 2015 /
 
Szuper köszi!
(#) dc001 válasza yoman917 hozzászólására (») Aug 16, 2015 /
 
"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á):
  1. void boot_program_page (uint32_t page, uint8_t *buf)
  2. {
  3. ...
  4. }

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
(#) csabeszq hozzászólása Aug 17, 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
(#) killbill válasza csabeszq hozzászólására (») 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.
(#) vzoole válasza csabeszq hozzászólására (») Aug 17, 2015 /
 
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.
(#) csabeszq válasza vzoole hozzászólására (») Aug 17, 2015 /
 
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.
(#) killbill válasza vzoole hozzászólására (») Aug 17, 2015 /
 
Es hogyan kapcsolod ki mindket LED-et? Mert bemenet allapotban mindket LED vilagitani fog halvanyan.
(#) vzoole válasza killbill hozzászólására (») Aug 17, 2015 /
 
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.
(#) killbill válasza vzoole hozzászólására (») Aug 17, 2015 /
 
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?
(#) vzoole válasza killbill hozzászólására (») Aug 17, 2015 1 /
 
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.

1pinLED.jpg
    
(#) killbill válasza vzoole hozzászólására (») Aug 17, 2015 /
 
É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.
(#) vzoole válasza killbill hozzászólására (») Aug 17, 2015 / 2
 
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.

1pinLED.jpg
    
(#) Gj hozzászólása Aug 18, 2015 /
 
Ü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
(#) yoman917 válasza dc001 hozzászólására (») Aug 18, 2015 /
 
Szia!
Köszönöm a felvilágosítást . A sejtésem akkor jó, mert az 1. és 4. rész kész van, a 2.-al épp küzdök. Tehát figyelek egy lábat, ha magas szinten van akkor boot, ha alacsony, akkor 0x0000-ra ugrik. A linket amit küldtél már többen javasolták, de valami nem világos. Két programot csinálok egyszerre, egyik a boot, a másik pedig a főrész. Ezeket a végén összefűzöm (srec_cat). Kezdésként egy változó értékét szeretném megváltoztatni. Ehhez a főprogramban egy változót egy meghatározott helyre deklarálok, így:
  1. const uint8_t appint __attribute__ ((section (".MySection")))=123;
Az atmel studioban beálítottam, hogy egy a 0x0400 címre mutasson.
A bootloaderben így akarom elérni:
  1. ISR(USART_RX_vect)
  2. {
  3.         char receivedData=USART_Receive();
  4.         buffer[0]=atoi(receivedData);
  5.         USART_Transmit(receivedData);
  6.         boot_program_page(0x0400,buffer);
  7. }
UART-on keresztül egy számot küldök, azonban a program nem csinál semmit. A főrészben ellenőrzésképpen kiíratom az értéket, de nem ír semmit. Itt elakadtam, mert egy az, hogy nem működik a program, a másik az, hogy teljesen összezavarodtam ennek a függvénynek a működésében. Elvileg működhetne ilyen logikával?
(#) rolandgw válasza Gj hozzászólására (») Aug 18, 2015 / 1
 
?
(#) csabeszq válasza vzoole hozzászólására (») Aug 18, 2015 /
 
Fantasztikus ötlet.
(#) csabeszq válasza csabeszq hozzászólására (») Aug 18, 2015 /
 
Vicces, de elsőre engem is megetetett a rajz. Olyan logikusnak tűnt, most már látom, hogy tényleg nem menne.
(#) csatti2 hozzászólása Aug 18, 2015 /
 
É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.
  1. void copy_bitmap_buffer_to_screen_buffer_dbuff(void)
  2. {
  3.         // Reset transaction counter
  4.         _dmaCounter = 0;
  5.         // Set transaction number
  6.         _dmaTransactionCount = 1;
  7.         // Make sure DMA controller is enabled and in double buffered mode for channel 0 and 1
  8.         // Data transfer cycle: 8 bytes from external SRAM (channel 0) to buffer, then 8 bytes from buffer to new address in external SRAM (channel 1), start again
  9.         DMA.CTRL |= DMA_ENABLE_bm | DMA_DBUFMODE_CH01_gc;
  10.         // Reset and disable DMA channel 0
  11.         DMA.CH0.CTRLA = 0;
  12.         DMA.CH0.CTRLA |= DMA_CH_RESET_bm;
  13.         // 8 byte bursts with repeat mode
  14.         DMA.CH0.CTRLA = DMA_CH_BURSTLEN_8BYTE_gc | DMA_CH_REPEAT_bm;
  15.         // Keep source address between transaction (walk through the SRAM), increment source address
  16.         // Destination address restored after each burst, increment destination address
  17.         DMA.CH0.ADDRCTRL =  DMA_CH_SRCRELOAD_NONE_gc | DMA_CH_SRCDIR_INC_gc | DMA_CH_DESTRELOAD_BURST_gc | DMA_CH_DESTDIR_INC_gc;
  18.         // No trigger source (trigger by software)
  19.         DMA.CH0.TRIGSRC = 0;
  20.         // Transfer 3 * 64000 bytes per transaction
  21.         DMA.CH0.REPCNT = 3;
  22.         DMA.CH0.TRFCNT = 64000;
  23.         // Source address is bitmap buffer
  24.         DMA.CH0.SRCADDR0 = BMP_BUFFER & 0XFF;
  25.         DMA.CH0.SRCADDR1 = (BMP_BUFFER >> 8) & 0XFF;
  26.         DMA.CH0.SRCADDR2 = BMP_BUFFER >> 16;
  27.         // Destination address is intermediary buffer
  28.         DMA.CH0.DESTADDR0 = (uint16_t)_dmaDoubleBuffer;
  29.         DMA.CH0.DESTADDR1 = (uint16_t)_dmaDoubleBuffer >> 8;
  30.         DMA.CH0.DESTADDR2 = 0;
  31.        
  32.         // Reset and disable DMA channel 1
  33.         DMA.CH1.CTRLA = 0;
  34.         DMA.CH1.CTRLA |= DMA_CH_RESET_bm;
  35.         // 8 byte bursts with repeat mode
  36.         DMA.CH1.CTRLA = DMA_CH_BURSTLEN_8BYTE_gc | DMA_CH_REPEAT_bm;
  37.         // Enable interrupt for transaction complete (start a new transaction if necessary)
  38.         DMA.CH1.CTRLB = DMA_CH_TRNINTLVL_LO_gc;
  39.         // Reload source address after each burst, increase source address
  40.         // Keep destination address between transaction (walk through the SRAM), increment destination address
  41.         DMA.CH1.ADDRCTRL =  DMA_CH_SRCRELOAD_BURST_gc | DMA_CH_SRCDIR_INC_gc | DMA_CH_DESTRELOAD_NONE_gc | DMA_CH_DESTDIR_INC_gc;
  42.         // No trigger source
  43.         DMA.CH1.TRIGSRC = 0;
  44.         // Transfer 3 * 64000  bytes per transaction
  45.         DMA.CH0.REPCNT = 3;
  46.         DMA.CH1.TRFCNT = 64000;
  47.         // Source address is intermediary buffer
  48.         DMA.CH1.SRCADDR0 = (uint16_t)_dmaDoubleBuffer;
  49.         DMA.CH1.SRCADDR1 = (uint16_t)_dmaDoubleBuffer >> 8;
  50.         DMA.CH1.SRCADDR2 = 0;
  51.         // Destination address is screen buffer
  52.         DMA.CH1.DESTADDR0 = SCREEN_BUFFER & 0XFF;
  53.         DMA.CH1.DESTADDR1 = (SCREEN_BUFFER >> 8) & 0XFF;
  54.         DMA.CH1.DESTADDR2 = SCREEN_BUFFER >> 16;
  55.         // Enable DMA channels
  56.         DMA.CH0.CTRLA |= DMA_CH_ENABLE_bm;
  57.         DMA.CH1.CTRLA |= DMA_CH_ENABLE_bm;
  58.         // Start transactions
  59.         DMA.CH0.CTRLA |= DMA_CH_TRFREQ_bm;
  60.         DMA.CH1.CTRLA |= DMA_CH_TRFREQ_bm;
  61. }
A hozzászólás módosítva: Aug 18, 2015
Következő: »»   684 / 837
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem