Új hozzászólás Aktív témák

• #3354 gyapo11 őstag Teasüti #3351

  Új Válasz 2016-07-26 09:07:07 #3354

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  gyapo11

  őstag

  válasz Teasüti #3351 üzenetére

  Valójában a villogás nem a megfelelő szó, jobb az akadozás. Simán el tudom képzelni, hogy valaki megírja az animációt, valaki más a távirányító kezelését, és a kettőt összeeresztve akadozni kezd, mert pont akkor nyomok rá a távirányítóra, amikor léptetni kellene az animációt, és a processzor egyszerre csak egy dologgal tud foglalkozni, a szem meg érzékeny az akadozásra. Ilyenkor jön az, hogy meg kellene találni az okát, de ezt idegen kódban és nem profi programozási tudással elég nehéz. Ha meg profi a tudás, akkor nem kell netről vadászni a kódot, hanem meg kell írni az első byte-tól úgy, hogy az infrát is le tudja kezelni a legkisebb akadás nélkül.
  A megszakítás jó dolog, de nem tud csodát. Vagy az eredeti kód fut, vagy a megszakítást szolgálja ki, de addig az eredeti kód áll. Ahhoz több processzormag, közös memóriakezelés stb. kellene, hogy egy beérkező megszakítás ne állítsa meg az egyik magon futó kódot, és a másik magon azonnal futhasson a megszakítás.
  Egy távirányítóról érkező parancs kiszolgálása persze elég rövid idő, de ha nem jól van megírva a kód vagy a library, akkor akár látható nagyságú idő is elmehet, és gond van.
  Nem beszélünk konkrét számokról, mert ahhoz kellene a kód, és még akkor sem könnyű összeszámolni a szükséges órajel ciklusokat. Ehelyett ha írunk egy kis ciklust, az kb. 100 ezer/s, ha csinál is valamit, akkor legyen 10 ezer/s, ez 100 μs, ha pl. hangfrekis hullámformát generálunk, és egy megszakítás elvesz ennyi időt, akkor az már hallható lesz.
  Sokszor láttuk már itt a fórumon is, meg más forráskódokban is a delay(1)-et vagy hasonlót, mert különben elvesznek byte-ok a soros vagy egyéb csatornán. Pedig a processzor 16 MHz-en pörög, és az ehhez képest rettentő lassú soros porton is el tud veszni adat, ha nem állítjuk meg egy ms-ig a futást.
  Már egy ilyen kis processzorocska is annyi mindent csinál, hogy nem elemezzük órajel szinten. Ráadásul mi c++ forráskódódot látunk, de a processzorba egy ebből generált bináris kód megy, nem tudjuk, hogy melyik arduino utasításból milyen bináris kódot generál, így nem tudjuk az időigényeket se. Ráadásul ott vannak a libek, amiknek még a forráskódját se nézzük, hanem csak include-oljuk és reménykedünk benne, hogy működik és nem ütközik semmivel.
  Ezért mondom, hogy ez hobbyra van kitalálva, mert pillanatok alatt tud bárki működő programot futtatni. Amint bonyolódik a program, mindenféle korlátokba ütközünk, az időzítést is nehéz kézbentartani, a libek minősége ismeretlen, a szigorú tesztelése időigényes. Mindezek elkerülése meg oda vezet, hogy elhagyjuk az arduino hw-t és sw-t is, és magát a mikrovezérlőt programozzuk profi eszközzel, debuggal, teszteléssel.
  Vannak komoly házvezérlések, és egyéb bonyolultabb projectek, tehát sikerülhet a dolog, de erre nem lehet építeni, nem lehet megélhetést alapozni rá.

Új hozzászólás Aktív témák