Sziasztok
AVR-ről szeretnék adatok egy mysql adatbázisba rögzíteni, lehetőleg usb-n keresztül. Megoldható ez, ha igen merre keresgéljek?
Köszi

Szia !

Itt nézz szét, ezzel a megoldással olyan AVR-rel is lehet USB keresztül kommunikálni, ami alapból nem tudja az USB-t kezelni. Van hozzá host program is ami USB-n tud kommunikálni az AVR-rel (pl. C-ben, Delphi-ben) és a sql-t is el lehet érni.
Bővebben: Link

A témán én több hónapon keresztül rágódtam, míg végül megvettem egy Arduino klónt (AVR-Duino UNO) 7650 Ft-ért és nem bántam meg (avr.tavir.hu). Olcsóbb Arduino is van, USB-RS232 átalakítót pedig 3300Ft-ért találsz ugyanott.

Ha számítógép kapcsolatot akarsz és nem automatikus viráglocsolót, arra az Arduino az ideális. Szoftverből programozhatod, rendes hardveres USB van, megfizethető. Ráadásul, ha összeadod az USB-kábel, NYÁK, IC-k, foglalatok,... árát, igencsak magasra felszökik a végösszeg. Én úgy voltam vele, hogy nem éri meg vesződni napokat, ha készen pár ezer forinttal drágábban megveheted.

Istvanpisti emlitette a V-USB-t (szoftveres USB). Egy digitális hőmérőnek tökéletesen megfelel, de ha 10k/s-nél gyorsabb adatátvitelt szeretnél, akkor felejtsd el. Arról nem is beszélve, hogy a szoftveres USB hogyan fog reagálni, ha összevissza interruptol a rendszer. Elszáll az USB? Késik az interrupt? Azért vetettem el a V-USB-t, mert egyértelmű választ nem kaptam rá.

A V-USB akkor jó, ha a sebesség nem kritikus és az IC hardverből mindent elvégez (pl. ADC olvasás), mialatt a szoftver az USB protokollal szórakozik.

A megoldás nem (túl) rossz, de az USB nagyon leköti az AVR erőforrásait, programozni nem nagyon lehet.
A másik, hogy a fordítót nekem azóta sem sikerült rábírnom hogy ebből a kódból fordítsak,
a Doper verzióazonosítóját is pl. a HEX fájl meghekkelésével sikerült módosítanom.
Ezért az obdev-es cuccokat csak az előre lefordított HEX fájlokkal lehet/érdemes használni(pl. Doper),
saját variáns elkészítését nem ajánlom.

Amit ajánlok: MCP2200, vagy kész USB-soros átalakító(TTL kimenetes).
Ezen kívül a PC-re is kell program, sőt, a nagy része valójában PC-n kell hogy fusson.
Az AVR-nek így nem kell az SQL utasításokat és válaszüzeneteket ismernie.

Abban igazad van, hogy a szoftveres USB erőforrás igényesebb az AVR oldalon, mint a hardveres megoldás, én azért javasoltam ezt, mert érdekes megoldásnak tartom, és ez egy hobbi fórum. Én nem arra gondoltam, hogy az AVR intézze az adatbázis kezelését, hanem arra, hogy ezt ua. a host program tegye, ami az AVR-rel tartja a kapcsolatot USB-n, ugyanúgy, mintha soros porton kapja az adatokat. Pont olyat, amit zsozsoX ír, még nem csináltam, de LPT portról vezérelt (nem uC) A/D adatait SQL-be mentő alkalmazást, és szoftveres USB-t AVR-rel már igen (saját célra nem értékesítésre).
Persze, ha csak a probléma megoldása a cél, akkor a legjobb, leggyorsabb megoldás a hardveres USB.
De én azt vallom, hogy nem csak a cél a fontos, hanem az oda vezető út sem érdektelen.

Nem tartom valószínűnek, hogy ilyen adattömeget célszerű SQL-be menteni.


A V-USB-nél az AVR az INT0 interruptot használja a kommunikációnál, ennek a legmagasabb a prioritása, a Timer, az ADC interrupt addig vár, amíg az INT0-t kiszolgálja az AVR.

Nem is az a baj, hogy a Timer vagy ADC stb. interrupt kivárja az INT0-t, hanem ha már fut a TIMER, ADC stb interrupt és akkor esik be az INT0. Ekkor hiába nagyobb az INT0 prioritása a már futó másik megszakítást már nem fogja félbeszakítani, hanem kénytelen kivárni amíg az befejeződik.

Igazad van, de ez is azt alaptételt erősíti, miszerint interruptban nem szabad/érdemes időigényes dolgokat csinálni.

Sziasztok, hosszas googlizás után sem találtam választ arra a kérdésemre, hogy lehet-e a külső megszakítás portot más lábra tenni? pl Atmega16 PD2 ről PD7re.
És ha igen hogyan????

Adatlappal is konzultálj.
Mellékeltem neked.

Mint látható ezek a fix interruptok, hogyha át szeretnéd tenni tetszőleges lábra, akkor max úgy teheted meg, hogy hardveresen rábütykölöd a PD7 -et az egyik INTx lábra.

Köszönöm a segítséget,adatlapot is néztem csak azt hittem valamilyen maszkolással át lehet szoftveresen tenni máshová, de így már nem is töröm rajta a fejem.Kösz

Hello!

Van 2db ATmega 328P-PU-m amin elvileg arduino bootloader van. Nem tudom őket felprogramozni ISP-n a TAVIR féle AVR AVRISP MKII-vel. Atmel Studio 6-al próbáltam, és nem ismeri fel őket amikor a Device signature-re kattintok. Lehet ez amiatt hogy az arduino bootloader van rajta?

Egy ATMEGA32-őt amin elvileg szintén az volt azt sikerült felprogramoznom. Azért írom, hogy elvileg mert ebayről vannak.

Nem lehet, az Arudino bootloader nem okozhat semmiféle problémát.

Viszont az Arduino alapból 16MHz-es külső kvarcra programozta a biztosítékokat.

Ha te 6 vezetetéken kvarc nélkül próbálod felprogramozni, az nem fog működni. Egy kvarcot rakjál be az XTAL1 XTAL2 lábak közé és ugyanezeket a lábakat 22 pF-körüli kapacitással kösd le a földre.

Ezután az ISP-nek mennie kellene, ahonnan akár a belső oszcillátorra is visszakapcsolhatsz.

Köszi! A külső kvarcznak is 16MHz-nek kell lenni ilyenkor, vagy a lényeg hogy külső legyen?

Szerintem tökmindegy a frekvencia, csak az ISP-nek helyesen add meg programozásnál.

Gondolom 1 MHz-es kristálynál lassabban próbál írni.

Ha hiányzik a kvarc, akkor minden áll.

Bocs, hülyeséget írtam. A doksi szerint 8-16 Mhz közötti kristály kell.

Table 9-3. Low power crystal oscillator operating modes(3).

| Frequency range (MHz) | Recommended range for capacitors C1 and C2 (pF) | CKSEL3..1(1) |
| 0.4 - 0.9 | - | 100(2) |
| 0.9 - 3.0 | 12-22 | 101 |
| 3.0 - 8.0 | 12-22 | 110 |
| 8.0 - 16.0 | 12-22 | 111 |

Köszi a válaszokat! Még egy dolog. Van 2db ATmega32-őm. Egy programmal ami sokmindent csinál, többek közt adatot fogad Soros porton.
Egyik pillanatról a másikra elkezdte azt csinálni, ha túl sok adatot fogad, (néha 5-10 karakter is elég) A soros port része lefagy, és fura dolgokat csinál. PL van hogy az az érzésem, hogy késik 1 percet az az utasítás amit legutoljára kapott. Elővettem egy másik ATmega 32-őt ugyanazt ráégettem változtatás nélkül, és megy minden rendesen. De hangsúlyozom 1 napja még a másik is ment. Szóval, mehet tönkre egy AVR-en a soros port rész?

[off]Tudod Murphy azt mondta: Ami elromolhat az el is fog romlani.
Tudom ez téged nem vígasztal, de miért ne mehetne tönkre az USART. Ha minden ugyan az és MCU cserével megjavul a dolog akkor ez van.
Bár jó lenne tudni, hogy milyen adatokról van szó és nem fordulhat-e elő túlcsordulás.
Mivel én nem vagyok AVR guru csak "parasztosan" gondolkodom.

Stack túlcsordulás. Azaz eszi a memóriát. Pl. ha sok rekurzív függvényhívás történik,
és a függvények változói is a stack-ben tárolódnak.
Az "1 perces késlekedés" lényegében vagy a stack "körbeér", vagy "leapad". Az első gyakoribb.

Sziasztok!

Tapasztaltatok már olyat hogy egy AVR eepromból kiolvasásra fals értéket ad?
Studio6-ot és jelenleg atmega88-at használom, a gyári eeprom.h -t töltöm be a programba.



ezeket a fv-eket használom . Indulásnál paramétereket kéne kiolvasnia a megadott címröl , és néha roszul olvas, vagy elfelejti, vagy magától! átírodik. A kódban sehol nincs olyan elírás ami átírná az adott byte-ot. Szerintetek mitöl lehet ez ?

Miota AVR-t használok ezeket a fv-eket hívom eeprom müveleteknél, és soha semmi baj nem volt vele... Most meg több eszköznél is van ilyen gond.

ez a "cím" ez mi akar lenni? Mert a fals érték kiolvasás pont ott bukik el, hogy rosszul adod meg az EEPROM címet. A gyári library pointerként várja a címet.

Tehát, például:


Pointerré kell előbb castolni a változót ahhoz, hogy működjön. Ez a "cím" a hozzászólásodban, kicsit sefüle-sefarka...

Igen igazad van , felületes voltam.
Pointerként használom, pont olyan formában ahogy leírtad.

Lehet esetleg gond a cím tartomány? Általában 10-100 között szoktam az EEPROM-ot címezni és használni. Vagy ez IC hiba lesz ?

Módosítok nem pont olyan formában ahogy te irtad hanem:

Néha magától átíródik, az tipikus esete a program counter elmászásának, amit a nem megfelelő feszültség szokott okozni. Ha az áramkör nagymértékben pufferelt akkor mindenképpen szükséges a Brownout reset. Enélkül valóban gyakorlati tapasztalatom, hogy az EEPROM össze-vissza teleíródik véletlenszerű adatokkal, egy-egy komolyabb program esetén. Nem véletlen volt régen indokolt a Reset áramkör.

Szerk: Értelem szerűen ez kizárólag be/kikapcsolási tranziens időszakban igaz. Minden azon kívüli indokolatlan EEPROM módosítás inkább stack overflow és underflow esetben valósulhat meg. Túlzott RAM használat esetén például (fordító általi dinamikus stack-elésre illik az SRAM terület minimum 20%-át szabadon hagyni).

Igazából túlzott ram használat nincs szerintem mert ez a progi egy kisebb kontrollerben is elférne, csak úgy voltam vele hogy most belefér
Program Memory Usage : 3474 bytes 42,4 % Full
Data Memory Usage : 182 bytes 17,8 % Full

A Brownout valóban ki van kapcsolva, alapból úgy volt, ahhoz nem nyúltam , úgy gondoltam fölösleges, mert a táp 5V elég stabil, minden lábon szürve van, plusz az 5V -os stab bemeneti feszültségén is egy viszonylag nagy kondi van.
Errata-ban olvastam hogy kis feszültségnél lehet gond , de ott is csak az írási folyamatot írja, az olvasásnál szerinte se lehet gond.

A nagy puffer okozza a gondot. Sajnos az errata-ban említett eeprom írás hiba valóban kis feszültségnél gond csak, viszont korábban megtörténik a rendellenes működés a program counter elmászása miatt.
Szóval a PC már elmászott, a program össze-vissza ír és a feszültség még stabil az EEPROM íráshoz.
5V esetén 4V3-as Brownout javasolt. Sajnos a minden lábon szűrés nem megoldás erre a gondra, mert nem feszültség tüskék miatt történik a rendellenes működés, hanem a nagy puffereltség miatti nem elég meredek feszültség tranziens miatt (tudod, van az a feszültség szint, hogy a proci egy része még működik, de a gyártási szórásokból van már olyan kapu egység ami már nem... pár mV különbség, de hibás műveletvégzést eredményez.)

Értem, így logikusnak is hangzik.
Szerinted megoldás akkor csak a 4v3 Brownout beállítása?
A nagy puffer lényegében egy 220µF 25V , ami viszont az analóg részhez kellene hogy maradjon.

Egyébként meg a program 1 esetben írja át ezt az EEPROM tartalmat , és utána ha nem akarok változtatin akkor akár évkig csak olvas a memoriábol, soha nem ír. Mármint direktben én nem szeretném hogy írjon. Ráadásul már elöre kész eeprom.hex fájlok vannak( alap konfig értékekkel) amiket csak rátöltök és ha minden jó akkor tényleg csak olvas az eeprombol.

Igen, elég csak a brownout.

Nagyon szépen köszönöm a segítséged.

Remélem meg fog oldódni a probléma.