- Motorola Edge 30 Neo - wake up, Jr...
- Huawei Mate X6 - keleti oldal, nyugati oldal
- Samsung Galaxy A56 - megbízható középszerűség
- Milyen okostelefont vegyek?
- Kicsomagolták a Vivo X Fold 5-öt (videó és fotók)
- Szerkesztett és makrofotók mobillal
- iPhone topik
- Honor 200 Pro - mobilportré
- Android alkalmazások - szoftver kibeszélő topik
- VoLTE/VoWiFi
-
Mobilarena
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
ekkold
Topikgazda
válasz
#70211840
#18173
üzenetére
>Van viszont egy komoly probléma ezzel a maggal.
>1. Windows - ArduinoIDE
>Iszonyatosan lassan fordít!!!
Nálad lehet valami gond a windows-al, mert ugyan nálam sem egy rakéta, de egy nagyobb kódot is lefordít másodpercek alaltt. (pl. egy kb. 1000 soros arduino program 9 másodperc alatt fordul le - Win7 + ArduinoIDE). -
ekkold
Topikgazda
válasz
#70211840
#18173
üzenetére
>Ez csak STM32 esetében igaz
>vagy jellemző már az összes hasonló eszközre?
A legtöbb hasonló MCU-ra jellemző, csak van amelyik nem minden lábán tudja, és sok olyan van, amiben csak felhúzó ellenállást lehet bekapcsolni, lehúzó ellenállást nem tud.>Tehát elég csak bekötnöm egy gombot egy pin-gnd közé?
>Ennyire egyszerű volna?
Igen.A pergésmentesítés szoftveres, vagy hardveres is lehet. Ha a szoftverben elfér (tehát nincs kicentizve az MCU kapacitása) akkor az a jó megoldás. Ha viszont az MCU tárhelye, ideje, kapacitása korlátait feszegetjük, akkor a hardveres megoldás is szóba jön.
Amikor pedig olyan környezetben működik majd az MCU, ahol sok zavarforrás is van, akkor előfordul, hogy a hardveres és szoftveres megoldás is dolgozik együtt. -
ekkold
Topikgazda
válasz
#70211840
#18167
üzenetére
Általában bekapcsolható "felhúzóellenállás" van a lábakon a legtöbb MCU-ban, de az STM32 esetében lehet a GND felé (lehúzó) vagy a +3V3 felé (felhúzó) ellenállás is, te határozod meg a szoftverben.
Több gomb kezelése sokféleképpen megoldható, kevés I/O láb felhasználásával, lehet pl. mátrixba kötni a gombokat (sor-oszlop elrendezés) Ekkor pl. 16 gomb esetén csak 2x 4láb kell (4 sor 4 oszlop).
Persze vannak ennél még trükkösebb megoldások is, attól függ mennyire vagy szűkében az I/O lábaknak, ill. mennyi plusz alkatrész fér bele a játékba, vagy mondjuk tudni kell-e különféle gomb-kombinációkat is felismerni, vagy várhatóan egyszerre csak egy gomb lesz lenyomva.
-
ekkold
Topikgazda
válasz
#70211840
#18075
üzenetére
Szia!
ST-Linkkel felprogramozva jónak kellene lennie. Azonban ezek a klón processzorok nem 100%-ig egyeznek meg az eredetivel, néhány eltérésbe már belefutottam én is (+ van olyan klón proci, amin gyári típusszám van).A proci csere amúgy megoldás lehet, annyira nem vészes beforrasztani az újat, nekem mondjuk csak mikroszkóp alatt megy, mert már nem olyan a látásom mint 20 évesen.
Elképzelhető az is, hogy csak annyi a gond, hogy a klón processzorban kevesebb flash van, és ezért írtak rá egy egyszerűbb firmware-t. Ezt nem tudod beszerezni valahonnét? Akitől vetted, nem érhető el?
A hardver nem látszik különösebben extrának, ha belelendülsz a programozásba akkor akár használhatod is valamire.
Arduinoval, és a gyári (ingyenes) fejlesztőkörnyezettel is programozható ez a proci. Kezdő programozóak az ST fejlesztőkörnyezete szerintem nagyon pilótavizsgás, jobb arduinoval nekiállni. Az arduinora kell telepíteni az ST procikhoz való kiegészítést - (az alaplap kezelőjében ez elvileg pár kattintás). Javaslom viszont ha azt az irányt választod, akkor szerezz be egy olcsó kis bluepill panelt is, és azzal kezdj - ledvillogtatás és hasonlók, majd kijelző kezelés, stb... és akkor programozd ezt a kis célhardvert ha már van egy kicsi alapod.
-
ekkold
Topikgazda
válasz
ViZion
#18049
üzenetére
Nálam a router, és az AP-k, egyetlen közös tápról mennek, a sok gyári dugasztáp helyett. Viszont a PC tápok hatásfoka nem valami csodás, (néhány spécibb verziótól eltekintve, de azoknál ki is hangsúlyozzák, hogy jó a hatásfoka), szerencsésebb egy laptop-táp vagy ahhoz hasonló eszköz.
Mondjuk ha a PC táp eleve adott, mert ott van mellette egy működő PC, akkor jó megoldás lehet az is. -
ekkold
Topikgazda
válasz
daninet
#17868
üzenetére
Ha felhúzó ellenállással nézzük akkor egyetlen lépésre ezt kellene kapni:
11 (mindkét kontakt nyitva)
01 (egyik kontakt zár)
00 (másik kontakt is zár)
10 (első kontakt bont)
11 (második kontkt is bont)
A másik irányba forgatva, a 01 és az 10 állapot fordított sorrendben jön.A kis panelen ugye bekötötted a GND-t és a +Tápot is az arduino panelre?
-
ekkold
Topikgazda
válasz
daninet
#17864
üzenetére
1, Valószínűleg fizikailag vagy nincs az enkóder panelján felhúzó ellenállás, vagy túl nagy értékű.
2, Mindenképpen kell felhúzó ellenállás (akár belső, akár külső) mert különben lebegni fog a bemenet és mindenféle zavart összeszed.
Felhúzó ellenállással valószínűleg azért nem működik amit írtam - mivel kicsi az esélye, hogy két különböző helyről, két különböző enkóder is hibás lenne. -
#17863
ekkold
Topikgazda
its_grandpa
#17857
ekkold
Topikgazda
válasz
its_grandpa
#17857
üzenetére
-
ekkold
Topikgazda
válasz
daninet
#17860
üzenetére
A kapott adatokról: a programod soros portra küldi ki amit kap, viszont a soros portra írás ideje összemérhető (vagy akár hosszabb) mint az enkóder impulzus-ideje. Ezért össze kellene gyűjteni egy csomó adatot és egyben kiírni - vagy méginkább egy megfelelő programmal számlálni az enkóder lépéseit, és csak a számláló változása után kiírni az értékét.
-
ekkold
Topikgazda
válasz
daninet
#17860
üzenetére
Minden mechanikus kapcsoló hajlamos egy olyan jelenségre amit "prellezésnek" hívnak. Fizikailag amikor az érintkezők összeérnek akkor rugalmasan torzulnak, majd az érintkező visszapattan, az áramkör megszakad majd újra összezáródik (akár többször is egymás után). Ez általában ezredmásodperces időtartományban zajlik (vagy akár 100usec tartományban). Emberi szempontból ez nagyon rövid idő, de digitális elektronikák szempontjából ez sok idő, simán észreveszi az áramkör és megpróbálja feldolgozni - ami alaphelyzetben hibás működéshez vezethet.
Két megoldási lehetőség van:
- Szoftveresen felkészülni a prellezés kezelésére - ahhoz hogy ez jól működjön nem lesz elég egy egyszerű kód. Persze megoldható teljesen jól is, csak az nem pár soros programrész lesz (készítettem már ilyet).
- A prellezés hardveres kezelése: a kontaktusokra kapcsolt felhúzó ellenállások után egy megfelelő időállandójú R-C szűrő is kell (ilyenkor a belső felhúzó ellenállást ki kell kapcsolni). Ez több alkatrészt igényel, viszont a szoftver viszonylag egyszerű maradhat.
Ha a programozás nem az erősséged, akkor a hardveres megoldás a könnyebb út, mivel az egyszerű áramkört igényel... Már én is elgondolkoztam rajta, hogy nekem is egyszerűbb lett volna hardveresen megoldani, mint szoftveresen, csak akkor már a hardver kész volt, így nem volt választásom. -
ekkold
Topikgazda
válasz
vviktor1
#17855
üzenetére
Nekem 100%, hogy a kijelző miatt akadt, ugyanis ha nincs beállítva a kijelző akkor nincs akadás. A soros porton így is kitol minden adatot ami kell, erre ráakasztok majd egy Arduino nanot, vagy egy BluePill-t, és az kezelheti a kijelzőt akadás nélkül... Egyelőre csak az ESP8266-ra épülő van bedobozolva, az ESP32 verzió csak próbanyákon van kijelző, és gombok nélkül - de teljesen jól működik. Ehhez tervezek majd egy végfokot, külön MCU-t a kijelzőhöz (és a kezelőszervekhez is), és így akarom majd egybe dobozolni.Emlékeim szerint a programozó app képest törölni is a flash-t, utána biztosan lehet a nulláról kezdeni a programozást. Ha mégis megfrissíted akkor írd meg majd légyszíves, hogy jól működik-e, mert még én sem frissítettem.
-
ekkold
Topikgazda
válasz
vviktor1
#17851
üzenetére
A karadiot kipróbáltam ESP8266-on, és az ESP32 változatot is. Az utóbbi kicsit gyorsabb, és nem csak az MP3 rádiók menek vele, hanem az AAC stream is. VS1053 modult még a vám mizéria előtt vettem ebay-en. Szerintem kimondottam jól szól.
Minden részletre nem emlékszem, letöltöttem hozzá mindent, felprogramoztam a leírás alapján és működött...
A karadióhoz van androidos app amivel lehet távirányítani mobilról, így akár kezelőszervek (gombok) és kijelző nélkül is működik.
A karadio32-höz próbáltam ILI9xxx kijelzőt illeszteni, működött is, csak a kijelző frissítése néha megakasztotta a hangot, így leszedtem róla, most nincs kijelzője, később majd illesztek hozzá (soros porton) egy külön MCU-val kijelzőt. Lehet, hogy csak egy sima 2x16-os LCD-t (mint az ESP32 esetében) úgy sem nézegetni, hanem hallgatni akarom.
-
ekkold
Topikgazda
válasz
vegyszer
#17800
üzenetére
Pl. a PIN-ek kiolvasását, és tárolását intézheted egy megszakításban. folyamatosan. A küldés - visszaolvasás pedig mehet a főprogramban.
Amikor egy tárolt blokk megtelik, akkor a megszakítás beállíthat egy flag-et, és egy másik tárolóba folytatja az írást. a flag alapján a főprogram indítja a küldést. Amikor a második tároló telik meg ismét beállít egy flag-et, és az első tárolót kezdi írni (aminek a tartalma addigra már remélhetőleg mentve lett). Ha ez így időben nem jön ki akkor több/nagyobb buffer kell.
-
ekkold
Topikgazda
Nekem már kellett hasonló, MCP3221 A/D konvertert használtam: olcsó, relatíve gyors, és 12 bites (szemben a NANO 10 bitjével). Elé egy analóg multiplexer került: 74HCT4051, hogy több dolgot is tudjak mérni vele.
Kapcsolási rajz részlet -
ekkold
Topikgazda
válasz
fpeter84
#17674
üzenetére
Általában fixpontos változókat használok, ez formázható sprintf() függvénnyel hogy az utolsó néhány számjegy tizedesként jelenjen meg. Illetve írtam saját függvényt is ami egy fixpontos változót ír ki úgy, hogy adott utolsó néhány szánjegy tizedesként jelenjen meg.
Lebegőpontos szán esetében a kerekítés úgy oldható meg a legegyszerűbben (és végülis fixpontos esetén is), hogy osztás előtt, hozzáadjuk a számhoz az osztó felét - így pont a kerekítés szabályai szerint alakul az osztás eredménye.
-
ekkold
Topikgazda
válasz
vegyszer
#17659
üzenetére
Igazából szinte bármilyen webszerver alkalmas lehet a feladatra. Nekem pl. van egy kis barkácsolt NAS-om, amin fut webszerver is. De van interneten is tárhelyem.
Logolni pl. az aktuális IP címeket, meg eszközöket szoktam, és van egy php oldal ahol rá tudok nézni. Pl. ha nem működik a freedns, akkor is el tudom érni az otthoni hálózatot, ill. látom melyik eszközöm mikor jelentkezett be utoljára. -
-
#17648
ekkold
Topikgazda
greekpietro
#17647
ekkold
Topikgazda
válasz
greekpietro
#17647
üzenetére
A loop mindenképpen lefut, de elhelyezhetsz benne egy gomb figyelést, ami le tudja futtatni amit szeretnél. Ha ezt csak egyszer (vagy akárhányszor) akarod lefuttatni, akkor a feladatok közé kell tenni egy számlálót is, és a gomb figyelésével együtt ezt a számlálót is figyeled.
-
ekkold
Topikgazda
válasz
angyalpc2
#17533
üzenetére
Találkoztam a problémával. A PL2303HXA-t hamisítják, a kínai verzió ugyanolyan jó mint az eredeti. Viszont a gyártó kiadott egy újabb drájvert ami csak abban különbözik a régebbitől, hogy meg tudja különböztetni az eredeti chip-et a hamistól. Hamis chip esetén pedig ad valamilyen kamu hibaüzenetet, aminek semmi köze a valósághoz. A megoldás: régebbi driver, és be kell állítani a windows-t, hogy ne cseréje újabbra (mert akkor megint nem fog működni).
Feltettem ide a drájvert: [link] -
#17429
ekkold
Topikgazda
tonermagus
#17428
ekkold
Topikgazda
válasz
tonermagus
#17428
üzenetére
Igen.
-
#17424
ekkold
Topikgazda
tonermagus
#17421
ekkold
Topikgazda
válasz
tonermagus
#17421
üzenetére
Az STM32-ben használható a flash, van hozzá arduino könyvtár, tehát el lehet menteni bele dolgokat. Ez egyúttal saját tapasztalat is. Az STM32F103C8T6-ban (BluePill) alapból 64k flash van, de több olyan példánnyal is találkoztam amiben a 64k feletti részt is tudtam írni és visszaolvasni, egészen 128k-ig. A kínából vásárolt procikat (alapból 72MHz-es) 104MHz-ig tudtam felhúzni, de itthon vettem eredeti STM32F101 procikat, (névlegesen 36MHz-es) amelyek 128MHz-en is vidáman működnek, sőt a nem létező USB (az adatlapja szerint nincs benne) is kifogástalanul működik....
-
-
ekkold
Topikgazda
Az arduino irányából nézve nem olyan nagy a különbség. Valóban van néhány specifikus dolog, de ezeken kívül a programok felépítése kb. ugyanolyan. Nekem az tetszett meg az STM32-ben, hogy egy sima arduinohoz képest nagyon gyors, az ára meg kb. ugyanaz (kicsit még olcsóbb is volt, amikor vettem). Nem csak az órajel, és a 32bit miatt gyorsabb, hanem hardveresen tud szorozni, és osztani, ami gyakran csak egyetlen órajelet igényel (14 nanosec!), (az osztáshoz időnként több kell). Mindez együtt nagyon gyorssá teszi.
-
ekkold
Topikgazda
A forrasztóállomásom szoftverét átírtam úgy, hogy a külső eeprom helyett a flash-be mentse a beállításait (így nem kell hozzá az eeprom a nyákra). Most ez úgy megy, hogy a 64k flash végére írom ki az adatokat (a program sokkal rövidebb). Viszont ha előre le tudnám foglalni a szoftverben a flash egy adott területét, akkor már fordításkor bekerülhetnének oda a default értékek, és később a flash-nek ezt a területét a programban lehetne írni is. Ehhez viszont az kellene hogy 1024-el oszható címen legyen a változó, mert csak egyben, 1k-s lapokat lehet törölni a flashben. Igazából enélkül is jól működik a program, de ügyesebb lett volna így.
-
ekkold
Topikgazda
válasz
ratkaics
#17151
üzenetére
Kétféle verzió is készült. Az egyik egy arduino nano-ra épült, a másik pedig MCU nélkül ananlóg és digitális IC-k felhasználásával. Mindkettő tudta a szabványos protokollt. Mivel munkaként készült annak idején, így a teljes projektet nem oszthatom meg, de ha konkrét kérdésed van, akkor igyekszek segíteni ill. válaszolni.
Addig is pár hasznos link, amin el lehet indulni (nagyjából ezekből ill. a protokoll leírásából indultam ki én is):
OpenEVSE [link]
Analog EVSE circuit [link]
Fórum téma hsz: [link]
Analog EVSE komplett projekt [link] -
ekkold
Topikgazda
válasz
Gergosz2
#16864
üzenetére
Elég régen vettem ezeket az enkódereket, sem típust sem adatlapot nem tudok prezentálni, de sima kommersz kétfázisú rotációs enkóderekről van szó. Aki már dolgozott ilyennel az ismeri. Nem nagy probléma MCU-val kezelni, viszont MCU-val hibamentesen kezelni már jóval nehezebb.
-
ekkold
Topikgazda
A legtöbb olcsó, kétfázisú rotációs enkóder egy "zajgenerátor", összevissza prellegnek tekerés közben. Nem az enkóder kezelése a nehéz szoftveresen, hanem a prellezés kiszűrése, hogy ne hibázzon tekeréskor, és irányváltáskor sem. Vagy hardveresen kell RC szűrőt hozzáépíteni. A két enkóder mondhatni csak a mechanikai poziciók számában különbözik.
-
#16865
ekkold
Topikgazda
razorbenke92
#16861
ekkold
Topikgazda
válasz
razorbenke92
#16861
üzenetére
Jól érted. Bár másképp programoztam le, de a lényege ugyanez. Tehát nem az a probléma, hogy nem kezeli jól a szoftver. Mindkét enkóder jól működik, csak az egyikhez ki kell kommenteznem egy részt a szoftverben, a másikhoz meg nem. A kérdés arra irányult, hogy ehetne-e univerzális megoldást készíteni, vagy valahogy automatikusan felismerni és aszerint kezelni az enkódert. Ha nem akkor marad az, hogy egy menüpontban állíthatóvá kell tenni...
-
ekkold
Topikgazda
Kétféle enkóder kapható.
Az állapotok jobbra forgatva
dupla lépéses enkóder esetén pl.
00 ; 01 11 10 00 ; 01 11 10 00 ; 01 11 10 00 ;
pontosvesszővel jelöltem az enkóder stabil állapotait.
szimpla lépéses enkóder esetén ugyanez:
00 ; 01 11 ; 10 00 ; 01 11 ; 10 00 ; 01 11 ; 10 00 ;Tehát az egyik típusnak van 11 és 00 stabil állapota is, míg a dupla lépéses kettőt lép egyszerre a másikhoz képest, azaz stabil állapotban mindkét érintkező nyitott.
A szoftverben ha nem megfelelően van kezelve akkor vagy kettesével lép, vagy minden második lépést kihagyja...
Történetesen kétféle enkódert találtam itthon és a kettő ebből a szempontból is kétféle... A különbségre úgy is tekinthetünk, hogy ugyanaz az enkóder fele annyi helyen áll meg stabilan, vagy dupla annyi helyen a másikhoz képest.
-
ekkold
Topikgazda
Enkóder kezeléssel kísérletezek. Van-e arra valamilyen egyszerű algoritmus, amivel a dupla lépéses és a szimpla lépéses enkódert felismerheti ill. megkülönböztetheti a program?
Egyelőre azzal próbálkoztam, hogy dupla lépésesként kezeli a szoftver, de ha olyan állapotban áll hosszabb ideig az enkóder, ahol a dupla lépéses nem állhatna, akkor átvált szimpla lépésesre. Ez működik is, de tudom szándékosan úgy tekerni a dupla lépéses enkódert, hogy a program szimpla lépésesnek vegye.
Tehát, létezik erre valami ügyesebb megoldás? -
ekkold
Topikgazda
válasz
Dißnäëß
#16792
üzenetére
Létezik olyan IC amiben SRAM és EEPROM van kombinálva. Tetszés szerint írható, kollátozás nélkül, és amikor csökken a tápja, automatikusan menti a tartalmát a belső EEPROM-ba. Csak egy 10uF-os kondi kell rá plusszban. Nagyjából úgy kezelhető, mint egy táp nélkül sem felejtő SRAM. Ráadásul a szoftverben sem kell foglalkozni a tápfesz elvétekeor történő mentéssel, és akár másodpercenként írható bele az aktuális adat...
-
ekkold
Topikgazda
válasz
Undoroid
#16765
üzenetére
Akkor a
static colors[]={255, 0, 0, 0,255, 0, stb.....}
helyett
static uint8_t colors[]={255, 0, 0, 0,255, 0, stb.....}
sort írj.
Ki tudja még mit néztem el, az a lényeg, hogy értsd a működését. Az időpontoknak sem kell fix 1 másodpercenként jönni, azt is veheti pl. egy fentihez hasonló táblázatból. Sőt akár a fenti táblázatban is lehet az RGB mellett egy következő időpontot mutató negyedik érték is.
Aztán ha kicsit szebb kódot akarunk akkor lehetne pl. struktúratömböt is használni... -
ekkold
Topikgazda
válasz
Undoroid
#16759
üzenetére
Valami ilyesmi irányba kellene menni, a delay()-t kihagyni, és csak figyelni az időt:
//***************************************************void szinbeallitas(){static uint_16t counter=0; //hívás számláló, gyak másodpercenként fog lépnistatic colors[]={255, 0, 0, 0,255, 0, stb.....} //itt fel lehet sorolni az összes szint amit meg akarsz jelenítenicounter += 3;//hármasával léptetjük, mert RGB-t szedünk ki a tömbbőlcolor(colors[counter], colors[counter+1], colors[counter+2]); //színbeállító fv. hívása} //end fv//***************************************************loop(){static uint32_t time1=0; //ebben lesz a hívás idejeuint32_t actualtime1; //ebben lesz az aktuális időpontactualtime= millis(); //aktuális időpont tárolásaif ((actualtime - time1) >= 1000){ //ha eltelt egy másodperctime1 = actualtime; //megjegyezzük a hívás időpontjátszinbeallitas(); //sajat szinbeállito függvény hívása másodpercenként.} //end if// itt lesznek a program további feladatai, pl. nyomógombok figyelése stb...} //end loop//*************************************************** -
-
ekkold
Topikgazda
válasz
Undoroid
#16755
üzenetére
Az A és B program egy-egy függvény legyen, amit a loop() meghív a gomb vagy kapcsoló állapotától függően.
Tehát az első kulcsszó függvény-eket kell írni.A működési idő: A millis() függvény megadja a bekapcsolástól eltelt időt millisecundum-ban. Kb. 54 napig tud számolni mielőtt túlcsordul a számláló, azaz átfordul, és újra nullától kezdve számol. Tehát egy feltétellel időnként megnézed a loop()-ban , hogy eltelt-e már az idő. Ha nem akkor minden megy tovább, ha igen akkor pl. nem hívod meg többet sem az A, sem a B függvényt.
-
ekkold
Topikgazda
válasz
Undoroid
#16677
üzenetére
Saját célra készültek. Régebben vettem nagyon baráti áron néhány STM32F101 procit. Mivel mostanában nehézkes pl. a BluePill beszerzése, ezért (is) készültek ezek a kis modulok.
Az a vicces a dologban, hogy a 101-es proci elvileg 36MHz-es, a bluepill viszont 72MHz-es, de a BulePil-en levő procikat 104MHz-ig tudtam felhúzni fagyás nélkül, amiket vettem, az mindegyik megy 128MHz-en is. Ráadásul az F101 adatlapja szerint nincs benne USB periféria, a gyakorlatban viszont mindegyiken működik... Igy ezeket a kis modulokat is simán lehet arduinoval programozni. -
ekkold
Topikgazda
válasz
gyulank
#16678
üzenetére
Igen! Mármint a nem igen. Tehát nem.
Nagyon régen programoztam PIC-et, és nálam sokkal-sokkal hozzáértőbbektől (több embertől is) azt hallom, hogy az ST-t érdemes megtanulni, mert az feljődik a leggyorsabban, és az utóbbi időben minden új fejlesztést ST-vel készítenek, kivéve ha valami nagyon alapos oka van hogy PIC-et kell használni. -
ekkold
Topikgazda
válasz
gyulank
#16673
üzenetére
Igazából ez is led villogtatás, de készítettem néhány fejlesztőpanelt ami lábkompatibilis a BluePill-el. Minden I/O lábra került egy LED, ezzel tesztelem le, hogy sikerült-e rendesen beforrasztani a procit a panelre:
[VIDEO-MP4-link]
-
-
ekkold
Topikgazda
válasz
Janos250
#16600
üzenetére
Köszönöm! Kb ilyesmit találtam én is, a
va_arg()-nak meg kell adni milyen típusú paramétert olvasson fel, és visszaadja az értékét. Tehát vagy meg kell adni, hogy hány paraméter van aktuálisan, vagy a legutolsó paraméternek kell pl .nullának, vagy mondjuk nullpointernek lenni, amiből a program tudhatja, hogy ez volt az utolsó paraméter. Azon gondolkoztam, hogy írok egy printf()-hez hasonlóan működő függvényt ami alfanumerikus LCD-re ír, de kevesebbet tud mint a printf (csak egész számot és c stringet kezelne), és cserébe sokkal kevesebb erőforrást fogyasztana mint a sprintf() + lcd-re írás. -
ekkold
Topikgazda
Nálam ez fordítva volt, tanultam pascal-t, majd utána c-t. A pascal szigora után, a c szinte megváltás volt. Ugyanaz a feladat sokkal rövidebben megoldható, és hatékonyabb kód is lesz a végeredmény.
A javascript, és a PHP nekem jóval később jött, de a c alapok után mondhatni gyerekjáték volt beletanulni . Persze nem vagyok profi programozó, de sokmindenhez hozzá tudok szólni. -
ekkold
Topikgazda
válasz
gyapo11
#16563
üzenetére
Egyetértek az előttem szólóval. A c fordító simán megeszi a pascal kódot csak a begin end helyett { } csúcsos zárójeleket kell használni. Viszont c-ben ugyanazt a feladatot sokkal egyszerűbben és tömörebben is meg lehet fogalmazni, pl:
pascal, c: x = x + 1;
c: x++;
-------------------------
pascal, c : x = 10*x;
c: x *= 10;
--------------------------
Persze még egy csomó dolog könnyebb c-ben, mert kevésbé szigorú mint a pascal, illetve sokminden felülbírálható (pl. változó típusok), és ha tudod mit csinálsz, akkor jól is fog működni. Pl.
x = 'A'; //x változóba berakunk egy A karaktert
x += 2; //x változóban a C karakter lesz -
ekkold
Topikgazda
válasz
Dißnäëß
#16522
üzenetére
Ha a potméterek csak feszültséget szabályoznak, akkor kiválthatod megfelelő felbontású PWM + aluláteresztő szűrő kombinációval. Ha ennél precizebb dolog kell, akkor egy A/D-vel vissza is mérheted a szűrő utáni feszültséget, és pontosíthatod vele a PWM-et (akár egy PI vagy PID szabályozással). Ha nem simán DC feszültséget szabályoznak a potik, hanem egy áramkör részei, akkor bonyolódik a helyzet (pl digitális potival). Persze pontosabb válaszhoz ismerni kellene a feladatot.
-
ekkold
Topikgazda
válasz
Janos250
#16448
üzenetére
Deklaráláskor nem ugyanaz történik. A használatában vannak hasonlóságok.
A char * egy pointer tipusú változó, ami karakterre mutathat (persze lehetnek egymásután karakterek a memóriában), de mutathat pl. nullára is (nullpointer), vagy pl. egy tömb kezdőcímét is belemásolhatjuk.
A char[ ] egy karakterekből álló tömb, ami a szögletes zárójelek nélkül a tömb kezdőcímét mutatja mint pointer. -
ekkold
Topikgazda
válasz
Janos250
#16446
üzenetére
char akarmi[ 100]; //
Ez lefoglal 100 bájtot adott kezdőcímmel, azért nem adhatsz értéket a ilyen módon, hogy akrami = ... mert ahhoz módosítani kellene a címét, viszont a lefoglalt memória adott területen/címen van. Igy az akarmi szögletes zárójelek nékül, gyakorlatilag egy pointer konstans.char * akarmi//
Ez csak egy pointert hoz létre, ami mutathat bárhová, (kaphat tetszőleges értéket) de a pointerhez nem foglal le memóriaterületet. Tehát ha létező c stringre mutat akkor lehet egy tömbhöz hasonlóan használni, egyéb esetben elszállhat a program.A c string egy olyan karaktertömb ami nullára végződik (ez jelzi a tömb végét). Tehát van egy aktuális hossza, ami változhat is, és van a számára lefoglalt memóriaterület ami megszabja a maximális hosszát. Ha "túlírod" elszállhat a programod.
Azért tud jól működni az strcpy() a korábban felvázolt esetben, mert ott a pointer által mutatott szöveget, valós lefoglalt memóriaterületre másolod.
A pointerhez egyébként a malloc() függvénnyel lehet (standard c-ben, de talán arduinoban is) memóriát foglalni, azaz a maloc() által adott címet töltöd a pointerbe , és akkor a malloc() által lefoglalt nagyságú tömbként is használhatod.
Jelenleg kevered a tömb és a pointer funkcióját, működését. Ezeket kellene tisztázni elsősorban.
-
ekkold
Topikgazda
válasz
Janos250
#16386
üzenetére
Leírom, hogy nekem miért érte meg jobban az opamp-os megoldás. Persze ez teljesen más mint a kérdezőé, csak arra szeretnék rávilágítani, hogy az opampos erősítős megoldás is lehet jó, és egyúttal sokkal olcsóbb is.
JBC 245 pákához terveztem állomást, és szerettem volna pontos/precíz PID szabályozást készíteni hozzá. Ennek a pákának az egyik tulajdonsága, hogy pár másodperc alatt fel tud fűteni, a legnagyobb hőmérséklet-változási sebesség amit mértem kb. 100 °C/sec.
A MAX6675 és hasonló céláramkörök konverziós sebessége adatlap szerint 0,17---0.22sec, ez azt jelenti, hogy két mérés között 17...22°C-ot is változhatna a páka hőmérséklete, tehát ezzel eleve nehéz lenne stabil hőfokon tartani, mert ahhoz sűrűbben kellene mérni. Tovább rontja a helyzetet, hogy fűtéskor, a páka vezetékén eső feszültség miatt nem lehet mérni, ezért a mérés idejére ki kell kapcsolni a fűtést. Ez azt jelenti, hogy ha folyamatosan mérnék, akkor nem maradna idő fűteni. Ha csak az idő 50%-ában fűtök, a másik felében mérek, az mégnagyobb hőingadozást jelentene. Tehát erre a célra egy ilyen IC kb. alkalmatlan lenne. Ráadásul ennek az IC-nek az ára pl. a hestore-ban éppen netto 1600Ft körüli.Az az opamp amit használtam kb 300Ft, az offszetfeszültsége maximum 25µV, tehát legrosszabb esetben ez kb 1°C hibát vihet be. A hidegpont mérésére használt hőszenzorom: MCP9700, 100Ft körüli a chipcad-nél vagy a TME-nél. Az MCU-ban levő A/D 12 bites ugyanúgy mint a MAX célIC-ben, csak azzal 2x128 mintát tudok venni és átlagolni kevesebb mint 2 ms alatt. Így ha mondjuk 40msec időközzel mérek akkor a ciklusidőnek csak 5%-át vesztem el mérési időre, és az idő 95%-ában lehet fűteni a pákát (mehetne a mérés akár 20 vagy 10 msec időközzel is, az sem okozna gondot).
Az MCP9700 hőszenzor 1...2 fok pontosságú, tehát ezzel együtt kb. 3 fok hiba + kb. 1% az ellenállás osztók miatt ami bejöhet. Mivel 330 fok körül forrasztok gyakran, a legnagyobb hiba 6 fok körüli lehetne. Azonban a forrasztóállomás kalibrálható, és ezzel a hiba jelentős része kiesik, tehát a végeredmény egy egész pontos szabályozás lehet.
A kérdezőnek valószínűleg nem kel ilyen sebességű és pontosságú mérés, de ha ismernénk a hőszenzora adatait, akkor valószínűleg lehetne hozzá optimális megoldást találni. -
ekkold
Topikgazda
válasz
wakula778
#16377
üzenetére
Szerintem nem biztos, hogy a hőszenzort kell cserélni, hanem esetleg az IC-t ami kezeli. Ahhoz viszont kellene adatlapot beszerezni a szenzorról. Egy hőszenzor jelét pl. egy jobb műveleti erősítő + A/D kombóval is fel lehet dolgozni, csak ismerni kell a paramétereit. A forrasztóállomásomban amit JBC pákához készítettem, könnyedén tudok tizedfokos felbontással mérni, úgy, hogy nem (vagy csak ritkán) ingadoznak a mért értékek. Az ebben levő termoelem mindössze 24,5 µV/°C feszültséget ad le.
-
ekkold
Topikgazda
válasz
Janos250
#16375
üzenetére
Igazából egy hőelemmel is lehet mérni. A vezetékek csatlakozásainál valóban keletkezik valamekkora hiba, de ez sok esetben simán belefér. A környezeti hőmérséklet - amihez viszonyítunk, bármilyen más hőszenzorral is megmérhető.
Ha semmilyen változás nem látszott az alkalmazott szenzor esetében, akkor lehetséges, hogy nem termoelemként kell mérni vele. Magyarul: lehet, hogy nem feszültséget ad a szenzor, hanem mondjuk az ellenállása változik a hőmérséklet függvényében. -
ekkold
Topikgazda
válasz
gyapo11
#16258
üzenetére
Szerintem meg aki raktárkészletet tart bármilyen távolkeleti cuccból az:
- kockázatot vállal
- pénze áll benne
- raktározási és cégfenntartási költségei is vannak
- és persze ezen felül még keresni is akar rajta (nem is várható, hogy nullszaldós avagy nonprofit alapon működjön).
Ezzel nem akarom védeni azt aki ezzel foglakozik, csak azt, hogy érthető, hogy többe kerülnek ezek a dolgok itthon, és hogy a piac szabályozza az árakat. Többször előfordult már, hogy a magasabb ár ellenére itthoni webshopból rendeltem meg kínai cuccokat, mert gyorsabban kellett, és nem fért bele a postázás kockázata sem. 2019-ben 6db csomagomat lopták el a postán, és egy email-ben "sajnáljuk"-on kívül semmilyen kárpótlást nem kaptam, és persze megírták, hogy az értékmegjelölés nélküli csomagokért semmilyen anyagi felelősséggel nem tartoznak. Gyakorlatilag nem hozta ki a postás a csomagot, értesítést sem dobtak be, majd állítólag visszaküldték, gyakorlatilag meg eltűnt... Egy időben itt ez annyira általánossá vált, hogy egy vidéki barátom címére kellett mindent rendelnem (ott nem tűnt el semmi), viszont további futárt kellett fizetnem, hogy eljusson hozzám (GSL, DPD, stb - ezeknél sem tűnt el soha semmilyen csomagom) . Azóta postán kizárólag értékmegjelöléssel küldök bármit is - érdekes módon azok nem szoktak eltűnni. Ha pedig nekem küld valaki, akkor azt kérem, hogy inkább futárral küldje... -
ekkold
Topikgazda
Többször nekifutottam már, hogy Arduino alatt, STM32 BluePill lappal vezéreljek, WS28xx ledszalagot. - de némelyik könyvtár egyszerűen nem működik a BluePill-el, ill. van amelyik csinál ugyan valamit de hibásan működik. Nem akartam saját könyvtárat írni erre, ezért az lenne a kérdésen, hogy van-e olyan könyvtár erre a feladatra, ami biztosan működik BluePill panellel? Próbálta-e már valaki ezt STM32-vel?
-
ekkold
Topikgazda
Annak idején amikor ACS712-20 áramszenzorral dolgoztam, akkor volt a legjobban használható, ha sima osztóval állítottam be a féltápot. Nulla áramnál elvileg féltápra áll be, és az áram irányától függően megy ez alá, vagy fölé. Van némi offszethibája, amit szoftveresen próbáltam kompenzálni több-kevesebb sikerrel. Sajnos ez az összes HALL elemmel működő áram szenzorra igaz, és ez korlátozza a felhasználhatóságukat.
Később MCP3221 A/D-vel dolgoztam fel az ACS kimenetét, ez filléres árú, 12bites A/D és egész gyors, azaz sok mintát lehet vele venni rövid idő alatt. Szoftveresen is könnyű a kezelése. Ugyanarról a tápról ment mint az ACS, így volt a legkisebb az offszethiba.
Viszont ezzel lehet a legegyszerűbben leválasztott módon mérni, és ez DC-re is alkalmas. Ezen kívül ha csak AC-re használjuk, akkor a kimenete leválasztható kondival (és máris nincs offszethiba), és lehet AC-ben erősíteni, meg opamp-al preciziós egyenirányítót építeni. Illetve mindez megoldható szoftveresen is, ha van idő elég sok mintát venni és feldolgozni. Viszont csak AC-re, az áramváltók is teljesen jók, sőt talán jobbak is.
Preciz söntöt használva, megfelelő opamp-al erősítve lehet a legpontosabban lehet mérni, de ott viszont nincs leválasztás. Ha ez nem lenne gond, akkor ez lenne a legjobb választás árammérésre.
-
ekkold
Topikgazda
Tulajdonképpen mekkora áramot kellene megmérned?
[link] A linken egy 100A-es, nyákba ültethető áramváltó, netto 1400Ft körül.[link] Ez a tipus kicsit drágább, de nagyobb kimeneti fesz esetén is pontos (ennek a kisebb áramú változatával már dolgoztam, és tényleg jó) Netto 2000Ft körüli. Valószínűleg ezt használnám, ha biztosra akarnék menni.
Schottky graetz + puffer + sönt, és mehet az A/D bemenetére. -
ekkold
Topikgazda
Ha AC-t akarsz mérni akkor a nullázás nem gond, hiszen az összes minta átlagát kell a nullának tekinteni, és ehhez képest kapsz kisebb és nagyobb (negatív és pozitív) mintákat. Ebből úgy lesz effektív érték, hogy az átlagot minden mintából levonod, mindegyiket négyzetre emeled, és összeadod. Ezután elosztod a minták számával, majd négyzetgyököt vonsz. Ha nem kell pontos effektív érték, akkor elegendő a mintákból levonni a DC offszetet, majd a minták abszolút értékéből átlagot képezni, és ebből számolni effektív értéket. Vagy lehet hardveres mérő-egyenirányítót készíteni néhány műveleti erősítővel, és akkor már csak DC-t kell mérni az MCU-val..
Viszont AC áramméréshez egyszerűbb egy sima áramváltót használni.
-
ekkold
Topikgazda
Amúgy az ACSxxx áramszenzoroknak a nullája el tud mászni, pl. érzékeny a külső mágneses terekre is, elég egy felmágnesezett csavarhúzóval a közelében matatni. Annak idején +-20A-ig kb. 0,1A felbontással tudtam mérni vele úgy hogy ne ingadozzon a mért érték, és a nulla is nulla legyen.
-
ekkold
Topikgazda
Két tüskesort össze lehet úgy forrasztani, hogy legyen kb. fél raszter eltolás benne. A raszteres panelbe egy hosszabb egyenes tüskesort, és egy forrasztott, két darabból álló, eltolásos tüskesort kellene beletenni. A további "emeletek" meg már lehetne rendes raszteres osztásúak.
Később gyártatott panelek esetén is megoldható, hogy az arduino felettin még van fél raszteres eltolás, a "további emeleteken" meg már nem kell.
-
ekkold
Topikgazda
-
#16029
ekkold
Topikgazda
tonermagus
#16028
ekkold
Topikgazda
válasz
tonermagus
#16028
üzenetére
Az élethez szerencse is kell, de ne feszítsd tovább a húrt.
-
#16024
ekkold
Topikgazda
tonermagus
#16021
ekkold
Topikgazda
válasz
tonermagus
#16021
üzenetére
Amit [PHM] belinkelt, 0.4V-al már működik, tehát 6V-ból simán tud 5V-ot csinálni. Ha a fogyasztás kicsi, akkor 5V esetén csak 0.1...0.2V-ot vesz le, ami még elegendő lehet a normál működéshez. Egy próbát mindenképpen megér.
-
#16018
ekkold
Topikgazda
tonermagus
#16013
ekkold
Topikgazda
válasz
tonermagus
#16013
üzenetére
A feszültségosztó nem megoldás erre. LDO stabilizátort keress, ezek akár 0,1V (vagy kevesebb) maradékfeszültséggel is tudnak dolgozni.
-
ekkold
Topikgazda
válasz
tukko1
#15903
üzenetére
Az arduino is tudja használni az STLink-et, csak ki kell választani, hogy azzal programozod, és akkor boot-loader sem kell rá (csak akkor kell ha az ST-t az USB-n akarod programozni).
Amúgy ilyen BluePill panelből amit vettél elég sok olyan fordul elő amin nem működik az USB. Talán valami hibás szériájú prociból építették, vagy hasonló. Nekem is van itthon néhány ilyen panelem, kb az 50%-án működik az USB, a másik 50%-án nem. Volt amin kinyírtam véletlenül a procit, forrasztottunk rá eredeti MCU-t, azzal megjavult az USB is
. -
ekkold
Topikgazda
-
ekkold
Topikgazda
válasz
Undoroid
#15762
üzenetére
Ha a szoftver (és a processzor is) ugyanaz, akkor a harver egyéb részében lehet különbség ami miatt nem megy. A nano és az uno esetében pl. a lábak számozása miatt lehet kavarodás, az LCD rákötésében. Illetve lehet, hogy a nano-nak pont valamelyik LCD-hez használt lábával van gond. Szoktam én is 2x16-os vagy hasonló alfanumerikus LCD-t használni, mert könnyen használható, egyszerű, és olcsó - egyedül a sok vezeték zavar. Ez utóbbit úgy oldottam meg, hogy egy 74HCT595 léptetőregiszter IC-vel vezérlem, így mindössze 2db I/O láb kell hozzá. Persze így saját drájvert kellett írnom hozzá, viszont az egyszerűbb és gyorsabb lett mint a gyári. Azonban történetesen uno/nano-ra nem írtam meg a szoftvert, mert olyanon nincsen, csak BluePill-en, ESP8266-on, és arduino DUE panelen használtam eddig.
Erről egy kis cikket is írtam: [link] -
ekkold
Topikgazda
Arduino környezetben is használható, és az arduinos függvények nagy része működik is rajta, de van néhány STM specifikus függvény, ami nem "standard arduino".
Ugyanakkor az ST-nek van hozzá ingyenes fejlesztő környezete. Azzal sokkal több a lehetőség, jobban kihasználható a hardver, de nehezebb/bonyolultabb a használata.
A forrasztóállomásom szoftverét pl. arduinoval készítettem erre a procira. -
ekkold
Topikgazda
válasz
Janos250
#15748
üzenetére
Az ESP32 és az ESP8266 is jó processzor, mindkettő jóval erősebb mint egy sima arduino. Viszont drágábbak mint az STM, többet fogyasztanak, és nem kell mindenhez Wifi sem.
Az STM procit használva a program matekozós része (pl. a forrasztóállomásom esetében a PID) olyan gyorsan fut le, hogy szinte elhanyagolható az erre fordított idő. Az A/D konverterre várakozás, vagy pl. az opampok beállási idejét kivárni sokkal több idő. Még mindíg meg tudok lepődni, mekkora számítási teljesítménye van ennek a procinak. Van pl. arduino due panelem, ami szintén igen gyorsnak számít, de a BluePill annál is gyorsabbnak tűnik. -
ekkold
Topikgazda
-
#15719
ekkold
Topikgazda
tonermagus
#15715
ekkold
Topikgazda
válasz
tonermagus
#15715
üzenetére
Esetleg valami ilyesmi? [link]
-
ekkold
Topikgazda
Nem tudom mennyire extra, vagy értékes az a program, de lehet, hogy a hardver ismeretében viszonylag könnyen megírható egy másik program az adott funkciókra. A programozó lábak levágása a prociról némi hekkeléssel még kezelhető: pl. kis köszörülés a tokon, ahol a láb befelé folytatódik, és vékony szál odaforrasztása... Némelyik kollégámnak ez sima rutinfeladat lenne
A lényeg: a védelemnek csak olyan szintűnek kell lennie, ami a program értékének megfelelő. Tehát elegendő ha a védelem megkerülése több munka, mint másik programot írni, és akkor nem fog senki sem foglalkozni a feltörésével - egyszerűen azért, mert nem éri meg.
Amit Géza írt lentebb, általában az is elegendő, és teljesen jó megoldás. -
#15686
ekkold
Topikgazda
tonermagus
#15685
ekkold
Topikgazda
válasz
tonermagus
#15685
üzenetére
Elvileg minden procinak van egyedi azonosítója. Ha ezt kiolvassa a programod, akkor simán megteheted, hogy csak azon az egy procin fusson a kód - és akkor hiába másolja le bárki is... Ezt továbbgondolva pl. az egyik projektemben úgy kezeltem ezt a problémakört, hogy az egyik menüpontban a program kiír egy egyedi azonosítót, amihez meg kell adni egy kulcsot. Ha a megfelelő egyedi kulcsot nem adják meg, akkor a program csak DEMO verzióként működik, indulás előtt 15 másodpercet várakozik, és csak 15 percig működik utána leáll. Ez a kipróbáláshoz bőven elég, és ha valaki tartósan akarja használni, akkor egy jelképes összeg ellenében elküldöm a számára szükséges egyedi kulcsot. Innentől viszont a program .bin formátumban szabadon letölthető a weblapomról, bárki rátöltheti a saját processzorára, kipróbálhatja, és ha tetszik akkor egy jelképes összegért cserébe teljes verzióként is használhatja.
Amúgy mi az a kütyü amit be fogsz mutatni?
A forráskódot amúgy nem tudják lementeni, csak a gépi kódot bináris formában. Nem lehetetlen ebből forráskódot készíteni, de azért elég sok munka ahhoz, hogy ne érje meg - azaz lehet, hogy egyszerűbb, gyorsabb új programot írni az eszközre.
-
#15579
ekkold
Topikgazda
tonermagus
#15576
ekkold
Topikgazda
válasz
tonermagus
#15576
üzenetére
Nekem bevált az STM32. Bevásároltam kínából néhány BluePill-t játszani, azóta pedig már egy ilyen vezérli a forrasztóállomásomat: [link]
-
#15504
ekkold
Topikgazda
tonermagus
#15503
ekkold
Topikgazda
válasz
tonermagus
#15503
üzenetére
Nyilván akkor a .bin fájlt kell odaadnod, de kell egy programozó eszköz (vagy csak szoftver), amivel fel lehet tölteni - ez a proci /alaplap típusától is függ.
-
ekkold
Topikgazda
Ennek több oka is van.
- Kínából rendelve kb. egy árban van a kettő (de lehet, hogy az FTDI picit drágább)
- ST-Link esetében a BluePill-en nem kell a jumpert átrakni a programozáshoz, míg soros portos esetben át kell rakni a jumpert minden programfeltöltéskor.
- ST-Link használata esetén sokkal gyorsabb feltölteni a programot, gyakorlatilag még 1 másodperc sem kell hozzá.
- BluePill oldalán külön tüskéken ott van az SWDIO, SWCLK, ezekre kényelmesebb csatlakozni.Ettől függetlenül abban igazad van, hogy sima soros porton is feltölthető a program. Tehát mindkét megoldás használható. Sőt van egy harmadik megoldás is: ha feltöltjük rá a boot-loadert, akkor onnantól a rajta levő USB-n keresztül is lehet programozni, így gyakorlatilag az USB kábelen kívül már semmi sem kell hozzá. Kipróbáltam mindhárom módszert, és nekem az ST-Link használata jött be leginkább.
(Csak zárójelben: ugye nem kevered össze az ESP32-t és az STM32-t ?)
-
ekkold
Topikgazda
válasz
Janos250
#15467
üzenetére
- Az a görbe amit nézel 50V D-S feszültségre vonatkozik. A FET nyitott állapotában pedig jó esetben ennél sokkal kisebb feszültség marad rajta.- A görbe tipikus adatokat ad meg, tehát nem mindegyik FET ilyen, hanem van szórás a paraméterekben, és csak átlagban ilyen.
Magyarán ez nem garantálja, hogy 3,3V-ról teljesen kinyit bármelyik ilyen tipusú FET. Azt hogy hamis vagy eredeti, ez alapján nem lehet eldönteni, csak akkor ha nagyon rossz. Sokkal jobb pl. az Rdson-t lemérni a max nyitófesz (16V Vgs) környékén, és esetleg a D-S letörési feszültséget, valamint a gate töltést, és a félvezető kapacitásokat. Ha ezek mindegyike stimmel, akkor talán eredeti, de ha bármelyik hibádzik, akkor hamisítvány. -
ekkold
Topikgazda
válasz
Janos250
#15464
üzenetére
Az alapján, hogy hol nyit ki, nem lehet eldönteni, hogy hamis-e. Az adatlapja szerinti treshold max. 2,5V, azonban itt csak 250uA-t kell vezetnie. Az Rdson pedig csak 4,5V-ra és 10V-ra van specifikálva, 3,3V-ra nincs. Tehát az adatlap szerint beleférhet sz is, hogy 3,3V-ról alig vezet, vagy az is hogy több A-re jó, de egyikre sincs garancia. (amit ötöd - tized áron rendelsz kínából, azok közül szinte biztosan mindegyik hamis).
Amúgy pedig a korrekt megoldás az, ha olyan FET típust keresel, amelyre 3,3V Ugs-nél is specifikálnak olyan értékű Rdson-t, ami megfelel a felhasználási célnak. a másik lehetőség FET meghajtó használata, ami a 3,3V-os vezérlőjelből nagyobb feszültséggel vezérli a FET-et. -
ekkold
Topikgazda
válasz
Istv@n
#15187
üzenetére
A legbiztosabb egy átfolyásmérő, mert biztos, hogy csak akkor ad jelet, ha megy a szivattyú.
Az átfolyó áram érzékelése is informatívabb mint a szivattyún megjelenő feszültség érzékelése. Ha az áram bizonyos határok közötti, az utalhat a normál működésre, ha a határokon kívül van akkor nem működik vagy rendellenesen működik. Arduinohoz kaphatók hall érzékelős áram szenzorok, amivel leválasztott módon mérhető az áram (bár nem túl pontosan, de erre a feladatra elegendő). [pl. ACS712 szenzor, vagy arra épülő modul]
Illetve létezik kicsi nyákba ültethető áramváltó is, amivel szintén leválasztott módon mérhető az áramfelvétel.
Szintén közvetett módszer, de a motorra szerelt kontakt piezo érzékelő (piezo mikrofon) is érzékelheti a szivattyú motor üzem közbeni rezgését.
-
ekkold
Topikgazda
Több oka is van. Pl. a standard c string függvények (pl. strlen()) is jól működnének, egyszerűbb lenne a konverzió egyes kijelzőkhöz. Kevesebb helyet/memóriát foglalnának az ékezetet is tartalmazó szövegek, nem okozna gondot egyes programok más processzorra való átvitelénél, az eltérő bájt-sorrend kezelés, ilyesmik. Összefoglalva, nekem sok szempontból jobb lenne...
Új hozzászólás Aktív témák
Hirdetés
- Gaming notebook topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Mibe tegyem a megtakarításaimat?
- Microsoft Excel topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Csak úgy szórja a dollár milliárdokat adatközpontokra az Amazon
- Shield TV-t csinált a Shieldből az NVIDIA
- Fujifilm X
- Motorola Edge 30 Neo - wake up, Jr...
- Revolut
- További aktív témák...
- Bomba ár! HP EliteBook 840 G2 - i5-5GEN I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Bomba ár! Lenovo ThinkPad L390 - i7-8GEN I 8GB I 256SSD I 13,3" HD I HDMI I Cam I W11 I Gari!
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Csere-Beszámítás! Sapphire Pure RX 7700XT 12GB GDDR6 Videokártya! Bemutató Darab!
- AKCIÓ! Gigabyte B85-HD3 B85 chipset alaplap garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest