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
Igen, lehet programozni.
Bővebben: Link (15. oldal) Adatlap szerint szinte mindenben megegyezik az C51-el, tehát mennie kell a programozásnak is. Ha most kezdesz procikkal foglalkozni, és nem valami cél miatt használod ezt a procit, akkor én azt javaslom ne használd. Nem jobb mint az ATMEL hasonló célra gyártott AVR családba tartozó processzorai. A 89C51 - 89S51 elhaló széria, bár mindennek, az egész processzoros világ ősatyja.
Sziasztok!
Aki AVR-Dopert használ Avr-dude-dal (linuxon vagy WinAVR-rel) annál előfordult-e már hogy a programozás elindítása után (néha) van egy kb 10-15mp-es szünet és valamilyen timeout error-t dob vissza?(...majd csak ezután elindul el a programozás) Egy ismerősöm megépítette az AVR-dopert a Topi-féle forráskóddal, kapcsolással és nyáktervvel és nála előfordul, továbbá szobatársammal terveztünk egy egyszerűsített AVR-dopert, 1 oldalas nyákkal és 74HC126 nélkül, de Én az eredeti AVR-Doper forráskódját írtam át, és ezzel is van timeout (de teljesen jól működik HC126 nélkül ) Illetve ezzel próbálgattam 20-30kbyte-os kódokat programozni AVR-be és előfordult hogy néha egyszerűen megszakadt a kapcsolat (a Topi féle kódossal nem tudom hogy előfordult-e már...) AVR-studióval timeout úgy emlékszem nem volt, de kapcsolat megszakadás az volt már programozás közben... Bár lehet a kapcsolat megszakadás az egyéni problémám...
Köszönöm az infót!
Ezt egy céláramkörhöz szeretném használni. Programozni már programoztam avr-eket, de ennyit még egyel sem szívtam.Szóval akkor elvileg jó úton jártam, de valamiért csak nem akar kommunikálni. Kristályt nem raktam mellé. Adatlapból úgy értelmeztem,hogy kell neki. És melyik programot használjam mellé?A Szoftverekben 89s52-nél kezdődik.Valszeg azért mert régi darab.
A kristályt hiányolta. Most megy végre.
A céláramkör 11.0592MHz-vel van építve. Abból már nincs itthon több, felprogramozni megteszi egy 4MHz-es is szerinted?
Csináltam egy servo tesztert és valahogy nem akar működni:
össze-vissza mozgatja, és sehogy sem akar stimmelni. A kódból leszűrhető valami hiba amit elkövettem? ATTiny45-el próbáltam megcsinálni USB-ről kapja az 5-ot és a 3. lábra kötöttem a vezérlést közvetlenül.
Idézet: „Én az eredeti AVR-Doper forráskódját írtam át, és ezzel is van timeout (de teljesen jól működik HC126 nélkül ) Illetve ezzel próbálgattam 20-30kbyte-os kódokat programozni AVR-be és előfordult hogy néha egyszerűen megszakadt a kapcsolat (a topi féle kódossal nem tudom hogy előfordult-e már...)” Ezt én is tapasztaltam, az eredetivel. Előidézni nagyon nehezen tudtam csak, rengeteg melómba került mire megtaláltam hol vérzik a gyári firmware. A vérzés hibája igencsak kritikus asszinkronitási probléma, amit én kijavítottam, így nekem akkor onnantól már nem jött elő. Ám, mivel az egész low-level programming mode rutin elég bénán van megírva, előfordulhat hogy valami más újabb asszinkronitási gondot okoz. Ehhez már durvábban át kellene írni, ami tekintettel arra, hogy a gyárinál is 100 programozásból max 1x jött elő, nem fordítottam nagy hangsúlyt. Ami ezeken kívül lehet hiba, az viszont már csakis az AVRUSB lib hibája lehet, EnableAllRequest függvégy és az annak segédrutinjai bugosak. Ezekkel nem foglalkoztam még, mert annyira elhanyagolható a szétcsúszás. Persze ez nekem csak AVRStudioval fordult elő, avrdude-al "-doper" kapcsolóval soha.
Leírtam a cikkben, hogy milyen hosszú impulzusokat kell kiadni. Abszolút nem értem a ciklusban lévő 30ms-es sleepjeidet, és eleve a for ciklust sem.
Processzoros áramkörben folyamat végrehajtásnál soha, de soha nem használunk forciklust és időzítést. Ennek több oka van. 1. a fordítók 99,9%-a rettentő primitíven optimalizálja a for ciklust 2. Nem szabad fenntartani a fő thread-et - aka. main loop - semmi ilyennel. 3. For-nál inc és dec... while ciklust ahol lehet, és mindig decrementálni. -> Miért? Mert a decrementálás igaz ugyan úgy egy utasítás mint az incrementálás, de a status regiszterek és az ALU a ZERO flag-et szereti és alkalmazza. Ergo, könnyebb megkérdezni a procit, hogy nulla-e mint hogy nagyobb-e mint 100. Ha egy 100-szor végrehajtandó ciklus kell akkor: változó = 100 while (változó--) { ... }
Teljesen igazad van a ciklusokkal kapcsolatban én is csak akkor használom, ha "lusta" vagyok optimalizálni vagy, ha nincs szükség rá valami miatt.
Én a basicom servo vezérlőét használtam ami, ha jól tudom valahogy megoljda helyettem az időzítést meg mindent amit kell. Csak gondoltam a belső órajelet nem jól állítottam be? A waitms 30 az a várakozás két váltás között. Elvileg a Servo(1)=I pedig beállít egy pozíciót. Lehet, hogy inkább az általad említett cikkel csinálom meg és C-ben csak nem szeretem, hogy 1000 dolgot kell csinálni egy kis program kedvéért, külön mappa meg miegymás, mintha egy óriási project lenne . (de ez csak a 5 percem van gyorsan kipróbálom mert rohannom kell miatt van így. Ha van időm természetesen én sem így állok neki . Vagyis a kérdésem, hogy jó a 8Mhz az első sorban? Kell még valamit állítani hozzá?
Erre nem tudok mit mondani. Ha egy program beépített hülyeségét használod, akkor innentől nem tudunk segíteni. Írj sajátot, ha az nem működik, máris tudunk segíteni. Így, egy beépített, ismeretlen összeügyetlenkedett megoldásra nem tudunk gyógymódot.
Ez egy alapszabály. Ne alapozz vakon a gyári beépített dolgokra. Főleg olyanokra soha, aminek nincs a forráskódja meg. Ha a bascom befordít valami okosságot, egy bugot, azt észre sem veszed.
Kerdes az, hogy a servo motorodnak megfelelo ez a jelalak, mert nem biztos, hogy a kitoltesi tenyezo szamit, hanem a magas allapot hossza idoben. (Azaz megadott frekvenciaju jellel kell vezerelni).
Igen sejtettem, hogy ez a baj csak reménykedtem, hogy az elektronikában jobb a helyzet, mint a szoftverfejlesztésben.
Vagyis akkor itt is érvényesül a nincs értelme venni semmit, mert lehet, hogy hibás elv. (Na ezért támogatomaz opensource-t, ott legalább bele tudok nyúlni, ha hibát találok). Versenyre kéne ott meg a basicom van előnybe részesítve. Az meg sem fordult a fejembe, hogy a szervónak más jel kell, de még talán az is előfordulhat.
Tessék elolvasni a SERVO leírást a bascom súgóban. PWM jelalakot gyárt és a Timerre ül rá.
A szervomotorod nem tudja követni 30 msec alatt a pozícióváltást....... A Bascom nem open source, de az ASM lefordított kódot az AVRStudioban meg lehet nézni... És ha csak ennyi van benne, akkor mégsem olyan vészes....
Minta: bascom: servos.bas
A súgóból: A Timer0-t foglalja a jelalak képzés miatt... Amíg a hátterét nem ismered a dolognak, nem lehet/szabad fejlezstőrendszert lehúzni....
Sziasztok! Tudna nekem segíteni valaki, hogy az Atmega128-ban USART-ot szeretnék használni Infra jelfeldolgozásra, milyen regisztereket hogy kell beállítsak? Az adatlapból nekem még nem egyértelmű, PIC-hez voltam eddig hozzászokva
Amúgy a PD2-es lábra van kötve (27-es). A válaszokat köszönöm!
Sziasztok
AVR-doper-el szeretnék ATTiny2313-at égetni. A beéllítások ugyan azok mint amik a mintavideókban vannak. Tehát ISP freki: 56,7Khz, az IC kiválasztottam a listáról... Read Signature-ra kb. minden második/harmadik gombnyomásra mást ad be. Van mikor írja is hogy nem stimmel a kiválasztott IC-hez. Mikor próbálom égetni, a következő hibaüzenetet adja: Idézet: „Getting isp parameter.. SD=0x03 .. OKOK Reading FLASH input file.. OK Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! WARNING: FLASH byte address 0x0018 is 0x00 (should be 0x01).. FAILED! Leaving programming mode.. OK!” Meg tudja valaki mondani hogy tudom kijavítani ezt a hibát? Köszi szépen
Programozás előtt a chip törlésre kerül?
Az ISP összekötőkábel 30 cm felett - ha nem muszály - ne legyen...
Infra mi?
TSOP IR távirányítóvevő vagy IrDA?
Ahogy mondod, törli égetés előtt.
Az ISP kábel kb. pont 30cm, de pl. ATTiny45-öt simán égeti...
Amíg a read signature bizonytalan, addíg három eset van:
1. Hosszú a kábel 2. Magas az órajel. 3. Alacsony túlságosan az órajel. 2313-ban van CKDIV8 és a gyárilag 8MHz-es RC-ről jár. Ez max 1MHz rendszer órajel, így a programozásnak 250KHz alatt kell lennie, ill. ennyi lehet max. Az ~50K indokolatlanul kicsi. Próbáld ki, hogy megnöveled a frekit, vagy mégjobban leviszed. Ha jól emlékszem valami ilyen 50K körül van a határ hogy nem írhatsz flasht és EEPROM-ot.
Helló
(Mikor lesz kész az ATTiny45 3.része? Nagyon várom már!!!) Akár melyik frekire állítom sem megy, 5 alatt pedig nem is engedi. Kipróbáltam, ATTiny45-öt gond nélkül égeti. Amúgy az ATTiny2313-as IC-nél melyik lábra kössem az ISP SCK lábát? Eddig a 19-ik lábra kötöttem (PB7, UCSK/SCL/PCINT7). Lehet ez a gond? Megpróbálom rövidebb kábellel is, de nem hinném hogy ez a baj forrása, ATTiny45-öt és az ATMega8-at is égeti...
Jó helyre tetted az SCK-t. Próbáld meg rövidebb kábellel.
Szerk: III. részért már nagyon rágjátok a fülem, készül-készül. De egybe a IV. résszel
Hát mostmár csak ~10 cm az ISP kábel, de mégsem jó.
most ezt kapom: Idézet: „Getting isp parameter.. SD=0x03 .. OKOK Reading FLASH input file.. OK Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! WARNING: FLASH byte address 0x0001 is 0xFF (should be 0xC1).. FAILED! Leaving programming mode.. OK!” Frekit mindet kipróbáltam...
Először 0x00 volt az első bájt, most 0xFF... Másik 2313 kéznél?
Hát 3-at vettem. Megnézem hogy avval megy-e...
... hát nem megy egyikkel sem. Randomozik a signature, és nem is égeti.
Uhh... Én azóta már egy rakat 2313-at égettem. A furcsa az, hogy a programozónak tökmindegy mit éget... Égetés közben azt sem tudja mit éget.
Tehát ő nem tesz különbséget tiny45 és 2313 között. Próbáld ki, külső órajellel táplálni.
Őőő építsek egy ilyet?
Akkor holnapra marad a dolog. Igaz hogy nem nagy "kunszt", de ma már nem kezdek neki, ahhoz már fáradt vagyok...
Aha... Próbáld ki. És a CLKIN-en nyomd be az arcába
Igen ezzel is próbáltam.
Ha nem 45-öst használok megy is szépen ezért nem értettem, hogy mi a baja. Ezért gondoltam, hogy esetleg rosszul állítom be a chip sebességét és ezért rosszul számolna stb..., de ez sem lehet szerintem hiba. Igazság szerint azért kezdtem el inkább ezzel, mert gondoltam ezzel a legegyszerűbb. Beállítom és kész... Megpróbálom saját C programmal, ha azzal sem megy akkor talán a szervó a probléma.
TSOP1736 infra vevő, csak adat vételre kellene.
|
Bejelentkezés
Hirdetés |