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
Mellekeltem az egeszet. Maga a hex file ugy kezdodik ahogy gondolod. .map file-hoz meg nem volt szerencsem (meg nem kellett), igy elso ranezesre nekem ez magas.
A mellekelt program nem egy mukodo bootloader, csak egy egyszeru UART kommunikacio. (fogad, majd visszakuld)
Nem is latok .map file-t. Van egy .sym, de abbol nem derul ki annyi minden. De mindegy is, mert ez a hex file, amit most kuldtel, ez teljesen jo, nincs benne semmi felesleges dolog, picit tobb, mint 1k kod van benne 0x1e000 kezdocimtol. Ha az .elf file-t disasseblalom, akkor az is teljesen normalis, 0x1e000 cimen kezdodik, az interrupt vektorok vannak benne, meg minden, ami kell. Ha ezt beegeted, ez sem jo?
Jelenleg ha ezt beegetem:
- avrdude: writing flash (123984 bytes): Writing | ################################################## | 100% 68.85s -avrdude: verification error, first mismatch at byte 0x1e000 0x0c != 0xff avrdude: verification error; content mismatch - a kod viszont fut - ha visszaolvasom csak End Of Filet kapom
Itt az en tudomanyom megall. Miert eget be 123984 byte-ot, amikor a hex-ben csak 1k van. Hacsak nem azert, mert akkora gyökér, hogy nullatol kezdve eget es nem onnan, ahonnan a hex file-ban kezdodik a kod. Biztos is, mert a hexfile utolso byte-janak a cime + 1 az pontosan 123984. Raadasul az elso hibat pont azon a cimen talalja, ahol az elso hasznos byte van. Teljesen nem ertem. Az AVRDUDE-t nem ismerem, sosem hasznaltam. Meg kellene nezned az AVRDUDE leirasat, hogy esetleg nem kell-e valamit maskepp megadni, ha nem a 0 cimre egeted a dolgot.
Koszonom szepen a segitsegedet! Tegnap keso estere ugy nez ki, hogy sikerult feltolteni ket programot. Egyet a Boot Sectorba es egyet a 0x0000 cimre es mindketto futni is kepes.
A gond szerintem a Make file-ban lesz, mivel ha kulon futtatom az AVRDUDE-ot parancssorban, akkor csak azt tolti fel amit kell. Igaz ott is azt irja ki, hogy 124xxx byte feltoltve, de ott mar 1mp alatt vegez is a muvelettel.
Sziasztok!
Egy arduino Uno-val feltöltöttem a bootloader-t egy ATMEGA328P-PU-ra. Honnan tudom meg hogy életképes ? (elméletileg le elenőrizte feltöléskor , bár az uno-n is volt blink teszt villogás , tudom csak a bootloadert teszi rá .. de egy próbát megért) És hogy tehetem rá a programom? Uploading Using an Arduino Board A központi avr nem kivehető.. És a V-usb -vel valaki boldogult esetleg? (Kezdő vagyok) A hozzászólás módosítva: Szept 2, 2015
Megpróbálhatod, hogy a két Atmega328 RX TX lábait összekötöd, RX-RX , és TX-TX sorrendben.
Az UNO-n el kellene vágni a reset vezetősávot (esetleg kikapcsolható lenne jumperrel?) , ezt a reset-et rákötöd a második AVR-ed reset-jére, a fő AVR-t meg folyamatosan reset-ben tartod. Olyan, mint ha ott sem lenne. Ha nem akarod a vezetősávot átvágni, akkor bonyolultabb lesz, kell egy USB-soros átalakító, és avrdude programmal tudsz programot küldeni az AVR-edre. Lehet, hogy a reset-et neked kell nyomnod programfelöltéskor, de ne aggódj, kb. 3x próbál feltölteni kb. 500mS-os szünettel, tehát lesz időd megnyomni a gombot.
Sziasztok!
Aki már használta a BASCOM-ban az 'inputbin' parancsot és fogadott vele értelmezhető adatokat, az kérem mondja el hogy mi a pontos beállítása. ATmega8-at használok és csak nullákat kapok vissza. Köszi.
Rányomod a kakaót és az optiboot 3-at villant, külső RESET-re.
A hozzászólás módosítva: Szept 3, 2015
És mért nem müködik ami a Helpben van?
A hozzászólás módosítva: Szept 3, 2015
Kicsit sem zavar, hogy ez nem az a topic?
Sziasztok!
BMP180-al próbálok kommunikálni. A szenzor biztos, hogy jó, mert a Raspberry PI-vel működik. Inicializálom az I2C buszt:
És a main-ben, de még nem a végtelenciklusban indítanám a kommunikációt:
És a while-nál megáll minden, pedig itt még nem is címeztem. Amit még tudni kell: Valójában ez a kapcsolás, mert GY-68-as modulban vettem a BMP180-at: Bővebben: Link Egy ATmega8-al próbálkozok, amit egy Li-Po akkuról táplálok aminek a jelenlegi feszültsége 4.02V. A BMP180 modulon van egy feszstab, de elvileg -szerintem- ez nem zavar most. A Raspberry-n 3.3V-ról járt, de a faszstab miatt 5V-ról is járhatna. Van valami ötletetek? Mert már a falat kaparom.
Megvan a hiba. Egy mindenttúlélős ATmega8-al kísérleteztem, amiben a TWI halott... kicseréltem és jó.
Long típusú változót szeretnék átküldeni bájtonként. A long az 4 bájtos.
Küldeni így próbálom:
Fogadni pedig így:
Kiírni így:
Valamiért mégis azt az eredményt írja ki, hogy -4113. Hogyan kellene helyesen szétbontogatni?
Találd ki, hogy signed, vagy unsigned lesznek a változók. Legyen unsigned, azzal könnyebb dolgozni (nekem). buf[0]=szam&0xff; buf[1]=(szam&0xff00)>>8; buf[2]=(szam&0xff0000)>>16; buf[3]=(szam&0xff000000)>>24;
A fogadás szerintem jó lesz. Tényleg be tud kavarni, ha signed a változó!
Felesleges így szétszedned a változót.
Köszönöm a válaszokat!
A hozzászólás módosítva: Szept 3, 2015
A sprintf működik, de sajna a bájtok szétdobálása nem. :/
Csatoltam egy képet, amin látszik hogy mit kapok és mit kellene kapnom.
Ezt a megoldást nem én írtam neked. Egyébként pedig rosszul állítod össze a long-ot.
Nem írhatsz le ilyet, hogy buf[0] << 24 ha a buf[0] típusa uint8_t. Szerintem a fordító is panaszkodott. Előtte castolnod kellene. (long)buf[0] << 24 már helyes, mivel az összegnek is long-nak kell lennie az összes elemet castolni kell. Még egy érdekes adalék az operátorok precedenciája. Azok a zárójelek feleslegesek ahol összevagyolod a buffer elemeit. Valahogy így:
A hozzászólás módosítva: Szept 3, 2015
Kizárhatnád az sprintf függvényt is, küldd át több részben, először ellenőrizd le, hogy a részek jók-e egyáltalán. Lépésről lépésre ellenőrizz!
Köszönöm mindkettőtöknek!
Kiszámoltam binárisan, hogy pontosan melyik lépésben mit is csinálok és így megértettem, jó lett! Idézet: „Azok a zárójelek feleslegesek ahol összevagyolod a buffer elemeit.” Elég régóta programozom, de a zárójeleket mindig következetesen kirakom. Ártani semmiképpen sem árt, mert ha kirakod, akkor is ugyanaz a kód fordul le (jó esetben), mintha nem raknád ki őket. Vannak, akik szeretik fejben tartani mind a 30 akárhány művelet precedenciáját, mások zárójeleznek. Volt szerencsém napokat eltölteni precedencia hibák miatt, legalább saját magamat nem szivatom vele.
Így van. Engem a valtozo<<2+4 vert át rendesen, mert az összeadás precedenciája magasabb, mint a shiftelésé! Meg a posztfix és prefix is okozott már többször galibát, főleg ha így dolgoztam vele: if (szamlalo++>10) ... Ez mikor le lesz fordítva, úgyis két művelet, először növelés, majd if, tehát én mindig úgy csinálom: szamlalo++; if(szamlalo>10) ... Bénának tűnik, de kód szempontjából ugyanaz fordul le.
Sziasztok!
Engedjétek meg, hogy feltegyek egy kérdést. Van ez a kapcsolás. Megépítettem többször breadbordon eszerint a kapcsolás szerint működött. Annyi eltérés van az Eagle-ben megtervezett NYÁK és a próbapanel közt, hogy a maratott NYÁK-on a Q1..Q7 tranzisztorok BS170-esek és nem pedig 2N7000 esek. Ami az én problémám, hogy az áramkör áramfelvétele ingadozik. Többször rámértem multiméterrel, sehol nem találtam rövidzárat. Az áramkör nem indul be, pedig minden jól van bekötve. A mért feszültség-áram értékeket feltüntettem a kapcsoláson. (Breadboardon 40..55mA mörüli áramfelvételt mértem és nem ingadozott) Miért ingadoznak a feszültség értékek adott határon belül? A hozzászólás módosítva: Szept 4, 2015
A C3-on lévő tápfeszt nézted szkóppal? Próbáltad resetben tartani a mikrokontrollert, hogy akkor is ingadozik-e a tápfesz?
A lithium-ion cella feszültségét úgy méred, hogy az AVR tápfeszültsége sem stabil? Ebből csak saccolni tudsz! Kapcsold át az AVR 1.1-2.5V referenciára, vagy amelyik van neki, és feszültség osztóval mérjed a cellát úgy, hogy 4.5V-os cellafeszültség esetén érje el a feszültségosztón mérhető feszültség a referenciafeszültség szintjét. A biztosítékot kicserélném, ha 0.56V esik rajta. Ez óriási pazarlás! Gondolom valami PTC, vagy automata biztosíték, ami visszakapcsol, ha megszűnt a rövidzárlat. Ehelyett egy normál üvegcsöves sokkal jobb választás lenne, mondjuk 500mA-re. Ha ennél nagyobb áram folyik, az már biztos, hogy káros. A relé azért kell, ha kívülről megtáplálod 5V-tal, akkor leválassza a cellát? Elvileg felesleges, mert a DC-DC konverter figyeli a kimenetét, és ha megvan rajta az előírt feszültség, akkor lekapcsolja magát. Plusz össze is diódáztad, tehát az 5V felől a DC-DC felé nem tud áram folyni. Ehhez megjegyezném, hogy a diódán is óriási feszültség esik, ha nagyon bent akarod hagyni, akkor schottky-t rakj be, 0.1V körül esik rajta. Esetleg megoldható lenne FET-es logikával is, akkor még relé sem kattogna, és nem is fogyasztana. A hibára nincs ötletem, valószínűleg elkötés, vagy programhiba. Ezt csak te tudod leellenőrizni. A két GND miért így van összekötve? Az ott egy áramgenerátor 180mA-re beállítva? Ez az áram csak a GND2-től a GND felé folyik?
A hozzászólás módosítva: Szept 4, 2015
Digitális lábakkal hogy lehet ventillátor sebességel változtatni?
uln2003an-em van segédnek
Google: fan speed control avr, és PWM-re képes lábbal tudsz sebességet szabályozni. Vagy szoftveres PWM-mel.
|
Bejelentkezés
Hirdetés |
