Szerintem, ha kapsz megszakítást, hogy megérkeztek az adatok.
Én az adat feldolgozásával kezdeném a ténykedést, nem az RS485 vezérlésével foglalkoznák.
Ha sok az adat, mire a végére ér a feldolgozás már biztos ott lesz az utolsó Byte is.

Vagy ha biztosra akarsz menni, küldesz a végén 1 lezáró karaktert, amivel aztán már nem kel foglalkozni. Így akár ki is hagyhatod a DMA átvitel vége figyelését.
Lényeg a feladatok okos megosztása a CPU és DMA között, hogy lehetőleg ne akadályozzák egymást.
Az RS485 átkapcsolása meg ráér, majd mikor újra adatot akarsz küldeni.

Az adással van a gondom. Rövid frame-ek mennek, de aránylag lassan (most 9600bps). A válasz viszont nagyon gyorsan el kezd érkezni, ezért hipp-hopp át kell kapcsolnom az irányt. Most minden puffer minimumon van, ami lehet (DMA-nál 1 a legkisebb, az UART-nál meg ott a HW duplapuffer). 5 byte kiküldésekor a 3. végén kapom a DMA ready jelet (igaz, a DMA kiürült, mert már átnyomta az UARTnak a duplapufferébe. Az UART TX jel meg az 5. byte elején már vált, mert az adat már a kimeneti shiftregiszterben van, tehát jöhet a következő, ha van. Ilyen kis sebességnél/adatmennyiségnél miért vacakolok a DMA-val? Mert igen sok tennivaló van, több soros port (szintén DMA-val a uC-k között, kijelző felé, még más szolga uC, nem igazán engedhetem meg magamnak, hogy msec-eket várakozzak a semmiért. A többi megy, csak ez a fránya RS485 okoz gondot. (igen, tudnék irányváltó jel nélküli RS485-öt is csinálni, de az a módi most az iszonyat nagy hosszok miatt nem működik, kell a normális meghajtás) Már olyan birkaságok is eszembe jutottak, hogy beáldozok egy UART-ot és arra is beállítok egy másik DMA csatornát csak nem 5 hanem 7 byte-ra. Amikor a "7"-es lejár, akkor pont kiment a másikból az 5 byte-om.

Köszönöm szépen a választ, akkor mepróbálom így.

És mi történik, ha a DMA átvitel vége megszakításban engedélyezed ezt:
DRE_vect, USART Data Register Empty Interrupt vector
Akkor, ha kiürült az USART kapnál még 1 megszakítást?

Bit 5 - DREIF: USART Data Register Empty Flag
The DREIF indicates if the transmit buffer (DATA) is ready to receive new data. The flag is one
when the transmit buffer is empty, and zero when the transmit buffer contains data to be transmitted
that has not yet been moved into the Shift Register. DREIF is set after a reset to indicate
that the Transmitter is ready. Always write this bit to zero when writing the STATUS register.
DREIF is cleared by writing DATA. When interrupt-driven data transmission is used, the Data
Register Empty interrupt routine must either write new data to DATA in order to clear DREIF or
disable the Data Register Empty interrupt. If not, a new interrupt will occur directly after the
return from the current interrupt.

Szerintem ez figyeli a puffer kiürülését is.

Erre gondolok:
21.15.3 CTRLA – USART Control Register A
...
• Bit 1:0 - DREINTLVL[1:0]: USART Data Register Empty Interrupt Level
These bits enable the Data Register Empty Interrupt and select the interrupt level as described
in Section 12. ”Interrupts and Programmable Multi-level Interrupt Controller” on page 123. The
enabled interrupt will be triggered when the DREIF in the STATUS register is set.

Köszi, most mérgemben nekiálltam NYÁK-ot tervezni, közben agyalok. Összedobok egy kispanelt és kikísérletezem már ezt a dolgot. Olyan szép, mikor szkóppal túrjuk a SW dolgokat...

Sziasztok!

Van egy áramköröm, aminél egy érdekes anomális fordul elő. A mikrokontroller egy ATMega48PA-PU. Erre egy CP2104-re épülő USB-UART átalakító (Pololu-1308) van kötve, így kerül kapcsolatba a PC-vel.

Próbapanelon minden tökéletesen üzemel, nincs kommunikációs hiba. Viszont a kész NYÁK-on időről időre előjön, teljesen rendszertelenül, hogy a mikrokontroller elkezdi ontani magából a bájtokat. Úgy figyeltem meg, hogy a programjában lévő 4 konstans string fix sorrendben, sokszor egymás után (legalább 10-szer ismétli meg őket, kötött sorrendben), amit megelőz véletlenszerű bájtokból álló sorozat. (Ez rendszertelen, változó hosszúságú, és nem is hasonló, valami memóriaszemét féleségnek néz ki) Tehát úgy néz ki, mintha valamiért a mikrokontroller behülyülne és a teljes RAM-ot kiküldené UART-on. Ezek után nem reagál semmire, csak a zsegít, ha áramtalanítom. Ha csak a CP2104-et húzom ki és dugom vissza, akkor is folytatódik a bájtáradat.
A dolog tetőpontja az, hogy ezt csak az elmúlt 2 napban csinálja, előtte a végleges áramkörben is tökéletesen üzemelt, napokon keresztül (legalább 3-4 napig ment)! Azóta a programot nem piszkáltam, ahogy a hardvert se, tehát nem értem, hogy mi válthatta ki. Kipróbáltam másik mikrokontrollerrel, de annál is ugyan ez a jelenség áll fönn.

5V-on üzemel az áramkör, a mikrokontroller 8MHz-en megy, de ez a próbapanelon is így van, ott pedig még sosem fordult elő a hiba.

Ha a fenti problémára van bárkinek ötlete, akkor legyen szíves segíteni. Köszönöm!

Sokat segítene ha mellékelnél kapcsolási rajzot és fotókat az áramkörről.

Az áramkörön a kapcsolási rajzhoz képest annyi az eltérés, hogy a 4N25 és reed relé párosokból kétszer ennyi van, ahogy a jobb alul lévő motorvezérlő részből is van még egy. Ezek tökéletesen ugyan ilyen felépítésűek, a használt alkatrészek is teljesen megegyeznek mindenhol.

A DSC_0225 képen (kézzel készül NYÁK, nem a legszebb...) bekereteztem, hogy melyik két vezetősáv köti össze a mikrokontrollert a az USB-UART átalakítóval. Sehol sem érnek össze, mértem szakadásvizsgálóval.

A DSC_0224 képen pedig a NYÁK felülnézetből látszik. Bal oldalon vannak a motorvezérléshez a relék, a tranzisztorok és a két MOSFET. Jobb oldalon van a CP2104, egy Pololu 1308 formájában. Ez USB-ről kapja az áramellátását, az áramkör többi része ugyan annak a PC-nek a tápjáról. Minden 5V-on üzemel. A bal alsó sarokban lévő fekete drót a GND a teljes áramkörnek, a sárga a motorokhoz viszi az 5V-ot, a piros a mikrokontrollerhez az 5V-ot. (Eredetileg a motorok 12V-ot kaptak volna, azért a két drót.) A jobb oldalon lévő vékony drótok és a csatlakozó a reed reléket kapcsolja a 4N25-ökhöz.

PC tápból kettőt is próbáltam az első eset óta, mindegyiknél előfordul. Ha éppen jól működik, akkor a bájtok nagy része hibátlanul megy, bármelyik irányt is nézzük.

Azért rendbe is tehetted volna a rajzot mielött feltöltötted. A lényeg valoszinü nem us a rajzon van hanem a tápon és az AVR csatlakozásán. Az a két 100nF kondi édeskevés olyan esetben ha induktiv a terhelés mint az esetedben a motor.
Nem tudjuk milyen az 5V táp milyen a belsö ellenállása és a szürése.
Az optok illesztése is elég felületes az AVR-hez. Oda mindenképp kell kb 1-5 kOhm terhelö ellenállás, meg talán egy egy kondi is jol jönne szürni a zajt a bemeneten ( gondolom végálláskacsolo a 2).

Szia! A képek szerint a belső oszcillátorról járatod az AVR-t. Ez általában nem elég stabil/pontos az aszinkron soros kommunikációhoz. Nekem legalábbis külső kristály nélkül mindig zagyvaság ment át a PC-re. Bár érdekes, hogy Nálad néha mégis jól működik. Ha van otthon a projekthez megfelelő kristályod, egy próba idejére forraszd oda alulról.

Azoknak az optoknak mi hasznuk van? (semmi). A D5, D6 dioda szinten kerdeses. Azoknak a rele tekercsekkel parhuzamosan kellene lenniuk.

Sziasztok!

Elkezdtem foglalkozni az UART kommunikációval. Elsőként egy olyan programot írtam, ami másodpercenként kiírja a számítógép képernyőjére, új sorba, hogy Hello World! Az eredmény viszont az lett, hogy másodpercenként kiír a képernyőre egy csomó ékezetes R betűt egy sorba. Putty terminált használok 9600-as baud rate-el. A külső rezgőkvarc 16MHz-es. A mikrovezérlő (ATmega16) adatlapja szerint a hibaszázalék 0.2% ami megbízhatónak minősül. Azért pont 16Mhz-es kristályt használtam, mert nincs itthon másfajta. Elvileg ezzel is működni kéne. Kipróbáltam az Arduino saját soros monitorjával is, ott meg csak kis négyzeteket rakott. Sőt kipróbáltam 250000-es baud rate-el (az adatlap szerint 0.0% a hiba), hát úgy sem akart működni.

Tudnátok benne segíteni?
Köszönöm

@Massawa: köszönöm a segítséget, úgy tűnik, hogy a beültetett 470µF kondi megoldotta.

@Ivan93: neked is köszönöm, betettem egy 12MHz-es kristályt, azóta minden bájt hiba nélkül átmegy.

@killbill: azért használok optot, mert az egyik motor a vezérléstől több méter távolságban van, a hozzá tartozó reed relékkel együtt. Zavarvédelem gyanánt tettem be, az ötletet Topi dallamcsengős írásából vettem. A dióda a rajzon valóban rossz helyen van, bocsi, a NYÁK-on már a tekercsekkel párhuzamosan van.

Szia!
A TX-et kimenetre állítottad?
Próbáld meg, hogy beírod MY_UBR=103; //ekkor 9600 baud lesz!

A TX-et nem állítottam be kimenetnek, de ha jól tudom, akkor erre nincs is szükség, mert amikor bekapcsolom aTXEN bitet az UCSRB regiszterben, akkor az uart átveszi az irányítást a TX láb felett. Tehát ha előzőleg bemenetnek adtam volna meg, akkor is kimenet lenne. A 103-as baud rate-et külön kipróbálom majd, de nem hiszem, hogy lesz változás.

Gondoltam, hogy ez az oka, de ez még az 5V-ra kerülő zajoktól nem véd meg.

Gyakorlatilag kihúztál kétszer két antennát és rákötötted a betápodra...
Ha úgy akarod csinálni, ahogy ezt kitalálták, akkor beépítesz egy 0505 konvertert (5V-ból csinál galvanikusan leválasztott 5V-ot, amit használhatsz a reed reléidhez, illetve egyéb szenzoraidhoz), ezek beöntött kis modulok formájában kaphatóak.

Ha van sei(); és timer_init();, de nincs init_pwm(); , akkor működik a kód. Ha csak init_pwm(); van, de a többi nincs akkor is működik a kód.
Ha mindhárom inicializálva van, akkor nem megy a PWM funkció.
Ezt mi okozhatja?

Köszönöm a javaslatot, utána nézek!

Igazad volt. Kipróbáltam, hogy UBRRL=103 és úgy működik. A kérdésem, hogy miért nem működött úgy ahogy én csináltam? Elvileg ugyan az lenne nem?


Még egy kérdés: a '/n' és '/r' parancsok nálam miért nem működtek? Ezekkel szerettem volna új sorba és sor elejére írni a következő "Hello World!" szöveget. Az eredmény az lett, hogy a / jelet nem írta ki, de az n és r betűt igen (egy sorba egymás mellé). Az ASCII táblázat szerint LF és CR parancsokat kéne írni. Kipróbáltam velük is, de úgy sem működött.



Egyedül úgy sikerült, hogy beírtam a tizes számrendszerbeli kódjukat:

Szia!
Szerintem azért, mert átadtál a konfigUART-nak egy 2 bytos egész számot (9600), amit a MY_UBR nevezőjében megszoroztál 16-tal, de ezt továbbra is 2 byte-os egésznek veszi a fordító, tehát a 16*9600-nak, csak az alsó byte-ja kerül be a MY_UBR nevezőjébe és ezzel a számmal osztja el az F_CPU-t (viszont a 16*9600 nagyobb, mint amit ábrázolni lehet 2 byte-on 65.535)
Két dolgot lehetne tenni, ha továbbra is változóként akarod átadni a baud értékét, akkor: 1.
, vagy a függvény definícióját változtasd meg
,ha nem kell változó, akkor:2.
ekkor ugye elég ez:

Most már értem, köszönöm a magyarázatot.

Szia! Azért nem működik a "/r/n", mert rosszul írod be őket. Helyesen "\r\n".

Ez tényleg a teljes kód? Ha igen, miért hagyod a main függvényt befejeződni?
A timer_init-ben miért a timer0 interrupt bitjét állítod, ha a timer1-t konfigurálod ott? Így az a szerencsétlen megpróbál meghívni egy nem létező megszakítást...

Szerintem miután a compare match megszakítást használod, igazából ezek nem is kellenek...
Egyébként szerencsésebb volna, ha mindenhol ahol perifériát (és főleg megszakítást) konfigurálsz betennéd a kódot egy cli(); .... sei(); közé.

Máskor add meg milyen mikrót használsz.

Sziasztok!
AVR C programozásánál belefutottam egy idegesítő bugba az EEPROM használatánál.


A fenti kódot úgy értelmezi a fordító, hogy a legelső (MASTERCODES) változót az EEP fájl legvégére rakja, és a továbbiakban úgy is kezeli. Ha viszont kiveszem a többi változót, akkor az elejére kerül, természetesen más pointerrel. A gubanc ott kezdődik, hogy egy másik gépemen pont fordítva történik, azaz az elsőként definiált változó az EEPROM elejére kerül. Az EEPROM tartalmát pedig nem frissítem a fejlesztés során, mert az már tartalmaz olyan értékeket amelyet a készülékem ír és olvas. Ha a változók definiálási sorrendjét felcserélem, akkor mindkét gépemen megcserélődik a sorrend:
az első gépemen lesz "jó" a sorrend, a másikor "rossz". Valamivel le lehetne fixálni a változókat?

Köszi, ez volt a hiba.

Próbáld meg struct-ba rakni:

Köszi, legközelebb ezt próbálom. A második gépemen (ahol "jó" volt a sorrend), ott a Toolchain 3.3.0 verziója volt telepítve, míg a "fordított" sorrendet adó gépen 3.4.2. Előbbit frissítettem, így legalább mindkét gép ugyanazt a fordított sorrendet használja, nem kell folyton átirogatni ha átülök a másikra.

Mindenesetre elgondolkodtató, miért csinálja ezt, főleg, hogy pont az újabb verzió fordítja át.
Ja igen, AVR Studio 4-et használok, de ez szerintem nem befolyásolja a fordító működését. A legújabb toolchain-ban sajnos nincs make.exe, de még telepítője sincs, csak egy önkicsomagoló cucc.

Helló Mindenki!
Egy ideje foglalkozom AVR programozással, szép sikerrel, egészen jó progikkal a hátam mögött (programozásban már nem vagyok zöldfülű egyébként sem). Szóval tetszik, meg minden, de egyelőre csak Arduinoban programozom. ezt a jó kis procit.
Ahogy olvasom, kissé memóriapazarlóan fordítja a kódot az Arduino, így szeretném más módon is megtanulni programozni. Több kérdésem is lenne:
1. Milyen más fordítókat használtok, ezek a hol érhetőek el, ha ingyenesek?
1/2. Assembly-n kívül melyik nyelv tartható a legalkalmasabbnak (C, Pascal) ?
2. AVR Studioban lehet assemblyben is programozni (még nem telepítettem fel)?
3. Arduinoban vagy más fejlesztőkörnyezetben lehet beilleszteni assembly betéteket, mint pl Pascal-ban, C-ben?