A kijelződ nem használ semmilyen órajelet.

Amit elrontasz, hogy nem tartod be a specifikációban meghatározott késleltetéseket.

Az LCD illesztése messze nem triviális és nem biztos, hogy érdemes újra feltalálni a kereket. A következő kódot nézd meg és a delay-eket másold ki belőle:

Program link itt

Hozzátenném, hogy a _delay_us rosszul működik, ha az F_CPU nem 8000000-en van, hanem 1000000-en.

Bővebben: Link

Sziasztok!

Lehet AVR chip-en mp3-at tároltatni és azt visszajátszani? Makett jármű hangeffekthez lenne szükséges.

Az AVR-ek flash memóriája ehhez kevés (64-256Kb), kell egy SD kártya. Úgy már megoldható. Vagy pedig annyira összetömöríted a hangfájlt, hogy ne foglaljon sok helyet.

Lehet, ha van elég memoria benne. Nézz be a digitális modellvasutak topicba. Azokban pici modulokban 10-20 mp-nyi hang van ráadásul nem is MP3 alakban.

Sajnos a probléma továbbra is fennáll.
A rolandgw által linkelt oldalról kipróbáltam egy 8 bites demo kódot. Ha internal 2MHz-től fentebb megyek, akkor mindenféle katyvasz jelenik meg a kijelzőn, vagy össze vissza jeleníti meg, éppen hogy sikerül.

Az alábbi linken találtam néhány specifikációt.
"Correspond to high speed MPU bus interface
 2 MHz (when VCC = 5V)"
Hitachi 44780

Nem tudom pontosan ez itt mi akar lenni.

Megoldódott, sajnos ez a demo kód is problémás!
Ahogyan írtad a késleltetésekkel volt a gond.
Köszönöm

A jo display meghajtás handshake tipusu, azaz a proci megvárja mire a display visszajelzi a küldött jel fogadását. Azok az egyszerü display meghajtok sajnos csak bizonyos sebesség mellett mennek, illetve minden idözitést ujra kell irni, ha más sebességü a processzor. Ezért én is inkább rááldoztam egy hetet, de megirtam a handshakes display meghajtot, ami bármilyen sebességnél megy ( mert nincs benne semmi ami az orajeltöl függ).

És plusz egy pin.Peter Danegger kód tökéletesen működik,ráadásul bárhova tehető a vezérlés,nincs egy porthoz kötve.

Igen, plusz egy pin, de profi megoldás

MP3 lejátszó IC 1200 Ft-ért, SD kártyáról

MP3-TF-16P

> És plusz egy pin.

Én az LCD-met évekig jegeltem, mert 16 lába volt, azaz a breadboard-on legalább 32 vezetékvég megfelelő helyre történő bedugásával kellett beizzítani.

Nemrég vásároltam a kínaiaktól 400 Ft-ért I2C LCD átalakítót, azóta használom is. Nem mindegy, hogy 4 vagy 16 vezetéket dugdosunk össze-vissza.

Vannak sporolos megoldások is, 4 (8) vezetéket simán ki lehet sporolni.. Persze az I2C az más tészta.

köszönöm a válaszokat, az ötlet nem is olyan rossz. Nagy látványosság lenne, ha a fények mellett hang is lenne. A szóban forgó makett egy busz. Bekapcsoláskor egy kis demo futna le, pl. indexlámpák majd helyzetjelzők, belsőtér világítás kapcsolna be, közben pedig buszhang lenne. Lehet a sok LED kapcsolgatás és villogtatás már önmagában nagy program lenne.

Egy jobb dekoder ezt mindet tudja, söt egy motort is tud még extra vezérelni.

Üdv!
Két atmega8-at szeretnék összekötni SPI-vel. Az egyik 8, a másik 1 MHz-n futna. A 8MHz-s lenne a master, így a max generált SPI órajel 4MHz lenne. Kérdésem: a slave 1MHz-s képes lenne így 4MHz-vel fogadni a beérkező adatot, vagy ha nem, akkor legfeljebb mennyivel?

Idézet az adatlapból (bár igen nehezen található meg, nincs az AC karakterisztikák között)

Ez alapján a slave fő órajelének maximum a negyede lehet az SCK órajel.

Nagyon köszönöm!

Elvileg a fele is lehetne, de annak tényleg a felének kell lennie vagy lassabbnak. Az AVR úgy működik hogy a portlábain minden órajel ütemben 1-szer történik mintavételezés, így bármilyen külső jel HI és LO állapotának 1-1 órajel erejéig stabilnak kell lennie, már ha valóban érzékelni is szeretnéd őket. Az RC oszcillátornak megvan az a szépsége hogy nem pont annyi, 1-2 százalékkal lefelé és felfelé is eltérhet. Ezért egy 1MHz-es AVR valószínűleg nem fog 500kHz-es SPI jeleket venni. Szerintem nem vesztesz vele ha a slave-t is 8MHz-en járatod, de a legnagyobb SPI órajel így is csak 2MHz lehet.

Egy olyan adatbuszt implementáltam, ahol az órajel nem mindig egyenletes ütemű, átvitel közben akár meg is szakakíthatja a folyamatot egy isr és a visszatérés után folytatva hibátlan eredmény születik. Létezik már ilyen technológia? Mi a neve? Fontos, hogy a megszakításvezérlés minden áron működjön.
Köszönöm, az információkat.

Szinkron adatátvitel a neve.

Kérdés, hogy HW vagy SW intézi az átvitelt valamint van-e külön órajeled.
Ha van órajel és HW veszi, akkor mindegy, úgy is órajel szinkronizált a cucc.
Ha tisztán SW-es az átvitel, akkor lehet kézfogásos az egész (3 vezeték, 1 adat, egy "adat érvényes" jel az adótól, egy "elfogadtam az adatot,jöhet a következő" a vevőtől.
Ha bármelyik túlfut ISR miatt, addig várakoznak. A szinkron átvitel emlékeim szerint időszinkronos (szoros időzítésű) átvitel, az esetleges elcsúszások miatt ndb adat után kötelezően szinkronkarakterek mennek, amik behúzzák a vevőt. Az aszinkron soros is byte-aszinkron / bit-szinkron átvitel. Remélem, nem értettem félre a kérdést...
JAni

Szoftveresen oldom meg a dolgokat. Hát arra voltam kíváncsi, hogy ilyen bitre bontható adatátviteli technólógia létezik-e valami létező elnevezéssel, hogy esetleg az én megoldásomnál jobban meg lehetne csinálni. Én úgy csináltam most meg, hogy van egy master és egy slave. A masteren generálom az órajelet és mindig az küld ki adatkérést. A slave-n egy megszakításom van, ami emelkedő élekre működik. 8 bitet küldök és egy paritás bitet. Ha adatkérést küldök, akkor a slave 1-el kezdődő parancsot kap és minden küldött bitre visszaküldi a megfelelő helyiértékű választbitet. Addig nem írom ki a puffer tartalmát a megfelelő változóba, amíg be nem fejeződik a tranzakció. Lehet, hogy nem használok szakszavakat, de én mindent iskolában tanultam, bocsi

Sziasztok.

Van valakinek tapasztalata AVR Dragon és Windows 8.1 (x64) párosításáról? Minden működik rendesen?

Előre is köszi!

Az egészet kicsit távolabbról kell szemlélni. Sokféle megoldás létezik, függ attól, hogy külön van-e adó-vevő adatvezeték, mekkora időzítések time-out, max. zavaró ISR idő stb. Gondolom nem kvázi-kétirányú portod van, azzal nagyon egyszerű (lenne). Két vezetéken egyirányú olvasás (1db adat+ 1db órajel) lehet a következő, ami nagyon "időfüggetlen":
Alapesetben órajel=1, (ez jelezheti,hogy van érvényes adat a SLAVE-ben, ha 0, akkor konvertál vagy más baja van). Master kér adatot, csinál egy 0 impulzust, ami Slave INT-re megy.
Ha a Slave ráér, kiteszi az ADAT-vezetékre az 1. bitet és az órajelen visszaküld egy 0 impulzust (érvényes adat a vezetéken) a MASTER-nek, az is INT bemenet természetesen. MASTER ezt beolvassa, ha odaér és kiküld egy 0 impulzust az órajelen (jöhet a következő bit). Aztán, ha nagyon ráérnek, gyorsan le is zajlik, ha nem, akkor ott, azon a bitpozíción állnak. Ha AVR a uC, akkor fordítgatnod kell az ÓRAJEL port irányregiszterét. Egyszerűbben: órajel bemenet mindkettőnél, Master átkapcsol kimenetre és 0-t küld, ezután megint bemenet. Slave kimenet lesz, adat kirak, küld 0 impulzust, bemenetre visszafordul. Azért itt is vannak veszélyek, figyelni kell a sorrendre meg az INT enngedélyezés/tiltásra és mindig figyelni kell a vonal állapotát, hogy adható-e impulzus (a legrosszabb helyen is befuthat hosszú ISR, ezt védeni kell 1-2 utasítás ideig mindenképp)
Külön kifejezést nem ismerek erre az átvitelre, de biztos van...
JAni

Minden megoldható, csak azt (is) nézni kell mire képes a hardver. Lehet minden fel(-és le) -futó élnél megszakítást generálni, de akkor biztosítani kell hogy egy-egy ilyen "börszt" után legyen elegendő ideje a processzornak feldolgozni azt. Azt sem árt tudni hogy ha minden 8(-16-...) bit után egy bájttá vagy szóvá rakod össze az eddig vett biteket akkor annak feldolgozási ideje is hosszabb lehet.

Ha az a másik interrupt olyan fontos hogy egy (egyébként rövid) vételi börszt tiltását eredményezi akkor el kellene gondolkodni hardveresen segített átviteli módokon, pl. SPI, I2C, USART. Ezeknél a bitek vételét nem gátolja meg semmi, az a háttérben történik. Az USART-nál(aminek van szinkronizált módja is) pedig az éppen fogadott(vagy küldés alatt lévő) bájton kívül még van 1-1 puffer bájt is, tehát a processzor egy egész bájtnyi időt "ki tud hagyni" anélkül hogy adatvesztés lenne.

Visszatérve a Te megoldásodra: ha maradsz a bitenkénti megszakításgenerálásnál akkor én ezt a megszakítást előrébb venném a prioritási listában, márcsak a rövidsége miatt is. Ez azt jelenti hogy a "zavaró megszakítás" elején egy "sei" utasítással engedélyezem a további megszakítások beérkezését hogy (jelentős) késlekedés nélkül lekezelhető legyen az átvitel. A második megoldás a fentebb már elhangzott handshake, ahol a vevő egy külön vezetéken jelzi hogy tudja-e fogadni a következő bitet vagy sem, illetve annak rövid átbillentésével jelezni tudja azt is hogy vette-e a legutóbbi jelet. E jelzés késleltetésével a következő bit átküldése is késleltethető.

Sziasztok!
AVR-el olvasnék több ds18b20 szenzort mellette fut timer és uart megszakítás. Ha a mainba rakom a szenzorok olvasását akkor nem olvassa be rendesen az értékeket. Ha a timerba akkor lefogja timert. Esetleg valakinek valami ötlete van-e? Segítséget elöre is köszönöm.

Szia!

Én a következőképpen csinálnám/csináltam:
- a timer interruptban minden meghívás után egy static változót növelni, amikor eléri a kb. 1sec időtartamot, akkor egy volatile jelzőt 1-be állítani. pl. 100Hz-es timer esetén, ha a változó eléri a 100-at, akkor jelző = 1, változó =0; (azért kell kb. 1 sec, mert a ds18b20-nak 12bites módban valahol 750ms a mérési ideje)
- a főprogramban figyelni, hogy ez a jelző 1 lett-e
- ha igen, akkor lenullázni ezt a jelzőt, lekérdezni a hőmérsékletet, elindítani a következő mérést, kijelezni a hőmérsékletet
- aztán csinálja azt a program amit kell

Sziasztok!

Egy áramkörömben van egy kis probléma. Ezt az encodert használom. A közös (C) a testre van kötve, a bal szélső az A pedig az INT0-ba a PD2-re, a B pedig a PB6ra. ATmega8L-t használok.
Amikor jön az interrupt (leeső élre) megvizsgálom a PB6-ot és ha magas akkor jobbra tekert, ha alacsony akkor balra. Legalábbis így működött egy másik alkalommal. Most nem hajlandó működni.
Ha esetleg véletlenül felcserélném a B-t és az A-t attól mág működnie kell, ugye?
Mi lehet a gond?

Szerk.: Természetesen a felhúzóellenállás be van kapcsolva, és a tápfesz mérhető az encoder lábain. Továbbá 1-1 100nF-os kondival is próbáltam a test felé.

Elöször így csináltam. 7 másodpercenként és 7 szenzort olvastam a főprogramban. De az olvasás hibás volt. Be tettem az olvasást az ISR-be ott müködött az olvasás, de megfogta az idözítést. Most azt probálom, hogy másodpercenként egyszerre csak egy szenzort olvasok a mért érték meg megy változóba.