-
GAMEPOD.hu
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
-
haxiboy
veterán
válasz Tomika86 #5673 üzenetére
Az egyik Windows Formban a másik XAML, előbbibe bele tudok nyúlni utóbbival még nem találkoztam a gyakorlatban, bár elvileg ez is C#.
A legegyszerűbb módszer szerintem hogy a két formot 1 az 1-ben átemelni, majd egy harmadik formban (ami alapból indul meghívja a másik kettőt önmagán belül).Az arduinos programok egyesítésében viszont nem tudok segíteni örülök ha 3 nap alatt sikerül beüzemelnem egy LCD kijelzőt
Premium Mining Rigek és Gamer/Workstation gépek: tőlem, nektek :)
-
nagyúr
válasz Tomika86 #15009 üzenetére
Kizártnak tartom, hogy Te a lebegőpontos - integer közti sebességkülönbséget érzékelnéd. Legfeljebb olyan esetben, amikor tízezrével végzel ciklusban műveleteket.
Ha csak 1 tized pontossággal kell számolnod, akkor szorozd fel az értékeket 10-zel, aztán a végén oszd vissza, vagy még gyorsabb a biteltolás, pl: x << 4, a számolás végén pedig osztás 16-tal.Szerintem egyszerűen maga a kijelző és/vagy az azt kezelő library lassú.
[ Szerkesztve ]
-
nagyúr
válasz Tomika86 #15011 üzenetére
nem csináltam rosszat igaz?
Persze, hogy nem. Nemrég az oszcilloszkópom kapcsán eléggé beleástam magam én is a sebesség témába, de én lementem egészen assembly-ig, hogy nyerjek néhány us időt, és azt láttam, hogy a fordító meglepően hatékonyan optimalizálja a kódot. Alig tudtam rajta javítani.
Hol érzed lassúnak a programot? A serial.print rohadt lassú tud lenni, még magas bitrátán is, ha esetleg 9800bit/s sebességgel használod, emeld meg 115200-ra, ha lehet.
-
stopperos
senior tag
válasz Tomika86 #15009 üzenetére
Esetleg csökkentsd a DS18B20 szenzorok felbontását, az alap 12 bit helyett a 10 is elég szokott lenni. A 750 ms szenzoronkénti kiolvasási idő így a negyedére csökken.
"What is Linux? I only joined because of the the penguin..." - meanwhile in the linux community. http://9gag.com/gag/arpZGOy
-
And
veterán
válasz Tomika86 #15013 üzenetére
Csatlakoznék Aryes kollégához, ami a lebegőpontos műveletek sebességét jelenti. Más - de szintén 8-bites - kontroller is elég nagy kódot generál az ilyesmihez, de ha adatküldési vagy megjelenítési ciklusonként csak egyszer kell végrehajtani, az lópikula.
A Nextion-hoz viszont két dolog: az első, hogy a debug-módja nem túl életszerű, mikor soros porton küldözgetek rá adatokat szoros időzítések mellett (erre egyébként a leírása is utal). A másik, hogy a változói számára a hagyományos módú értékátadás (egyáltalán: parancsküldés) rettentő pazarlóan bánik az adatmennyiséggel. Ezt megkerülni csak 'reparse' módban lehet, amit a Nextion parancskészlet részletezése is jótékony homályban hagy. A legtöbbször csak annyit említ róla, hogy ezt úgysem szokás használni, így aztán mindenféle netes példákból lehet csak kihámozni a gyakorlati megvalósítását (pedig nagyon előnyös dolog). Azzal viszont én 500 ms-os gyakorisággal adok át a legkisebb (Basic-sorozatú, vagyis a létező leglassabb) típusnak közel 100 változót, és nem tűnik lassúnak. Persze egyetlen képernyőn sosem jelenik meg az összes, de azért pár tucat biztosan, és mellette mást is csinál, animál / rajzol a HMI. A valóságban hibátlanul működik, debug-gal pedig ugyanaz a Nextion-kód közel sem tökéletes.
Mod: a bitráta a uC - Nextion között nálam is 115,2 kbps.[ Szerkesztve ]
-
gyapo11
őstag
válasz Tomika86 #15021 üzenetére
Állíts össze egy áramkört emulátorban meg a valóságban. Sokszor előfordul, hogy egy egyszerű kapcsolás milliószor gyorsabban fut a valóságban, mert az alkatrészek ismerik a fizikát és realtime történik a legbonyolultabb folyamat is, az emulátorban meg percekig tart az első tizedmásodperc kiszámolása.
De van fordított eset is, pl. ha egy c64 emulátort futtatunk egy mai korszerű processzoron, akkor lehet 10-100-szoros is a sebesség, sok játékot nem is lehet játszani, ha olyan időzítéseket használ, ami a sebesség miatt lerövidül.menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
And
veterán
válasz Tomika86 #15024 üzenetére
Mivel a Nextion-féle Gauge objektumnak nem sok beállítható jellemzője van, ezért igen, muszáj írni egy rövidke script-et, ami adott eseménynél - most a Timer-en, ill. annak lejártán kívül más nem jut eszembe, ami erre a célra jó lenne - szépen átszámolja / átskálázza neked a bemenő mennyiségeket (nyomásértékeket) a mutató szükséges elfordulását eredményező ívszögekké.
-
nagyúr
válasz Tomika86 #15030 üzenetére
Hát persze, ez így teljesen rossz, mert 180-270-ig map-eli az értékeket, csak visszafelé, a lesz 270, a 400 pedig 180.
A helyes kód:map(nyomas, 0, 400, 270, 540);
Minden magára valamit adó gauge 360 feletti értéket érték%360-ként fog értelmezni, ha nem, akkor hibát ad. Ez utóbbi esetben neked kell a műveletet elvégezni, vagyishelyes_érték = map(nyomas, 0, 400, 270, 540)%360;
[ Szerkesztve ]
-
nagyúr
válasz Tomika86 #15032 üzenetére
A % az osztási maradék műveleti jele, amit ugye bonyolultan is le lehetne írni, hosszú képletekkel, de így egyszerűbb és elegánsabb. De gyanítom, hogy enélkül is működne, már 30 évvel ezelőtt, Commodore64-en, a Graphics Basic-ben is lehetett körívet rajzolni 360-nál nagyobb szögekkel.
-
nagyúr
válasz Tomika86 #15049 üzenetére
Nem azért kérdeztem, mert tudok jobbat, főleg úgy nem, hogy nem írtad le, hogy mi volt a választás szempontja. Én eddig kétszer vettem LCD kijelzőt, raspberry-hez. A legdrágább és legrosszabb vétel egy eredeti PiTFT kijelző volt, azt 8e Ft-ért vettem, szintén 2.8", abból Octoprint rig lett. A másikból gameboy emulátort csináltam, az egy 3"-os érintőkijelző volt, 640x480 60Hz, postával együtt 6ezer Ft-ért. Egy 2.8"-osat kaptam ajándékba, ami UNO-hoz való, szintén érintőkijelző, 320x240, Kedei típusú, ebből csináltam egy oszcilloszkópot, ez konkrétan ingyen volt. 7"-ost nem vettem még, de ha vennék, a Kedei márka környékén néznék szét.
[ Szerkesztve ]
-
Janos250
őstag
válasz Tomika86 #15066 üzenetére
Srácok!
Vigyázzunk anyanyelvünk tisztaságára akkor is, ha bizonyos körökben ennek az ellenkezője a sikk! Ne kövessük őket!
A brutális az rossz, durva, bunkó, balf.. a latin brutusból. Attól, hogy bizonyos körök szlengjében a brutális nem a rosszat, hanem a jót jelenti, ne kövessük őket!
Bocs az offért!Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
gyapo11
őstag
válasz Tomika86 #15079 üzenetére
Autóban arra kell készülni, hogy nagy impulzusok lesznek, amik megzavarhatják a processzort, szóval kondizni kell rendesen.
A MΩ-ot nem értem, minél nagyobbak az ellenállások, annál könnyebben szedik össze a zavarjeleket.
10 kΩ már jobb, arra is lehet hogy kell még kondi.menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
nagyúr
válasz Tomika86 #15085 üzenetére
Ja, nem, egyáltalán nem hülyeség, így szokás csinálni, csak én valamiért azt hittem, hogy az 5V tápfeszültséget akarod így előállítani.
A zenerrel együtt jó megoldás, de ahogy a kolléga írta, a MΩ túl sok, nagyon zavarérzékeny lesz, szerintem is elég oda egy 10kΩ+20kΩ osztó.[ Szerkesztve ]
-
gyapo11
őstag
válasz Tomika86 #15081 üzenetére
Az elkó az elektrolit kondenzátor, az meg elég nagy induktivitással szokott rendelkezni, tehát impulzus szűrésre nem annyira alkalmas. Inkább valami induktivitásszegény kondi kell oda, tantál vagy kerámia. A zéner egy dióda, ami fordított irányban elvileg kinyit egy adott feszültség fölött, pontosabban a letörési feszültséget tartja. Itt is az a kérdés, hogy milyen gyorsan tudja ezt tenni. Szerintem kezdj egy 100 nF kerámiakondival, aztán meglátod kell-e még más védekezés is.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
And
veterán
válasz Tomika86 #15104 üzenetére
Erős túlbiztosításnak tűnik. A kétlépcsős stabilizálás a hőtermelés szempontjából sokat nem segít, valószínűleg nem lesznek túlságosan távol egymástól a stabok. A 4700 μF-os puffer a bemeneten is soknak tűnik (elvégre nem egy trafó a forrás), a második stabkocka kimenetén pedig egyenesen ellenjavallt, egy stabilizátor vagy LDO eleve nem szereti az ilyesmit. Stabilabb nem lesz tőle, a bekapcsolási áramlökés pedig nem kívánatos. Oda bőven elegendő egy 0,1 / 1 μF-os kerámia, elvégre a 78xx-ek hullámosság elnyomása - bár nyilván frekvenciafüggő - nem annyira rossz érték.
-
And
veterán
válasz Tomika86 #15106 üzenetére
Függ a várható terhelőáramtól, amúgy annál is jóval - egy nagyságrenddel - kisebb kapacitásértéket szoktak használni. Viszont egy autóban a feszültségtüskék csúcsértéke szélsőséges esetben akár sokszor 10V is lehet, úgyhogy a bemeneti kapacitás tűrési feszültsége is ennek megfelelően választandó, illetve az induktivitás helyétől függően be lehet tenni a körbe szupresszort is. Ötletek: [link], [link].
-
gyapo11
őstag
válasz Tomika86 #15104 üzenetére
Ha a stabilizátor közel van az arduinohoz, akkor csak előtte kell az impulzusokat szűrni, és utána a nagy elkóval minél közelebb az arduino betáp pontjához. Rövid vezetéken nem tud tüske keletkezni, mert nincs induktivitása mint egy antennának. Az akkufesztől lesz egy vezeték az első stabilizátorhoz, ha az hosszabb, akkor ott már lehet tüske, a stab előttre kell a 100 nF és a puffer. A stab után már ne tegyél elkót, vagy ha mégis, akkor kell egy dióda párhuzamosan a stabbal fordított irányban, hogy ha a stab betápja megszűnik, akkor a kimenete ne kerüljön magasabb szintre mint a bemenete, azt nem szereti. Ha az arduino szed össze impulzusokat, akkor fémdobozba kell tenni és testelni, a táp maradhat kívül, hogy ne fűtse.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
gyapo11
őstag
válasz Tomika86 #15112 üzenetére
Akkor OK, nem kell pufferkondi, 3 A-es kocka 3 A alatti fogyasztás, elvileg rendben. Ha 8 V-ból állít elő 5-öt, akkor 9 W-ot el fog fűteni, valami borda kell rá.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
And
veterán
válasz Tomika86 #15112 üzenetére
Rosszul tudom, hogy a 'hagyományos' 7805-ösökből - ezzel a típusmegnevezéssel - csak 1 vagy 1,5 A terhelhetőségű létezik?
"Nextion 7" kijelző (erre 2A áramfelvételt írnak)."
Mindegyik 7"-os típusra (basic, enhanced, intelligent) 430..530 mA-es fogyasztást írnak. Javasolt tápellátás címén említenek lehetőleg minimum 2A terhelhetőségű tápot, de a valós fogyasztás annak a negyede lesz még maximális háttérfényerőnél is.
Ha valóban 3A-t közelítené az áramfelvétel - a valóságban az összes említett csingilingivel együtt sem fogja -, akkor a 20W-ot meghaladó disszipáció miatt sokkal jobban járnál egy kapcsolóüzemű megoldással (mellesleg azt is meg lehet toldani szűréssel).[ Szerkesztve ]
-
And
veterán
válasz Tomika86 #15119 üzenetére
Persze. Az adatlap 21. oldalán láthatsz is egy példát (Fig. 34) az opcionális szűrésre, ami egy plusz aluláteresztő LC-tagból áll. Amúgy a tervezett konfigurációhoz nagy valószínűséggel 1A-es terhelhetőség is bőven elegendő lesz, én olyan 6-700 mA körüli fogyasztásra tippelnék.
-
stopperos
senior tag
válasz Tomika86 #15119 üzenetére
Az arduinohoz nem kell 7805, mert ha azt megtáplálod 7V-15V között, akkor az előállítja magának az 5V feszültséget és nem táplál vissza USB-n. Ez elég a megának és a szenzoroknak amit írtál. A kijelzőt külön kell megoldanod.
Az előállított 5V feszültségre és a bemenő feszültségre raknék esetleg egy-egy 10-100uF mérettartományból kondenzátort."What is Linux? I only joined because of the the penguin..." - meanwhile in the linux community. http://9gag.com/gag/arpZGOy
-
stopperos
senior tag
válasz Tomika86 #15124 üzenetére
Igen. Én egy ideig a projektemet számítógép tápegységről tápláltam meg (5V és 12V), de utána átálltam egy egyszerűbb 12V-os led tápegységre. Nálam egy kétsoros lcd kijelző, 2 relé, 4 pwm csatorna + szűrés megy az aruinoról meg annak 5V-jéről. A 12V a műveleti erősítőnek és a tranzisztoroknak kell.
[ Szerkesztve ]
"What is Linux? I only joined because of the the penguin..." - meanwhile in the linux community. http://9gag.com/gag/arpZGOy
-
nagyúr
válasz Tomika86 #15129 üzenetére
Az árkülönbségből ítélve nagyjából ugyanez lehet. 5500+haszon+magyar áfa.
A tápot illetően szerintem tehetsz vele egy próbát, esetleg a regulátorra tegyél hűtőbordát, ha érezhetően melegszik.
Ha mégis megsülne: semmit nem veszítesz, úgyis kívülről akartad adni neki az 5V-ot.[ Szerkesztve ]
-
Tomika86
senior tag
válasz Tomika86 #15141 üzenetére
Ha jól gondolom akkor
- a float értéket átalakítja character tömbre
- összefűzi stringbe
- megnézi a hosszát és ez alapján byte-onként írjaKiolvasásnál
- azt nem értem, hogy amikor kiolvasok akkor miért a "chrFloat" hossza alapján ?
ez alapján tudjuk, hogy mennyit írtunk, ugyanennyit olvasunk vissza, de mi van akkor ha nem tudjuk mennyi byte-ot kell visszaolvasni (tehát mitől meddig tart egy összetartozó érték) -
nagyúr
válasz Tomika86 #15142 üzenetére
Én azt nem értem, hogy
1. minek astrcat( chrFloat, buffer); //
a kódba, felesleges művelet.
2. minek kell egyáltalán az EEPROM-ba kiírás előtt a float-ot string-gé alakítani és úgy kiírni? A float minden esetben 4 byte, nem kell gondolkodni, hogy mennyit kell visszaolvasni, ráadásul ha két számjegy+tizedespont+két tizedes esetén már kevesebb írásmennyiséggel is jár (4byte vs. 5byte).[ Szerkesztve ]
-
nagyúr
válasz Tomika86 #15146 üzenetére
Ha esetleg meggondolnád magad, ezzel az erről az oldalról vett példával így is ki lehetne íratni a float értékeket:
void EEPROM_writeFloat(int ee, float value)
{
byte* p = (byte*)(void*)&value;
for (int i = 0; i < sizeof(value); i++)
writeEEPROM(xAddr, ee++, *p++);
}
float EEPROM_readFloat(int ee)
{
float value = 0.0;
byte* p = (byte*)(void*)&value;
for (int i = 0; i < sizeof(value); i++)
*p++ = readEEPROM(xAddr,ee++);
return value;
}[ Szerkesztve ]
-
nagyúr
válasz Tomika86 #15147 üzenetére
Most jöttem rá, hogy a kód az egész "hatalmas" EEPROM-ba csak ugyanarra az egyetlen címre írja ki az értéket, aztán azt írja felül újra és újra. Így végülis mindegy, hogy milyen hosszú a szám. Azt hittem, hogy folyamatosan írja egymás után, log-ba.
Megjegyzem, hogy ez a módszer elég gyorsan el fogja használni azt az egy memóriacellát a folyamatos írással. Ha a cella élettartama során 1000000 írási műveletet bír elviselni, 10ms-onkénti írással durván 3 óra alatt ez be is fog következni.[ Szerkesztve ]
Új hozzászólás Aktív témák
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- World of Tanks - MMO
- Otthoni hálózat és internet megosztás
- Ukrajnai háború
- Stellar Blade
- AMD off topik: VGA, CPU, APU és minden, ami AMD
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Így építsd a billentyűzeted!
- Linux felhasználók OFF topikja
- Bemutatkozott a Moto G32 4G
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest