Igen, soha nemvolt kompatibilitási problémám.
Használok még szintén ebay-ről vett Arduino Mini Pro modulokat is, ezekkel sincs semmi probléma.

Esetleg tudod pontosan kitől vetted az ebay-en a fejlesztői panelt? Pontosan milyeni Mini pro modulokat vettél eddig? Ha esetleg megvan a forrás az is érdekelne. Mindig picit lutri az előre utalásos vásárlás, bár eddig, hogy lekopogjam nekem sem volt problémám egyik vásárlásommal sem.

Szia, előre elnézést kértem, mert sejtettem, hogy nem túl jó helyen járok. Sajnos olyan sok a fórum téma, hogy nehezen igazodtam/igazodom ki rajta. Újra elnézést kérek. Azért remélem még whit33r válaszol itt. Köszönöm az iránymutatást és az eddigi segítséget!

Oké, jogos, nem gondoltam végig rendesen.

Az adatlap szerint ez nem jó !
Ezért nem jön ki a pwm jel.

Fault and Protection Handling
The FAULT pin indicates an error event with shut down has occurred such as over-current, over-temperature,over-voltage, or under-voltage. Note that FAULT is an open-drain signal. FAULT will go high when gate driver is ready for PWM signal (internal EN_GATE goes high) during start up.

Üdv!

Atmel Studio 6.2-es változatába beépítettem az Arduino szoftver által használt header fájlokat, így már nyugodtan tudom az ott elérhető függvényeket atmel studioban is használni. Az eddig lefuttatott példák tökéletesen működtek, most soros monitorra szeretnék adatot kiíratni, ez azonban nem működik. A programozás egy STK500-as programozón keresztül történik, ezen keresztül menne a kommunikáció is az atmega chip és a számítógép között, ez lehet a gond? Igényelne a dolog még további beállításokat esetleg? (képet mellékeltem)

Sziasztok!
Az lenne a kérdésem hogy ezt a kódot mondták, hogy írjam be a fuse bitek állításához, és nem reagál most konkrétan semmire. mit lehet vele tenni?
"avrdude -c usbasp -p attiny2313 -P usb -U lfuse: w: 0x00: m -U hfuse: w: 0x00: m"
Üdv: Dávid

http://www.engbedded.com/fusecalc
Alul kitöltöd 00-kkal és megnézed hogy mit is állítottál be.
Igen átállítottad külső órára. Milyen órajelforrás van mellette?

+ a reset-et is letiltotta.

Mi értelme van a Profi „Atmel Studio 6.2” lebutításának amatőr Arduino szintre?

Az Atmel Studio 6.2 -nak kel még az : #include <stdio.h>
Bővebben: Link

De ez nincsen benne az arduino.h-ban?

Gondolom megpróbál Arduino-t szimulálni vele (debug).

Sokmindent el lehet mondani az Arduino-ról, de prototípus készítéshez kiváló. Ha meg AVR Studióban debuggolni is tudod, akkor ötvözöd a két rendszer előnyeit.

Mindenki tisztában van vele, hogy az Arduino mikrokontrolleren pazarolja a memóriát, drasztikusan lerontja a teljesítményt,... de annyi lib-et megírtak hozzá, amit simán csak letöltesz és pár perc alatt összeütöd vele a prototípust is.

Használok I2C hálózatot és időnként tesztadatokat kell rajta kinyomni. Kultúrált programozás helyett természetesen Arduino-zok és az sem zavar, ha 20k-s végeredmény születik.

Valamikor a Világnak kezdetén nagy divat volt a Bézik nyelv! Mégis letűnt a színről!
Szerintem ez lesz az imádót Arduino sorsa is.

Viszont az eredeti kérdés az volt: Hogyan kel soros monitort szimulálni?
Ezen az öszvér megoldáson.

Szia!

Én is csináltam ilyet atmega 2560 mirovezérlővel. Azt tanácsolom nézd meg a attiny2313 adatlapján a fuse beállításokat. Az én esetemben ez így nézett ki: -U lfuse:w:0xE0: m -U hfuse: w: 0x99: m : ami azt jelenti h high fuse alapbeállításon maradt, l fuse lényege pedig h külső osszcillátort használhattam órajel generáláshoz. Ha a belső osszcillátort akarod használni akkor CKSEL bitek valószínüleg mások lesznek, a 0x00 beállításnál minden bited 0 eléggé rossz verziónak tűnik.

Pontosan a lényeg, hogy a két rendszer előnyeit szerettem volna ötvözni ez sikerült is, nyugodtan tudok már használni előre megírt függvényeket is pl: PID(). A soros monitoron való kiíratással pedig az lehet a gond, hogy egy régebbi hiba miatt elszállt a boardon az USB/soros chip, ezért használok programozáshoz stk500 programozót, amit ISP6 csatlakozóval kötöttem össze az arduinoval. Azt gondolom ez lehet a gond, mivel most már szinkron soros kommunikáció történik nem pedig asszinkron soros, de lehet, hogy rosszul gondolom.

Annak idején volt basic és gépi nyelv (assembly). Az assembly képességei lényegesen jobbak voltak, de macerás, ezért mindenki basic-ben tolta az egyszerűbb feladatokat.

A C/C++/Java/C# nem tartozik az egyszerű nyelvek közé. Valószínűleg az Arduino ki fog veszni, de arra mérget vehetsz, hogy nem a C/C++ fogja megölni. A C/C++ legnagyobb hibája, hogy nincsenek szabványos könyvtárak. A Java/C# könyvtárak millióit adja, míg a C csak egy fordítót és szevasz. Nem kell egyesével levadászni a netről a megfelelő licenszű könyvtárakat, hanem már készen megvan minden. Ugyanaz a kód megy Windows, Linux, Android, Mac OS... alatt is.

Az Arduino még ettől messze van, de felépítésében hasonlít rá.

Csak egy kis problema adodik. A ukontrollerek nem egy erogep tipusok. Azokra valos ideju programot probalunk irni ASM e C nyelven, es nem vinf.$ vagy Macis stilusban programolni, aholis gigabytokban merjuk a ramot es terrabytokban a hattertarat. Csinaltam egy par PC-s vezerlest ipari folyamatokra de sajnos a valosideju vezerles csak DOS alatt sikerult normalisan. A mai napig dolgozik rendszerem DOS alatt. De ma mar nem csinalnek ilyet, inkabb valami Atmel, Microchip kontrollerre hajaznek. Viszont csak ASM, vagy C programnyelvvel. Csinaltam 1-2 projectet Arduinora is, de igen szoszatyar volt a fordito. Az hogy valaki uC-t ugy akar programozni mint egy PC-t ..... No comment. A libeket C vagy ASM nyelven nem kell levadaszni a netrol. Kis gyakorlas (3-4 ev) es kialakulnak a dolgok.

A Standard C library szerinted megis micsoda, ha nem szabvanyos konyvtar. Es bizony jon a C forditoval. Persze altalanos celu fuggvenyek szazairol van szo, nem i2c meg spi es egyeb HW specifikus dolgokrol.
Mellesleg BASIC-et a mai napig hasznalnak rengetegen. Akar PC programozasra, akar mikrokontrollerre. Igaz, nem az ős BASIC-et. vizuál bézik, bascom..

> A Standard C library szerinted megis micsoda?

Jó kérdés. Valami múltbeli örökség a 70-es évekből. Mindenesetre a printf és még 10 másik függvény használható is, de összehasonlítani a Java/C# könyvtáraival merész.

Itt értsd a lefedettséget / dokumentáció minőségét / hordozhatóságot. A Standard C library sehol sincs a másik kettőhöz képest.

Java alatt az SQL-től a ZIP fájl olvasásáig minden egységes keretbe van összeszedve. Ahány C kódot láttam, annyiféle hash-tábla megvalósítás volt benne.

Mivel ez itt most 8 bites AVR témájú topik!
Hogy az Isten csodájába jön ide a Jav, vagy SQL???

Az egesz C egy multbeli orokseg, de valamiert a mai napig minden ertelmes helyen ezt hasznaljak HW kozeli es rendszer software-k irasara. Dokumentaciorol meg annyit, ha en tudni akarom, hogy a memset() fuggveny mit csinal, akkor egy terminalban annyit mondok a gepnek, hogy man memset... De ezt te is megteheted ma mar a google-n, nem kell UNIX gep hozza. Szoval a C konyvtar dokumentaltsaga jo. Hogy SQL es ZIP fuggvenyek hol vannak, az mas kerdes, mikrokontrollerekrol beszeltunk. Te mar lattal AVR-re JAVA interpretert?

Konkrétan arról van szó, hogy az Arduino hasonló keretek közé próbálja alakítani a C-t.

Hogy ne kelljen az SPCR = 0x53 -as baromságokkal szórakozni a kódban, hanem az SPI könyvtárat használva értelmes körülmények között lehessen SPI kommunikációt írni.

Ez pedig működik Atmega328P, Atmega2560,... sőt még PIC klónok alatt is.
Pont ugyanaz a cél, mint a Java/C# alatt, csak jóval gyengébb a megvalósítás minősége.

Konkretan arrol van szo, hogy az arduinosok milliardokat akarnak keresni. Aki tud programozni es erti az adatlapot, az bizony ilyen baromsagokkal foglalkozik, hogy SPI drivert ir az adott kornyezetnek megfeleloen. Meg aztan, ha egyszer mar megirtad, akkor van SPI konyvtarad. De ha jobb kell vagy mas, akkor atirod. Es legfokepp tudod, hogy mit csinal. Aki meg nem tud ilyet irni, az ne programozzon mikrokontrollert...
Es kozben azon elmelkedtem, hogy a nagytudasu Java programozo ismeroseim miert b@sszaznak orakon at, amikor az androidos java kodjuk tok mast csinal ket tableten... Szoval, en mar nagyon regen nem hiszek ezekben a mindenen futo nagy komplexitasu dolgokban.

Hát, ha tudnád, hány hardvert / program megrendelést mondtam vissza, mert nem futott Linuxon.

Helyesen fogalmaztál, órákba telik egy Andoidos alkalmazás egyik tabletről a másikra portolása.
C/C++ alatt Windows-Linux között ugyanez években mérhető.

Én is megírtam magamnak vagy 50 libet, ami I2C-től a bootloaderen át mindent elintéz, fut azon a 3 IC-n amit használok. Mindenki megír magának szerintem ugyanennyit. Konkrétan az egésznek semmi értelme, ezen próbál az arduino valamit segíteni.

Hát, ha tudnám. De nem tudom. De nem is ertem, hogy ez most hogy jon ide. A man fut linux-on is. En csak ennyit emlitettem.
Ha egyszer en letoltok egy android alkalmazast, ami minden androidon kell fusson, akkor miert nem fut?? Pont az lenne a lenyeg, hogy ne kelljen portolni. Ok megirtak a programot, mi letoltottuk a marketrol, es mast csinalt a ket tableten. Ennek semmi koze ahhoz, hogy egy C-ben megirt kodot hogyan lehet dozerre portolni. Ez ket tok mas dolog.

Nagyon off topic.

Maradjunk az eredeti témánál: miért nincs egységes AVR library a perifériák kezelésére.

Miért kell mindenegyes AVR IC-re külön megírni a TIMER rutinokat, mert tök más a regiszterkiosztás és még csak véletlenül se fordul, ha más mikrovezérlőn használnám...

A XXI. században élünk, a jelenlegi fordítók igazán kioptimalizálhatnák az



bonyolultságú hívásokat. Az Arduinonál próbáltak erre csinálni valamit, de úgy sikerült, ahogy.

De milyen korlátok árán?

Használhatsz ösz.-visz. 5 Atmega típust.
Atmega8, -168, -328, -1280, -2560.

És a többi, ami hiányzik a felsorolásból, azt neked kel megoldanod?

Szerintem addig amíg a perifériák nem egységesek nem is lehet a perifériakezelést egységesen megoldani (ez az oprendszer dolga lenne, ha itt létezne olyan). Amit az egyik vezérlőnél meg tudsz oldani, a másik vezérlő nem tudja. Ami már inkább kérdésem, hogy legalább a stringkezelő és szám->string átalakító függvényeket miért nem tudták egységesen megcsinálni (bár lehet hogy ez inkább microchip-ék hülyesége?). Elég érdekes hogy pl. az utoa függvény paramétereket más sorrendben kell átadni atmeléknél és máshogy mc-éknél.

benjamin kollega valaszolt helyettem is. Ket kulonbozo TIMER-hez ne akarjunk egyseges fuggvenyeket.. Ez inkabb az atmel hibaja, ha egyaltalan hiba ez, de semmikeppen nem a C nyelve. A nyelvtol fuggetlenul lehetnenek megirt konyvtarak. Es addig jo nekunk, amig a C fordito nem optimalizal ki kulso konyvtari hivasokat... Bar mar a standard C string hivasokat hajlamos atirni, ha kulon nem kered meg, hogy ezt ne tegye.

Bocsanat, nem benjamin, hanem benjami.


Az itoa, utoa nem standard C fuggvenyek, mindenki ugy implementalja oket, ahogy akarja.
Az sprintf standard, igaz nem tud akarmilyen szamrendszerben dolgozni. Ha valakinek 7-es szamrendszerben kell kiirnia szamokat, az valoszinuleg megirja maganak a egyebkent 8 soros fuggvenyt. Bővebben: Link Nem is ertem, hogy itt az AVR (es pic) topikokon mindeki itoa-zik es usart_out meg hasonlokkal irnak ki, amikor siman lehet csinalni printf()-et. Ezerszer egyszerubb lenne a dolog.

Akarjunk közöset.

Nyisd meg az Atmega8535 (Atmega32) és az Atmega328P doksiját a TIMER0-nál.
Gyakorlatilag a 328P timer0-ja a továbbfejlesztett változata a 8535-nek.

Tehát:

timer_set_mode(0, TIMER_FAST_PWM);

-nek mindkét vezérlőn mennie kellene, míg a

timer_set_mode(0, TIMER_FAST_PWM_OCRA_TOP);

csak 328P-n szabadna, hogy forduljon, ellenkező esetben fordítási hiba.
Agybajt kapok attól, hogy 10 IC-n 20 féle regisztert kell össze-vissza állítani, típusonként máshogy.