Fórum témák

» Több friss téma
Fórum » AVR - Miértek hogyanok
 
Témaindító: pakibec, idő: Márc 11, 2006
Témakörök:
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
Lapozás: OK   192 / 840
(#) ATtiny válasza _Petya_ hozzászólására (») Feb 22, 2010 /
 
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.
(#) _Petya_ válasza ATtiny hozzászólására (») Feb 22, 2010 /
 
Köszönöm a gyors választ!

Az alábbi módokon piszkálom a 0..3-as lábakat:

  1. PORTA |=  (1<<PINA3);
  2. PORTA &= ~(1<<PINA3);

(ez egy speaker, be-ki kapcsolgatom ciklusban)

  1. PORTA = (1<<PINA0)|(0<<PINA1)|(0<<PINA2);

(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
(#) ATtiny válasza _Petya_ hozzászólására (») Feb 22, 2010 / 1
 
A led kikapcsolás elrontja igen.

Így kéne a LED-eket piszkálni:

  1. PORTA |= (1<<PINA0); //0-ás pinen lévő LED be
  2. PORTA &= ~((1<<PINA1)|(1<<PINA2)); // 1-es és 2-es pinen lévő LED ki


A lényeg, hogy a PORTA = utasítást kerülni kéne.
(#) _Petya_ válasza ATtiny hozzászólására (») Feb 22, 2010 /
 
Köszönöm, ez volt a megoldás! Megint tanultam valamit.

Petya
(#) szilva válasza ATtiny hozzászólására (») Feb 23, 2010 /
 
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:
  1. #define PINA    _SFR_IO8(0x19)
  2. #define PINA0   0
  3. #define PINA1   1
  4. #define PINA2   2
  5. #define PINA3   3
  6. #define PINA4   4
  7. #define PINA5   5
  8. #define PINA6   6
  9. #define PINA7   7
  10.  
  11. #define DDRA    _SFR_IO8(0x1A)
  12. #define DDA0    0
  13. #define DDA1    1
  14. #define DDA2    2
  15. #define DDA3    3
  16. #define DDA4    4
  17. #define DDA5    5
  18. #define DDA6    6
  19. #define DDA7    7
  20.  
  21. #define PORTA   _SFR_IO8(0x1B)
  22. #define PA0     0
  23. #define PA1     1
  24. #define PA2     2
  25. #define PA3     3
  26. #define PA4     4
  27. #define PA5     5
  28. #define PA6     6
  29. #define PA7     7
(#) ATtiny válasza szilva hozzászólására (») Feb 23, 2010 /
 
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.
(#) vagnerjazon hozzászólása Feb 23, 2010 /
 
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)
(#) niches válasza vagnerjazon hozzászólására (») Feb 23, 2010 /
 
É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
(#) vagnerjazon válasza niches hozzászólására (») Feb 23, 2010 /
 
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!
(#) ATtiny válasza vagnerjazon hozzászólására (») Feb 23, 2010 /
 
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.

  1. #include <avr/io.h>
  2.  
  3. #define LEDon   PORTB |=  (1<<PINB0)
  4. #define LEDoff  PORTB &= ~(1<<PINB0)
  5.  
  6. int main(void) {
  7.  uint8_t led_allapot = 0;
  8.  
  9.  DDRB = 0b000001;        // PORTB állapot: 0-bemenet, 1-kimenet
  10.  PORTB = (1<<PINC4); // Felhúzó ellenállás bekapcsolása
  11.  for(;;)
  12.  {
  13.   if(!(PINB & (1<<PINB4)))     // Akkor igaz ha PINB4 = 0
  14.   {
  15.     // ide kéne még prell mentesítéshez valami delay is
  16.    if(led_allapot)
  17.    {
  18.     led_allapot = 0;
  19.         LEDoff;
  20.    }
  21.    else
  22.    {
  23.     led_allapot = 1;
  24.         LEDon;
  25.    }
  26.   }
  27.  }
  28. }
(#) vagnerjazon válasza ATtiny hozzászólására (») Feb 23, 2010 /
 
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.
(#) labu01wx hozzászólása Feb 23, 2010 /
 
Sziasztok!
Érdeklődnék, hogy lehet-e programozni az RF-es avr-eket AVR Dragonnal?
(#) Ricsi89 hozzászólása Feb 23, 2010 /
 
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.
(#) ATtiny válasza vagnerjazon hozzászólására (») Feb 23, 2010 /
 
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.
(#) nikolatesla hozzászólása Feb 24, 2010 /
 
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.
(#) neogeo2 válasza nikolatesla hozzászólására (») Feb 26, 2010 /
 
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

avrisp.gif
    
(#) Tomi20 hozzászólása Feb 27, 2010 /
 
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...
(#) Menyét válasza Tomi20 hozzászólására (») Feb 27, 2010 / 1
 
Ü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.
(#) (Felhasználó 4577) hozzászólása Feb 27, 2010 /
 
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.

code.c
    
(#) Sir-Nyeteg válasza (Felhasználó 4577) hozzászólására (») Feb 27, 2010 /
 
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.
(#) (Felhasználó 4577) válasza Sir-Nyeteg hozzászólására (») Feb 27, 2010 /
 
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.
(#) Barbár hozzászólása Feb 27, 2010 /
 
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
(#) Sir-Nyeteg válasza Ricsi89 hozzászólására (») Feb 27, 2010 /
 
Ü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?
(#) Ricsi89 válasza Sir-Nyeteg hozzászólására (») Feb 27, 2010 /
 
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ó.
(#) (Felhasználó 4577) válasza Sir-Nyeteg hozzászólására (») Feb 27, 2010 /
 
Tudtommal csak D4-D7-ig lehet vezérelni 4 bites módban-
(#) Sir-Nyeteg válasza Ricsi89 hozzászólására (») Feb 27, 2010 /
 
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.
(#) Sir-Nyeteg válasza Ricsi89 hozzászólására (») Feb 27, 2010 /
 
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...
(#) ATtiny válasza Sir-Nyeteg hozzászólására (») Feb 27, 2010 /
 
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.
(#) Sir-Nyeteg válasza ATtiny hozzászólására (») Feb 27, 2010 /
 
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.
(#) ATtiny válasza Sir-Nyeteg hozzászólására (») Feb 27, 2010 /
 
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.
Következő: »»   192 / 840
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem