Akkor jobban járnál egy ilyennel: Bővebben: nucleo 103
Már rajta van az ST_LINK dughatod az USB-be

Melyik a legkönnyebben használható? (olyan FT232RL USB-TTL átalakító panelem nincs)

Na ez nem semmi. Ezt csak rádugom az usb-re és már mehet is a program az arduino ide-ről?

A legjobb az FTDI automatikusan telepíti a Win a drivert hozzá.
Bővebben: Link

Igen!
Bővebben: Link

Azt, hogy "Jobban jársz EGY esp8266-TAL" én nem állítanám. Én használom rendszeresen mindkettőt, és egyik alma, másik körte. Nem összehasonlíthatóak. Ha kell WiFi, vagy nagyon nagy sebesség, vagy sok memória, de semmi más extra, és kevés láb is elég, akkor jó az ESP. Ha sok periféria kell, pontos ADC, sok láb, kis fogyasztás, akkor STM32.
Némi megszokás után használhatóságban nincs annyira sok különbség, mindkettőnek megvannak a hülyeségei. Az viszont biztos, hogy AVR-hez képest mindkettő bonyolultabb, mert nagyon sokkal többet tud.

Azért egy ST-Link sem annyira drága

Igény kérdése. Ha az kell amit írtál akkor nyilván STM32. Viszont ha csak sebesség vagy RAM a kérdés akkor az ESP jobb választás mint az AVR. Főleg ha nem 8266 hanem ESP32. Viszont ha hosszú távon akar gondolkodni nyilván érdemesebb az STM-et megtanulni.

Nem az árat kifogásolták, hanem a két panelt összekötő vezetékek kényelmetlen dugdosását!

Különben a Nucleot felvásárolta az STM és egyre nagyobb lesz a támogatottsága.

Ha feltöltesz rá egy bootloader-t, onnantól tudod USB-n programozni ugyanúgy mint egy arduinot. Persze telepíteni kell az arduino környezetbe az STM32-t, és egy USB drájver is kellhet.
Ha a közelemben vagy, akkor akár én is szívesen rátöltöm neked a bootloader-t.

Ha fel van töltve a bootloader akkor már a jumperekkel sem kell bohockodni?

A Nucleo fantázianevű sorozat az ST Microelectronics terméke. Tehát nem vásárolt fel semmit.
Ez a legolcsóbb fejlesztőeszközük, mert a debuggeren és a cél mikrokontrolleren kívül nincs rajta más. Sokféle változatban kapható, mindegyiken másik fajta STM32 mikrokontrollerrel.

Ilyesmire én inkább azt ajánlanám, hogy használd a szinte minden klíma beltériben található, bontásból akár ingyen is beszerezhető légterelő-mozgató motort, MP24AA a típusa. Annak van egy gyárilag beépített 64x-es áttéte (ha jól emlékszem) és így nagyon pontosan lehet mozgatni. A régi floppy lejátszókból is lehet mozgató motort bontani. Vezérléshez pedig legegyszerűbb - ha nem pár tranzisztorral akarod megoldani - a egy A4988 modul, az AVR-el jól vezérelhető

Hello! Ha lehet, ne csak írj, olvass is! mert egy 12 évvel ezelőtti hozzászólásra válaszolni valakinek, aki 143 hónapja nem volt a környéken sem, nem biztos hogy hasznos..

Nem, akkor nem kell a jumperekkel sem bohóckodni.

A jumperekkel csak akkor kell variálni, ha soros porton akarod programozni, én kipróbáltam mindegyik módszert: a soros portos programozást, az USB-s bootloader használatát, és az STLinket is.

Ez a kis STM panel teljesítményre amúgy egy "atomerőmű" az arduino nano-hoz vagy az arduino mega-hoz képest.

Megtudná mondani valaki hogy ha így kódolok egy float változót (binarizálok) akkor a másik oldalon (szintén arduino hogy kell visszaálítani? (ezt se értem hogy bontja fel mert nem értem ezt a sort csak amit autodidakta megtanultam de ezt még nem (byte * b = (byte *) &temp)
Köszi.

A b változó egy mutató, ami címet tárol, nem értéket! A 2. sorban megkapja a float változó memória címét, ahol is tárolódik az érték. A b[x] indexeléssel pedig eléred a temp változó memória címén tárolt byte értékeket. Mivel 4 byte-on tárolunk egy 32 bites float értéket, így a b mutatón keresztül elért 4 darab byte az azon bitek összessége nyersen, ami leír egy float változót!
Visszaállítása:
byte b[4] ;
b feltöltése a vett értékekkel...
float *temp= (float *) &b;
...
valami=*temp;

Köszi igen ezeket a pointereket még nem igazán értem. Még át kell néznem. pl. hogy a memoria nem csak 256 rekesznyi vagyis hogy fér bele a b-be mutató.

Teljesen jó, amit írtál, de nem feltétlenül kell ennyire túlbonyolítani. A Serial.write a doksi szerint több bájtot is tud egyszerre írni:

Adő oldalon:

Vevő oldalon:


Én nem próbáltam ki, felelősséget nem vállalok érte, de működnie kell.

Bocsi még egy kérdés:
Tehát már kezdem érteni hogy a
float*temp azt jelenti hogy pointer tipusú a temp változó
&b az meg hogy b változó címét képzi ami be mehet a pointer tipusba
és akkor a (float *) pedig hogy float azaz 4 byte azaz 4 tömbelemet próbál float váltzó byte -i ként kezelni (konvertálni)?? vagy hogy is van ez?
Bocsi de egy kezdőnek a szájbarágósan megy ez.

Igen, nagyon jól látod.
Van egy float fáltozód temp néven valahol a memóriában, mondjuk a 100-as címen, 100-103 között. Ez 4 bájt (a tartalma elég kusza, le van írva a megfelelő szabványban, ami a 32 bites lebegő pontos számokról szól).
Ekkor: &temp=100
A b változód egy cím, jelen estben a 100-as, ami valahova mutat a memóriában, és azt a helyet bájt-tömbként értelmezi.
Azaz a b[0] az a temp változód első bájtja, stb.
Az egészet azért kell (byte*)-ként kezelni, mert a Serial.write egy bájt (vagy char) tömböt, vagy egy konkrét bájtot vár paraméterként.
A * az & ellentéte, egy cím által mutatott változót jelöl. Azaz (byte*)100 az első bájtod a temp floatból, ugyanaz, mint b[0].
Remélem ez elég érthető így, és én sem rontottam el.

DS18B20 ról tudja valaki hogy a sensor.requestTemperatures(); kérést hogy lehet ki kerülni hogy ne fogja meg a procit amig el nem végzi a mérést?
Másodperceket elvesz. (több szezór egy bus-on + több bus)
Pedig a mérés kérés után a kiolvasást késöbb végzem 5mp el hogy legyen ideje a mérésre újabb mérést pedig min 10mp ként kérem.
A kiolvasás az nem vesz el szinte semmit.
Azt gondolná az ember hogy azért van szét választva a mérési parancs a kiolvasástól hogy amikor tetszik kiadjuk azt majd elvégzi. De ne várja meg!
Nincs ennyi időm erre.
Vagy lehet nem is a megvárás miatt lassú? hanem hogy címezetlen általános a kérés? Esetleg ezt a parancsot is konkrétan megcímezve kéne kiadni? Lehet egyáltalán ilyet?
Mert a kiolvasást pontos címenként kérem és ott gyors.
(kell a 12 bites pontosság más megoldás kéne)

Szia!

A legnagyobb felbontás mellett is 0,75s a konverziós idő adatlap szerint... Az 5s alatt biztos, hogy bőven készen kell lennie, az nem számíthat! Milyen táplálással mennek: parazita vagy önálló ?!

rendes táplálás,
Azt értem hogy sok idő kell a konverzióhoz (gondolom A/D átalakítás). De azt egyedűl meg teheti a szenzor mér kell várni rá?
Kiadom a parancsot és elküldi a könyvtár a szenzórnak de aztán ne várjon mig el is végzi a konverziót.
Nincs véletlen olyan parancs, vagy paraméter a könyvtárnak? vagy másik könyvtár? aminél nem várja meg?

Azt érteném hogy ha túl korán kérném le az értéket (.getTempC(...) akkor meg állítaná a futást és várna amig nem fejeződött be a konverzió
De itt nem az történik mert az érték kiolvasás egy két millisec és kész.
Hanem a konverzó .requestTemperatures(... -kérésénél már megállítja loop-omat. és vár amig be nem fejezi. (.getTempC(...) nél pedig akkárhányor lekérdezhetem nem állít meg csak arra kis millsecre amig lejön a one wire bus-on. Sőt többször is lekérhetem egymás után nem állít meg. Csak nem lesz friss az adat pontosabban az utolsó mérés eredményét (konverzió) küldi.

Elvileg van olyan függvénye is, hogy setWaitForConversion. Ha itt TRUE paramétert kap, akkor várja a konverzió végét, ha FALSE van beállítva, akkor rögtön visszatér...

Nem használom az Arduino könyvtárát, én PIC-re megírtam és úgy csináltam meg, hogy ne blokkoljon, pontosan, ahogy írod: kiadod a parancsot a konverzióra és amíg nincs kész, addig magára hagyod ( időnként ránézel persze, akár 10 ms-ként is !) és közben tudsz mást csinálni! Ez a hátránya a "gyári" programoknak, hogy megírták, ahogy megírták és ez van, ha Te írod meg, akkor hosszabb "törpölés", de azt csinálja, amit akarsz! Lehet, hogy van megfelelő program, de meg kell találni, ill. tesztelni kell !

szerk.: Közben sdrlab kolléga írt lehetséges megoldást !

Igen köszi közbe Én is megtaláltam.
Ez a megoldás:
sensor.setWaitForConversion(false);
szuper

Sziasztok. Ismét itt.
Amiket tudtam szerezni a dologhoz az a HCPL-3120 driver, és K30T60-as IGBT-k.
Ezzel a fajta driverrel is megoldható a vezérlés?
Talán még annyira nem is bonyolult mivel itt az opto-val egyben van így egy alkatrészt meg lehet spórolni.

Már csak segédtápok kellenek az optocsatolóknak.

És elméletileg ugyan ezzel a programmal meghajtható?
Segédtápnak 15V elegendő lehet igaz?