Én valahogy mégis jobban örülnék a működésnek, mint a szépségnek...

Engem hasonló képpen szivatott két összeérő vezetősáv. Fél órán keresztül néztem a nyákot, semmi hibát nem találtam, majd tűvel megkapargattam minden forrszem közelében lévő vezetősávot. Ezután lett jó. Egyébként nekem is ez a terv alapján van megépítve az a 74-es IC környékén volt a hiba.

Köszi!
Opto-n gondolkodtam én is, de nem szeretném felhasználni erre az avr idejét. Az lenne a jó ha erre építenék egy céláramkört ami jelez a procinak ha kiesés volt.
Vettem már 220n-s 600V-os kondit, ezeket rákötöm úgy a 230-ra ahogy mondtad (ha nem sok a 220nF), de itt elekadtam.

A bemenet felallasa legyen ugyan ez. Az opto kollektorat kosd a tapra, emmiterere kossel egy parhuzamos RC-t. Ugy kotsd, hogy a masik fele a foldon van. Az opto/RC kozos laba-t kosd ra egy komparator + bemenetere, es a - bemenetre pedig fesz osztot tapfelre. Ez ugy fog mukodni, hogyha megszunik a 230 akkor elkezd kisulni a kondi az R-en keresztul. Ha a tapfesz fele ala csokken, akkor alacsony szint jon ki a komparatorbol, amit az avr egyik ext. interruptjara kothetsz. Az RC idoallando legyen 5ms, igy kb 10 ms kieses utan kapsz jelzest.

Köszi!

Ez kell nekem!

Átnéztem ezredjére, de ha van hiba, én nem találtam meg... Kicsengettem az összes vezetősávot és az egymás mellett futókat is. Se zárlat, se szakadás. Ma már nem, de ha nem oldódik meg a probléma a segítségetekkel, akkor van még egy kimaratott nyákom, amit megépítek, hátha tényleg valamit elrontottam.

Nekem is az volt az első, hogy sípolgattam, de semmi nem volt. Mivel a két sáv között pár 100 Ohm, vagy több is lehet, amit sípolással nem tudsz kimutatni, de ott van és alattomos jelenségeket okoz.

Egypár pont amit átnézhetnél. Esetleg jobb kép a nyákról?

A programozót CDC vagy HID módban használod?

A programozót biztos hogy CDC módban használja, mert a képeken látszódik, hogy az AVR Studo prímán beolvasta minden paraméterét, és maga a programozó "magja" tökéletesen működik.
HID módban nem sorosportként jelentkezik be, ígyhát az AVR Studio sem látná.

Lásd, a legelső képet!

Itt a programozó és a cél AVR között van a gond.

Köszönöm a sok választ! Megnéztem újra, 500.-ra is a nyákot, de sajnos továbbra sincs semmi. Próbáltam programozni ATMega8-at, belső oszcillátorosat és 20MHz-es kristályosat, ATMega16-osat. Próbálgattam állítgatni a videón is látható SPI frekvenciát, a teljes skálát végigpróbálgattam. Most elkezdem megépíteni még egy példányban, ha az megy, akkor megnyugszom és nyugodtan jobban megy majd újult erővel a hiba keresése is. Ötletem még esetleg a 74126PC, mert annak a helyes működéséről nem tudtam meggyőződni, de kicseréltem azt is, mert volt itthon 3.

Ha jól emlékszem, akkor a cikkben nem jól van leírva az isp csatlakozó lábkiosztása. A csatlakozó irányát jelző jel van emlékeim szerint a rossz oldalon.

-- Melléklet törölve.
Topi

Ostobaságot ne terjessz kérlek. A cikkben jól van a csatlakozó kiosztása. A pöcök is, és az egyes láb is.

Mellékletedet töröltem, mert megtévesztő.

Sziasztok!

Kicsit hosszú, de új témát nem akartam nyitni.

Az alábbi kódrészletnek az lenne a lényege, hogy egy eszköz különböző gombnyomással indítva más funkciót lát el. Ez még működik is. Csakhogy az előző állapotot is megakarom őrizni, így gombnyomás nélkül indítva is működjön. Erre kellene az EEPROM.

A probléma az, hogy nem azt olvassa ki az eeprom-ból, amit kellene. Sokszor olyan mintha 4-es lenne a memóriában, mert joystick-ként jön be ha nem nyomok gombot.

Tudna valaki ebben segíteni?

Köszi

"A probléma az, hogy nem azt olvassa ki az eeprom-ból, amit kellene. Sokszor olyan mintha 4-es lenne a memóriában, mert joystick-ként jön be ha nem nyomok gombot."
Ez a joystick-os resz nem nagyon ertheto.

Amugy az eeprom muveletek elott hivd meg az eeprom_busy_wait() fuggvenyt mert ez szukseges a helyes mukodeshez. Igy tippre ez lesz a hiba.
Tovabbi informaciok Itt.

(Ui. eeprom_write_byte helyett hasznalj update_eeprom_byte-ot)

A megvalósításomat nem érted, vagy azt ahogy elmagyaráztam, hogy mit akarok?

A tipped úgy néz ki jó lesz. Most már sokkal kevesebbet hibázik. Csatolva látni, hogy hova tettem be. Lehet esetleg, hogy a switch-et le kellene cserélnem 3 if-re és mindegyik elé busy()? Vagy azzal nem lenne különbség? Igazából az lenne fontos, hogy a switch a feltétel értékét elmenti, és azzal hasonlítja a case értékeket? Vagy miden case esetén újra megnézi a feltételt? Nálam ez most nem biztos, hogy mindegy.
Bár ez már inkább C elémélet, mint avr.

Az update az jobban kíméli az eeprom-ot ugye? Erről olvastam futólag. Tudsz erről esetleg valami irodalmat ajánlani?

Köszi a sok segítséget.

Sziasztok! Na most már van két ROSSZ programozóm!
Teljesen ugyan az a hiba. Programozáskor megvillan a LED és jön a hibaüzenet...
PLEASE HELP!!!

Rossz a kábel vagy a processzor amit programoznál. Vagy hibás egyszerűen a nyák amit elkészítettél.

Nézd meg, jó-e a cél processzor, kap-e tápot, működik-e a reset, a szalagkábel csatlakozó nincs-e fordítva összeszorítva.

Ez inkább már így programozón kívüli hiba, ha egyikkel sem megy.

Topi! A 74126 invertál? Át akarom söntölni ideiglenesen, hátha az a hiba... Úgy gondoltam, hogy a 10kOhm-os ellenállások elött kiszedném a MOSI, MISO, SCK és RESET jeleket... Vélemény? Tudom, hogy akkor nem lesz magas impedanciás és programozás után le kell húzni, de hátha kiderül a hiba...

A 74126 nem invertál, csak a kimenetet (MOSI,MISO,...) tudja nagyimpedanciás állapotba hozni (3State Buffer).
Pontosan nem ismerem a programozó működését, de ha kihagyod és a céleszköznek azon portját bemenetre állítod, akkor nem nagy a valószínűsége, hogy problémát fog okozni a próbára elhagyása.

Nincs véletlen rendes 74HC126-od? Mert ahogy ezt a régi adatlapot látom, igen csak bemenő áram gond lehet.
Buffer előtti ellenállásokkal a maximális kimenő áram: I = U/R, azaz 5V/10K = 0,5mA.
Az adatlap szerint pedig legalább 2-5mA áram kell a bemenetére.

Ezzel az ellenállásokkal az az ősrégi TTL-es 74126 meg sem fog mozdulni. Az áramkör CMOS IC-kre tervezett!

Tévedtem továbra sem jó.
Annyi a különbség, hogy most a bill jön elő olyankor mikor nem kellene.

Egy kicsit átvariáltam, hogy ne kelljen annyiszor olvasni és ne az legyen a gond.

Olyan probléma még van, hogy van még egy csomó másik fájl is, de azok közül csak 2-nél szerepel ugyanilyen eeprom olvasás. A megvalósítás ugyanaz, mint ennél a switch-nél. A különbség annyi, hogy ott eepromból olvas nem a korbbi MODE változót használja.

A kodot megmutatnad teljes egeszeben? Mert en itt nem latok hibat perp. amugy az if (MODE!=x) -es feltetel ellenorzeseket kiveheted, mert az eeprom_update_xxxx fuggvenyek elobb megnezik, hogy az adott cimen mi az eeprom tartalma, es csak akkor irja az eepromot, ha az mas mint az argumentumkent kapott adat. Es igy a legelso eeprom olvasasra sincs szukseg, csak a switch elottire.

A helyzet a söntölést követően sem változott...

Hat igy direktbe kotve nem is lesz jo, mert igy a JTAG szerinti 9-es es 5-os lab nincs invertalva.

A LUFA\Drivers\USB\HighLevel és LowLevel mappában lévő .c fájlokat hozzá kell adni a projekthez, ha nem találná meg.

Egyébként a DevChapter9.c és USBInterrupt.c fájlokban van eeprom hívás a complete.c-n kívül.

Az eepromon kívül minden másnak jónak kell lennie, mert addig minden működött.

Az eeprom_read elé is kell az eeprom_busy_wait?
Korábban raktam, de most ebben a változatban nincs.

Milyen JTAG szerintiről beszélsz? Ez ISP.

Proci amire kötötted? Típus, stb?
A kábel 9 erű, a csati 10 pólusú. Ha el van "tolva" a kábel a csatiban a bekötött erek közötti távolság sem stimmel.

Igen, oda is kell.
Az eepromos resz jonak latszik. Szerintem a bekapcsolaskor hibas allapotot olvas be kozvetlen a buttons_init utan. Rakjal a get_status es a buttons_init koze egy 100ms varakozast.

Bocsanat ISP-t akartam irni.