Hirdetés
- OLED monitor topic
- Kompakt vízhűtés
- Milyen videókártyát?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- OLED TV topic
- Apple MacBook
- Jól áll az ARM-os Windows helyzete, de a játékoknál nem jön az áttörés
- Kormányok / autós szimulátorok topikja
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Fejhallgató erősítő és DAC topik
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
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
-
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.
Új hozzászólás Aktív témák
- Apple watch Series 9 45mm stainless steel 2026.12.12 .iSTYLE jótállás
- Apple watch Series 7 41mm stainless steel 41mm megkímélt kiváló akku
- Canon EOS 250D gépek, objektívekkel, kiegészítőkkel. (200 vagy 970 expoval)
- DJI FPV Fly More Combo drón szett +Motion Controller
- Samsung Galaxy A72 gyári független dual
- HIBÁTLAN iPhone 15 Pro Max 256GB White Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3006, 90% Akksi
- Bomba ár! Dell Latitude E7240 - i7-4GEN I 16GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
Állásajánlatok
Cég: FOTC
Város: Budapest