- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- sziku69: Szólánc.
- Magga: PLEX: multimédia az egész lakásban
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Gurulunk, WAZE?!
- Kempingezés és sátrazás
- Viber: ingyen telefonálás a mobilodon
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
-
LOGOUT
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
-
Janos250
őstag
válasz
gyapo11
#13605
üzenetére
Igen.
Én az ESP8266WebServer-t használom, mert szerintem az a legkényelmesebb.
A fejlesztője aktualizálta, változtatás nélkül fut ESP32-n is.#include <WiFiClient.h>#include <ESP8266WebServer.h>ESP8266WebServer server(80);server.begin(); // start the HTTP serverserver.on("/", handle_index);void handle_index() {// ide irom, hogy mit csinaljon}
A paramétereket név szerint is, sorszám szerint is lekérdezhetem.
Majd ha lesz időm, írok valami tutorialszerűt.
Régebben itt valakinek csináltunk egy elég összetett programot, valami locsolás vezérlésre, de már nem találom itt.
Soros porton továbbítást nem tudom, nekem a fordított kellett: soros portról jövőt továbbítani wifi/router/nyilvános net segítségével adott IP című eszközre. -
Imy
veterán
válasz
gyapo11
#13566
üzenetére
Akárhogy is próbálkozok, nem találok rendesen működő példát. Van hogy kihagy az encoder számolása, ha van benne más is.
[link] Itt a 18-as hozzászólást próbáltam, de nem igazán működik ez sem.
Az interruptot meg fogalmam sincs, hogyan kell kezelni. Nem értek én annyira az arduinohoz.
-
repvez
addikt
válasz
gyapo11
#13474
üzenetére
ilyesmire gondoltam, de nem találtam sehol ekkora méretben vagy aminél már alapbol be lenne épitve arduino kompatibilis servoelektronika a vezérlésre.
DE a legjobb valami olyan lenne ami csak a keresztmetszet szűkítésével operál és nem zavarja meg az áramlást a csőben mint egy keresztbe tett lap.
-
válasz
gyapo11
#13468
üzenetére
Az ilyen gyors reagálást igénylő feladatokhoz sokkal alkalmasabb a gumi kontaktusos nyomógomb (pl. távirányítók, gamepad-ek gombjai stb), az ugyanis nem pereg, így nem kell prellmentesíteni.
Cserébe nem zár nullára, de ez egy nyomógombnál többnyire nem is okoz problémát.A zongorabillentyűkről jut eszembe: akár optokaput is lehet ilyen célra használni (szerintem a szintetizátorok sebességérzékelős billentyűmechanikáját is valahogy így oldhatják meg).
-
atesss
addikt
válasz
gyapo11
#13462
üzenetére
2db egy-áramkörös záró mikrokapcsoló van, ilyesmi: [link] (Hiába nézne ki elsőre két-áramkörösnek a 4 lába miatt, nem az.)
Illetve van még 4db DIP-kapcsoló, ilyesmi: [link]
Utóbbinál is lehet pergés tulajdonképpen, szóval azt is meg kellene oldani akkor már.
És ráadásul már elég kevés helyem is van a nyáknak azon a területén, szóval helytakarékosnak is kellene lennie (pl. 1-2 raszteres alkatrészekből).
MOD:
aryes
Hát igen, a SW-es megoldás jobban tetszene.
Bár most ugyan nem számítana, de - kvázi tanulási célból is - olyan megoldást szeretnék ami azért kicsit elegánsabb.
Szóval sleep-et nem szívesen raknék be, mert amúgy indokolatlanul lassítja a program működését, sőt fixen egy időre megakasztja.
Ami az ötletem lett helyette:
Lehetne az Interruptot ugyan letiltani ilyenkor, de helyette a MAIN ciklusban "órával" mérni, hogy mikor telt el már több mint 80ms. És ha ez eltelt, csak akkor indulna el a tényleges interrupt-handler függvény. A függvény végén pedig újra engedélyezni az Interruptot, globálisan. -
válasz
gyapo11
#13462
üzenetére
De jelen esetben is egyszerűbb a szoftveres megoldás: interrupt esetén kell egy kb. 50-80ms sleep (ezalatt természetesen az interruptokat letiltani, hogy ne okozzon zavart a pergés miatt a többszörös interrupt), csak utána beolvasni a portok állapotát. A gomb elengedése esetén ugyanez, csak itt az eredményeket eldobjuk, ha nincs művelet gomb felengedésre.
-
atesss
addikt
válasz
gyapo11
#13450
üzenetére
De mivel többször is mértem, így eléggé valószínűtlen hogy minden mérésnél pont a rövid impulzusba mért volna bele.
Mindegy, ma du. végre kiderül, ma meg tudom mérni szkóppal.
A PCF8574 bemeneti pinjeire erősen ajánlott ellenállásokat is megveszem, de még direkt nem forrasztom be, előtte kimérem szkóppal ezt az anomáliát.
Mondjuk már így előre felmerült bennem, hogy ilyen "egy-impulzusos" jelre hogyan fog tudni szinkronizálni a szkóp.
Minek kellene lennie majd a trigger-forrásomnak ?
Rigol, digitális, elég nagy tudású (és sajnos a bonyolultabb funkciókat nem is nagyon tudom használni). -
Tankblock
aktív tag
válasz
gyapo11
#13422
üzenetére
Egy normális SSDben van támogatva a wear leveling figyelése és nem ugyanoda irogat vissza, plusz a cachelése is jobb. SD nél meg max ha az oprendszer figyel rá....
Nálam SD kártyából több hallt már meg mint ssd/hdd ből...
Igen lehet RPi4 is SSDről futtatni/bootolni.
Attól én még hiszek a különböző lokációkon tárolt adatokban, azok nehezebben sebezhetőek... Bármely gépről hozzáférehetőek. -
lmaresz
aktív tag
-
-
válasz
gyapo11
#13292
üzenetére
"De vannak ilyen cmos ic-k, régen sok erősítőbe, előerősítőbe tettek ilyet, hogy ne a puruttya yaxley legyen a bemenetválasztó."
Most csak a kiegészítő elektronika nélküli lehetőségeket mondtam.
"I2c-ről nem régen volt szó, hogy ha a libraryban nincs lekezelve, akkor akár az egész program futását meg tudja állítani egy hibás szenzor."
Hát ezen sajnos az sem segít, ha több lábra vannak elosztva a szenzorok.
-
válasz
gyapo11
#13282
üzenetére
Ha a vezérlő egy, a TX lábon keresztül vezérelt H-bridge-en keresztül látná el a többi lapot táppal, a vezérelt lapok Vcc lába előtt pedig egy dióda + puffer kondenzátor lenne, a tápvonalat közvetlenül az RX lábukra kötve sima serial kommunikációval lehetne a tápvonalon keresztül kommunikálni velük. Jól gondolom?
-
repvez
addikt
válasz
gyapo11
#13240
üzenetére
Eddig amiket találtam azok mind elég jónak tünik addig amig csak azokat a dolgokat használom ami alapbol benne vannak a programban, de nem mindegyikhez találtam információt, vagy azt a weboldalt ahonnan a kivánt senzort , érzékelöt modult, be tudnám inportálni a programba, vagy ha meg van akkor meg azt nem találom, hogy hogy lehet alternativ libarykat betölteni a szimulátorhoz és a kodoláshoz.
Eddig amiket találtam a tinkeren kivül:
autodesk 123d circuits
Victronics Arduino simulator
Fritzing
Siiid
VBB4Arduino
VBB (virtual bread board) Bár ez érdekes, mert amit a neten találok az elég részletes és sok dolgot be lehet inportálni, de amit le lehet tölteni most a microsoft storebol az elég alap.
Proteus
ÉS vannak olyan programok amikkel elvileg lehet szimulálni az arduino kapcsolásokat, de eddig csak olyant találtam ahol a legalapabb elektronikai elemekkbol kellett felépiteni hozzá a kapcsolást, tehát ha egy giroszkopot akarsz bekötni, ahhoz tudnod kellene a giroszkóp panel összes elemét hogy van bekötve és le is rajzolni a programba mielött a panelhoz kötöd.
Ez nekem már nagyon magas szint.
Ilyen a EAGLE, a TINA, és még pár.Szóval ha valaki a fentiekbol vagy azon tul tudja, hogy lehet beimportálni szenzorokat és librarykat, az jó lenne
-
válasz
gyapo11
#13222
üzenetére
Dennis M. Ritchie C könyvét ismerem (nekem is megvan) és egyáltalán nem csodálkozom, hogy nem értetted.
Én C64-en kezdtem BASIC-ben, még a 90-es évek elején. Az alapokat azzal tanultam, de sokan mondják a Pascal-t is, mint jó kezdő nyelv, az nekem kimaradt. Később C64 assembly-ban is próbálkoztam, ami nagyon jól jött nemrég, amikor egy Attiny12-t programoztam assembly-ban. -
repvez
addikt
-
gyapo11
őstag
válasz
gyapo11
#13213
üzenetére
Még egy kiegészítés az emulációhoz, más elektronikai emulátoroknál láttam, hogy néha iszonyatosan belassul, mert rengeteget kell számolnia. Tehát van egy áramkör, elindítod, szaladnak a másodpercek realtime. Van egy másik áramkör, elindítod, és másodpercenként mondjuk 1 ms-ot halad. Egyrészt nagyon sokat kell várni, hogy meglásd hogy pl. 1 percnél mi lesz, másrészt az időzítések is problémásak lehetnek mivel 1000-szer lassabban telik az idő, harmadrészt bonyolultabb áramkörnél a használhatatlanságot is elérheti a lassulás.
A valódi hw elemek viszont pontosan tudják a fizikát (nekünk sajnos meg kell tanulni), és mindig minden realtime történik bármilyen bonyolult áramkörben is. -
#13158
Drótszamár
őstag
gyapo11
#13156
-
Janos250
őstag
válasz
gyapo11
#13063
üzenetére
Mivel kis méretekben akarjátok használni, ide most nem passzol, ezért is teszem offba, de azért megjegyzem, hogy az ESP32 (ugye kitaláltátok
) RMT az a Remote Controller rövidítése. Azért nem passzol ide, mert elég nagy, és azt biztosan nem tudja, amit írtatok, hogy a zavaró fényeket ne vegye figyelembe. Viszont, ha adni akarunk, megadjuk a vivőfrekit, és a mintát (64 byte, vagy ennek max nyolcszorosa ), és adja ameddig akarjuk, akár végtelenségig -
válasz
gyapo11
#13063
üzenetére
Egy tetszőleges attiny vagy 555 ic is pont megfelelő lenne a feladatra, csak az az egy probléma, hogy a tsop nem alkalmas folyamatos jelfogadásra, ezáltal optokapunak sem! Az adatlapja (ez éppen a tsop31238 adatlapján olvasható, mert az volt épp kéznél) szerint
"• Burst length should be 10 cycles/burst or longer.
• After each burst which is between 10 cycles and 70
cycles a gap time of at least 14 cycles is necessary.
• For each burst which is longer than 1.8 ms a corre-
sponding gap time is necessary at some time in the
data stream. This gap time should be at least 4 times
longer than the burst.
• Up to 800 short bursts per second can be received
continuously.
"Egyébként egy attiny85 + cr2032 elem + IR LED + ellenállás kombó távolságtól függően teljesen jól ellátná a feladatát, de csak ha nem kell nagy sebességű mozgást érzékelni.
-
And
veterán
válasz
gyapo11
#13063
üzenetére
Stílszerűen egy kontrollerrel
. Én 12F-sorozatú PIC-kel szoktam, nem tudom, van-e ilyen célkontroller készen hozzáférhető kivitelben is. Vagy hogy egy arduino - mondjuk a legkisebb nano - PWM-je rávehető-e erre, talán igen. Bár azt nem igazán értem, miért kell neked valamelyik IR-protokoll szerinti jelet adnod (szimpla folyamatos vivő nem elegendő!) és azt dekódolnod egy egyszerű optokapu helyett. Így az egyetlen előnye a környezeti fény kizárása. Akkor már inkább az a TSSP közelítésérzékelő, bár ahhoz is szükség van legalább egy rövid impulzusokra kapuzott / modulált vivőre. -
And
veterán
válasz
gyapo11
#13056
üzenetére
(A TSOP-sorozat nagyon jól kitalált, annyira rá van hangolva a segédvivő (a -4838 típus esetén konkrétan 38 kHz) frekvenciájára, hogy nem érdekli sem a folyamatos háttérfény, sőt adott időt túllépve már a vivő jelenléte sem. Maga a tok pedig valószínűleg előszűrőként működik a hullámhossz érzékenységi maximum, 950 nm környékén. Azt azért megérzi, ha az adóoldali IR-led nincs rendesen kihajtva, közvetlen uC-lábról táplálva - tranzisztor nélkül - nem tud akkora hatótávot.)
-
Janos250
őstag
válasz
gyapo11
#13040
üzenetére
Azért a nagyobb áramokra inkább a LiFePo (lítium, vas, foszfor) akkuk a jobbak, bár ezeknek kisebb a kapacitásuk, és a feszültségük is valamivel kisebb. Régebben itt valaki ajánlotta ezeket a kisebb feszültségük miatt 3.3 V-os lapok meghajtására konverter nélkül, de már nem emlékszem, ki.
-
Janos46
tag
válasz
gyapo11
#12898
üzenetére
Megmértem. Valóban van benne egy dióda, az 1K terhelésre kb. 0.2 voltot esik a feszültsége, tehát lehet hogy egy germánium dióda van benne. Legalább is (régi) ismereteim szerint azon esik ennyit. Tehát akkor valóban helyes a kapcsolási rajz, és onnan is lehet táplálni egy nagyon kis fogyasztású valamit. Írok egy PÜ-t is.
-
Janos46
tag
válasz
gyapo11
#12874
üzenetére
Igen, ez így rendjénvaló lenne. Ezt csak úgy tudnám elképzelni, hogy az usb-ről táplált belső 5 voltot rávezeti egy diódán nyitó irányban a VIN tüskére, (de akkor ott esik a diódán a feszültség), így ha VIN-re adod a feszkót a diód zár, befelé minden rendben múködik. De nem ismerek olyan diódát (ami nem jelent semmit), amin ne esne nyitóirányban valamennyit a feszültség. Itt pedig ugyan annyit mértem.
-
Janos250
őstag
válasz
gyapo11
#12816
üzenetére
Nekem is kell előbb-utóbb grafikonokat csinálni, hogy egy szenzoros arduino szerverhez (természetesen ESP32
) kapcsolódva a telefon kirajzolja a mért adatokat. Az a bajom ezekkel a chart rajzolókkal, hogy a megjelenítő gépen/telefonon megákat akar letölteni netről. Ha nem kapcsolódik a nethez, nincs ábra. Én ezért jelenleg inkább abban gondolkodom, hogy svg ábrát csinálok. Kicsit zöld, kicsit savanyú, de...
Már használtam az svg-t arra, hogy koordinátákkal megadott sokszögeket, szövegeket, miegymást rajzoljon ki. Egyszerű, rövid, tömör, könnyen megtanulható.
Például egy link annak, aki nem ismeri:
link -
-
válasz
gyapo11
#12761
üzenetére
133 órajel, egy utasítás attól függően, hogy mit csinál, 1-4 órajel, legrosszabb esetben is 33 utasítás, hát, ennél azért lehet jobban is optimalizálni a feladatot.
Nemrég elmerültem mélyebben az AVR assembly-ban, egy for ciklust port piszkálással együtt körülményektől függően negyed ennyi, vagy még kevesebb idő alatt meg lehet oldani. -
Janos250
őstag
-
ecaddsell
aktív tag
válasz
gyapo11
#12562
üzenetére
ESP32
#include "xtensa/core-macros.h"uint32_t start, stop;...start = xthal_get_ccount();<kód amit mérni akarsz>stop = xthal_get_ccount();A különbséget meg kiírod soros porton, USB-n stb.
Hiába mutatod meg a forrás valami programnak, ha a háttérben az interruptok viszik az időt, meg néha cache miss van a nagyobb kód miatt, ez lehet csak ESP32, vagy mondjuk STM32-nél meg pl. bus matrix hozzáférés korlát van (az STM32 bus matrixot érdemes kicsit megnézni, tanulságos, hogy működik egy modern MCU).
A profilerek is tényleges futást mérnek és sok esetben egyszerűbb tickcount-ot nézni (ez majdnem mindenütt van) mint a toolokkal (ha van egyáltalán) küzdeni.Egyébként az iopin toggle is ugyanez. Az állapotváltás közzé teszed a kódot amit mérsz és szkópon vagy multiméteren nézed az eredményt. Itt is a HW bütykölés csupán a pin váltás nézése.
De felőlem azt csinálsz amit akarsz, elég sok infót bedobtam már, lehet többiek tudnak olyan progiról amit keresel, nem hiszem, hogy olyan egyszerűen működik mint gondolod, legalábbis ha tényleg komoly időzítési kritériumok vannak.
-
válasz
gyapo11
#12562
üzenetére
"én pl. a kapcsos zárójelet üres sorba teszem elöl-hátul. "
Én miután Kínából egy csomó hamisított attiny85-öt kaptam, amik belül attiny12-k voltak, bosszantott a dolog, és beleástam magam az AVR assembly-ba (mert ram hiányában nem támogatja a C fordító) hogy tudjam őket valamire használni. Eléggé egyszerű és szerethető dolog, már írtam benne servo motor kezelést, serial kommunikációt is.
úgyhogy ezentúl valószínű a nagyobb lapokhoz is fogom használni az assembly-t az időzítés-érzékeny dolgokra. Ha esetleg kérdésed lenne ezzel kapcsolatban, talán tudok segíteni. -
ecaddsell
aktív tag
válasz
gyapo11
#12555
üzenetére
Ha semmi mást nem csinál csak direktbe pineket matat az arduino is gyors (nem 100kHz), nézd meg itt (korábban is javasoltam, hogy keress rá a pin toggle-re):
https://arduino.stackexchange.com/questions/24452/pin-toggle-speedAz ESP32 10 MHz (tegnap rosszul írtam):
https://www.esp32.com/viewtopic.php?t=15952.75x gyorsabb, ami nem annyira sok.
STM32F103-nál 18MHz-et lehet elérni, de mondjuk az a kód nem hasonlítható a többihez, mert nem fordított kód, hanem assembly-ben megírt, előre feltöltött regiszterekkel operál.
https://stackoverflow.com/questions/59708656/stm32f103c8-gpio-speed-limit
Vsz. az ESP32 meg az arduino is gyorsabb lenne, ha így lenne megírva.Összességében azért ezek az értékek jól mutatják kb. mit lehet várni. Az STM32 egy nagyon flexibilis rendszer, de hobby szinten nehéz használni, az arduino a másik véglet, az ESP32 meg valahol a kettő között (csak ne kelljen assembly-ben használni, ne legyenek idő kritikus részek benne...).
Viszont az órajelen felül a nagyobb adatoknál is hátrányban van az arduino rövid proci szóhossz miatt.
-
Janos250
őstag
válasz
gyapo11
#12551
üzenetére
Már nem pontosan emlékszem, de régebben próbaként csináltam olyan programozható led szalag meghajtást ESP32-n, hogy while-ban figyeltem a gépi ciklusok számát (a 80 Mhz-est, mert csak azt lehet), így elég pontosan lehetett időzíteni még a 200 körüli nanosec-eket is. Nem mértem hányszor ment le, de néhányszor le kellett menjen 200 nanosec alatt, mert másként pontatlan lett volna. Viszont az ESP32 oprendszere - ha nem tiltod le a megszakítást - egy millisec-enként megszakít talán 6-8 microsec időtartamra, mert akkor nézi meg, kell-e taskot váltani. Ha kell, akkor parkolópályára kerülsz egy ideig. Az oprendszer által kezelt megszakításokból kétféle van: az egyik csak egész millisecenként adja rá a vezérlést, a másik meg azonnal. Régebben használtam, már nem nagyon emlékszem rá :-(
Az se mindegy, melyik magra teszed. A nullás kezeli a WiFit és a BT-ot, oda nem érdemes rakni időkritikus dolgokat. -
ecaddsell
aktív tag
válasz
gyapo11
#12551
üzenetére
Csak az ESP32-ről vannak ilyen téren tapasztalataim, ami gyors de van néhány buktatója.
Ha csak output pin-t váltogatsz akkor azt akár 4MHz-el is meg tudja tenni, azaz a loop idő microsec alatti (nem mértem meg, a neten megtalálható már mások megtették).Számomra az első pofon amibe beleszaladtam az ESP32-vel az az interrupt latency volt. Ugye ez az az idő ami eltelik a között, hogy valami input pin-re jelet adsz és a kód eljut odáig, hogy elkezdi futtatni az első általad kért utasítást. Ez pedig nagyságrendileg 2 microsec. Ha nincs semmi kritikus időzítésed akkor nem hangzik soknak, de ha kiszámolod, hogy egy 240 MHz-es magnak ez hány gépi kódú utasítás akkor kijön 1 döbbenetesen nagy szám, kb. 500 utasítás (ennek nagy részéért az RTOS felel, ha ez vigasztal).
Ebből talán már látszik, hogy maga proci gyors, elég komplex műveleteket végezve (ezt nem megszakításban) 64 bites ill. double számokkal (sima float van HW-esen), nagy tömbökben stb. sosem volt gondom ezzel. Viszont a nagy interrupt latency az azt jelenti, hogy ha nagyon sok a megszakítás az nagyon vissza tudja fogni és kevésbé kiszámíthatóvá teszi.
Ebbe sajnos akkor futottam bele amikor a 10 digit/s-es frekimérő felbontását szerettem volna javítani, amihez 10 000 mérés kellett volna másodpercenként (ha a jelnek van ennyi periódusa).Az STM32-vel ilyen gond nincs (mondjuk egy F103-ra eleve aligha varázsolsz valami oprendszert ami bezavarjon) viszont a blue pill-t leszámítva nincs értékelhető Arduino támogatása (vagy legalábbis amikor néztem nem volt) és pl. a nagyobb F407-nek (ebben már van float) már nem mellékesen a legkisebb tokozás is a már nem éppen barátságos 100pin (akkor sem barátságos amikor gyártatod a NYÁK-ot, részletek eléggé off).
Nálam a megoldás az volt, hogy még egy CPLD-t teszek a már eleve külön panelen lévő CPLD mellé ami a gyors logikát kezeli, ha már az ESP32 ebben nem jó. Ennek a VHDL kódját már meg is csináltam és működni látszott amikor parkolópályára került egy kicsit ez a projekt (sőt most per pill. felújítás miatt minden ami ehhez kell le van fóliázva...).
Az igazi az lenne, ha lenne kis pin számú (nem BGA) CPLD nagyobb logikával megfizethető áron (sajnos a gyártók ezen a vonalon alig fejlesztenek, nekik ez nem business). Az arduino/ESP32 tök jó arra, hogy user interfész logikázzon és azt gyorsan össze is lehet dobni, de ha valami tényleg gyors kell legyen ahhoz HW logika kell.
Egyébként ha rákeresel arra, hogy pin toggle majdnem minden infót készen kapsz, de 1 blue pill. (meg programozó ha nincs) nem akkora befektetés és ha nincs is szkópod a legtöbb multiméter sokkal többet tud mint amilyen sebességgel ezek tudják a pint módosítani (pl. az elég olcsó ANENG AN8008 10MHz-ig).
-
válasz
gyapo11
#12549
üzenetére
Én meg zenész vagyok, első - félig-meddig - sikeres építésem egy gitártorzító kapcsolás volt. Egy kartonlapra forrasztottam fel a cuccokat, és pár percig működött, aztán ki tudja miért soha többet.
Én igazából programozni szeretek, minden más (külső elektronika) csak szükséges rossz. 
-
válasz
gyapo11
#12538
üzenetére
Én igazából ott vagyok leragadva, hogy a tranzisztor árammal vezérelt, és áramerősítést végez, tehát miért jelenik meg az emitteren ugyanaz a feszültség - 0.7V?Mire ezt leírtam, rájöttem, hogy a bázis-emitter ez esetben diódaként viselkedik. Viszont a 90Ohm elég bázisvédő ellenállásnak? Nem hiányzik onnan egy nagyobb értékű ellenállás? Vagy az emitteren a feszültségosztó úgyis korlátozza az áramot? Ha az osztó korlátozza a bázisáramot, nem ugyanannyi áram "folyik el" a mért körből?
-
Nyirike
csendes tag
válasz
gyapo11
#12541
üzenetére
A táblázat nincs a kódban. Feszültségekből számolom vissza a termisztor ellenállását. És tesztek alapján ellenőriztem, hogy jó e a képlet.
A végén pedig az kapott ellenállás érték alapján visszafejtem a korábban mért ellenállás/hőmérséklet párok alapján kikalkulált együtthatók segítségével.
-
Nyirike
csendes tag
válasz
gyapo11
#12539
üzenetére
Ez a termisztor nem lineáris. A függvényt meg én alkottam meg amiből statisztikát csináltam és 0-200 ohm között 2%-s pontossággal tudom mérni. Sajnos ez elég tré pontosság, mert 1 ohm is már fokokat jelent ahogy emelkedik a hőmérséklet és csökken az ellenállás. Az a tartomány ami érdekel ott viszonylag pontos. 50 fok alatt meg nem nagyon érdekel, mert nem ez az üzemi működés.
Az hőfokot pedig az alábbi kalkulátorral számoltam ki:
https://sanjit.wtf/Calibrator/webCalibrator.htmlA termisztort meg kimértem 110-40 fokig fokonként ebből volt egy közelítő ohm/hőfok értékem. Ebből tudom amúgy hogy 50 fok alatt drasztikusan emelkedik az ellenállás 0 foknál már 5 kOhm.
A legbiztosabb az lenne ha beépítenék egy új hőfok jeladót ami teljes pontos lenne, de nem akartam a kocsihoz ennyire hozzá nyúlni.
A pontosságot úgy próbáltam növelni, hogy a lehető legkisebb szórású ellenállásokat használtam azokat 3 műszerrel megmértem, a tranzisztor nyitófeszültségét is 3 műszerrel mértem meg és így jutottam el a viszonylag pontos kalkulációhoz.
-
Nyirike
csendes tag
válasz
gyapo11
#12526
üzenetére
Tegnap megcsináltam a kapcsolást több ellenállás párral. Mindegyiknél ugyanaz a eredmény. Maximum 200ohmig tudom visszaszámolni a termisztor értékét, Hiába emelem 500 esetleg 1kOhmig.
Elkezdtem nézni a feszültségosztó képletét és mivel 90Ohm a felhúzója a műszernek, amint emelkedni kezd a drasztikusan a termisztor ellenállása annál kisebb értékben változik a rajta eső feszültség így a visszaszámoló képlettel egyre pontatlanabb.
A mutató amúgy 60-110 fok között mutat valamit így érthető hogy úgy lett belőve a felhúzója.
Tesztek alapján igazából e tartomány között viszonylag pontosan tudom mérni a termisztor értéket arduinoval persze lekövetve a tápfeszültséget ami 12 esetleg 14.4 vagy bármi más lehet.A képletek jól működnek, mert folyamatosan kiraktam a consolera a számolt feszültség eséseket a mutatón, a termisztoron és a plusz feszültségosztón és mindegyik az, amit számolok.
Tehát köszönöm a segítséget. A mutató és az arduino is jól megy úgy hogy nem zavarják be egymást.
Az általad írt Emitter követő tranzisztor bekötése pontosabb értéket adna? Tudnék 200 ohm fölé is számolni? Vagy érdemlegesen nem változna sokat az érték?
-
Nyirike
csendes tag
válasz
gyapo11
#12520
üzenetére
Köszi.
Így gondoltad?
Így hogy változik a termisztor ellenállás mérése a kódban?
Eddig úgy csináltam hogy 4.7k ellenállással felhúztam 5V-ra mérés után ki tudtam számolni:
float vA1 = analogRead(A1);
float R2 = (float)4700 * (1023.0 / (float)vA1 - 1.0);Ez már így nem jó. Se a felhúzó nincs se a divider nincs benne.
-
Janos250
őstag
válasz
gyapo11
#12509
üzenetére
"adni-venni kell byte-okat"
Az ESP32 RMT-je (ReMoTe) ezt (is) csinálja.
"vagy van jobb ötlet?"
Nem jobb, más:
Egy titkos algoritmussal az adó az utoljára adott N db. kódból generálja a következőt. A vevő tudja az algoritmust. Ha elvész a szinkron, akkor, ha az adó ad egymásután N db. kódot, akkor a vevőnél helyreáll a szinkron.
Akkumulátort cseréltél,és nem nyit a távirányító. Megnyomod egymásután mondjuk 15-ször, és már nyit. -
ecaddsell
aktív tag
válasz
gyapo11
#12509
üzenetére
Olyan nincs, hogy feltörhetetlen, csak olyan, hogy sokáig tart és nem éri meg vele foglalkozni.
Ha a vevőben van óra akkor lehetne nyilvános kulcsos rendszer.
Az adóba be kell írnod az óra percet, hozzáadsz még két random számot és a titkos kulccsal titkosítottan elküldöd.
A vevőben a nyilvános kulccsal kibontod. A két random számot eldobod az óra percet meg hasonlítod és ha hibahatáron belül van (mondjuk 2 perc) akkor elfogadod. -
Janos250
őstag
válasz
gyapo11
#12486
üzenetére
"Semmi kedvem nincs ilyet leprogramozni semmilyen nyelven"
Nem is kell, ezt már mások megtették.Amit leírtál, az tipikusan az "okos otthon" probléma: bamba user számára emészthető módon megfogalmazható szabályrendszert leírni. Ezt netes közösségek már elég jól körbejárták, van pár kiforrott irány, módszer. Kérdés, hogy érdemes-e egy sajátot csinálni, vagy a kiforrott, kidolgozott, hiba javított módszerek valamelyikét alkalmazni. Van itt a PH-n is egy topicja, de aki ezt a témát akarja kezdeni, az sokra nem megy vele. Ezeknek az elve, hogy van egy központi szerver, tipikusan valamelyik málna, vagy annak klónja, amihez kapcsolódnak az egyes eszközök, kontrollerek, szenzorok, stb. Pl. ESP8266-os konnektor, vagy akármi küldi a jelet a központ felé, az "szórja" az üzenetet, illetve feldolgozza. Ennek a feldolgozónak lehet különböző szabályok szerint (ezek egyike pl. a Node Red) megadni az utasításokat, szabályokat. De például lehet hang utasításokkal is vezérelni. Részletesebben nem ismerem, csak az egyik ismerősömnél láttam, hogy amikor megérkeztünk a házához, akkor bemondta a telefonjába, hogy "Hi Google", amire a Home assintant (ha jól emlékszem) figyelő állapotba került, és ezek után azt mondta neki hogy "home" vagy valami hasonlót, és felgyulladt a villany, miegymás.
Tehát ezt csak gondolatébresztőként írom, hogy nem gazdaságosabb-e egy jól kiforrott rendszert átvenni, mint egy sajátot létrehozni. -
válasz
gyapo11
#12487
üzenetére
Ha ilyen dolgokat kell csak állítani, hogy 1 perc helyett 2 percig világítson a lámpa, akkor esetleg egy olcsó keypad+LCD shield is lehetne megoldás, és a paramétereket menüből módosítani, hozzáadni-letiltani előre definiált perifériákat (pl szivattyú, lámpa stb) az előre definiált portokon, ami szintén hülyeálló megoldás. Ha i2c megoldás, akkor csak 2 lábat foglal (és nem csak uno-hoz lehet használni), a keypad pedig 1db analóg lábat. Így lehet menet közben is változtatni.
A beállított paramétereket elmented eeprom-ba/spiffs-re, és egy véletlen reset után is megmarad minden. -
válasz
gyapo11
#12479
üzenetére
A LEGO grafikus felülete sajnos nem nyílt forráskódú, a National Instruments csinálta neki, de nekem is ez volt az alap ötletem, hasonló ökoszisztémát létrehozni arduino-val, amit ugyanúgy lehet grafikusan programozni.
Elég sokat kutattam a témában, és a legjobb fejlesztői környezet, amit erre készen találtam a http://snap4arduino.rocks, szerintem ezt vedd alaposan szemügyre, a lényege, hogy saját blokkokat lehet benne létrehozni, pl csinálhatsz benne "szivattyú" blokkot, minden paraméterét legördülő listából lehet állítani, gyakorlatilag egy óvodás is tud benne működő programot csinálni. Azt hiszem Arduino forráskódot is tud csinálni, de ha ez nem is, akkor a tinkercad oldalon lévő hasonló blokkos környezet viszont igen. Sőt, igaz, hogy ez attiny85-höz lett készítve és ha jól látom már egy ideje nem fejlesztik, de esetleg a cocomake7 pc-s programját is nézd meg, ez is tud arduino kódot létrehozni és XML-ben programot menteni, szintén gyerekjáték a használata. -
cog777
senior tag
válasz
gyapo11
#12480
üzenetére
Ja, ertem. Sajnos PLC-hez nem ertek. Lehet logikat modositani ugy hogy nem inditod ujra?
Felvetodik a kerdes bennem mi van ha egy szelepet kinyitsz, majd modositod a programot ugy hogy kitorlod a szelepet a programbol. Akkor az nyitva marad.
Mar pedig ha nem szakember programozza, akkor siman elofordulhat.Ugy kepzelem el hogy allapotgep szerut kell osszerakni valos idoben. Ezt le lehetne irni egy fajlban, es ezt beolvasni. Minden blokk/allapot egy feladatot reprezental. A fajl ujrabeolvasasakor ertesiteni kell a blokkokat a valtozasrol/illetve ujraszervezni a blokkok kozti kapcsolatokat ha modosult a logika.
Elso korben mindenkeppen reset-es megoldast kepzelnek el (ahol mindennek megvan a maga biztonsagos es alap allapota) mert mar az onmagaban is szep feladat.
Masodik korben megprobalnam megoldani hogy hogyan kezeljem a valos idoben megvaltozott allapotokat. Pl 3 blokkbol egyet kitorolt a felhasznalo. Mi legyen ha eppen a masodik volt futas alatt. stb.En esp-ben gondolkodnek, mert python-ban pl ujra lehet tolteni a modulokat anelkul hogy a program tovabbi resze leallna. (pl hibajavitasra jo, ahol a szelep nyitas modult frissited)
Tovabba tud webszerverkent mukodni, es tavolrol racsatlakozva megnezni a naplojat. Tovabbgondolva, akar egy blokk diagram szerkesztot is meg lehetne valositani
ahol megtervezed a folyamatot. Igy csak egy bongeszo kell...Persze te dontod el mi szamodra a megfelelo.
Erdekes a feladat. Remelem irsz felole hogy haladsz.@Janos250: wow Node Red is erdekesnek tunik...
-
-
válasz
gyapo11
#12476
üzenetére
Erre a feladatra viszont a legjobban ajánlott téma a blockly/scratch típusú grafikus nyelvek! Az elsős gyerekem játékot írt benne, mondjuk alapból is okos gyerek.
Van, ami rögtön arduino kódot generál, van, ami a firmata fw-en keresztül vezérli a lapot. Mindegyik tud XML-ben kódot exportálni, nyílt forrású, az XML-ből megpróbálhatsz byte kódot generálni a saját parser-edhez.
Vagy amit én csináltam, robohw kolléga programnyelvéhez hasonló byte kódos robot vezérlő nyelvet találtam ki, hasonló a harvard architektúrához, csak nagyon szűkített utasításkészlettel (15 utasítás). Ehhez hasonló robotot akartam építeni a gyerekeimnek, de csak a parser lett kész, a frontend még nem készült el eddig. -
robohw
aktív tag
válasz
gyapo11
#12472
üzenetére
"Még a basicnél is sokkal egyszerűbb nyelvet szeretnék, input/output melyik portra mit, feltételek, időzítés, mindezt byte kódokkal."
Ennek az általam ajánlott tini Basic-nek az utasításkészlete nem más mint a BASIC nyelv subset-je.
Ennél egyszerűbbet, úgy vélem, nemigen lehet összehozni. Lényegében azt tudja, amit te igényelsz. Alap I/O, iteráció, szelekció, delay. Mondjuk byte kód nincs, de azt már nem olyan nehéz megvalósítani.
Amit te szeretnél, hogy egy nyelvet definiálsz és ahhoz megírod a parsert, scannert, kódgenerátort, virtuális gépet, az már nem annyira triviális feladat.
Ehhez talán némi segítségül szolgál az amit én csináltam. Csak ez assembly, bár annak elég puritán, szvsz könnyű elsajátítani. A VM-je is egyszerű. Itt megtalálod: [link]"Ha az arduino be van építve valahova messze a pc-től, akkor a kábeles kapcsolat már nem jó, sok embernek nem notebookja van, nekem az, de én se szívesen húzgálnám ki minden frissítéskor az összes kábelt belőle."
A PC terminál és az arduino (vagy AVR) közötti soros kapcsolat lehet wired is és wireless is. Én opcionálisra csinálnám. Vagy a vezeték végi csatlakozót dugja rá a portra, vagy a wireless adaptert és akkor nyomhatja úgy is. A dolog előnye, hogy nem kell PC-n byte kódra fordítani, hanem direktben az eszközön is megszerkeszthető, lepróbálható a program. Persze lehet használni csak byte kód átvitelére is.
Némi plusz munkával megvalósítható simplex kapcsolat is, egy 3-400 Ft-os RF adó-vevővel. Itt reálisan max. 1000 byte-os adatcsomagról beszélünk. Ennél hosszabb programot aligha írna bárki. Na meg, maga az eeprom is csak ekkora.Jó, lehetne írni PC-re egy emulátort, ahol kipróbálható, tesztelhető lenne a kód, de ilyen rövid programoknál én ezt fölösleges befektetésnek tartom.
-
robohw
aktív tag
válasz
gyapo11
#12468
üzenetére
"A program nem arduino kód lesz, hanem tömény adat, még ezt sem tudom hogy hova fog kerülni, valószínűleg az arduino eepromjába, és egy arduino kódban megírt értelmező fogja értelmezni.
Szóval milyen megoldást javasoltok a kód hordozására?"Erre kínálkozik két megoldás is. Az egyik egy BASIC-szerű programnyelv, amely a kontroller eeprom-jában tárolja vagy onnan olvassa be és futtatja a kódot. A másik is hasonló megoldás, a neve VTL (very Tiny Language) ez még a BASIC-nél is szimplább.
Erről írogatok egy cikket mostanában, csak keveset foglalkozok vele és magától nem akar befejeződni.
A BASIC eredetileg arduino uno-ra lett írva, az én célom a nyelv egy 40 lábú AVR-re való kiterjesztése. ATMega32L lett megcélozva, mivel ezt 500 Ft körüli összegért be lehet szerezni.
-
Janos250
őstag
válasz
gyapo11
#12416
üzenetére
Itt van rá library, de hogy mennyire jó, azt nem tudom:
https://www.codeproject.com/Articles/645/Sunrise-Sunset-Calculations
-
cidalain
veterán
válasz
gyapo11
#12416
üzenetére
Én nem pepecselnék, bevágnám egy 365 (vagy 366, szökőév van idén) elemű konstans tömbbe, és az adott napról csak lekérném hanyadik nap az évben, és kolvasnám a konstans tömb adott wlemét, aztán csókolom. Ezek az időpontok simán leszedhetők netről, még begépepni sem kell.
-
válasz
gyapo11
#12416
üzenetére
Amennyire én tudom, az általános képlet igencsak bonyolult. Maga a napkelte/nyugta egy szinuszhullámot követ, tehát ha arra a helyre, amire kíváncsi vagy kiszámolod az függvényt jó vagy. Viszont figyelembe kell venni a nyári időszámítást is, ha korrekt akarsz lenni, szóval az még plusz munka.
-
robohw
aktív tag
válasz
gyapo11
#12215
üzenetére
"Mint ahogy egy kalapácsot megveszel és dolgozhatsz vele pénzért."
Hát ez rossz analógia.
Az sem igaz, hogy felhasználható, azaz továbbértékesíthető lenne egy 3th party lib, vagy kódrészlet, ha azt nem tiltják.
A szoftvereknél az az alapvetés, hogy amit ENGEDNEK, azt lehet, amit nem említenek, azt meg nem lehet.Eleve, a saját fejlesztésével együtt eladja az addíciót is, mivel anélkül nem működne a sajátja sem, ergo, pénzt kap más munkájáért.
-
_q
addikt
válasz
gyapo11
#12213
üzenetére
Arduinonál is csomó könyvtár van, ami alapból nincs benne a fejlesztő környezetben, github-ról lehet letölteni. Viszont akkor azt mondod, hogy minden könyvtár, ami az arudino IDE-hez elérhető githubon, vagy IDE-n keresztül az mind ingyenesen és legálisan használható akár fizetős megrendelésre készült szoftverben is?
-
Tankblock
aktív tag
-
Bogyo72
csendes tag
válasz
gyapo11
#12142
üzenetére
Én az Adafruit-GFX ajánlása szerint próbálom, de az x1-ből kivontam, a w-hez meg hozzáadtam pár pixelnyit, hogy biztos legyen a törlés, de így ott maradnak azok a kósza pixelek.
int16_t x1, y1;uint16_t w, h;tft.getTextBounds(string, x, y, &x1, &y1, &w, &h);
Tegnap még kipróbáltam én is amit ajánlasz, az talán jó lesz a normál karakteres fontoknál, még ellenőrzöm biztosan tökéletes-e. A spec., nem azonos szélességű karakteres fontnál, viszont ugyan úgy problémás a kiírás. Lehet elfelejtem azt a betűtípust, pedig jó, mivel kis méretű és méretezésnél nem pixelesedik.
Egyébként vannak Adafruit-GFX-el használható, csak számokat tartalmazó karakterkészletek? -
vargalex
félisten
válasz
gyapo11
#12075
üzenetére
Akkor már nagyon közel vagyunk az ESP8266 deep sleep fogyasztásához (ha túl nem léptük), így felesleges vacakolni vele. Az rf modult és a hőmérőket szerintem nyugodtan lehet GPIO-ról hajtani (én is azt teszem), így csak akkor terhelik a tápot, ha nincs deep sleep. Sőt, ha ESP8266, akkor nyilván az RF modul is felesleges...
Cserébe nem zár nullára, de ez egy nyomógombnál többnyire nem is okoz problémát.
. Én 12F-sorozatú PIC-kel szoktam, nem tudom, van-e ilyen célkontroller készen hozzáférhető kivitelben is. Vagy hogy egy arduino - mondjuk a legkisebb nano - PWM-je rávehető-e erre, talán igen. Bár azt nem igazán értem, miért kell neked valamelyik IR-protokoll szerinti jelet adnod (szimpla folyamatos vivő nem elegendő!) és azt dekódolnod egy egyszerű optokapu helyett. Így az egyetlen előnye a környezeti fény kizárása. Akkor már inkább az a TSSP közelítésérzékelő, bár ahhoz is szükség van legalább egy rövid impulzusokra kapuzott / modulált vivőre.
Új hozzászólás Aktív témák
Hirdetés
ekkold- WLAN, WiFi, vezeték nélküli hálózat
- Kormányok / autós szimulátorok topikja
- Filmvilág
- Kazy Computers - Fehérvár - Megbízható?
- Samsung Galaxy A34 - plus size modell
- sziku69: Fűzzük össze a szavakat :)
- Apple MacBook
- Luck Dragon: Asszociációs játék. :)
- iPhone topik
- Parkside szerszám kibeszélő
- További aktív témák...
- BESZÁMÍTÁS! Asus ROG Flow Z13 + ROG XG RTX 3070 - i9 12900H 16GB DDR5 RAM 1TB SSD + RTX 3070 8GB WIN
- Samsung Galaxy A41 64GB Kártyafüggetlen, 1Év Garanciával
- AKCIÓ! Dell Latitude 5440 14 FHD üzleti notebook - i5 1335U 8GB RAM 256GB SSD Intel Iris Xe
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Telenor 5G Indoor WiFi Router (FA7550) + töltő (bolti áruk 100.000Ft)
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest