Hirdetés
- Milyen processzort vegyek?
- Melyik hordozható audiolejátszót (DAP, MP3, stb.) vegyem?
- Egy vagy két tápkonnektor lesz az új csúcs-GeForce-on?
- Milyen billentyűzetet vegyek?
- Amlogic S905, S912 processzoros készülékek
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- SSD kibeszélő
- Kezdő fotósok digitális fényképei
- ZIDOO médialejátszók
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
Hirdetés
-
Greenwashing miatt támadják az olaszok a Sheint
it Olaszország vizsgálatot indított a Shein weboldal és app ellen, greenwashing vádjával.
-
Szivárvány
lo ...
-
Unknown 9: Awakening - Amit a játékról tudni érdemes
gp A PC-re és konzolokra szánt alkotás jövő hónap közepén érkezik.
-
PROHARDVER!
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
-
nagyúr
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. -
nagyúr
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.
[ Szerkesztve ]
-
nagyúr
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.
-
nagyúr
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...
[ Szerkesztve ]
-
nagyúr
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.
-
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.
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
-
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
-
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?
Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
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.[ Szerkesztve ]
Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
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 érkezik
if (indata.indexOf("on") > -1)
{
digitalWrite(output_pin, HIGH); // Kimenet bekapcsolása
}
// Ha "off" string érkezik
else if (indata.indexOf("off") > -1)
{
digitalWrite(output_pin, LOW); // Kimenet kikapcsolása
}
// Ha "start" string érkezik
else if (indata.indexOf("start") > -1)
{
byte position_ = indata.indexOf("start");
timeValue = indata.substring(0, position_).toInt();
}
}
Köszönöm!
[ Szerkesztve ]
-
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. -
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 #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ó.[ Szerkesztve ]
-
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 #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 #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 #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.
[ Szerkesztve ]
-
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!Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
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.
Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
nagyúr
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.
-
nagyúr
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. -
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.....
[ Szerkesztve ]
Release the Beast....
-
nagyúr
válasz Tomika86 #15545 üzenetére
Aztán túlcsordul 0-ra, akkor két fordulatnyit hibázni fog, mert csak 2-től számol a kód. Ilyenkor meg fog lódulni a mutató, és pl. 1000-es fordulatnál 333-at fog mutatni egy pillanatra.
Minden számítás után nullázni kell ezt a számlálót, és nem lesz gond. Mármint ha a másodpercenkénti impulzusok számából számolsz.Azthittem az impulzusok közötti időből lehet pontosabban számolni.
Mondom, ez a fordulatszámtól/periódusidőtől függ. Kis fordulatszámnál (pl. 0-100 közt) talán érdemesebb/pontosabb az impulzusok közötti időből számolni. De itt az is számít, hogy a loopban könnyebb az impulzusokat számolni meg az adatokat átlagolni, mint az interrupton belül pl. tömbbe menteni a periódusidőket, az átlagoláshoz. Átlagot pedig muszáj számolni (oversampling), ha nem szeretnéd, hogy darabosan közlekedjen a mutató.
[ Szerkesztve ]
Új hozzászólás Aktív témák
Hirdetés
- Gigabyte Ryzen Gaming PC: RTX 2060 Super 8Gb / 16Gb Ram / 512Gb SSD
- LENOVO LEGION GO 83E10032HV + INGYEN futár
- HP Pavilion x360 14-dy Érintős hajtogatós Laptop Tab 14" -50% i5-1135G7 16/512 FHD IPS
- Bomba ár! Dell Latitude 5501 - i7-9850H I 32GB I 512SSD I Nvidia I 15,6" FHD Touch I Cam I W11 I Gar
- Bomba ár! Lenovo ThinkPad Yoga 370 - i5-G7 I 8GB I 256SSD I 13,3" FHD Touch I W10 I Cam I Gari!
- MSI GeForce RTX 2060 VENTUS GP OC 6GB GDDR6 192bit (2025.04.07-ig garancia)
- LG UltraWide 34WN700-B 34" WQHD 2K (3440x1440) IPS 75HZ FreeSync Monitor
- HP EliteDesk 800 G1 TWR, i7-4790 3.6GHz, 24Gb RAM, GeForce GTX 1050 Ti 4Gb, Samsung SSD 250Gb
- Pc minimal film, zene
- Destiny 2 Shadowkeep/Beyond Light/Forsaken Pack/SW-Outlaws
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen