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   804 / 837
(#) rolandgw válasza glaci hozzászólására (») Máj 4, 2019 / 2
 
Gombhoz a kabátot? Pár száz forint egy AVR.
(#) vilmosd válasza glaci hozzászólására (») Máj 5, 2019 /
 
Keil Itt nezz szet
(#) szabi95 válasza rolandgw hozzászólására (») Máj 5, 2019 /
 
Köszi!
Ha a main-be írom akkor megeszi a fordító, egyébként nem. Lehet ez volt a gond azzal amit én találtam, hogy header fájl-ba akartam írni. Hogy hogy működik azt nem igazán értem. Laboron nem foglalkoztunk struktúrákkal meg makrókkal, csak a régi jegyzetben volt egy nagyon rövid rész róla(azt is tegnap olvastam el ).
(#) rolandgw válasza vilmosd hozzászólására (») Máj 5, 2019 /
 
2 kB limit. Van amire az is elég.
(#) glaci válasza vilmosd hozzászólására (») Máj 6, 2019 /
 
Köszi, már nézegettem!
(#) glaci válasza rolandgw hozzászólására (») Máj 6, 2019 /
 
Szia !
Igazad van. Bár nem kell feltétlen elmenni a lehetőségek mellett. Korábban elkezdtem pic-et programozni, mert ahhoz a neten jobban hozzáférhetőbb volt a dokumentáció, ill. a tananyag. Eleinte, pascalban programoztam, mivel azt már korábbról ismertem, aztán áttértem c-re, mert abból a pic-hez több anyag volt megtalálható. Most meg elérkezettnek láttam, hogy elővegyem ezeket az mcu-kat, mert elég sok van belőlük és nem nagyméretű eszközöket szeretnék belőlük, csak szinte játékokat csinálni. Ezért gondoltam velük foglalkozni. A hozzászólásodból viszont nem tudtam kiolvasni a segítő szándékot.
(#) rolandgw válasza glaci hozzászólására (») Máj 6, 2019 /
 
Idézet:
„A hozzászólásodból viszont nem tudtam kiolvasni a segítő szándékot.”

Szia!
Pedig segítő szándékkal írtam. Az AVR-hez minden ingyenes és korlátlan, nem kell huncutkodni a törésekkel, próbaidőkkel. A 8051-nél másik lehetőség, hogy összelapátolsz egy fejlesztőkörnyezetet SDCC-vel, vagy letöltesz valami készet. Régebben eléggé megbízhatatlan volt, de folyamatosan fejlesztik. Egy próbát talán megérne.
(#) CHZ hozzászólása Máj 10, 2019 /
 
Sziasztok!

ATMEGA 8515 szívat, újabb programmal szeretném feltölteni, de nem sikerül.
Törlése sem működik, képen látható hibaüzenet jelenik meg.
Proci működött, ezért nem értem.
Más típusú AVR rel próbálva az égetőt, nincs probléma.
Mi okozhatja, meghibásodhatott az IC, működő panelből vettem ki.?
A hozzászólás módosítva: Máj 10, 2019
(#) rolandgw válasza CHZ hozzászólására (») Máj 10, 2019 /
 
Jó lenne tudni a fuse bit beállításokat, amivel fel lett programozva.
10k ellenállást tettél a Reset - táp közé?
Az ISP clock 1/4-e lehet az AVR clock-nak.
Nem külső kvarcról ment a panelben?
Az a baj az extreme burner-el, hogy az AVRDUDE-t használja, de sokszor elmaszatolja a lényeget.
Ez megbízhatóbb, szerintem.
A hozzászólás módosítva: Máj 10, 2019
(#) CHZ válasza rolandgw hozzászólására (») Máj 10, 2019 /
 
Köszönöm a válaszod!
10k bent van, fuse bit képen látható.
Extreme burner eddig jól kezelte, sokszor égettem ezt a procit is.

Image 6.png
    
(#) rolandgw válasza CHZ hozzászólására (») Máj 10, 2019 /
 
Ezen a képen nem látom. A low/high fuse bájtok pontos értéke kellene, két hexa szám. Ezt elvileg tudnod kellett az első felprogramozásnál.
(#) CHZ válasza rolandgw hozzászólására (») Máj 10, 2019 /
 
Így volt beállítva.
Letöltöttem a javasolt programot, még ismerkednem kell vele, kipróbálom ezzel is.

Image 7.png
    
(#) rolandgw válasza CHZ hozzászólására (») Máj 10, 2019 /
 
Ez a gyári default érték is.Ha ez lett visszaírva, akkor belső 1MHz-el megy, 250 kHz lehet a max. ISP clock. Ezen tudsz állítani a burner-ben?
(#) CHZ válasza rolandgw hozzászólására (») Máj 10, 2019 /
 
Megpróbálom. Rossz fuse bit beállítással kizárhatom a programozás lehetőségéből:
(#) kalmi.kalmi válasza CHZ hozzászólására (») Máj 10, 2019 /
 
Tec-halott lehet az AVR ! Én is jártam így nem egyszer és nem egyféleképp.
(#) rolandgw válasza CHZ hozzászólására (») Máj 10, 2019 /
 
Itt nézd meg. Az SPI-t ne kapcsold ki!
(#) kalmi.kalmi válasza rolandgw hozzászólására (») Máj 10, 2019 /
 
Én is ezt használom, hasznos oldal !
(#) CHZ válasza kalmi.kalmi hozzászólására (») Máj 10, 2019 /
 
Gondoltam rossz beállítás miatt lezártam a procit, de már én is arra tippelek, hogy hibás (kínai). Van még 2db azokkal nem volt problémám.
A hozzászólás módosítva: Máj 10, 2019
(#) kalmi.kalmi válasza CHZ hozzászólására (») Máj 10, 2019 /
 
Nekem a legutóbbi hibám az volt, hogy lassúra vettem az avr belső oszciját, bent hagytam a 8-as osztást és 128khz helyett 16khz-el ment a proci és nem kommunikált az "gyors" írómmal.
Egy másik író program megoldotta a problémát.
(#) CHZ válasza rolandgw hozzászólására (») Máj 10, 2019 /
 
Köszönöm, képen látható beállítással, másik 8515 működik.

Image 8.png
    
(#) zolee1209 hozzászólása Máj 11, 2019 /
 
Sziasztok!

XMEGA128A1 és A1U-ra vonatkozik a kérdésem, hátha valamelyikőtök belefutott már ebbe a problémába.

UART-ot használok MASTER SPI módban. Az F és C porton lévő 0-1 UART modullal is a következő a helyzet. "Normál" üzemmódban, mikor programból kezelek mindent, a TXCIF bit figyelésével tudom, mikor ment ki az adat, ez működik is. Viszont szükségem lenne DMA átvitelre, amit csak RXCIF és DREIF bitekkel lehet indítani UART esetén. A problémám az, hogy a DREIF (data register empty) bitnek akkor törlődnie kellene, ha írtam a DATA regiszterbe. Alapból 1, DATA regiszter írására törlődne, majd ha kiment az adat, visszaáll 1-be. De nem törlődik, így a DMA pakolja bele ezerrel az adatot, noha még ki sem ért... Teszteltem programból, minden harmadik DATA regiszter írásra törlődik csak a DREIF bit, eközben persze az adat megy kifelé. Többféle UART móddal próbálkoztam, aszinkron, szinkron mód, különböző adatszélességekkel, de a DREIF bit nem úgy működik, ahogy adatlap szerint kellene neki. Esetleg tud valaki erre megoldást, vagy ez egy újabb bug az amúgy sem rövid XMEGA errata-ba?
(#) csatti2 válasza zolee1209 hozzászólására (») Máj 12, 2019 / 1
 
Annak idején egy projektet ATXMega128A1U-val kezdtem el megvalósítani. Rengeteg problémába ütköztem és nem győzött meg különösebben. Most bele néztem a kódba, mert emlékeztem, hogy használtam DMA-t az USART-hoz és kommentben megtaláltam, hogy a küldés az istennek nem ment DMA módban (a végén simán byte-onként küldtem, mint a kőkorszakban) a fogadás viszont rendesen működött.

Őszintén szólva ha már elkezdtél megtanulni egy új 3V3-as rendszert, azt javaslom kukázd inkább az XMega sorozatot és válts át ARM-ra (Atmel is jó, de az STMicro hobbi szinten elérhetőbb, mert olcsóbban beszerezhetőek és sokkal olcsóbb a programozó eszköz [2-3 USD vs. 30k Ft]). A megtanulásuk nagyjából hasonló erőfeszítést igényel, de az ARM alapú rendszerek sokkal nagyobb teljesítményűek (és kiforrottabbak is). Ezt saját tapasztalatból mondom, úgy hogy ráadásul még be is vásároltam egy csomó XMega-t annak idején, ezek azóta is csak a port fogják a fiók mélyén.
(#) rolandgw válasza csatti2 hozzászólására (») Máj 12, 2019 /
 
Most próbálgatom az új STM32G0 sorozatot. Megeszi reggelire az XMega-t, ahogy mondani szokták, pedig "csak" M0+.
(#) dzsolt válasza zolee1209 hozzászólására (») Máj 12, 2019 / 1
 
Rég voltam itt, azért remélem segítek.
Ha jól emlékszem a DMA_CHx_CTRLA regiszter SINGLE bitjét 1-be kellett állítani, hogy minden DRE triggerre csak 1 bájtot küldjön az UART-ra. Előtte természetesen beállítani a TRIGSRC, SRCADDR, DESTADDR, TRFCNT regisztereket.
(#) zolee1209 hozzászólása Máj 12, 2019 /
 
Működik a DMA küldés...

Az UART-nál tegnap már szerintem az ideg miatt nem vettem észre, hogy miért működik ahogy, igazándiból jól. A DREIF bit akkor 1, mikor írható a DATA regiszter. Az elsőnek beírt adat átkerül a kimeneti shift regiszterbe. Az UART DATA regisztere double buffered, ezért még két bájtot kell ráírni azonnal, hogy a DREIF bit törlődjön, jelezve, hogy nem tud adatot fogadni. A szoftveres UART küldést teszteltem DREIF figyeléssel, és hibátlanul működött. Utána ismét bekapcsoltam a DMA-t, nem az igazi még...

dzsolt: Köszönöm, a SINGLE bit beállítása megoldotta a problémát, szépen teszi a dolgát a DMA és az UART is immár.

csatti2 és rolandgw:
Tisztában vagyok azzal, hogy a ma kapható eszközök tekintetében akár elavultnak is tekinthetnénk az XMEGA sorozatot. Úgy tíz éve programozok assembly-ben avr-re, néhány alkalommal PIC-re. Egyszerűen megszoktam, és nem volt kényszerítő erő, hogy C-t tanuljak. Régebben vettem stellaris launchpad-et, mint szintlépés, sajnos a fejlesztőkörnyezetet sem tudtam összehozni, aztán ráhagytam a dolgot. Az XMEGA-hoz megvan mindenem, és úgy gondolom, elégséges a teljesítménye a leendő projektbe.
(#) zombee hozzászólása Máj 13, 2019 /
 
Sziasztok!

UPDI.vel foglalkozott már valaki? Úgy értem, nem csak rákötni és felprogramozni az IC-t, ami lehet
pl. ATTiny816. Maga a protokoll és annak gyakorlati megvalósítása, szimulálása, másolása érdekel.
Van egy (szokás szerint) nem túl olcsó programozó ami ATMEL-ICE néven fut, ez egyébként a
legolcsóbb ami szóba áll az UPDI-s eszközökkel. Dobozolva+USB+ISP kábellel 32k HUF, "csupasz" PCB 18k.

Mivel nem olcsó, és a (szériagyártásban lévő) programozandó áramkör hiba esetén könnyedén
tönkrevághatja (korábban, ISP-s eszköznél volt már rá példa!), szeretném az UPDI programozó
funkciót egy AVR-be tenni, lehetőség szerint "standalone" módban. A neten találni ezerféle
Arduino-s megoldást avrdude-el megtámogatva, de több értelme volna ha az UPDI protokollt
és a beégetendő adatot egy AVR-be tenném bele. Természetesen kicsit beleástam magam a témába:
a kommunikáció fél-duplex aszinkron UART, automata baud rate detektálással amit a programozó
eszköz diktál. 12 bites keretekkel dolgozik (startbit+8adat+paritás+2stopbit), a BREAK kivételével
minden jel generálható és fogható egy "régebbi" AVR-es UART perifériával. Amúgy ha nincs
hiba az átvitelben, BREAK (alaphelyzetbe állítja az UPDI-t) nem fog kelleni.

Egy ATMega168 pont alkalmasnak tűnik a célra, a PROGMEM elbírja a 8kB flash tartalmat,
a maradékon pedig a FUSE bitek és maga a protokoll programkódja el kell hogy férjen.
Azért lesz mégis ATMega328, mert egyrészt a 8kB flash-t kettőzni kell hogy az adatmemória
sérülése esetén ne csináljon szériahibát, másrészt az eszköz teszteléséhez is tartalmaz rutinokat.
A hozzászólás módosítva: Máj 13, 2019
(#) rolandgw válasza zombee hozzászólására (») Máj 14, 2019 /
 
Próbálkoztam Mega4809-el és MPLAB Snap-el legalább programot beégetni. Feladtam. Van egy ~5 GB-os kódhalmazuk, amit író program néven fut, AVR-re használhatatlan. Remélhetőleg az űrprogramban nem vesz részt az MC, mert sohasem jutunk el a Marsra.
(#) zombee válasza rolandgw hozzászólására (») Máj 14, 2019 /
 
Atmel Studio 7 és ATMEL-ICE. Egyelőre. 4-es Studio-hoz képest bika gépen ez is lassúcska,
de azért tűrhető. Még jó hogy a kódot -egyelőre- készen kapom. Sajátjaim továbbra is 4.19-en fordulnak.

Időközben összedobtam egy jelszeparátor nevezetű cuccost, amivel a fél-duplex
jelet kvázi-duplex jellegűre alakítom. Erre logikai analizátort dugva meg lehet figyelni a bájtok
oda-vissza mozgását, elkülönítve a két végpontot. A kezdő megszólítást (2 rövid impulzus)
leszámítva az összes bájt dekódolható, mint szabványos aszinkron jelsorozat.

Ha esetleg nem lenne érthető: a jelszeparátor úgy működik, hogy a D1-D4 diódák segítségével
egy kb. 1.2V-os feszültségkülönbséget hozok létre a két végpont (programozó és IC) között.
Kihasználom azt, hogy alapesetben a vonal HI állapotban van, azaz nincs adás egyik oldalon se.
A (fizikai) kommunikáció úgy működik hogy az adó a jelvezetéket 0V-ra húzza, a vevő pedig figyeli.
A diódákon eső feszültség miatt a vevő bemenete nem tud 0V-ra húzódni, de az 1.2V körüli
feszültségszint elegendő arra hogy azt LO jelszintnek érzékelje. Innen nincs más hátra,
mint egy-egy komparátorra rávezetni mindkét végpont jelét, aminek invertáló bemenetét
D5-R5 páros segítségével dióda-feszültségre (~0.6V) feszítek elő. A komparátorok kimenete
pedig egy rendes UART jel, szétválasztva a programozó és az AVR által kiadott jeleket.

Az "ISP*" egyelőre csak tápfeszültség adásra kell, a jelátvitelben nincs szerepe.
Következő lépés a MISO jel bekötése lesz az ATMEL-ICE helyére: a LUFA AVRISP-mkII
programozómba "Virtual Serial" firmware-t betöltve egy alkalmas PC-programmal
elméletben megvalósítható az UPDI programozás...
A hozzászólás módosítva: Máj 14, 2019
(#) zaza99 hozzászólása Máj 24, 2019 /
 
Sziasztok!
Vettem kínából egy Nano V3.0 MINI USB ATmega328P CH340G 5V 16M mc-t, de nem tudom felprogramozni. Még egy blink program se megy fel rá.

BN: Ismeretlen alaplap
VID: 1A86
PID: 7523
SN: Tölts fel bármilyen vázlatot, hogy kinyerhesd

Van ötletetek?
(#) pont válasza zaza99 hozzászólására (») Máj 24, 2019 /
 
A CH340 drivert telepítetted?
Következő: »»   804 / 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