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
Hát ha az adatlapba az van írva, hogy max 8MHz, akkor az biztosan úgy is van. Max 80Ft egy kvarc, a HEStore-ból 480Ft a posta.
Nem akarok veled vitatkozni, de amit az adatlapban ir, azt meg jocskan tul lehet hajtani. A kvarc nem lehet mas erteku, mert itt adatatvitelrol van szo.
Te tudod. Bár akkor nem értem, hogy miért nem próbálod ki.
Vagy esetleg érdeklődj az MSC Budapest-nél, hátha tudnak picit olcsóbban adni. Szerintem viszont megér 3000Ft-ot, hogy stabilan működjön, gondolom mivel ekkora AVR-t használsz nem kis dologról van szó, aminek stabilan működnie kell.
Megnéztem amit küldtél és ki is javítottam. De nem működött. Úgy látszik én is magyarázok hiába neked. A feltett mintaprogramod pedig szintén nem működött. A a mátrix bill.-es programodat meg megnéztem de nem tudom mit nem lehet felfogni abban, hogy kezdőként egyelőre nem tudom kihámozni a lényeget belőle sajnos. Olyan kérdést tettem fel amit két mondatban meg lehet válaszolni ehelyett jössz itt a fellengzős szöveggel meg a lényeg kerülgetésével.
De itt be is fejezem a diszkussziót nem vagyok hajlandó sárdobálásba átmenni. Aki segíteni próbál annak továbbra is köszönöm!
De veszem a fáradságot, rendszeresen el szoktam olvasni. Csak lehet, hogy neten keresztül harmadjára sikerül megérteni azt amit élőben akár félszavakból is.
Idézet: „Megnéztem amit küldtél és ki is javítottam. De nem működött.” Hulla fáradtan megírtam neked egy példaprogramot magyarázattal, amiben ejtettem egy hibát, amit kb. 20 perc múlva trudnai ki is javított. Te viszont szerintem nem javítottad ki a hibát. Ha kijavítva a programot bemásoltad volna, segítettük volna és szerintem még most is segítenénk, ha hagynád. Az AVR-ekkel való ismerkedést nem ilyen komoly programokkal kell kezdeni, mint a 4X4-es billentyűzet mátrix, hanem mint például a LED villogtatás. Most nem szeretném visszakeresni, hogy hányszor írtuk le Neked hogy hogyan kell megvizsgálni egy port logikai állapotát if-el, de legalább harmadszor ugyan azzal a hibával másoltad be a programod. Idézet: „Olyan kérdést tettem fel amit két mondatban meg lehet válaszolni ehelyett jössz itt a fellengzős szöveggel meg a lényeg kerülgetésével.” Lényeg kerülgetésével? Trudnai-val összehoztuk neked a programot, neked csak 4 helyen kellett volna megcserélned egy szót. Hogy segíteni tudjunk, nem csak mi kellünk, hanem Te is. Továbbra is várjuk (ha mások nem, akkor én igen) a kijavított példaprogramomat, ami még nem működik és szívesen segítünk, segítek a hiba kijavításában. :yes: Ne egyből úgy kezd, hogy két portot kötsz össze, először csak egy porttal mennyen a LED bekapcsolás, ha azzal megy, majd átalakítod két portosra. Mint írtad kezdő vagy, akkor még nem is egyből a LED gombnyomásra kapcsolásával kellene kezdeni, hanem LED villogtatással. Ez már működik? Szívesen segít mindenki, de megírni senki se fogja helyetted. Szerk.: Kijavítottam helyetted a hibát. Ne felejtsd el beilleszteni az #include-okat, mert azok nélkül nem fog működni.
Nem próbáltam ki, de elvileg működnie kell. PB4 és a test közé a nyomógomb megy, a PB1 és a test közé pedig a LED és egy ellenállás vele sorba. Ha nem megy szólj.
Szia!
Köszönöm a türelmet és a segítőkészséget. Azért voltam kissé indulatosabb a kelleténél mert idegesít, hogy nem vagyok tisztában teljesen az mcu specifikus szintaktikai formulákkal és így egyelőre nem, vagy igen nehezen értelmezem a komplexebb kódokat mint amit ajánlottál is például. Alap kacsolásokat már építettem kísérlet gyanánt. Pl.: 7 szegmenses számláló 7447-el, tranyós erősítőfokozat reléhez, stb. Azok még működtek és értettem is amit írtam csak ezekben ugye nem kellett bemenetként portot használni, meg tulajdonképpen semmi komoly(abb) műveletet. Kicsit türelmetlen vagyok elismerem. Ezt a kódot nézegettem , maga a logikája kb. ugyanaz mint az enyém lenne csak ez PIC-hez való ugyebár. Most van egy angol nyelvű könyvem az AVR-ek C nyelvű programozásáról azt el akarom olvasni, megérteni az alapokat mert úgy gondolom az kell ahhoz, hogy egyáltalán kérdezni tudjak és a választ is megértsem. Természetesen a kódot amit imént írtál meg fogom nézni alaposan(!) -már el is mentettem- és ha problémám lesz szólok. Üdv! Axel"
Szia!
Csatolok kettő World dokumentumot, amit még én írtam réges régen, egy darabig feljegyeztem pár dolgot, hogy ha elfelejteném valahol meglegyen, szerintem Neked is tud segíteni. Arra viszont nem vállalok garanciát, hogy minden jó benne, mert régen írtam, de az alapokat meg lehet belőle tanulni. Bárki szabadon felhasználhatja, szabadon terjeszthető de csak az írója nevét feltüntetve.
Nagyon hasznos dolgokat írtál le, ilyen magyarul érthető leírások tudják elősegíteni a programozás tanulását
Próbáltam csak röviden, tömören a lényeget összeszedni, az egyikben inkább az AVR, a másikban a C felé irányulva. Érettségi után talán egy cikk is lesz belőle, mondjuk egy Atmega8-al.
Mindent az internetről szedtem, fórumok, Hobbielektronika.hu, AVRFreaks.net (ezt nagyon ajánlom mindenkinek, rengeteg hasznos dolog megtalálható itt), Google, adatlapok.
Csupa joindulatbol, es joszandekbol: Nem AVR-t kell tanulni, hanem digitalis alapokat, es egy (tobb) programozasi nyelvet, (esetleg olyant, amihez van fordito AVR-re). Ajanlom a C-t. Vagy valami basic -et. Az egyszerubb. Aztan veszed az adatlapot es megirod, amit akarsz. De ez nem ket het, es nem is ket honap igy egyutt.
Hogyha külső kvarcot szeretnék használni, akkor mindenképpen kell két kondenzátor, amiket a kvarcra meg a GND-re kell kötni? Anélkül nem megy?
Igen, kell, anélkül nem megy.
Köszönöm a választ, akkor most bontogathatok valahonnan, mert sikerült kihagyni a rendelésemből.
Ahogy előttem is írta valaki, ne AVR C-t tanulj meg, hanem tanulj meg általánosságban programozni C-ben, mellette pedig a digit alapokat érdemes felszedni. AVR-t C-ben lehet programozni, de az semmiben sem tér el az ISO-tól, viszont rengeteg részt nem lehet használni, amit érdemes megtanulni előtte. Az mcu specifikus részek meg megint nem specifikusak - minden mikrokontroller alapvetően egy kaptafára megy: be kell állítani bizonyos regisztereket, engedélyező biteket, bitek állapotát kell figyelni, IO-t kell beolvasni, stb. Ez az adatlapból jön. Viszont nem rajtuk kezdenék C-t tanulni. Pl a jó öreg hello word mcu-n sokkal nagyobb falat, holott tényleg azzal a legegyszerűbb kezdeni, kontrolleren még egy ledet kigyújtani is nagyobb mutatvány.
Én AVR-en tanultam a C-t és aztán tanultam meg a PC C++t.
C-ből a ciklusszervezést, feltételes utsaítsokat, elágaztatást, tömb és string műveleteket, függvényírást meg egy két alap dolgot már ismerek azért. Nem a "hello world"-nél tartok, szóval a fő gondom nem ez. És ahogy kivettem az eddig átnézett kódokból mcu programozásnál sokkal mélyebbre ritkábban mennek le ott a lényeg inkább a hardver működésének, pontos ismerete. Nyilvánvaló persze, hogy mellette még bőven van mit tanulnom C-ből. Mikrokontroller specifikus alatt pedig a hagyományos PC programozástól való szintaktikai eltéréseket értettem.
variszabinak köszi a segédleteket! Idézet: Ugy erzem nem ertetted meg a lenyeget. „..specifikus alatt pedig a PC programozástól való szintaktikai eltéréseket értettem.”
Idézet: „Ahogy előttem is írta valaki, ne AVR C-t tanulj meg, hanem tanulj meg általánosságban programozni C-ben, mellette pedig a digit alapokat érdemes felszedni. AVR-t C-ben lehet programozni, de az semmiben sem tér el az ISO-tól,” Gondolom ANSI C-t akartal irni, de most nem ez a lenyeg. Egy mikrokontrollernel eleg nehez sokszor betartani az ANSI eloriasokat. Pl. az integer promotion-t sokszor ledobjak, hisz tobbnyire az csak felesleges kod novekedessel jar, minthogy egy 8 bites MCU-n ugye az alap tarolasi egyseg 8 bit az integer 16 bitjehez kepest. Tehat ha a C minden 8 bites szamot szepen felkonvertal 16 bitre, elvegzi a muveletet majd csonkolja 8 bitre, hat az kisse feleslegesnek tunhet es pazarlasnak is. Es akkor ott van az architekturalis kulonbseg, ugyanis a C-t Neumann kornyezetre talaltak ki, Harvard architekturara csak kuszkodesekkel es megalkuvasokkal lehet railleszteni. Pl. ki kell kenyszeriteni tarolasi osztalyokat, gond van ha a string kezelo fuggvenyt RAM-ban vagy ROM-ban tarolt stringekkel hivogatjuk, ha speci regiszterekbe szeretnenk kenyszeriteni egy valtozot, akkor azal igen csak meg kell szenvednunk stb. Nem is beszelve arrol, hogy mit muvel a gcc a bit teruletekkel. Pl. a "hagyomanyos" PORTA &= 1<<4; szepen kioptimalizalodik, azonban ha letre hozok egy bitfield-es PORTA valtozot, akkor azzal a fordito igencsak megkuszkodik (pl. PORTAbits.b4 = 0). Osszessegeben en mai napig ugy velem a C nem mikrokontrolleres kornyezetbe valo. Ami miatt hasznaljuk, mert egyszeruen sok ember C-t ismeri, es igy ugy gondoljak a tanulasi gorbe nem annyira meredek. Vagy talan csak nincs jobb nala?
A felhuzo ellenallasok globalis tiltasat(ekkor nem kell egyesevel tiltani a bemeneteken) a
muvellettel lehet elerni. De javaslom az adott uC adatlapjanak elolvasasat, ott az "I/O Ports" cimu fejezet alatt le van irva minden ide tartozo informacio.
Nem tudom, hogy miért szükséges ez. Alapból minden felhúzóellenállás tiltva van. Most pedig nem tiltani kell, hanem engedélyezni.
Idézet: Ajanlj egy jobbat „Ami miatt hasznaljuk, mert egyszeruen sok ember C-t ismeri, es igy ugy gondoljak a tanulasi gorbe nem annyira meredek.” Nem utolso szempont az sem, hogy PC-n az alap a C. (kernelek, stb.) Es ha mar valaki elsajatitotta akkor viszonylag konnyeden hasznalhatja uC kornyezetben is ezt a nyelvet. Es bar tobbfele eszkoz szpecifikus C nyelv letezik, megis van annyi hasonlosag, hogy lehet hasznalni ansii C ismerettel.
Mert az o megoldasa pillanatnyilag magas aktiv. A teljes kodjat meg nem latta senki, a konkret aramkori kapcsolast meg nem latta senki. Csak reszleteket tudunk. Az, hogy a PUD-ot 1-be allitja artani nem arthat, viszont csokken a hibalehetosegek szama. Kb ingyen van az az egy sor.
A C hasznalatanak valojaban nem a tanulashoz van koze, hanem a program elkeszitesehez szukseges idot jelentosen redukalja, igy jobban megeri anyagilag, meg ha erosebb uC-t is kell venni a nem idealis optimailzacio miatt.
(Pl. ha komplett tcp/ip stacket+http-t le kene programoznod asm-ben megneznem mennyi ido alatt vegeznel.) A kuszkodest AVR eseten nem a neumann vs harvard architektura adja, hanem az, hogy ugyan azokkal az utasitasokkal nem ered el a flash-t mint a ram-ot. AVR32 eseten boven nincs ilyen problema mert a 32 bites cimtartomanyban van mappelve minden. Raadasul van lehetoseg inline assembly-re ha nagyon szukseges. Idézet: „A kuszkodest AVR eseten nem a neumann vs harvard architektura adja, hanem az, hogy ugyan azokkal az utasitasokkal nem ered el a flash-t mint a ram-ot.” Pontosan, epp errol beszelek! Azaz mig egy Neumann architekturanak a lenyege, hogy a program es az adat ugyanabban a memoriaban van tarolva, a Harvard-ban ez elkulonul. Idézet: Bővebben: Link „The Harvard architecture is a computer architecture with physically separate storage and signal pathways for instructions and data.”
ATtiny13-hoz külső kvarcra mekkora kondenzátor kell? Olvastam itt olyat, hogy 22pf, csak biztos szeretnék lenni benne. És azt jól értem, hogy a kvarc mindkét lábára és a földre kell kötni őket? Ja és ponyprogban melyik fuse bitet kell átállítani, hogy külső kvarcról menjen? Nagyon köszönöm.
Szia!
Én mindig 22pF-ot rakok, az biztos jó. Amúgy a múltkor csináltam 10db panelt, és elfogyott a kondi. Két darabra nem jutott. De azok is gond nélkül elindultak. Persze később pótoltam, az a biztos
Köszönöm szépen! És a másik két kérdésemre tudja valaki a választ?
Idézet: „Ja és ponyprogban melyik fuse bitet kell átállítani, hogy külső kvarcról menjen?” Az adatlap Memory programming része ezt részletesen kitárgyalja.
Köszönöm, de sajnos nem találtam meg. :no: Majd később nekiállok és átnézem mégegyszer.
|
Bejelentkezés
Hirdetés |