Arduinó környezetben szeretném hogy minél egyszerübben lehessen használni, tehát hogy ne kelljen #define-t használni magában az .ino fájl-ban. Tehát attól függöen hogy melyik konstruktort használom, az alapján döntöm el hogy mely funkciók legyenek befordítva.

Arduino-ban a library-k előbb fordulnak le, mint az INO program. Ezért az INO már nem tud visszahatni a library-ra, abban nem tudsz feltételes fordítást csinálni. (Amennyire én tudom.)

Az Arduino-ban az INO fájl egyébként c++ fordítóval lesz lefordítva, annyi trükk van benne, hogy az Arduino ezeket a lépéseket végzi el:

* A függvényekhez ha nem írtál prototípust, akkor automatikusan a fájl elejére beilleszt prototípusokat.
* A kézzel beírt inklúdokból kitalálja, hogy melyik libet használod, és azoknak az inklúd foldereit hozzáadja a fordításhoz, illetve a libet lefordítja:
* A függő libeket _önmagukban_ fordítja le, majd a kapott binárist a főprogramhoz linkeli. Ezeket a libeket forrásból fordítja, de egy temp folderben cache-eli, tehát ha nem változik, akkor nem fordítja újra.

Látható, hogy a függő libek fordítása független az INO programtól. Ezért nem tudunk fordításkor aszerint elágazni, hogy mi van a főprogramban. A libek ezért úgy működnek, hogy dinamikusan vannak összekötögetve például a pinekkel, amiket szám szerint adunk át és futásidőben állítgatja be magát.

(Ez egyébként időkritikus programok esetén probléma lehet, mivel a hardverek függvényen keresztüli elérése setPin(2, HIGH); setPin(4, HIGH) sokkal lassabb, mint ha be lehetne írni pl, hogy PINB|=0b0010100; )

Mivel a library fordítása független a főprogramtól, ezért az Arduino keretei között maradva az lehet a megoldás, hogy a két megvalósítás:

* Két külön library ugyanolyan nevű osztállyal: így csak az a kód lesz belefordítva, ami fut is



* Két osztály azonos interfésszel: így a fordító rossz esetben mindkét osztályt befordítja, és ha valóban interfész szerint érjük el a függvényeket, akkor rossz esetben a függvényhívások indirekten lesznek megvalósítva. Ez csak akkor baj, ha idő vagy helyhiány van.



* Egy osztály felparaméterezve és _futásidejű_ elágazásokkal: Itt az összes kód ott van a csipen a végén, és egy kevés plusz időt is elvesznek az elágazások futásidőben.

Köszönöm a részletes leírást, az első megoldást szeretném elkerülni ha lehetséges de nincs kizárva hogy ez lessz a megoldás. Erről lenne szó, ez teszt változat, valójában a konstruktor hivással dől el hogy mely kommunikációs interfészen keresztül fogunk kommunikálni az adott eszközzel (SPI vagy UART) és ahogy figyelem az SPI van elönybe részesítve. A harmadik megoldást használom jelen pillanatban, a másodikkal megpróbálok kisérletezni. Köszönöm mégegyszer. (jelezd nyugodtan ha rossz megoldásokat használok és nézd el nekem, ez csak hobbim kb. 4,5 éve iratkoztam fel az arduinos 60 napos tanfolyamra előtte szinte 0 programozói tudással. Ez nekem olyan kisérlet és tanulási projekt )

Elég komolynak látszik, nem semmi feladat ezt jól megcsinálni.

Láttam olyan trükközést, hogy a library nem cpp, hanem .h include fileban volt...
Így az ino-ba megfelelő sorrendben include-olva, megváltoztathatók a paraméterek/feltételes fordítások...

Egy bosszantó problémával találkoztam és nem tudom merre kellene elindulni.

Adott egy modul, ami 12V-os tápot kap, ebből TS34063 segítségével állít elő 5V-os tápot egy Attiny2313 részére. A attiny RS485 buszon kommunikál SN65176-os buszmeghajtón. Az IC 12V-os reléket vezérel ULN2003-as IC-n keresztül. A tápot (és RS485-ös buszt) kb 1m kábelen kapja egy relén keresztül. Ugyan erre a relére van még kötve több hasonló modul. A 12V egy akkumulátoros tápegységről jön. A programban watchdog használva van, ha 8 mp alatt nem kap üzenetet a buszról, akkor reset-eli.

A hibajelenség, hogy néha táp elvétele és visszakapcsolása után a modul (csak ez az egy) nem kommunikál. A tápot a relé nem csak ettől a modultól hanem az összes többitől is elveszi, mert ezek közösítve vannak.

A hibát úgy lehet megszüntetni, ha a modulnál egy pillanatra lekötöm a 12V-ot.

A fenti jelenség ritkábban fordul elő, ha a bodlevel 4,3V helyett 2,7V.

A modul viszont attól nem javul meg, ha rákötöm a programozót (ISP-től tápot nem kap) és kiolvasom a fuse biteket.

A fenti hibát nem értem, mert a tápot megkapja az attiny, a programozó (hobbyelektronikás avr droper) kommunikál az attiny-vel (pl.: fuse biteket kiolvassa). Rámérve megvan az 5V. A reset sem lehet gond, mert maga az olvasásnak is reset-elni kellene.
Program hiba sem lehet, mert egy pillanatra lekötés után rögtön megindul a kommunikáció.

Viszont ha a táp reléjével az ettől és az összes többi modultól elveszem és visszaadom a tápot, az nem javítja meg.

Valakinek bármilyen ötlete mit kellene tennem vagy mit kellene megnézni, merre elindulni?

Keresztbe csereberéled az alkatrészeket egy jól működő panellel, és figyeled mikor megy át a hiba a "jó" panelre.

Az Attiny olyan keveset fogyaszt, hogy "maradékon is megél". Például a kommunikációs vonalak van hogy visszatáplálják. Ha az adatvonalakra feszültséget teszel, akkor is beindul. Lásd pl.: https://hackaday.com/2018/01/05/attiny-chip-abused-in-rfid-application/

Nem lehet, hogy az RS485 buszról parazita módon felvesz egy kis áramot, és azon eléldegél?

Ez magyarázná, hogy miért kell lekötni ahhoz, hogy újra tudjon indulni. Azt nem magyarázza, hogy milyen hibaállapotban van.

Én régebben szívtam sokat ilyennel.

Ismét egy pointer-os kérdésem lenne. Egy függvény 2 argumentumot vár, pointer egy uint8_t tömbhöz és a tömb mérete, én viszont csak egy char (int8_t) változót szeretnék átadni neki és persze 1 -et mint méret. Leírom hogyan gondoltam(valószínü tévesen mivel a kód lefordul de warningot ad gondolom mivel tömböt vár, cast to pointer from integer of different size [-Wint-to-pointer-cast]).

A csodába, a kérdés meg lemaradt. Barátkozzak meg a warning-al vagy más módon adjam át a változót?

Hiányzik a pointerképzés:

Ahh , ezer köszönet. Ezekbe a pointerekbe még nagyon el tudok tévedni.

Sziasztok.
Lenne egy problémám 2 db motort kellene vezérelni oda,vissza forgás.
Úgy szeretném hogy az 1. motort 2 láb és a 2. motort ismét két láb vezérelné.
Optocsatoló + Mosfet N és P csatornás controller
Ott jön a baj hogy pwm jel kellene de csak egy Atmega8A van és csak 3 lába mehet pwm-re.
Gondolkozok egy Atmega164 6db PWM kimenete van, ebből 2 db menne az első motorra 2 db pedig a másik motorra.
Ez így lehetséges?
Vagy meg lehet oldani másképpen is?

Miért kell neked 2 PWM egy motorhoz? Az irányváltás miatt amugy is kell egy H-hid valami azaz az egyik lábbal vezérled az irányt (H/L) a másikkal meg adod a sebességet (PWM).
Nem tudjuk milyenek a motorok, de ha 1A aluliak akkor itt a TB6612 chip az egyböl 2 motort tud vezérelni.

Én eddig ezeket használtam:

L9945
Amperben határ a csillagos ég. Ez egy driver IC, 8 db N-FET meghajtására képes, akár 2 H-híd konfigurációban is.

VNH5019
Ha elég kevesebb Amper is, akkor ebbe integrálták a teljesítmény FET-eket. Hűtés nélkül is elmegy róla 5-8 Amper.

VNH7040AY
Szintén integrált megoldás.

Hídmeghajtó nélkül szívni fogsz, mert magadnak kell megoldanod, hogy ne nyissanak szembe a tranzisztorok, ki kell bírnuk a generátor üzemet, stb.

Igen tudom linkeltem egy képet hogy is gondolom de be linkelem megint.

http://www.bristolwatch.com/img1/hb2.jpg


2 láb az avr-től menne a OC1 és OC2 re úgy gondoltam hogy ha akarom vezérelni a fordulatot akkor 2 pwm kimenet kell ami az OC1 és OC2 re fog menni.
De lehet hogy rosszul gondolom .

Lenne egy másik is:
itt

Azért gondoltam hogy én építem meg mert optocsatoló és mosfettem is van a motor árama max 4A lenne 12V-ról.

Mindkét lábon elvben ugyanazok a szintek vannak, csak amikor irányt váltasz akkor az egyik lábon fixen H vagy L szint van, de másikon a PWM továbbra is a H meg az L között ugrál. Ha simán az egyik láb PWM, akkor irányváltáskor a sebesség is invertálodik ( ha elöbb állt a akkor utánna max sebességel fog forogni és forditva.
De ezt kezelni lehet pl port tükrözéssel. A PWM jelet egyszer az egyik, ellenkezö irányban meg a másik portra vezeted ( a kodban).

AVR-en nincs port tükrözés, az OCR1A mindig ugyanarra a pin-re dolgozik. A kimenet kitöltési tényezőjét viszont tetszőlegesen lehet változtatni irányváltáskor.

Úgy gondoltam hogy ha OC1B 1 akkor OC1A 0 és irányváltáskor felcserélem OC1B lesz 0 és OC1A
1 lesz.

Az első rajz szerintem sehogy sem jó:

* A tranzisztor zárásakor a motor tekercsében keletkező feszültségtüskét nem vezeti el sehova. Ezt a tranzisztorokkal "szemben" elhelyezett diódák szokták megoldani. Ha a FET alkatrésznek van parazita diódája - azaz fordított emitter source - feszültségre áram folyik rajta, akkor az elvezetheti, tehát ez megoldás lehet elvileg. Mivel ez itt lényeges, ezért azt be szokták rajzolni a rajzba.
* Ha PWM-mel hajtod, és a PWM "off" állásba megy, akkor valójában a motornak mindkét pólusát 0-ba húzod! (Vagy mindkettő magasba van húzva, lényegében akkor is ugyanez történik a leírtak szempontjából mindegy.) A forgás miatt a motor által generált feszültség a FET parazita diódájával együtt rövidzárba kerül, a rendszer fék üzemmódban működik. Ráadásul semmi nem korlátozza az áramot, csak a tekercs és a FET-ek: ezek fognak nagyon melegedni. PWM-mel hajtva tehát előre hátra fogod rángatni a motort. Egy jó vezérlőben a PWM "off" üzemében a motor szabadon fut, nem pedig fék üzemmódban van hajtva.


A második rajz is rossz, mert a H-híd mindkét oldalára ugyanazt az N-FET típusú kapcsolót jelöli, ami biztosan nem jó: egyik low-side, a másik high-side switch kell hogy legyen. Magyarul a felsők P-típusúak. Itt legalább a parazita diódák jelölve vannak. De külön kondi a H-Híd tápjára nincsen téve. Mindent összevetve nekem ez is egy nagyon hanyag rajznak tűnik, nincsen rendesen végiggondolva. Ja, és ha egyazon tápon van motor és mikrovezérlő - ahogy a rajz sugallja, akkor egyáltalán nem mindegy az alkatrészek térbeli elrendezése, ami szintén nem derül ki a rajzból.

De a regisztert atirhatod bármelyik portra. Neked az OC1 fizikai portot (pint) nem is kell használnod.
Persze azt is csinálhatod, hogy irányváltáskor invertálod a OC kimenetet.

Nem feltétlenül. Felül is lehet, és szokás is N FET-et használni. Természetesen ezzel a kapcsolás is változik.

Nem kevered valami másfajta MCU-val? Ezeken az AVR-eken nem tudod a regisztert átírni másik fizikai portra. Erről van szó, nem? https://www.microchip.com/wwwproducts/en/ATmega8A#datasheet-toggle

Igen, ezért írtam high-side switch-et, azzal összefoglalhatunk minden megoldást, ami a magas oldalt kapcsolja. Ha jól gondolom, nem vagyok szakértő.

Ugye azért szokás "felül" is N típusút használni, mert ezek azonos gyártási feltételek - tehát azonos ár - mellett jobb tulajdonságokkal bírnak, igaz?

Én nem mondtam, hogy a pint lehet változtatni, csak ugyanazt a tartalmat megjelenitheted egy másik porton. ASMben már többször csináltam. De ha jol rémlik az OCR regisztert is tudod olvasni.

Ha "big banging" módszerrel használod a PIN-t, akkor igen, bármelyiket tudod vezérelni. De a hardveres PWM úgy működik, hogy egy órához tartozik két OCRXA és OCRXB compare regiszter, amivel csakis az OCXA és OCXB lábakat tudod vezérelni. (Az X az óra indexe, az ATMEGA8-ban csak egy óra van.) Tehát nem tudod átkofigurálni, a hardveres PWM csakis ezen a két lábon tud kijönni. Szoftver "bit banging" PWM-et bármelyik lábra lehet csinálni, de sokkal macerásabb - pláne, ha tűpontosra kell csinálni. Ezért ha 4 lábon akarunk PWM-ezni, akkor a legésszerűbb nagyobb procira váltani.

Te tudod....

Igen Atmega8A-ra gondoltam .

Hello.
Segítség kellene Atmega8A-ról lenne szó OC1B (PB2) láb nem akar változni OC1A-val használnám PWM jelre.
Ha változtatom OCR1A és OCR1B értékét csak az OCR1A reagál.
Próbáltam változtatni a TCCR1A és a TCCR1B értékeket de valahogy nem mozdul akkor se. :/