mikor rájöttem arra, hogy fordítva volt bekötve (egyébként úgy is világítottak a led-ek (?!), nyilván széthúzta, meg az is lehet, hogy működés közben vettem el a táptot (éjjel 3-kor néha ne vagyok túl koherens. Hát azért az oda tud rúgni egy chipnek. Azt pl tudom, hogy a PIC melegítésre elveszíti az adattartalmás - de akár részlegesen is. volt ilyenem.
Nem hiszem, hogy rossz lenne a chip-ed, nagyon valószínűtlen. Arra gondolok, hogy az ilyen kínai utángyártmányok kispórolnak egy csomó dolgot, pl. a tápfesz szűrőkondenzátorait, vagy nem olyan kerül bele, amilyen kéne. Vagy a tápegységed nem megfelelő esetleg, ellenőrizd le. A másik persze az, amit már írtam, hogy az ISP-d által kiadott jeleken az élek nem elég élesek. Nem tudom, milyen kábelt adnak hozzá, de próbálj meg minél rövidebb kábelt használni.
Az Atmel Studio három fájlformátumot tud kezelni, Intel, Motorola, és Generic. Alapból Intel-re fordít, ennek a leírását itt megtalálod a Wikin. A többi is meglesz, ha rákeresel. Ezek igazából nem bináris, hanem szövegfájlok.
az UNO R3 panelom van, 328P vezérlővel, felületszerelt kivitel. Rendeltem most 2 darabot hogy kicseréljem, remélhetőleg ezt még nem hamisítják...
azóta megpróbáltam beleírni egy hosszabb programot az ISP-vel. belement, de szerencsére ez a programozó GUI úgy van megcsinálva, hogy vissza is ellenőrzi, és itt már hibát jelztett. Vagyis a bootloader területen van hibás szektor (mindig ugyanott), meg itt is van. Ebből arra gondolok, hogy a chip mindenképpen meghalt, viszont ha kicserélem, akkor még ISP programozással tudom használni a panelt - legfeljebb ha más része is sérült, akkor nincs többé USB programozás.
Van esetleg egy emészthető leírásod arról, hogyan épül fel a programozónak adott hex fájl, illetve a visszaolvasott fájlok?
Az arduino klón nincs védve, ezért egy működő példányből vissza tudnám szerezni a bootloadert, de az már látom, hogy a beírt és a visszaolvasott hex nem teljesen azonos szerkezetű.
Az Atmel valóban word-ben címzi a programmemóriát. Melyik vezérlő van az áramkörödben?
A felprogramozásnál általában érzékeny arra, hogy szépek és gyorsak legyenek a felfutó élek, egyébként előfordulnak ilyen-olyan hibák. Ebben van különbség az egyes ISP áramkörök közt. Meg, persze, érdemes minél rövidebb madzagot használni.
Az xmega előtt saját felprogramozót használtam, hol printerporton keresztül (+AHC244 jelformálásnak), hol egy FT232R USB kontrollert. A felprogramozó áramkört kábel nélkül cstlakoztattam a nyákhoz, nem volt vele soha probléma.
Hex editornak a Norton commander egyik utánérzését szoktam használni, én szeretem. Sőt, régebben még a programot (assemblerben) is ezen írtam, és parancssoros fordítót használtam.
Nos, az UNO csak részben élte túl a műveleteket (de uyge a tudomány érdekében nincs az az ár, ami túl magas lenne...), mert megsérülta bootloadere,illetve úgy néz ki, inkább a memória, valahol a 7A80 címnél - vagyis éppen a bootloader tartományban. Töröltem az egészet. Amikor visszatöltöm rá a bootloadert (adafruitról, arduinoról, mindenhonnan) akkor 5-ből négyszer memóriahibát jelez kb ugyanazon a címen. Aztán ötödjére működik az ellenőrzés, de a programozásnál már beakad, nem tud programot betölteni. Ha az ISP-n töltök fel programot, az működik -de valószínűleg nem éri el azt a hibás címtartományt.
Segítenétk nekem valamiben?
Az ISP programozónak ugye megmondom, honnan kezdődik a boot-rész, de az 3800 - 3F00 tartomány, vagyis kb a memória felétől. Ehhez képest a bootloader a programban a 7800 címtől kezdődik. Egy helyen azt találtam, azért, mert az ATMEL itt wordben számol , vagyis 2 byteban, és akkor a cím valóban a fele, mint byteban. Ez így lenne? Illetve, azt jól gondolom, hogy manuális bootloader töltéskor előbb
- törlöm a teljes tartalmat - ezzel nyitom a lockbiteket, megengedi az írás
- betöltöm a bootloadert
- zárom a lockbitet a bootloader területen
- betöltöm a programot (bootloaderrel USB-n vagy a programozóval az ISP-n)
- zárom (ha akarom) a lockbiteket a programrészen. és akkor utána már csak törléssel tudom olvasni/továbbírni a chipet.
Van olyan hex editor, amivel egyszerűen lehet az ATMEL chip hex fájljait szerkeszteni? Egy egyszerű editor nem tud mit kezdeni a sorok elejére írott címekkel.
még annyit, hogy az Arduino UNO és a NANO (klón) panelon biztosan működik az ISP kiolvasás. (Csak mondjuk nem kell azt hinni, hogy ugyanúgy állnak a csatlakozók a 6-pólusú aljtzatban. Mert fordítva. De még ettől sem halt meg :) )
és működik! annyira primitív, hogy nem tudja a protokollt amit minden atmel programozó, olyan progi kell, ami direkt ezt ismeri. amúgy nagyon szép történet, egy német manusz (http://www.fischl.de/usbasp/) tervezte és írta a fw-t, a kínaiak meg elkezdtek ötforintért hw-t gyártani hozzá.
Ma jött meg a Made in China Mega. Gond volt vele, mert nem csatlakozott az USB portra. Körülnéztem a fórumokon és kiderült, hogy a kínai alaplaphoz le kell tölteni installálni a drivert. Utána COM7 porton bejelentkezett. Ha valaki szintén kínai MEGA 2560-at vesz, akkor a drivert innen töltheti le:
Igaz, nem tudom, hogy mi, mert szkóppal még nem néztem rá. De, ha lekapcsolom a tápról az Rx-et, akkor megszűnik a kommunikáció, amit a Tx LED állapota mutat, nem villog.
Lehet-e külön tesztelni őket? Arra gondolok, ha csak a master vezérlőt és 485 modlut programozom fel és helyezem feszültség alá, akkor is lennie kell mérhető jelnek? Persze csak az után, hogy a leírtak szerint kimértem az alkatrészeket.
(Bocs, de azért kérdezlek, mert vasárnapig semmi időm ezekkel a cuccokkal foglalkozni.)
Nem mondom, hogy kínai cuccokkal nem szívtam meg. Pl. rendeltem egy igéretes oszcillátort, ami a reklám szerint 100kHz-1MHz-ig működik. Valóban, működik is, de 600kHz-től, hogy úgy mondjam, erősen logaritmikus, azaz, 2-3° poti elfordításra több száz kHz-et ugrik. Szép színes, jól mutat a polcon, hangfrekire jó lesz :-)
Kínából jött már többször hibás cucc. Lábak nincsenek bekötve, kivezetve, rossz helyen van a felírat, a vezetősáv nem megy át az IC alatt, fordítva beültetett alkatrészek, stb. Ez egyértelműen a minőségbiztosítás és tesztelés hiányának tudható be. Simán küldenek 20 db egyformán rossz cuccot. Sose tesztelték...
Először ellenőrizni kell, hogy a modulok úgy vannak-e kötve, mint ahogy az a rajzon van, stimmelnek-e a feliratok stb. (Nekem van olyan DS18B20 modulom, amin az összes felirat rosszul van.) A következő rész annak ellenőrzése, hogy az UNO--modul vezetékelés, a szoftverekben a lábak deklarálása megfelelő-e.
Aztán jön a mérés, logikai analizátorral vagy oszcilloszkóppal. Előbbi olcsóbb valamivel, utóbbi meg okosabb, bár a célnak mindkettő nagyjából megfelel. Ha ez nem áll rendelkezésre, akkor csak a try-and-error módszer marad, vagyis próbálkozni kell különböző könyvtárakkal, különböző felállásokkal stb.
Ezen túl nem nagyon van ötletem, a kód és a kapcsolás a leírtak alapján láthatóan működik, működnie kell.
A példádban lévő kapcsolást is megcsináltam a hozzá mellékelt szoftverekkel és az sem megy. Igaz, a busz végére nem tettem se lezáró, se le- és felhúzó ellenállásokat, mivel azok a kis modulokba be vannak építve. A buszon két UNO van.
Mert ez nem RS485 protokoll. A Serial alap esetben (pl. Uno, Nano stb.) a soros kommunikációra van fenntartva (az IDE termináljára küld és onnan fogad). Nyilván használható két kártya között is adatkommunikációra, erre is millió példa van a neten. Ha két kártyát megfelelő módon kötsz össze, ezzel az eljárással, amit a példában hoztál, tudsz közöttük kommunikációt csinálni.
Miért nem megy? Ez és még más hasonló RS485 kommunikációs programok csak az Arduino IDE soros monitorával hajlandók kommunikálni. Ha leválasztom az USB portról és önálló tápot adok neki, meg se nyekken.
void loop() { // send message to slave ("A") with different value for (int i = 0; i < 5; i++) { switch (i) { case 0 : Serial.println("A1000"); break; case 1 : Serial.println("A0100"); break; case 2 : Serial.println("A0010"); break; case 3 : Serial.println("A0001"); break; } delay(2000); } }
valahogy továbbra sincs kedve az arduino "rendes" programfelületét használni (valaki azt írta, olyan, mintha a McDonaldsban akarnád megtanulni a főzést...), használom a modult, mert kényelmes, hogy nyákon van, viszont néha jó lenne belenézni egy két library assembly kódjába, már csak ötletek miatt is.
van olyan forrásotok, ahol ilyenek vannak? pl most éppen a "wire" érdekelne.
Ez az új (1.4 utáni) Arduino IDE-vel nem működik. Ez az Atmel AVRISP-mkII-vel műszaki tekintetben többé-kevésbé azonos: https://www.hestore.hu/prod_10035315.html# Atmel Studioban látod a Fuse biteket, tudsz teljes másolást (clone) csinálni stb.
Az Arduino IDE-vel nem fogsz tudni Fuse bit-eket olvasni és a kódot sem tudod kiolvasni (pláne nem visszafordítani olvasható kódra).
jól gondolom, hogy pl az arduino NANO-ban a "normális" USB- s programozásra az RX/TX lábakat használja, és nem a MOSI/MISO lábakat, tehát valószínűleg ezért nem lehet kiolvasni a tartalmat, és akkor valószínűleg a FUSE-okat sem lehet piszkálni. Következő kérdés: ajánljatok egy nagyon egyszerű (olcsó) programozót is, ami képes erre. ilyet találtam: https://www.banggood.com/USBtinyISP-AVR-ISP-Programmer-Bootloader-USB-Download-Interface-p-929287.html?rmmds=search
Megmondom őszintén, elég sokat bírkóztam az ötleteddel, aztán sikerült is túlbonyolítanom a progit. A végén mégis az előző elgondolás győzött. Egy olvtárs segített a Tavir Fórumon és kiemelte a szükséges részletet, ez már jól működött, több bemenetre is:
int buttonStateRising=1; int buttonRisingEdge = 1; int lastButtonStateRising = 1; ...
//Here starts the code for detecting a rising edge on pin 11 buttonStateRising = digitalRead(11); if (buttonStateRising != lastButtonStateRising) { if (buttonStateRising == LOW) { buttonRisingEdge = 0; Ide teszed a te feladataid megoldását Serial.println("There was a rising edge on pin 11"); } }
Végülis ebben is változóba van mentve a bemenet állapota. Csak a Serial.println parancssor helyére a végrehajtandó programot írtam be.
- az Arduino-n lévő interfész, meg a benne lévő bootloader csak egyirányú kommunikációra alkalmas, adat BETÖLTÉSRE (én a PICIKIT2-t használom PIC-hez, ott ez nem így van)
- az ATMEL chipekhez is létezik olyan eszköz, ami be is ír, meg vissza is olvas.
- az Arduino modulok ugyan nem használhatók kiolvasásra, de a rajta lévő chipet egy "rendes" programozóval ki lehet olvasni
Én magam nagyon alapszinten játszom vele, bár készítettem már olyan eszközt, ami az adott célra nagyon is jl használható (mondjuk eredetileg PIC-el), viszont egyszerűen nincs időm a nyákkal vacakolni, ezért kezdtem el egyáltalán az Arduinot.
Az arduinot (klónt) NEM a saját programnyelvén programozom, mert van egy AVR simulator nevű programom (megvásárolva :)) http://www.oshonsoft.com/, ami egyszerűbb. Ez hex fájlt generál, a betöltésre meg az XLOADER-t használom.
És akkor újra a kérdés, és higgyétek el, nem lustaságból, egyszerűen nincs időm rá, hogy kikísérletezzem (viszont mondjuk canon javítás területen pontosan így szoktam segíteni...) : megmondaná valaki, hogy pl. egy xloader progival van e olyan lehetőség, hogy azokat a számomra szükséges fuse-okat úgy beállítsam, hogy többé ne lehessen kiolvasni az ATMEL chipet, de továbbra is lehessen újraprogramozni? Gondolok itt arra, hogy egy kis asm-szekvencia, amit beillesztek a programba, ami a hex-szel együtt átmegy és a programozás zárásaként ezt megoldja?