AVR programozót milyet?

Sziasztok!
Milyen olcsó és jó programozót ajánlotok AVR ISP-n programozáshoz?
Eddig AVR STUDIÓ-val használtam ISP MK II-t , de megpusztult.
Köszönöm.

Könnyen lehet, hogy "csak" ennyi a fix: YT - AVR ISP MKII Repair & Upgrade

MOD: úgy tudom, hogy az AVR ISP mkII-t publikussá tették és ezt a kínaiak lemásolták. Szerintem az működik. Személy szerint nem vagyok a klónok híve, így nincs gyakorlati tapasztalatom.

USBASP

Atmeg64A olvasás

Sziasztok,
Egy olyan kérdéssel fordulnék hozzátok, hogy van e arra bármi féle, akár költséges, de elérhető módszer arra, hogy egy Atmega64A tartalmát kilehessen olvasni akkor ha az zárolva van(LB1=0, LB2=0)
Köszönöm.

Nem csak ennyi.
A GTL2003-as IC-t (illesztő) kicseréltem, de az USB-s, AT162-es állandóan ismételten küld ki a céláramkör AVR-nek rövid RESET jelet.
A programozó ATMEGÁT érte valami.

Uh, ezt szomorúan olvasom .

Még tavaly sikerült az ebay-en eredeti ISP mkII-t venni egész baráti áron. Ha nem sürgős, akkor érdemes lehet nézegetni és várni.

A LUFA projektben van AVR ISP mkII kompatibilis firmware.
Feltöltöd egy Arduinora (Micro/Leonardo), és kész a programozód.
Kb 12 éve én is készítettem, tök jól működött. Mondjuk azóta nem használtam, mióta váltottam Atmel ICE-re, ami most 30000 ft.
Vagy itt van egy Olimex AVR ISP mkII klón 8000 ft.

Köszönöm.
Van Micro-m, de ahhoz jobban kellene értenem a software mókoláshoz, hogy meg tudjam csinálni.
Az Alin rendeltem 1 MK II-t, remélem jó lesz ~6500Ft.

Az USBASP eszközkezelő drivert feltöltöttem.Milyen "égetŐvel" tudom a céláramkört programozni?

Például. Bővebben: Link
Kell még hozzá egy 10 Pin-es tüskesor és egy ic foglalat, valami proba panelon, és megfelelően összekötni őket.

Ez van. Kép mellékelve.
A Bascom-Avr nem kezeli az USB portot ( legalább is, amit letöltöttem).
Az AVR dude 1 pillanatra bevillan, mint régi DOS-os kép.
A Zadigtól leáll a gép.

Megvárom, míg bejön az MK II rendelésem.

A bascom kezeli az USBASP-OT amit linkeltem.

AVRATJTAGICE mkII féleségek

Sziasztok!
Feltöltő-debuger dobozok, 3 fajta. Nagyokban, az egyikben 1db uC, vonalmeghajtók. Másikban űrsikló cuccok (ugyan az a típus), 2db M128, FIFO, 512kB SRAM stb. Mivel tud többet az egyik-másik? A legkisebben meg csak 2db kicsi uC van.

Köszönöm!
A BASCOM 2.0.8.5 - ös .bin file-t kér, a MikroC kimenete .hex kiterjesztésű, tehát nem eszi, hogy az USBASP programozómat kipróbáljam, kezeli-e?
Van valami, ami a .hex file- t átteszi .bin - be?

Lehet választani bin és hex között (jobb oldal a filenév utáni lenyíló).

Atmega8L

Szép kora estét mindenkinek.
A mellékelt kapcsolási rajz részleten az Atmega8l külső 18Mhz quartz szerepel, ez gondolom csak tévedés lehet, az adatlap szerint 8Mmhz kell, vagy tévedek?

Igen, max. 8 MHz-es quartz lehet a 8L mellett és 16 MHz-es a sima 8 mellett.
Van aki próbálkozik a túlhajtással, de ez ahhoz már túl nagy a 8L-nek.
Ha megvan a program forrás szinten, akkor abból valószínűleg kiderül milyen kell.
Milyen áramkör ez egyébként, hol találtad?

Bővebben: Link

Forrás nincs, de az ITT lévő kommentek alapján tényleg 18 MHz-esre van tervezve. Akkor viszont ne L-es kontrollert használj, hanem a sima ATmega8-at.

Köszi az infót.
Elfogattam a megépítését, így tisztába kell tennem a részleteket.

Soros port 1. byte küldése

Sziasztok!
Hogyan kell kiküldeni soros porton reset után az első adatot?
Pár uC-t néztem, reset után 0 a TI flag, vagy nevezzük bárhogy, ami azt jelenti, hogy
nincs kész az új adat fogadására (soros puffer nincs kész, pl. ad). Kínai ASM programokat néztem, ott bevezettek egy külön bitet (legyen busy), ami akkor is belenyomja a soros pufferbe az adatot,
amikor nincs kész (elméletileg), aztán nullázza, soha többet nem kerül rá a vezérlés (mert beáll a soros üres flag). Most vagy én vagyok a hülye hozzá (99%), vagy reset után miért nem áll be 1-be a bit? Áthidaltam, hogy inic-ben 1db 00h byte-ot kiküldtem, fogjuk rá a bekapcsolási tranziensre, de ez nem normális, szerintem. Főleg érdekes, hogy van olyan uC amiben van SETBit TI utasítás, de akkor bebillen az interrupt flag, amikor a globálisat engedélyezem, elugrik rá. Bár szimulátorban néztem, 3 sim 3 választ adott... Nem nagy gond, csak kérdezem a nagytudású hozzáértőktől. STM nagyokon nem néztem, lehet, ott jól megy, 8-bites apróságokon kértem AI segélyt is, össze-vissza-balfékséget adott.

Szia, te most STM8 családhoz szeretnél tanácsot kapni?

Ez itt az AVR családdal foglalkozó topic, azok nézik akit AVR-t (ATmega, ATtiny) programoznak. Jó lenne, ha megfelelő topicban tennéd fel a kérdést, ha nincs akkor nyitni kell egy "STM8 - Miértek hogyanok" néven ezt a kérdést meg itt töröltetni a moderátorokkal.

Az is jó lenne, ha megadnád pontosan milyen kontrollert, milyen nyelven, milyen környezetben programozod, előbb kapnál segítséget.

Bocsánat, elúszás volt. Nem-nem, nem STM specifikált, általános volt a kérdésem! Tehát egy pl. soros rutin úgy kezdődik, hogy megnézzük, az adó üres-e? De reset után jópár uC-nél ez 0 (foglalt), akkor az első byte hogyan mehet ki? (ott várakozik szegény) persze felülbírálva (sok helyen ezt használják) akkor is belenyomja a bufferbe (ez a megoldás bit/utasításpazarlás, mert soha többet nem használjuk), ha nincs kész. Egyszerűbb lenne resetkor 1-be állítani az "adómeghajtó üres" bitet, de nem. Nem?!? (sajnos nem találtam általános uC topic-ot, de AVR-nél is így van, nyelv nem számít, környezet nem számít, általános volt a kérdésem). Közben ránéztem egyéb perifériákra, egyre szörnyűbb a helyzet (matek tárproc is reset után azt jelzi, nincs kész, lehet felülbírálni első nekifutáskor...nem így tanultam) Biztos én vagyok értetlen, de ezért kérdezek.

Reset után nyilvánvaló, hogy semmi sem volt még küldve, tehát van egy tiszta állapotod. Megkülönböztetheted az első alkalmat, amikor feleslegesen elugrik az interruptra az összes többitől, amikor ténylegesen elküldött bájt után jön az interrupt.

Jó esetben, hogy ne kelljen ilyen logikát tenni az interrupt rutinba, hogy aztán azt mindig lassítsa, létezik valami trükk is, pl.: SETB TI, CLR TI, és csak utána engedélyezed globálisan az interruptokat. A bit törlésének elvileg törölnie kell az interrupt-állapotot a kontrollerben.

AVR-nél a UCSRnA, TXCn mondja, hogy az adás kész, a shift regiszter üres, RESET után ez 0, azaz az adás nincs kész. de én nem ezt használom adás előtt. Helyette UCSRnA, UDREn. Ez azt mondja, hogy a UDREn kész új adat fogadására, a buffer üres. Ez RESET után 1, azaz üres a buffer, adásra kész.

AVR IT nélküli küldés:



A következő byte-ot egyébként sem akkor kell berakni a bufferbe, ha már kiment az előző, hanem amikor a buffer UDRn üres (ekkor még megy az adás a shift regiszterből), de ahogy látod a TXC1-et lehet törölni, te is megteheted első adás előtt, ha azt szeretnéd.

Az IT-s küldés ennél bonyolultabb, de ott is a UDRE IT-t kell használni a következő byte küldéséhez, nem a TX Complete-et.

Én ezt az egészet úgy gondolom (úgy tanultam), hogy bekapcsolás (tápfesz megérkezik, indul a kütyü) után és (akár hard- , akár soft- ) RESET után is minden (használni tervezett) egységet fel kell készíteni a használatra (inicializálás). Ebben benne van, az is, hogy milyen szabvány szerint (baud-rate, bitszám, stopbitek, stb...) kommunikáljon. Ezek után kész arra, hogy rendesen működjön, vagyis ezután kell neki megmondani, hogy üres az adópuffer, engedélyezni az adás IT-t, stb...
Futottam már bele olyan hibába, hogy figyelmetlenül írtam meg az inicializálást, és nem értettem, hogy miért nem azt csinálja a uC, amit szeretnék látni... Azután rájöttem, hogy bizony törölni/alaphelyzetbe állítani kell mindent.

Egyébként szerintem jogos, hogy induláskor "le van tiltva" az adás lehetősége (a foglaltság kb. ezt jelenti...). Ilyenkor bármi lehet bárhol a regiszterekben, RAM-ban... Ha engedélyezve lenne, akkor (főleg egy rosszul megírt program esetében) elkezdhetne magától küldeni valamit, akár csak egyetlen byte-ot, ami adott esetben a fogadó-oldalon ki tudja mit okoz. (A uC gyártója biztosan nem tudhatja...) Éppen ezért jogos, hogy minden kifelé történő akciót csak a program(író) kifejezett engedélyezése után tudjon végrehajtani.

Szerintem...

Ohh, én marharépa, hát AVR-nél duplapufferelt, ennél az őskövületnél meg nincs ilyen, még az újabb klónoknál sem Azért nyavalyogtam ám, mert egy többprocos rendszerben reset után nagyon gyorsan van adatmozgatás, így (?) próbálnak valamit védeni, órajelre kiszámolták, mikor kell mennie adatnak... és hasonló kisagyas dolgok (amik még kiderülnek). Marad a gyorsabb klónra átportolás. Köszönöm!!!

A mester adja a resetet és nagyon pontos időben vár egy adatot, különben eldobja magát. Általánosan merült fel az alapállapot utáni első tranzakció mikéntje, de most megvilágosodtam, hogy milyen irányba kell nézelődnöm. Az, hogy az adás lehetősége tiltott, rendben, de itt pl. azt jelzi vissza, hogy nincs kész az adatvételre a regiszter (mint ha most adás folyamatban lenne), ez kavart meg AVR-nel/ennél a vacaknál. Néha nagyon tudom szégyellni magam, hogy átsiklok alapdolgokon...