Hasonló modult használok. Gondolom a példaprogramokkal küzdessz és nem kapsz vélhetően jó eredményt.
Én is küzdöttem, nálam ezzel a módszerrel jó:
void pH_meres() { int buf[10]; // buffer feltöltése for (int i = 0; i < 10; i++) { // 10 mérés átlagolása buf[i] = 0; buf[i] = analogRead(pHSensorPin); delay(10); } for (int i = 0; i < 9; i++) { byte j = 0; for (int j = i + 1; j < 10; j++) { if (buf[i] > buf[j]) { int temp = buf[i]; buf[i] = buf[j]; buf[j] = temp; } } } unsigned long int pHkozep = 0; // min és max értékek elhagyása for (int i = 2; i < 8; i++) // 6 középső érték kiválasztása pHkozep += buf[i]; float pHsensor_atlag = pHkozep / 6; pH_ertek = mapfloat(pHsensor_atlag, 765, 665, 4.01, 7.01); if (pH_ertek > pH_max) { pH_max = pH_ertek; } if (pH_ertek < pH_min) { pH_min = pH_ertek; } pH = pH_ertek; }
Ez a részlet az én kódomból való, de az eredetijét a netről loptam és én csak testreszabtam. Nálam megy. Fontos, hogy használat előtt kalibrálni kell (a boardon lévő két poti segítségével), én erre pH 4.01-es kalibrációs folyadékot használtam.
nagy ISP frekvenciánál (mondjuk 187kHz) is működött az átvitel. Csak éppen néha tévesztett. Ennek nem értem a magyarázatát, de az AVRDUDE a flashelés után visszaolvassa az adattartalmat, és olyankor mindig kiderül.
Semmit sem nagy kunszt írni, feltéve, hogy eleget foglalkozol vele, meg értesz hozzá :)
Az USB soros illesztő típusa teljesen mindegy a bootloadernek. A lényeg, hogy sorban kapja a bájtokat. Akár egy másik mikrokontroller is küldhetné, még PC sem kellene hozzá.
A fenti kettő elég ok a kínainak, hogy ne akarjon újat fejleszteni. 😃
A felprogramozáshoz nem kell fix frekvencia, csak a felprogramozandó proci órajel frekvenciája legyen nagyobb (2x? meg kéne nézni), mint amit a felprogramozó kiad. Az előfordulhat, hogy valami geb@sz miatt úgy álltak be a fuse bitek, hogy a belső 32kHz-es oszcillátorról ketyeg a mikrovezérlőd. Ehhez pedig tényleg kis órafrekvencia kell a felprogramozónál.
megnéztem szkópon az ISP jeleit, teljesen tiszták. Lehet persze, hogy nem is a jelek éleivel van baj, hanem mondjuk az órajel stabilitásával. érdekes lenne ugyanazt a nanot vagy unot egy "rendes" programozóval megírni, hogy ott mi az ISP felső sebességhatára, ahol még megbízható.
eredetileg csak annyit akartam, hogy a lock-biteken le tudjam zárni a chipet. aztán amikor megjöttt az USBTINY, (klón), akkor nem pont úgy működött, mint ahogyan (felületes információk alapján) gondoltam. Akkor már vérszemet kaptam, hogy mindenképpen megértsem, miért úgy viselkedik, ahogyan. A netes információk egy része nem pontos (vagy én értem néha félre), szóval van azért benne kihívás. Bootloaderből állítólag van azért néhány változat pl az adafruiton is - valamit reszelgettek rajta.
Az pedig egyáltalán nem evidens, hogy a kínai utángyártott bootloadere PONTOSAN azonos legyen az erdetivel, mert a kínai egy teljesen más USB chipet használ
, aminek lehetnének más paraméterei. Mikor próbálhgatom és az isttennek sem működik, akkor nyilván igyekszem kizárni minden lehetőséget. Végül az írás előtti teljes törlés volt a kulcs - vagyis azt kellett csak kiiktatni.
egyébként valóban nincs szükségem a bootloaderre , az arduinos panelra is csak azért, mert nincs időm, energiám nyákot gyártani, anyagilag is értelmetlen lenne. PIC-es panelt gyártottam, de én igazából outsider vagyok.
Semelyik Arduinon nem védett a bootloader. Nyugodtan felülírhatod. Amúgy miért akarsz ISP programozás mellé bootloadert? Lehet, hogy írtad, de nekem kimardt.
A kínai klónban is ugyanaz a bootloader van. Nyílt forrású, a forrás és a bináris is szabadon elérhető. Miért is vacakolnának mással?
Örülök, hogy sikerült. :) Az Arduinokat egyébként konkrétan nem ismerem, de már vagy húsz éve dolgozom Atmellel, kezdve az Atmega103-mal. Jó sokat szívtam közben, pl. a 103-asnál az AD konvertert - az akkori előzetes adatlap alapján - free running módban használtam. Nem ment könnyen, de valahogy megoldottam: később jött egy errata, hogy a korai adatlapokon szereplő dolgokkal szemben a 103-ason az AD konverternek nincs free running módja. (Workaround: read up-to-date data sheets.) Leizzadtam, mert akkorra már az egyik kuncsaftomnál működtek a műszereim a gépsor mellett...
Ugyancsak a 103-asnál először azt írták, hogy 6V-ig mehet a tápfesz. Valamiért nekem az 5.8V kényelmes volt. Csak azt vettem észre, hogy az EEPROM programozással vannak bajok. Később jött az errata, hogy 5.5V-is működik a chip.
A legnagyobb szívás az az assembler fordítóval történt. Egy darabig minden jól működött, aztán egy frissítés után nagyon furcsa hibák jöttek elő. Vagy egy hónapot szarakodtam vele, de aztán rájöttem (hogyan? már nem tudom), hogy a fordító nagyon ritkán a relatív ugrásokat rosszul fordítja le, mégpedig olyankor, amikor a relatív ugrás a legnagyobb abszolút értékű negatív érték volt (-0x40) - de akkor is csak ritkán.
Szerencsére megvolt a régi verzió, ami hibátlanul fordított, egy-két utasítás hiányzott belőle az újabb kontrollerekhez. Később ezt javították, de úgy, hogy a jelenlegi fordítók már a -0x40-es relatív ugrásra is "relative branch out of range"-et jelentenek.
Szóval, én már mindig mindenre előre gyanakszom. Ennek ellenére szeretem az Atmel kontrollereket, eszem ágában nem lenne másra átváltani.
Nem hiszem, hogy rossz lenne a chip-ed, nagyon valószínűtlen.
Ezzel a mondatoddal nagyon sokat segítettél, emiatt kezdtem tovább kísérletezni.
Kiderültek a következők:
- az ISP program,amit találtam, a BITBURNER, az AVRDUDE-on alapul. észrevettem, hogy amint beírok a prpgrammemóriába, automatikusan törli a bootloader részt is. egész éjjel ezzel vacakoltam, semmi értelme nem volt, hiába lockoltam a bott területet, azonnal felülírta FF-el . Reggel pedig rájöttem: az AVRDUDE alapból MINDEN flashelés előtt törli a teljes chipet - vagyis alapra állítja a lock-biteket. Még ki is írta, hogymelyik paraméterrel lehet ezt kiiktatni (-D).
- most már az rendben volt, hogy nem törli egyik rész a másikat (a program a bootloadert.)
- a programozandó chipet betápoltam külön ( a programozón ki kell venni egy jumpert) - ez nem volt elég
- elkezdtem lassítani az ISP órajelét. lehet, hogy végül túlzásba estem, de végül 32kHz-es ISP frekit állítottam be.
- és akkor visszaolvastam a működő (kínai) NANO panelről a bootloader (hátha a kínai bootloadere nem pontosan azonos az eredetivel), majd (köszönhetően neked) értelmezni tudtam a hex fájlt, átírtam úgy, hogy visszaírható legyen - (egyetlen sort kellett beszúrnom egy másik bootloaderből).
- felprogramoztam a bootloadert a halott UNO-ra-
- felprogramoztam a ki tesztprogramot. mindkettő hiba nélkül (és tetű lassan) ment.
Most működik az UNO, lehet újra USB-ről programozni.
Köszönöma a segítségedet.
Tanulság: ahhoz képest, hogy mennyien használják, az egész arduino/ISP NAGYON rosszul van dokumentálva. Vagyis, aki már ismeri, az megérti a leírásokat, de sehol nincs egy olyan, ami rendszerbe foglalva tárgyalná.
A segítőészségről annyit - bár itt nem kérdeztem -, hogy az egyik magyar AVR fórumon akartam a MEGA 2560 "nem megy" kérdést feltenni, de szerencsére már valaki megelőzött. A lényeg, hogy a nagy guru válaszadó, csak annyit válaszolt, hogy kínait vettél? Így jártál. Nem mondta volna ki a varázsszót, hogy kínaihoz kínai drivert! Így aztán egy amerikai fórumon akadtam rá a válaszra és a linkre. Azóta nagyon jól muzsikál a MEGA. egy több, mint 2500 soros programot vertem bele, ami 32db digitális I/O-t vezérel gond nélkül.
Ezzel is úgy vagyok, mint bármilyen más elektronikai hobbimmal, ha magam nem, mástól legfeljebb minimális segítséget várhatok. Arra viszont jó, hogy amit magamtól kiszenvedek, azt biztos nem felejtem el. Ja, persze nem vagyok üzletileg érdekelt, hogy csak olyanoknak adjak tanácsot, aki csak egy bizonyos gyártó által forgalmazott termék felhasználóit részesíti előnyben. Tudom, valamiből meg kell élni!
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.
