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
Ebben én nem látok hibát. Látatlanban azt tudom mondani, hogy szinte 100%, hogy kikapcsolod a felhúzó ellenállásokat valahol a programodban. Konkrétan a LED-ek bekapcsolásának környékére gondolok. Ugye nem felejtetted el, hogy a PORTA = 1 például vidáman kikapcsolja a kód elején bekapcsolt felhúzó ellenállásaidat. Hiszen azokat is PORTA = XX -el kell bekapcsolni a bemenetre konfigurált lábakra.
Köszönöm a gyors választ!
Az alábbi módokon piszkálom a 0..3-as lábakat:
(ez egy speaker, be-ki kapcsolgatom ciklusban)
(ez pedig LED kapcsolás, a 0-s lábon lévő be, a többi ki) Lehet hogy ezek közül valamelyik elrontja a felhúzó ellenállásokat? Petya
A led kikapcsolás elrontja igen.
Így kéne a LED-eket piszkálni:
A lényeg, hogy a PORTA = utasítást kerülni kéne.
Köszönöm, ez volt a megoldás! Megint tanultam valamit.
Petya
Nem teljesen világos, hogy ha már szimbólumokat használtok a portlábakhoz, akkor miért keveritek a PORTA, DDRA és PINA regiszter bitjeit, van ennek valami különös oka?
Ha pl. DDRA-nak adunk értéket, akkor - én úgy gondolom - a bitnevekben is DDA0, DDA1, ... neveket használjunk, ne PINA0, PINA1, ... neveket. Ugyanígy a PORTA-hoz PA0, PA1, ... nevek "illenek". Világos, hogy (jelenleg!) a header file (iom16.h) alapján a PA0, DDA0 és PINA0 értéke is 0 lesz, de ez nem feltétlenül kell, hogy mindig így maradjon, valamint az sem kizárható, hogy egy másik típusnál máshogy van (lesz). Portoláskor egy eltérés ezekben a bitsorszámokban nagyon megtréfálhat, ha nem a megfelelő bitneveket használjuk. Idézet a header fileból:
Igazad van, de mivel nem túl valószínű, hogy valaha is ki fog jönni olyan atmel kontroller, ahol az egy porthoz tartozó 3 regiszter bitjei nincsenek szinkronban, így ez elméleti kérdés marad. Természetesen, mondjuk diploma munkának, érdemes kerülni ezt a megoldást, mert bele fognak kötni. De a működést nem befolyásolja.
Bővebben: Link Valaki válaszoljon, legyen szíves! Nem hiszem, hogy olyan bonyolult lenne a megoldás, hogy senki sem tudja! (elnézést a másodszori kérdezésért, csak nagyon várom már a választ)
Én negálnám a port állapotát, így ha egyszer megnyomod 1, következő gombnyomásra pedig 0. Ehhez először pedig alapállapotot is beállítanék a LED-es lábra.
Ha jól tudom a negálás a ! -lel történik. niches
Benne van a kódban a negálás. Az alapállapot nem oldja meg szerintem a problémát, mert nekem az kell, hogy ha megnyomom a gombot, majd el is engedem, maradjon égve a LED. Amikor pedig mégegyszer megnyomom, kapcsoljon ki. Próbálkoztam úgy, hogy megnyomáskor egy változó értéke 1 lett, és addig volt bekapcsolva a LED, amíg 1 az érték, de a változó értéke a gomb elengedésekor ismét 0 lett, és végül így is csak addig égett a LED, amíg nyomtam folyton a gombot. Tehát végülis valami olyasmi kéne, hogy ha akár csak egy pillanatra is megnyomom a gombot, akkor mentse el valahova, hogy megnyomtam a gombot, és ne írja felül, csak ha mégegyszer megnyomom. Olvastam itt valami talán hasonlót, az eeprom-ba írást, de nem tudom, mi az, és hogy kell, meg hogy egyáltalán az kell-e nekem. Köszönöm a választ!
Nem próbáltam ki, de szerintem te erre gondolsz. Valami célszerű delay kell még a kódba a kapcsoló prell menesítéséhez.
Köszönöm, ez már félig jó, de hiába teszek bele delay-t, ha túl sokat vár, akkor a nyomás után kapcsol be a LED, ha túl keveset, akkor meg olyan mintha ott se lenne. Amit én felvetettem a hsz-emben (eeprom) az járható út egyébként? Mert ha igen, akkor jobban szeretném úgy megcsinálni, mert abból többet tanulnék, mivel itt most nekem az a lényeg.
Sziasztok!
Érdeklődnék, hogy lehet-e programozni az RF-es avr-eket AVR Dragonnal?
Helló!
Az AVR-Doperrel elvileg lehet soros kommunikációt is folytatni ugye? Itt csak simán terminál programban elvileg kiválasztom a portot és összekötöm a doper megfelelő kivezetéseim a kontrollerrel és mintha FTDI-vel, vagy sima soros portra lenne kötve használható? Mert tervezek egy Demo-board-ot és akkor nem tennék rá FTDI-s soros átalakítót, ha a doper tudja ezt.
Az eeprom írás nem erre való. A delay-el tökéletesen meg lehet csinálni. Rakd át a Delay-t a példám szerinti 26-os és 27-es sor közé. Azaz oda kell beszurni azt a sort ami a delay-t tartalmazza.
Helló! mindenkinek.
Aki tud égetni AVR-t az írjon már egy P.Ü-t! Vagy valaki magyarázza el,hogy kel csinálni.A pic-el könnyebb dolgom ugyanis ahhoz van magyar le írás.
1. Csinálj egy a mellékletben szereplő kábelt.
2. Telepítsd a Ponyprog-ot. Itt letölthető 3. Csatlakoztasd a kábelt. 4. Ponyprog>Setup>Calibration 5. Ponyprog>Setup>Interface setup... 6. Állítsd be: Parallel és utánna Avr ISP I/O. 7. Probe gomb. Ha megjelenik hogy OK, akkor eddig jó. 8. Keresd meg a device menüben amid van 9. Nyiss meg egy .HEX fájlt. 10. Write Device gomb. 11. Örülj
Heló
Szeretnék építeni egy ilyen tranzisztor/fet tesztert Link A program Atmega8-as AVR-re van írva, van itthon Atmega168-am, összehasonlítottam őket, és eléggé hasonlítanak. A kérdésem az lenne, hogy a programot módosítás nélkül beégethetem a 168-ba? Fog működni? Ezzel a projekttel kapcsolatban nem értem, hogy miért van kétféle kapcsolási rajz, mivel jobb a bonyolultabb? Sajnos németül semmit nem tudok, angolt tanultam suliban. Próbáltam google fordítót használni, de eléggé értelmetlen szöveget hozott ki...
Üdv
Azért van kétféle rajz mert az amelyiken több az alkatrész az tartalmazza az autómatikus kikapcsolást, PD6-on(12-es láb) vezérli. S1-et megnyomva kap ujra tápot. Ha az egyszerűbbet építed meg akkor PD6 nem vezérel semmit és csak egy kapcsoló kell amivel a tápot kapcsolod S2 a rajzon, S1 elhagyható. ha mégis bent hagyod akkor azzal tudsz "reszetelni". Beégetheted a 168-ba menni fog.
Sziasztok!
BEzen az oldalon található frekvenciamérőt egy kicsit leegyszerűsítettem, átírtam LCD kijelzőhöz, csatoltam egy forráskódot. Eredetileg ATmega16-hoz írták, én ATmega168-at használok hozzá. Miért van az, hogy a frequency változó értéke mindig 0? Kb. 480Hz-et adok a T1 lábra, azt a 74HC191-es részt pedig nem építettem meg. Ha jól látom a szoftverben, akkor magától kiválasztja, hogy melyik bemenetet kell használnia.
Nagy okosság:
Ha már LCD-t használsz, akkor írasd ki arra a változók értékét (is). frequency = (counter*factor); Gondolom valamelyik nulla lehet. Nem néztem tovább.
A counter értéke 0, ezt már kiírattam.
A factor értéke fix, ez amolyan kalibráló, fent lehet beállítani az értékét.
Sziasztok!
A következő kérdéssel fordulnék hozzátok: Egy ATmega8 -as AVR PB2-es lábával szeretnék PWM jellel vezérelni egy ledet., de hiába keresgéelk napok óta google -ben, és itt a fórumon is nem tudom megoldani a PWM kezelését. Valaki fel tudna tenni egy abszólút egyszerű, de teljes C -s forráskódot (tényleg az elején az include-októl a legvégéig. Ha ugyanezt meg tudnám csinálni az ATmega8 -as PB2-es lábán mint ebben a cikkben onnantól a többi már menni fog, csak ebben segítsetek légyszi! Előre is köszi! Üdv! András
Üdv mindenki!
Megpróbáltam utánaépíteni ATtiny "inkrementális jeladó" cikkét. A hibám hasonló, mint gr89 problémája, amire válaszoltam. Nálam az alsó sor fekete négyzeteket jelenít meg. Felső sorban nincs semmi. A legtöbb (amivel eddig találkoztam: összes) lcd driver az LCD D4-D7 lábain kommunikál vele. ATtiny cikkében viszont a D0-D3-on kommunikál. Már beforrasztottam a szalagkábelt. Van valakinek megoldása a D0-D3 lábon keresztüli vezérlésre? Mi lehet a hiba?
A legelső dolog, hogy forraszd át a felső 4-re, mert az alsón nem lehet kommunikálni, max ha nem 4bitesként, hanem 8 bitesként használod a kijelzőt, de akkor meg kell mind a 8 láb. A rajz meg hibás. Én is néztem, hogy miért úgy van, de kiderült, hogy úgy nem lesz jó.
Tudtommal csak D4-D7-ig lehet vezérelni 4 bites módban-
Kapcsolási rajz
Jól van, akkor nem vagyok , mert én is így tudtam, de mivel a driver is gyönyörűen meg van írva, így nem gyanakodtam. Próbáltam kibogarászni az alsó képet, ahol működik, de ott nem látni, hogy hova megy a szalagkábel.
Köszönöm!
Működik! Eredeti kódban levő lcd-driverrel hibátlan. Most már csak arra kell rájönnöm, hogy miért nem számol...
Elnézést a hibás rajzért. Nyilván a megépített verzióm is a D4 - D7 adatvonalakat használja, hiszen másképp nem is működne. Már ki is javítotam. Amúgy készült egy 4x-es dekódolást is bemutató kód is. De túl bonyolult lett. Így azt nem akartam közzé tenni. Mindenesetre akit érdekel a 4x-es dekódolást megvalósító kód annak el tudom küldeni.
Abban tudnál segíteni, hogy miért nem számol?
Az 1x-es prelleg, nem próbáltam még továbblépni ezen, jónak tűnik. A 2x-es viszont csak a PD3/int1-re reagál. Csak plusz-minusz egyet hajlandó lépni. Ha PD2 magas, akkor 4000valamnnyi és 0 között billeg, ha alacsony, akkor 0 és 1 között váltakozik. Ui: hiányoltam is a 4x-es kódot, hogy hova tünt. De egyenlőre elegendő számomra a 2x-es is. Azt hiszem.
A 2x -es dekódoláshoz másképp kell bekötni az encodert. Akkor csinál ilyet, amit írtál, ha az 1X-es dekódoláshoz van bekötve az encoder, mivel ilyenkor az index jelre kerül az egyik csatorna, így folyamatosan nullázza a számlálót. Max +-1 -et hajlandó számolni.
Idézet: „ A kapcsolási rajz alapján a SZÖGADÓ-1 csatlakozóhoz kell kapcsolni a szögjeladó Z (index) csatornáját. A SZÖGADÓ-2 -es csatlakozóra jön a szögjeladó B csatornája, míg a SZÖGADÓ-3 -as csatlakozóra a szögjeladó A csatornáját kell kötni. ” |
Bejelentkezés
Hirdetés |