Szerintem meg nem! Az IC adatlapja szerint csak 3.3V és 2.5V jeleket kezel az Rx és Tx vezetékeken. De az ellenállások miatt kibírja az 5V bemenetet, és egy 5V-on futó AVR a 3.3V-os kimenetét már HI-nek fogja érzékelni. Azaz használható, de ettől még 3.3V-os marad a cucc.

Bar adatlapot a modulrol nem talaltam, de szerintem ennek nem kell adni sem 5 sem 3.3 voltot, mert az USB 5V-rol jar a chip, es az ad ki 3.3V max. 100mA-t. Ugyhogy gyanitom, hogy siman 3.3V-os jelekkel megy, de ahogy zombee is irja, kibirja az 5V-ot, es a 3.3V meg egy AVR-nek már HIGH (0.6 x Vcc).

Az IC adatlapjáról néztem. Kiegészítő szintillesztőt nem látni a modulon, így biztos a 3.3V-os jelszint.
Véletlenül nekem is van itthon egy ilyen, használom is, de eddig nem vettem észre hogy ne működne. Ha előkerül, mérek rajta egyet...

Az avr-gcc 5-ről tudtok valamit?

Legnagyobb meglepetésemre az avr-gcc 4.8.2 13%-kal kisebb kódot fordított, mint az avr-gcc 4.4.
Igazából az érdekelne, hogy van-e hasonló ugrás kódméretben avr-gcc 5 alatt is, vagy még csak korai fázisban van?

Hogy lehet felrakni Windows-ra? Mit kell egyáltalán letölteni? MinGW-t?

Nem értem tisztán ezt az avr-gcc dolgot.Van egy linuxos verzió és van egy win-es a studiohoz,amit az Atmel fejleszt ?

Sziasztok!
Tudnátok abban segíteni, hogy .ino fájlból hogyan csinálok .hex-et?

Az AVR-GCC win alatt ugyanúgy használható parancssorból mint a linuxos verzió. Csak win alá van egy Eclipse/Visual Studio alapú IDE, ami a GCC-t használja. Elvileg Atmel fejleszti ezt is, csak csomagban(WinAVR ill. AVR Toolchain) kapod, Linuxhoz meg a "csupasz" AVR-GCC fordító érhető el.

Szia! Lefordíttatod az Arduinoval, majd valahol a c meghajtón az user/appdata/local settings/temp/ mappában megkeresed a hex fájlt. Ne zárd be közben a progit! Az útvonal lehet, hogy nem pontos, már rég néztem utána, de valamelyik temp mappában fogod megtalálni. Előtte állítsd be, hogy láthatóak legyenek a rejtett fájlok.

Megkerestem, nálam ez az útvonal: c:\Users\Morgo\AppData\Local\Temp\build1822675597850789791.tmp\
A temp mappában érdemes a legfrissebb dátumú mappát keresni.

Total Commander ebben nagyon hasznos tud lenni, de a Temp mappa előzetes ürítése is segít...

Igen én is azt használom. Az ürítgetés meg időnként eszembe jut, máskor nem...

Sziasztok! Adott egy K típusú hőelem, amivel termosztátot akarok készíteni úgy hogy egy ATMEGA8 vezérel egy relét, és az volna a kérdésem, hogy hogyan köthető össze az ADC-vel a hőelem? A hőelemnek a hőmérséklet függvényében változik az ellenállása?

A hőelem kicsit macerás, lehet hogy hőellenállás(pl. KTY82) jobban feküdne. A hőelem termoelektromos feszültségforrás, a K típusú kb. 41uV/°C (mikrovolt!!! / fok) feszültséget ad ami erősítés nélkül nem mérhető AVR-el.

250 Cfok körül kellene mérjen, a KTY82 kibírná? S jó volna valami eléggé lineáris mérőzeközt választani.

Azt nem említetted mennyit kell bírnia.
Amúgy KTY81 akart lenni(mert az furatszerelt), de sajnos csak 150°C-ot bír. A hőelemet semmiképp nem tudod elkerülni, mert nagyjából lineáris és bírja a hőt. Mi pl. hullámforrasztóba(~275°C) is használjuk, nem zavar be a mérésbe az sem ha a mérendő közeg vezetőképes.

Neked mindenképp kell egy erősítő, egy KTY81 a hidegpontra, annak is erősítő meg áramgenerátor. A két értéket(KTY81 és K-hőelem) összeadva megkapod a hőmérsékletet. Nem árt az erősítők bekalibrálása sem, de az értékeket már lehet digitálisan korrigálni az AVR programban.

Vagy egy MAX31855 megoldja az egeszet es egyaltalan nem kell A/D-vel meg mikrovoltos erositovel bajlodni. Ebben benne van a hidegpont homero, az erosito, 14 bites A/D, minden.

Köszi ! Gondolom a studioba nem piszkálhatok bele ez ügyben,meg kell várni a frissítést ?
4.8.1-nél tart.

AVR ToolChain telepítéssel "belepiszkálhatsz".

Sziasztok!
***
Erre van az apróhirdetés!
-moderátor-

A Winavr az valami 2010-es borzalom. Szerintem a jelenlegi gcc méretben a felére fordít.
Nem értem, hogy miért álltak le a fejlesztésével.

Eddig úgy tudtam hogy a WinAVR-t ugyanazok csinálták mint a ToolChain-t. Pl. a help ugyanaz, csak utóbbinál néhány oldal hiányzik(pl. az "Alphabetical Index" majdnem üres).

Két éve még működött nálam a WinAVR minden további gond nélkül. Mondjuk én alapból kis IC-kre(pl. ATTiny13) írok programot, ezért elvből nem használok lebegőpontos számításokat sem. Aminél nagyobb felbontás kell, ott uint8_t tömbként kezelem a 64-256 bites számokat, rájöttem hogy a mai (!!!) fordítókkal is kisebb kódot eredményez ha "kézi vezérléssel" oldom meg a 64 bites számok alapműveleteit. Nem mindegy a programszervezés, én azért figyelem hogy egy új utasítás mennyivel növeli a fordítás utáni kódméretet, ha túl nagynak találom akkor elkezdem keresni a növekedés forrását és ilyen-olyan trükkel(pl. ciklusszervezés) lefaragok belőle.

Hát igen, nekem már a 32 bites számok kezelésével is igencsak sok bajom. Minden számot külön regiszter 4-esbe rak a fordító, amit push/pop műveletekkel végigzavar a vermen a függvénybe belépéskor és kilépéskor. Gigantikus kód keletkezik még a 32 bites változókkal is.

Mindegy, én gyakran használok 32 bites számokat. Nem trükközök sokat, fogok egy 328P-t 16 MHz-en, azzal talán elboldogul.

Annyira kicsi a különbség árban, hogy inkább benyomom azt a 200 forintot, csak ne kelljen szórakozni.

Ezért kell globálisként definiálni őket, és akkor nincs az a sok push-pop, nem a stack-re teszi őket ki és be. Persze nem árt ha a függvényeidet is hozzájuk hangolod, azaz a paraméterlistában és a visszatérési értékben nem adod át ezeket a "nagy" számokat. Ez egy nagyon egyszerű trükk, de simán ellenőrizni tudod az így kapott kódot.

A másik kedvencem a szövegkonstansok. Ha nem globálisként definiálom őket hanem valamelyik függvényben, esetleg egy függvényhívás paraméterlistájában adom meg, a fordító akkor is lefoglal nekik n+1 bájtnyi helyet a RAM-ban, azaz valahogy mégiscsak globális lesz a változó. Végülis valahol érthető hiszen tömbről van szó, de tényleg folyamatosan a memóriában kell lennie? Egy példa:


Csak szólok hogy a MAI fordító is ugyanazt a hibát elköveti, azaz a fenti sztringekre már a program futásának legelején áttölti a sztring konstansokat a RAM-ba, és azok végig ott lesznek. Most képzelj el egy hosszabb listát, és akkor hiába van ATMega128-ad, ennyi sztring egyszerűen nem fér el a RAM-ban (egyszerre). Pedig garantált (a fenti példa szerint) hogy ezekből kettő egyszerre soha nem kell neked.

Ezért van az (és megint egy apró trükk) hogy ha sok az előre definiált sztring akkor használom a PROGMEM funkciót. Ezek normál esetben is foglalják a FLASH-t, de ha PROGMEM-el mennek akkor a RAM-ot már nem fogják. Max csak a kezelő függvény ami ideiglenesen áttölti a szükséges részeket a stack-be vagy egy munkaváltozóba, aztán el is felejti. Vannak kifejezetten PROGMEM sztringeket kezelő gyári függvények, a többit sajnos neked kell megírnod. De megéri.

A C nyelv pontos betartasa nem hiba egy fordito reszerol. Ha egyszer maskepp nem lehet megoldani, akkor igy oldja meg a fordito. A pointer az pointer. Ha a FLASH-t nem tudja ugyanazokkal a pointeres muveletekkel elerni, mint a rendes data-t, akkor kenytelen a const data-t is atmasolni a RAM-ba. Ez nem a fordito hibaja, hanem az AVR-e. Ez a Harvard architektura nagy hatranya a sok elonye mellett. Nem veletlenul csinalnak manapsag Modified Harvard processzorokat, mint pl. a Cortex-M3. Ez azert tulzas, hogy kell. Ettol rovidebb kod lesz, az igaz, de ezzel az erovel programozhatnal BASIC-ben is. Ennel sokkal jobb megoldas, hogy ha sokat kell 32 bites szamokkal dolgozni, akkor nem 8 bites uC-t hasznal az ember, hanem 32 biteseet, ahol egy atlagos fuggvenyben a lokal valtozok regiszterekben vannak vegig, nem stack-el semmit. Ja, es mindjart a FLASH-t is pont ugyanugy kezeli, mint a RAM-ot. Es olcsobb, mint egy ATMega128...

Érdekes, ha egy függvényen belül definiálok egy tömböt, azt automatikusan a stack-re teszi.
Ezért a sztring konstansokat is tehetné a stack-re, majd a pointert átadni a hívott függvénynek.
És akkor nem kellene a RAM-ba helyeznie a fordítónak, C szabványok vagy Harvard architektúra ide vagy oda. Érdekes hogy a "kívánatos" működést le lehet programozni három lépéssel: sztring definiálása PROGMEM használatával, egy helyi tömb definiálásával és másolással. Csak ez pár sorral hosszabb, és aki nem ismeri ezt, vakarhatja a fejét hogy hova megy el az a sok memória...

Ebben nincs semmi erdekes, ezt igy kell csinalnia.Nem tehetne, mert a string konstans az konstans, azaz a program teljes futasi ideje alatt meg kell legyen. A stacken meg nem marad meg. Ezert masolja olyan RAM teruletre, ahol vegig megmarad.Biztos van ilyen fordito is AVR-re, csak az nem C fordito.
A PROGMEM sem ad teljes megoldast a problemara, mert a prgram irojanak minden egyes esetben tudnia kell, hogy az adott string rendesen lett deklaralva vagy PROGMEM-ben. Vagy masolgatni kell, ahogy te is mondod, de az megint egy eleg pazarlo megoldas.

Pont a másolgatós megoldás az ami nem pazarló, mert nem kell az összes sztringet a legelejétől kezdve a RAM-ban tárolni. Max. ott lehet pazarlás hogy az átmeneti tömböt a leghosszabb, éppen előforduló sztringre kell méretezni, és egy pár betűs sztringnél is le kell foglalni az egészet. De mondjuk egy strlen_P() sokat lendíthet a dolgon, mert egy sztring konstans mérete már fordításkor adott. Kérdés az, hogy a fordító hogyan kezeli ezt le.

Ha a "pazarlás" címszó alatt a CPU időt érted, akkor igazad van, a PROGMEM-ből másolgatás elég sokat felemészt. A "default" megoldás meg semmit, mert az AVR indulásakor mindent bemásol a RAM-ba és a függvény hívásakor a pointert adja át.

Es mit csinalsz egy olyan fuggvenyhivasnal, ahol tobb string is van? Az strlen_P() egy kutyakozonseges fuggveny, es a gcc nem fogja forditasi idoben kiszamolni, hogy az mit adna vissza.Igen, azt ertem. Pazarlas alatt mindent ertek, ami lassitja vagy hizlalja a kodot es pazarolja az eroforrasokat. Az osszes const data RAM-ba masolasat azert nem nevezem pazarlasnak, mert az AVR-en maskepp nem lehet szabvanyos C-t forditani. Ez nekem is nagy csalodas volt, amikor eloszor dolgoztam AVR-rel a von Neumann architekturas processzorok utan.

Az más kérdés ahol egyszerre kellenek, de a legtöbb esetben(lásd a fenti példaprogram részletet) mindig csak akkor és ott kell, máshol nem. A PROGMEM erre is megoldást nyújt.

Ezért is írom úgy a függvényeimet(már amelyik programnál feltétlen szükséges) hogy a "mezei" konstans sztring helyett FLASH-be égetett sztringeket kezeljenek, és nem kell másolgatni sem, közvetlenül a konstansokat dolgozza fel(pl. SMS küldésnél karakterenként olvassa ki és másolja a küldő pufferbe).