- Xiaomi Mi 11 Ultra - Circus Maximus
- Motorola Moto G72 - a titkos favorit
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy A56 - megbízható középszerűség
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Fotók, videók mobillal
- Samsung Galaxy S23 Ultra - non plus ultra
- Egy hét múlva érkezik a Honor Magic V5
- Szívós, szép és kitartó az új OnePlus óra
-
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
-
Tankblock
aktív tag
válasz
Tomika86
#15541
üzenetére
Szia,
fordulatszám azaz adott idő alatt megtett fordulatok száma. Ha korlátozod az időt 1 [sec]re akkor csak az impulzusokat kell számolnod, majd viszonyítani a perchez. rpm / rotation per ,minute.... Nem tudom mekkora lesz a legmagasabb fordulatszám a byte sztem túl kicsi.....
-
válasz
Tomika86
#15539
üzenetére
Az interruptból vegyél ki minden számítást és tedd át a loop-ba, úgy, hogy csak ennyi legyen:
void impulzus() // Impulzus érzékelésre meghívás
{
fordulat++;
}Hogy miért? Két okból. Először is, az interruptot olyan rövidre kell írni, amennyire csak lehet. Másodszor, mert a millis() függvény interrupton belül nem működik (bár olvasni tudod, de nem számolja az időt, mert az is megszakítással működik) és ez rejtett hibához, pontatlansághoz vezethet.
A számításnál szerintem mozgóátlagot kéne számolni mert így elég hektikus lesz a mutató mozgása.
-
válasz
Tomika86
#15534
üzenetére
Én mindenképp a négyszög jelet választanám, digitális bemenetre, és megszakítással számolnám belőle a sebességet. Szerintem teljesen felesleges még egy plusz eszközt közé iktatni, ráadásul az analóg bemenet elég zaj és egyéb zavar érzékeny, és nem is biztos, hogy elég lenne a felbontása a pontos méréshez.
-
Janos250
őstag
válasz
Tomika86
#15524
üzenetére
Ha több if van, mindenképp végigvizsgálja az összeset. Ha if-else , akkor ha egyet megtalált jónak, nem vizsgál tovább. Ha egész, vagy sorszámozható típus alapján válogatsz, a case áttekinthetőbbé teszi a programod. Et az if-elsek sorozata tulajdonképp, ha van benne break, if-ek sorozata egyébként.
-
Janos250
őstag
válasz
Tomika86
#15518
üzenetére
Ahogy ekkold is írta, szerintem is az spintf rá az egyik legjobb megoldás, mert akkor teljes formátumot is adhatsz.
https://www.cplusplus.com/reference/cstdio/sprintf/
Ez egy jó konverziós függvény, tanuld meg a használatát! -
And
veterán
válasz
Tomika86
#15497
üzenetére
Én így csináltam régebben (nem Nextion mellé, ott az Arduino vezérelte a sokkal egyszerűbb kijelzőt, és egy 'master' kontroller felől kapta az adatokat, de ez lényegtelen):
char msg[64];char term = 0xFE;bool firstc = true;void loop() {if (Serial.available() > 0) {uint8_t msgl = Serial.readBytesUntil(term, msg, 64);if (firstc) {oled.clear();firstc = false; }switch (msg[0]) {case 0:page0();break;case 1:page_IRlearn();break;// ...}}}Az is kiderült, hogy jobban járok, ha a teljes vételi 64 byte-os pufferméretet megadom neki, mert különben néha hibázik.
-
And
veterán
válasz
Tomika86
#15495
üzenetére
Többféle lehetőséged is van, de mind kerülőutas. Az első, amit a #15224-ben volt említve (temp változós megoldás). A másik, hogy a numerikus pad bekapcsolása létrehoz egy zárolt képernyőt keybdB néven, ezt unlock-kal felnyitod, és az "OK" gomb megnyomásához írsz egy rövid szkriptet, ami elküld valamit. Ennek hátránya, hogy globális, vagyis ha több numpad-ot is leteszel, mindegyikre érvényes lesz.
-
And
veterán
válasz
Tomika86
#15246
üzenetére
Azt lenne jó látni (pl. egy terminálprogrammal), hogy mennyi adatot küld valósan ilyenkor az MCU. Nem tudom, mennyi attribútumot lehet megadni egy Xfloat-hoz, de jó sok van neki, és ha több ilyet egyenkénti parancsként leküld az arduino, akkor bizony egy valag töltelékadat lesz a kommunikációban. Mondjuk a Text-nek is van elég tulajdonsága, bár nem annyi, mint az Xfloat-nak.
A nyers adatként szükséges 1..2 byte-hoz képest minden más módszer terjengős. -
And
veterán
válasz
Tomika86
#15239
üzenetére
Ezt perpillanat csak te tudhatod. Natív adatmennyiségben a komplett képernyőn megjelenő input információ akár 16..18 byte-on is továbbítható. Hogy a lebegőpontos értékeket miért továbbítod text-ként, azt nem teljesen értem, de szerintem felesleges. Xfloat-ként (vagy akár szimplán ponttal elválasztott, byte-méretű értékpárokként) mondjuk 1..2 byte adattal megúszható lenne egy-egy ilyen mező. Ha a hagyományos módon, egyenkénti értékadással, parancsonként továbbítasz ennyi adatot, akkor a korábbi példa alapján az egyszeri frissítéshez is az említett hasznos adat minimum 8..10-szeresét kell karakterként a HMI-be küldeni, ami nagyságrendileg 150..180 byte. Az adatokat másodpercenként pl. 10x frissítve ez már bő másfél kilobyte, bár valószínűleg a számértékeket tartalmazó mezők frissítéséhez ez a ráta túl sok, a mutatós műszerekhez pedig esetleg kevés (bár itt már képbe jönnek a hardveres képességek, illetve hogy pontosan milyen módon animálod a mutatókat).
Én ezt úgy oldanám meg, hogy a szükséges frissítési gyakoriságok okán kétféle - egyenként fix hosszúságú - adatcsomagot küldenék az MCU felől, a HMI-t pedig protocol reparse-ba állítanám: az egyik típusú, ritkábban küldött csomagban lennének a numerikus mezők értékei pl. 16 byte-on (két bevezető + 7*2 byte), a másik, sűrűbben frissített csomagban pedig a mutatóké, mondjuk 6 vagy 8 byte-on.
Azt mindenképpen ki kell majd tapasztalnod (és nem a debugger-ben, hanem a valós kijelzőn!), hogy milyen frissítésnek van egyáltalán értelme a mutatós műszereknél, mert ez nagyon hardver- és megoldásfüggő. De ha jól csinálod, semmiképp nem a szükséges adatmennyiség vagy az átviteli sebesség fogja korlátozni a megjelenítést, mert másodpercenként erre 2-300 byte elég lehet, a 115.2 kbps-es portsebesség pedig adatkerettel együtt 11 kbyte/s hasznos átvitelt adhat. -
And
veterán
válasz
Tomika86
#15236
üzenetére
Amúgy nem tudom, milyen mennyiségben és mekkora periódussal küldöd be az adatokat, de ha a hagyományos módban elég sok változót adsz a HMI-nek folyamatosan, nagy bitrátával, és nem hagysz elég időt a belső feldolgozásra, akkor biztosan ki lehet akasztani az 1kB-os puffert (parancs + adat + lezárás).
A reparse mode ezen úgy segít, hogy nem kell komplett parancsokat vagy értékadásokat a hagyományos módon beküldened, elegendő csak magát az értéket. Például: az "n0.val=123" parancs a lezárással együtt 13 byte hosszú, protocol reparse módban pedig egyetlen byte-on elküldhető az érték, amit egy script képes a megfelelő helyre / változóba tenni. De még nagyobb értéktartomány esetén sem lesz 2..4 byte-nál hosszabb az üzenet. Mivel ilyenkor adatokat küldesz, nem parancsokat, a visszirányú forgalom (HMI válaszüzenetek száma) is minimalizálható. -
And
veterán
válasz
Tomika86
#15233
üzenetére
A Nextion felől visszaküldött üzeneteket bizonyos szintig be tudod állítani a bkcmd nevű belső változóval. Ha nullára állítod (default értéke: 2), az invalid variables üzenet elvileg nem jön többé, de a buffer overflow továbbra is megmarad. Ennek oka van, bár korábban szerintem már volt erről szó, hogy a debugger ilyen jellegű, soros átvitellel kapcsolatos szimulációja elég sok kívánnivalót hagy maga után. Vagyis a jelenség nem is feltétlenül valós. Azt is említettem, hogy a protocol reparse mode aktiválásával egy csomó probléma kiküszöbölhető, a rendkívül terjengős eredeti adatmennyiség a töredékére csökkenthető, cserébe neked kell a vételi pufferből kiszedni és a kívánt adatformátumra gyúrni a HMI-be beeső adatokat ( u[index] vételi tömb illetve ucopy függvény segítségével).
-
And
veterán
válasz
Tomika86
#15222
üzenetére
Ennek a kivitelezése szerintem nem arduino-specifikus. Ha nincs egy 'send', 'ok' vagy hasonló gomb a kijelzőn, ami az értéket elküldené az MCU-nak, akkor szerintem kerülőúton juttathatod be a változót, például:
- rendszeresen, adott időközönként kiolvasod az értékét az MCU-val (get x0.val), vagy
- ugyanezt megteszi a HMI, timer-eseménnyel ciklikusan adatot küld az MCU felé (prints x0.val.0), vagy
- mint az előbb, de a timer event-hez felhasználsz egy temp változót, aminek csak az a feladata, hogy összehasonlítsa az előző értéket az aktuálissal, és ha utóbbi megváltozik, elküldi a beviteli mező értékét (a lényeg, hogy csak egyszer küldje, ne folyamatosan).
Arra ügyelni kell, hogy - mivel a HMI nem ismeri a natív float típust - "Xfloat" mezőből is mindig integer értéket kapsz, ilyen bevitt értéknél a tizedespont helyét és ezzel a kapott szám értelmezését az Xfloat-mező ws0 és ws1 attribútumai adják meg. -
Tomika86
senior tag
válasz
Tomika86
#15183
üzenetére
Mit jelentenek a következők:
-String indata = Serial.readStringUntil('#');Addig olvas amíg '#' karakter nem érkezik?
-if (indata.indexOf("on") > -1)Itt gondolom Ha a beérkezett string az on, mi a > -1 ?
- illetve az utolsó kettő sor érdekelnebyte position_ = indata.indexOf("start");timeValue = indata.substring(0, position_).toInt();// Soros porton érkező adat figyelése ha sorosport elérhetőif (Serial.available()){String indata = Serial.readStringUntil('#');// Ha "on" string érkezikif (indata.indexOf("on") > -1){digitalWrite(output_pin, HIGH); // Kimenet bekapcsolása}// Ha "off" string érkezikelse if (indata.indexOf("off") > -1){digitalWrite(output_pin, LOW); // Kimenet kikapcsolása}// Ha "start" string érkezikelse if (indata.indexOf("start") > -1){byte position_ = indata.indexOf("start");timeValue = indata.substring(0, position_).toInt();}}Köszönöm!
-
Janos250
őstag
válasz
Tomika86
#15180
üzenetére
Kirészletezve:
ESP321 SPI vonalai összekötve a 13.56 MHz-es olvasó megfelelő lábaival, közben a madzagok "megcsapolva", hogy a SALEAE digitális analizátoron lássam a forgalmat. SALEAE is, és ESP is USB-n gépbe.
Adafruit programját feltöltve az ESP32-be, rendesen működik. Kikapcsolás nélkül feltöltök az ESP32-re egy programot, ami az ESP saját SPI hardverjét használja. Szintén működik.
Kikapcsolás után ugyanez a program nem működik, úgy, mintha az Adafruit valamit átállított volna a slaven. Viszont digitális analizátoron nézve, az Adafruit, és a saját UGYANAZOKAT a jeleket küldi, ugyanolyan időzítéssel. Mi a fenét kellene még vizsgálni, hogy kiderüljön, mi állítódik át az Adafruit hatására, hogy utána a kikapcsolásig működik a másikkal is. -
Janos250
őstag
válasz
Tomika86
#15177
üzenetére
Valaki használta már ESP32-n a saját SPI-vel valamilyen 13.56 MHz-es olvasót? Van két olvasóm. Az egyikbe eddig nem sikerült életet lehelni, de a másik hibamentesen működik az Adafruit programjával, viszont ESP32-n vannak gondok. Saleae-n nézve PONTOSAN ugyanazt küldöm ki, időzítések is pont ugyanazok, mégsem tudja olvasni. Érdekes, hogy ha előtte az Adafruit programmal olvastam, akkor jó az ESP SPI driverrel is, de áramtalanítás után már nem. Tanácstalan vagyok. Mit lehet még nézni, ha az analizátor ugyanazt mutatja?
-
WinZol
aktív tag
válasz
Tomika86
#15112
üzenetére
Hi,
Szauna vezérléshez akarok Nextion 4,3-as kijelzőt venni.
Itead.ccHonnan érdemes beszerezni?
Van Magyarországon forgalmazó? (Akkor céges beszerzés)
Ha Kína, akkor honnan / hogyan megy áfa mentesen? (Akkor nem céges)
(nem szeretnék clone-t venni) és jó lenne néhány héten belül átvenni.Mennyire éri meg a Capacitive? (+ 7 USD)
Köszi
WinZol
-
gyapo11
őstag
válasz
Tomika86
#15162
üzenetére
Egyszer csináltam hasonlót, csak nem arduino volt hanem pc, és nem c hanem assembly. Pénztárgép fekete doboza volt, epromba írt. Már nem tudom mi volt az elválasztó jel, de valami olyan, ami biztosan nincs a kiírt adatokban. Ha csak számokat vagy betűket írsz ki, akkor jó a % vagy # meg ilyenek. Én nem használtam pointert, hanem bekapcsoláskor addig olvastam az epromot, míg az utolsó elválasztójelet megtaláltam, ez után jöhetett a következő írás. Így akármilyen változó hosszúságú adatot írhatsz, az elválasztójel egyértelműen meghatározza, hogy hol a vége és a következőnek az eleje. Ez egyben a wear levelinget is megoldja, mert teleírod az összes byte-ot, utána persze törölni kell, ha akarsz bele írni.
-
válasz
Tomika86
#15162
üzenetére
A PLC-ről sajnos csak annyit tudok, hogy létezik.
csak szeretem megérteni amit csinálok
Teljesen jogos igény.
Wear leveling az lenne mint ssd esetében, hogy összevissza rakja az adatokat?
Nem összevissza, hanem sorban, egymás után, mivel itt mindig szekvenciálisan írsz, és nem kell random törölni adatot a sorból.
-
válasz
Tomika86
#15159
üzenetére
A double az is lebegőpontos érték, ráadásul mega board-on ugyanúgy 32bites, mint a float. Szerintem te az int vagy long típust keresed.
Mi az, hogy nem működik?
Légyszi, ha kódot illesztesz be, válts át a régi szerkesztőre (a szövegbox fölött jobbra), mert ott olvasható lesz a kód, az új szerkesztő szétbarmolja az egészet...
-
válasz
Tomika86
#15157
üzenetére
Nem kell a mutatókkal törődnöd, ez a függvény belügye.
Én a mai napig nem igazán értem a mutatókat, mindig elolvasom, megértem, aztán két nap, és totál elfelejtem az egészet.
Ha átállsz erre a megoldásra, és eldőlt, hogy milyen adatokat szeretnél menteni még az EEPROM-ba, akkor javaslom, hogy implementálj némi wear levelinget is. Ha aktuális, és érdekel, akkor leírom a módját.
-
válasz
Tomika86
#15154
üzenetére
Használd azt a két függvényt, amit korábban javasoltam. Az mindig 4byte-ot fog írni.
Ha külön 7805 lesz a kijelzőnek, az úgy jó, csak ne felejts el egy diódát tenni a pufferkondi elé, hogy a többi fogyasztó ne szívja le idő előtt a benne tárolt kraftot a másik irányból.
-
válasz
Tomika86
#15150
üzenetére
Ez jó kis feladat, kétféle megoldási javaslatom van, külön-külön vagy együtt is alkalmazható:
1. kikapcsoláskor szeretnél menteni, ezt úgy lehet megoldani, ha a tápfeszültség elvétele esetén pár másodpercig még működni tud. Ezt vagy egy akkumulátorral, vagy egy szuperkondenzátorral tudod megoldani. Az egyik pinnel figyeled a tápfeszültséget, mikor megszűnik, azonnal mented az adatokat.
2. wear levelinget alkalmazol az EEPROM-ba írásnál, erre van készen library, de egy nagyon egyszerű módszerrel házilag is meg lehet oldani. Ezek után tetszőleges gyakorisággal mented a menteni való adatokat, mert néhányszor 10 byte-nyi adatot 64kbyte területre kb. az idők végezetéig el lehet osztani. -
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. -
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;
} -
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). -
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) -
-
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. -
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.
-
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. -
-
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.
-
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). -
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.
-
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].
-
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.
-
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.
-
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ó. -
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. -
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! -
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. -
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.
-
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; -
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é.
-
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. -
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. -
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.
-
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ú.
-
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
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Thinkpad X230 legenda: i7 CPU, IPS kijelző, 12 GB, dupla SSD, magyar villbill, webcam, fingerprint
- Honor X6b 128GB Kártyafüggetlen 1Év Garanciával
- Apple Watch SE2 / 44mm / Midnight / Black Sport / Cellular (99%)
- Iphone 13 Pro Max 128 GB /// 86% Akku // Számlával és Garaniával
- Iphone 12 Pro Max 128 GB /// 88% Akku // Számlával és Garanciával
- Maximális teljesítmény és biztonság, csak az ARCTIC mx-4-el! Adj új erőt a gépednek!
- Honor 400 lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- Konzol felvásárlás!! Nintendo Switch
- KÖZEL FÉLÁR! Apple Magic Keyboard, Mouse, Trackpad, Pencil, Smart Magic Keyboard Folio, Watch szíjak
- AKCIÓ! HP Elitedesk 800 G1 USDT mini asztali számítógép - i7 4770S 16GB RAM 128GB SSD Intel HD
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged