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
Az egy dolog, hogy mit definiálsz, de ezt a 8MHz-et be is kéne állítani.
Külső kvarc, vagy belső oscillátor, konfigbitek hogy állnak?
Nincs külső kvarc.A belső oscillátor,nem tudom hogy megy-e?
Azt hogy nézhetem meg?
Nyilván megy, különben a 7 sec-et sem csinálná.
https://ww1.microchip.com/downloads/en/devicedoc/doc2535.pdf 6. fejezet
Be is programoztad a fuse biteket?
Ha itt 9.6MHz van, akkor a define-nak is illik ennyinek lennie, de ettől sokkal nagyobb a freki különbséged.
Nézem a pdf-et amit linkeltél,de az angolom elég gyatra,igy egy darabig el leszek vele.
A fuse bitekhez nem nyúltam,mert nem tudom mit kell állitani rajta. Akkor a #define F_CPU 8000000UL Irjam át #define F_CPU 9600000UL-ra?
Nyilván, de ha a CKDIV8 be van kattintva, az még 8-al oszt...
6.2.2 Calibrated Internal 4.8/9.6 MHz Oscillator és 6.3 System Clock Prescaler
Kivettem a CKDIV8 ról a pipát.Belöttem 4.8 MHz-ra a oscillátort .Próba.
Be is programoztad a fuse biteket? Vagy csak a szoftver töltöd le?
Milyen fejlesztő környezetet használsz? Az a fejlesztőkörnyezet tudja egyáltalán értelmezni a #define F_CPU -t? A hozzászólás módosítva: Nov 8, 2020
Valószinüleg,az kimaradt,
de ezek vannak beállitva.
Mi maradt ki? Hiába állítod be, ha nem progizod be a fuse-t
ÉS azt hogy tegyem? Nagyon süti vagyok hozzá még.
Ha a fele kérdésre sem válaszolsz....
Milyen fejlesztő környezetet használsz? Az a fejlesztőkörnyezet tudja egyáltalán értelmezni a #define F_CPU -t? Milyen progival/programozóval sütöd be a szoftvert?
Ilyen? https://www.hobbielektronika.hu/cikkek/avr-doper_usb-s_isp_programo...l?pg=9
nézd meg a videót. Felül program fül mellett fuses fül?
Közben kiderült a hiba oka. Nem "human error" volt
Ez a vacak pir szenzor 7 mp-ig küldte a jelet. Köszönöm a segítséget.
Valószínűleg eleve lámpa kapcsoláshoz tervezték. Nincs rajta potméter, amivel állítható az idő? HA nincs, akkor valamelyik ellenállást kell lecserélni rajta.
Az F_CPU nem azt mondja meg, hogy mennyivel menjen a CPU. Az annyival megy, amennyit beállítasz neki a fuse biteknél. (Mondjuk később is lehet osztani rajta.) Az F_CPU a delay-nak mondja meg, hogy hány ciklust számoljon.
Szia. Van rajta potméter,és minimumon volt,és ezért "csak" 7mp-ig volt aktív.
Én a következőképpen kerülném/oldanám meg a problémát:
1. Bejövő portnál csak az élet figyelném, nem a szintet, és interruptor használnék. Amikor bejön az IT, bekapcsolnám a LEDet, várnék 200ms-ot, majd kikapcsolnám, és ezután élesíteném ismét az IT-t. Mivel az eredeti programban sem gond a 200ms-es várakozás, így gondolom nem probléma itt sem. 2. Ha egyébként sem csinál semmit mást a cucc, akkor maradhat a mostani program alapvetően, csak az if rész igaz ágába beletenném a kikapcsolást is a 200ms-es várakozás után, majd további 8s várakozást. Addigra biztosan megnyugszik a pir szenzor. Az if hamis ága pedig feleslegessé válik. 3. Ha tervezed, hogy mást is csinál majd a kütyü, akkor a várakozást is IT-be tenném (a 200ms-ot is és a 8s-ot is, majd csak ezután élesíteném a bemenetfigyelő IT-t).
Szia. Igazából már most tökéletes a kód,mert majd 30 mp lesz a végső időintervallum,csak gondoltam kipróbálom,hogy jól írtam-e meg a programot.
Így igazából nem alakitok rajta semmit,de köszönöm!
zamatőr, csak most láttam a kérdésedet, nem tudom hogy megoldódott-e már. Nem teljesen értem, hogy egy idő után átíródik a memőria, vagy mindjárt programozás után nem jó?
Csak mert nekem volt egy olyan hibám, hogy egy bootloaderes avr egy idő után mindig megromlott, hibás volt a memória tartalma, újr kellett programozni. Kiderült, hogy a brown-out-detect nem vot bekapcsolva, és feltételezésem szerint áram lekapsolás után, mikor a táp kondiban annyira csökkent a feszültség, hogy már nem tudott megbízhatóan működni, átugorhatott a bootloader kódjának a belsejébe, és felülcsapott pár bájtot a program memóriában.
Sziasztok!
Úgy hallottam hogy MPLABX -ben is lehet AVR-t programozni, csak kell hozzá valami plusz progi vagy valami beépülő modul amit le kell hozzá tölteni, de nem tudom mit kell és hogyan. Ha valaki tud nekem ebben segíteni akkor azt megköszönném. Előre is köszi a segítséget!
Mikor utoljára néztem Atmel Studiot az egy testre szabott Visual Studio volt. Mivel ez nagyon nem az én világom, így tovább nem foglalkoztam vele, de mivel Microsoft, így linuxon tuti nem ment. Nem hiszem, hogy ez azóta változott volna, túl kellemes csalódás lenne a Microsofttól.
Hát azt nem is tudtam hogy Microsoft termék . Akkor valószínű hogy nem lesz Linuxra, de valami megoldás érdekelne hogy AVR -re is tudjak programozni.
Ha linuxon akarsz dolgozni, akkor neked kell összeraknod a toolchain-edet. Visual Studio Code-ot lehet linux-ra is telepíteni (a mai Microsoft már nem a 20 évvel ezelőtti cég). Rengeteg nyelvet támogat a kiegészítőin keresztül. Nem tudom, mennyire könnyű összehozni benne a debug részt AVR-e (én magam már régóta inkább ARM-okat programozom, az AVR nagyon elavult), de programot írni rájuk minden további nélkül lehet benne.
MPLABX alapból támogatja az AVR-t, hiszen az is Microchip termék. Az IDE pedig fut mindhárom nagy operációs rendszeren. Nem kell semmit sem neked összerakni. Letöltöd, és működik.
Ami neked kell az a microsoft vscode (for linux) es annak a platformio extension-je. Azzal csillio board-ra tudsz fejleszteni, nem csak atmel.
Nem remlik semmi extra (a beallitasokkal kapcsolatban), millio leiras van rola a net-en. Lehet kezzel is hegeszteni sajat cuccot ha akarsz, pl ha szigoruan assembler-ben akarsz fejleszteni, akkor kell(het) is. En ubuntu alatt hasznalom. A hozzászólás módosítva: Nov 30, 2020
|
Bejelentkezés
Hirdetés |