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
1. Az Arduino-t hogyan akarod programozónak használni?
2. Az avrdude-t milyen paraméterekkel hívtad meg?
Üdv!
Milyen avrdude parancsot használsz? Hogy van összekötve az Arduino <-> ATTiny2313? ----------------------------------------------------------- Arduino még nem volt a kezemben, csak a neten fellelt infók alapján a következő a tippem: A programozás során az Arduinoban található ATMega328(P)-ra vagy rákapcsolódva. A Signature Byte erre utal valóban. A 328-as ICSP csatlakozója ugye nincs összekötve az Arduino ICSP-jével? Ha nincs, akkor valószínű, hogy bootloader módban próbálod a 2313-at felprogramozni, ami nem lehet. (Tyúk - Tojás; hogy bootloader módban programozhasd előtte fel kell a bootloadert programoznod rá)
Kösz az eddigi válaszokat. Ezen az oldalon leírtakat követtem, de nekem nem sikerült.
Az Arduino-t használtam ISP-ként, a 328-asra már sikerült programot feltöltenem, igaz, az Arduino keretrendszerből.
A neten a következőt találtam:
1. Az Arduinoban található Mega328P-t programozd fel az ArduinoISP "sketch"-el 2. Arduino - Attiny összekötése Arduino - Attiny pin10 - RST pin11 - MOSI pin12 - MISO pin13 - SCK + táplálás 3. az avrdude parancs kiadása A COM Port és a flash megfelelően legyen kiválasztva.
Köszi, megpróbálom.
Sajna még mindig nincs sikerélmény, de még kutakodom a neten, találtam is valamit, de még nem tudom kipróbálni. Majd otthon...
Azt írják az egyik oldalon, hogy tegyünk be 10µF kondit az Arduino Reset és GND közé. Mindenesetre rendeltem egy "rendes" AVR-ISP programozót is, annak mennie kell... Kösz az eddigi segítséget mindenkinek!
Sziasztok!
Szeretnék ötletet kérni Tőletek. UART-on történő kommunikációhoz. Pontosabban RS-485. 6 byte-os csomagokkal operálok, azonban meghatározhatatlan időnként "befagy" a rendszer. A beszélgetés lépései: M küldi S1 cím a buszra, S1 vissza küld 6 byte-ot. M ezeket eltárolja. M küldi S2 cím a buszra, S2 visszaküld 6 byte-ot. M ezeket eltárolja. Ha mindkét csomag kész, PC-re továbbítja őket. Nem ISR-el fogadom a byte-okat, hanem polling-olok. A gondom az, hogy a while-ban beragad valamelyik eszköz. A rendszer íróasztalon van, SN75176 IC-vel. M=m128, S1 és 2=m8. Baud 9600. Lezárók 120ohm-ok a busz elején, végén. Szoftverben keressem inkább a hibát? Pl.: lehetne ISR-el fogadni a masterben és a slave-ekben? Vagy villamosságtani gond lehet? Hogyan lehet védekezni az ilyesfajta hibák ellen? Köszönöm szépen!
Szerintem: minden hardware-esen elképzelhető hibát kezelni kell a szoftverben. Ha a program nincs felkészülve valamire, akkor az a program még nincs kész! Biztosan van egy feltételed, ami vár valamire, ami hiba esetén nem következik be. Ilyenkor kell egy timeout, amit megfelelően méretezve, azonnal kibukik a hiba. Ezután lehet újra próbálkozni, vagy szólni az user-nek, hogy a hardware hibás, javításra szorul. Ki kell debuggolni, hogy mi okozza a hibát!
Fel kell készülni vezeték szakadásra, arra is, ha lekapcsolod a páraelszívót, ami ilyenkor óriási zavart okoz, ha elmegy az áram, ha villám csap be a közelbe, ha kóla löttyen valahova  A hozzászólás módosítva: Júl 26, 2018
Ahogy Kovidivi is mondja, minden lehetőségre fel kell készülni.
A polling-nak pont ez a veszélye, ha van egy időigényesebb ciklus, akkor le is maradhatsz 1-1 bitről/byteról és az UART már nincs is szinkronban. Szerintem ISR-ben kéne, legalább a fogadást (RXD) végezni. Így valószínűbb, hogy nem maradnak le byte-ok. pl.: Ha M küldi S1 cim-et a buszra, induljon el egy idő számláló (6byte küldése 9600-baudon ~5ms időbe telik jól számolom?) legyen pl 10ms, ha ezen belül nem jön válasz, akkor küldje újra legyen egy byte számláló is, ha kevesebb mint 6 byte jött be, akkor a csomag érvénytelen (közben rájöttem, hogy csak van benne, mert ha nem lenne, akkor folyamatosan összeakadna és nem csak néha) Ami még fontos, hogy milyen a csomag felépítése? Ha Sx küld egy csomagot, akkor értelmezheti e Sy-azt egy M-től érkezett üzenetként?
Egy gyors kérdésem lenne: A TQFP tokozású AtMega32-nek miért van három pár GND-VCC kivezetése? Mindet be kell kötni, vagy esetleg ugyanazt a kivezetést jelentik és segítenének a tápfesz továbbításában? Köszi!
Mindet be kell kötni, és mindegyikre kell a 100 nF kondenzátor. (Egy nagyobb tokon akár 10-14 pár táp is lehet, és azokat is mind be kell kötni.)
Amúgy a datasheet is írja.
A GND és AVCC párt is be kell kötni, amit nem karikáztál be.
Jó meglátás, nekem fel sem tűnt. Valóban, az analóg tápot is be kell kötni, különben nem fog működni az egész MCU. Adatlapban benne van, hogy melyik részegység honnan kap tápot.
Tipp: Aref és a GND közé 10 100nF kondit tegyél. Hamár tápot tervezel. Az az analog referencia (belső) tápja!
Azt meg is találtam az adatlapban, hogy az analógot be kell, csak a többit nem. Köszi a válaszokat!
Igen, azzal is van problémám, hogy az adatot címnek tekintik a buszon résztvevők.
Hogy lehet ez ellen védekezni? (Pl.: mondjuk előre eldöntöm, hogy az adatok értéke 0-250-ig terjednek, mondjuk a címek ez felett 255-ig...? De szerintem ez így nem jó megoldás.)
(már késő van lehet picit kusza lesz a gondolatom)
Tipp: Legyen fix a csomag félépítése. Byte-ról bytera: 1. byte - egy fix byte pl.: 0xAA Ha lehetséges (az rs 485-öt nem használtam még), a küldő fél miközben küldi az első byte-ot, figyelje is a bejövő jelet. Ha a "visszhang" nem = a fix byte-al (0xAA), akkor valaki más is van a vonalon.... Sőt talán az összes adatot érdemes így visszaolvasni. Miközben M/S adatot küld figyeljen is. Ha nem egyeznek meg, akkor rossz volt az átvitel -> ergo ismételni kell, némi késleltetés után. A késleltetés chipenként eltérő legyen . ... és még talán... lentebb folyt... 2. byte - cél cím, kinek is küldöm az adatot a következő byte lehetne a forrás cím, de esetedben nem kell így ezt most hagyjuk is.... ill. ha utasítás is van (ír/olvas) ez is mehet a 2. byte-ba 1 bit feláldozásával (mint az I2C-nél) további byteok (3.-6.) maguk az adatok. Kell még egy byte számláló is, hogy tudjuk hol is tartunk. Az előző hozzászólásomban említett időzítő most hasznos lesz. ITT JÖN a folyt... Ha a hallgató/fülelő uC-be bejön az első byte, ami nem 0xAA, akkor már tudjuk is hogy az csak zaj a buszon. Közérdekű: Jól gondolom, hogy valószínűleg 0x00-át kapnánk "zaj" byte-nak? A gondolat menetem itt most inkább kihagyom... Ekkor a byte számlálót nem növeljük, az stopper nem indul. Ha bejött az első byte, ami 0xAA, akkor indul a stopper és a byte számlálás is. Ha nem jön meg a következő byte a szükséges időn belül, ami ~2.08ms, akkor a csomag érvénytelen. Kezdjük elölről a figyelést. Ha nem jön meg mind a 6 byte, akkor szintén érvénytelen a csomag. ... Itt abbahagyom. Már totál ki vagyok merülve....
Ellenörző összeget lehet készíteni, nem kell fix első byte adatnak (idő és hely pazarlás). A csomagban lehet a küldendő byteok száma is, ekkor lehet változó hosszúságú is az adat (felhasználás függő). Ha nem jó az ellenörző összeg, akkor eldobjuk az egész csomagot.
Én erre olyan megoldást láttam, hogy speciális karakterrel azonosítják az adatot és a címet.
Tegyük fel, egy $ karakter, és utánna X darab szám (lehet decimális vagy akár hexa vagy ami tetszik), ami a címet azonosítja. Aztán pl egy # karakter, és utánna a megfelelő adat, szintén lehet decimális hexa akár szöveg tehát karakter is, vagy ahogy tetszik. Szóval a vevők a dollár jelből tudják, hogy cím következik, és a kocka jelből pedig, hogy adat következik. Amelyík vevő felismeri, hogy az üzenet neki szól, az veszi az adatokat. Pl.: $00#27A4BB (HEX) Pl.: $01#10110001 (BIN) Pl.: $02#Ez egy adat (SZÖVEG) Pl.: $A5#598 (DEC) Ha szükséges az adat után tehetünk "adat vége" karaktert, ami mondjuk egy újabb speciális karakter (jelen esetben a kukac) pl.: $00#27A4BB@ Vagy akár keretbe is foglalható, miszerint az adatot két kocka közé tesszük pl.: $00#27A4BB# Az utóbbi két lehetőséggel az is eldönthető, hogy rendben átjött -e minden adat. Aztán, hogy a helyességét ismétléssel, vagy paritánssal ellenőrzöd, vagy sehogy, egyéni döntés. Igazából ez még csak az elmélet amit majd én is használni akarok... A hozzászólás módosítva: Júl 29, 2018
Szia!
Hm... Nem is rossz elgondolás. Szóval; M küldi $ 0x01 S1 felismeri, visszaküldi mondjuk a saját címét, hogy fent van a buszon M küldi $ 0x01 megint, erre slave vissza nyomja az adatokat lezárva #-el M küldi $ 0x02 S2 felismeri stbstb. Igazából a slave-eknél a fogadás simán mehet ISR-el, hisz csak a megszólításra várunk. Viszont a masterrel, hogy csinálom meg a megszakításos fogadást? Hogy tudnék feltölteni monduk egy temp tömböt az adatokkal, hogy "zavarás" ne érje. Persze a kész temp-et megvizsgálni és átadni az értékeket az S1 S2 tömböknek. Köszönöm a gondolatot, próbálkozom.
Én leginkább csak az adat és cím szeparációra próbáltam ötletet adni.
De ha arról van szó, hogy a slave felől küldenél valamit megszakítással a masternek, szerintem akkor a megszakításrutinba kéne egy olyat írni, hogy a master behallgat a vonalba. Az a slave pedig aki kiváltotta a megszakítást, az előző elv alapján elküldi a "nevét" és az adatot. Pontosabban, amíg nincs reagálás a master felől, addig a slave csak a nevét küldi bizonyos időközönként, csökkentve ezzel az adatforgalmat. Ha a master azonosította ki akar beszélni, ezt visszanyugtázza az aktuális küldőnek, és ez után a slave küldheti az adatokat is.
Sziasztok!
Szeretnék egyszerre három pwm jelet kreálni. Az áldozat egy mega32. A pwm kimenetek működhetnek egyszerre? Nem foglalja le nagyon az mcu-t? Üdv!
Ha hardveres PWM-et használsz, elmehet a uC aludni is!
Végül ma összejött a mutatvány: egy Arduinót ISP-ként használva sikerült feltölteni egy hex fájlt a Tiny2313-ba.
Hogy más is okulhasson belőle, leírom, hogy mi volt a megfejtés: az ArduinoISP sketch-ben a baud-ot át kell írni 9600-ra és így letölteni. Az avrdude parancssorában is meg kell adni ezt a sebességet ( -b 9600). Ennyi. 
Sziasztok!
Segítséget szeretnék kérni, mert már teljesen eltévedtem az AVR programozás útvesztőiben. ATtiny13-at szerettem volna programozni Flowcode-ban (sajnos a C nem megy, az AVR assemblyvel még csak most ismerkedem), de nem sikerült a PWM létrehozása, pedig az adatlap szerint van két csatorna is erre a célra. A feladat nagyon egyszerű, mindössze arra lenne szükség, hogy bekapcsolás után, kb. 20-40 sec. ideig a 6. lábon egy fix (de állítható!) kitöltéssel PWM-et hozzunk létre. Majd, az időzítés lejárta után, egy másik PWM jelet generáljunk az 5. lábon és az előzőt kikapcsoljuk. Minden lehetőség érdekel (kivéve, hogy használjak más típust)! Köszönöm!
Megosztod a programod forrását? Vaktában nehéz segíteni.
Ránéztem erre a Flowcode-ra. Szerintem C-ben könnyebb lenne...
Sziasztok.
Van egy MKII klónom, saját építésű. Próbáltam több firmware-t is beletölteni, de az Avr studio 4.19 nem ismeri fel. Tud valaki olyan firmware-t ami jó lenne. Atmel studio felismeri, és éget is vele. Köszönöm:
Természetesen megosztom, de csak a PWM létrehozásának van meg a folyamatábrája kipróbálás céljából, nem a teljes feladatnak. Már itt falakba ütköztem, mert van a Flowcode-ban PWM makró, viszont az ATtiny13 típus kiválasztása után, a makró tesztablakában az "unavailable" üzenet látható. Ha az ATtiny45 van kiválasztva, akkor a "disabled" üzenet jelenik meg. Ezért a szükséges paramétereket a makróhoz már nem is tudom beállítani. Lehet, hogy bizonyos típusokhoz nem elérhető néhány funkció, mert a Flowcode-om nincs regisztrálva, csak próba verzió?
Ez az egész max 10 sor C-ben. Van hozzá támogatás, példák, és a teljes, professzionális fejlesztőeszköz ingyen van.
Biztos, hogy akarod ezt a Flowcode dolgot? |
Bejelentkezés
Hirdetés |
