Köszönöm a választ. Amit lehet, próbálok VS guiból megoldani, és amiket írtál (parancsokat) szépen meg is tudom oldani pár kattintással. A fogalmakat lehet, hogy keverem, de ha jól értem a "branch" gyakorlatilag egy verziót jelent. Addig nincs is probléma, amíg választok a branch-ek között, simán tudok ide-oda lépkedni, de ha átírok valamit, hiába csinálok akármit (saját branch, mentés, commit...), az általam módosított fájlokra nem tudok semmilyen "trükkel" verzió összehasonlítást kierőszakolni. Lehet, hogy nem is lehet, de te is említettél valami "conflict"-os dolgot. Az ok, hogy kimásolom, meg összehasonlítom a két konfigfájlt soronként, de én azt szeretném, hogy ha kijön egy új verzió, akkor valahogy jelezze, hogy az általam mentett "branch" és az új fájl között milyen módosítás történt.
megmondja, milyen fileokban valtoztattal valamit, milyen branchen vagy
git add .
git commit -m"ezek az en valtoztatasaim"
elmenti egy commitba a valtoztatasaidat
git pull
rahuzza a tavoli valtozasokat a te cuccodra. ha ugyanabban a fileban te is modositottal, megprobalja osszefesulni. ha ez nem sikerul neki, kozli hogy conflict van, oldd meg, es utanna commitol. ez a commit a conflict fix lesz csak. innentol azert zold oves a dolog, egyelore jobb, ha nincs ra szukseg.
ha lesznek conflictjaid, akkor valassz youtuberol valamilyen gui cuccot, amiben atlathato hogy mi tortenik, aprankent at lehet latni a dolgot.
Nem annyira programozás, de kéne kis segítség mert valahogy nem igazán jön össze semmi. Végre rávettem magam, hogy áttérjek PlatformIO-ra. VSCode alá raktam. Az már jó, hogy lényegében nem kell küzdeni az ablakokkal és sokkal használhatóbb a szerkesztő, de szeretném akkor már a Git-et is használni. Addig OK, hogy klónozom, betöltöm, lefordul, minden fasza, de ha módosítás után akarok újabb repót felrakni, akkor a módosítások matt nem engedi, amíg vissza nem állítom a fájlt. Hogy kell ezt szakszerűen csinálni. Pl. ha nem akarok mindig új Tasmota konfigot csinálni.
Segítséget kérek ESP-12E (LoLin) - Arduino IDE használatában.
Egyszerűen nem tudom az ESP minden lábát beazonosítani és írni-olvasni. Valami más mindig van egyes lábakon (D5, D6, D7, D8), ezeknek nem lehet megmondani, hogy csak egyszerű digitális lábként akarom használni?
Az A0 láb csak analog olvasásra használható, vagy ez is lehet digitális ki-be menet?
Az S3, S2 lábbal sem tudok mit kezdeni.
Amit szeretnék használni:
I2C bus : ez megy a D1-D2 lábon, IDE 4, 5 PIN (ez OK)
DS18B20 (One Wire BUS): ez menne a D4 lábra, IDE 2 PIN
Attól függ, milyen. Adatlapját meg kell nézni. A legtöbb IR cucc simán elmegy alacsonyabb terheléssel is, de ahhoz, hogy több méterről be tudd szórni, nem biztos, hogy elég. Adatlap. Aztán mérések. Sok.
Sziasztok! Segítséget kérnék. Elég sok mindent (szerteágazó témában) oldottam már meg Arduval, különböző kártyákat használva.
Most egy egyszerű IR adót kéne csinálnom egy Roomba porszívó indítására. Megvan az IR Libary, a kapcsolást is összeraktam furatos deszkán, viszont az IR mintha nem kelne életre. Kicserélve az infra led-et normálra látom a villogást, de az ir-led használatakor a telefonos kamera (mert így gondolom minden esetben látnom kéne) sem reagál. (Ardu, IR led + előtétellenállás) ha itt indulna, utána kapna egy RTC-t az időzítéshez. IR adót korábban is próbáltam, volt, hogy összejött, (univerzális) volt, hogy nem, és nem értem, mi a fránya rigolya ezeknél. Nem szokott gond lenni a kapcsolásokkal amit építek.
LEHET, hogy IR led használatánál kevés a táp, amit az USB ad le, és meg kéne próbálnom külső táppal vezérelni? NEM tudok tesztelni, panelem több van otthon, meg kéne építsek egy vevőt, amivel megnézem, hogy villognak-e egyáltalán?
A jelenlegi kapcsolásban nincs erősítés, egy 2N222-t próbáltam, valami szösszenet lehetett, mert bekapcsolt a robot, de nem indult el, pedig a CLEAN parancs (136) megy ki a programból. Minden ötlet segít, kérem, ha valakinek van bármi elképzelése, hogy miért nem megy, (ma megpróbálom egy samsung vagy pana tv-vel) az súgjon!
Sketch uses 924 bytes (2%) of program storage space. Maximum is 32256 bytes. Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes. /home/$USER/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude -C/home/$USER/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:/tmp/arduino_build_448742/Blink.ino.hex:i
avrdude: Version 6.3-20190619 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "/home/$USER/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf" User configuration file is "/home/$USER/.avrduderc" User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyACM0 Using Programmer : arduino Overriding Baud Rate : 115200 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00 avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
Az elmúlt 7 évben személyesen szívtam végig az "Minden Arduino -> Saját hardver + Arduino környezet -> Saját hardver + Arduino alapú firmware + Atmel Studio debug -> Saját hardver + Atmel AVR, de Arduino nélkül + Atmel Studio debug -> LPC1768 + mbed + Eclipse -> STM32 + mbed -> STM32 + STMCube + HAL" utat.
Nem akarok még egyszer kis lábszámú AVR-t debuggolni. Nem, nem. Se Ardunino projektet importálni Atmel Studio alá. Se éveken át javítgatni az Arduino alapból elcseszett dolgait.
- A 8 lábú 8 MHz és a BGA-324 700 MHz is ugyanazon logika mentén épüljön fel, ugyanazokkal az eszközökkel lehessen rájuk fejleszteni, debuggolni, és a lehető legtöbb kód lehessen közös. A legdrágább erőforrás ugyanis a programozó ideje.
És ez most már igaz a legkisebb projektjeimre is. Amikor 1 dollár egy ATTiny85, és 1.3 egy 8 lábú STM32G0, akkor az 1000 db / év alatti sorozatoknál simán megéri az utóbbit választani. Mert 300 dollár lesz a különbség, ami 90 ezer forint. Egy beosztott mérnök két napra kerül ennyibe. Ha pedig hobbi, akkor még drágább az idő. Ott 10 darab esetén van 3 dollár különbség. És szívjak szórakozás helyett? :-)
Szeretem, ha homogén a komponens lista. Elég egy gyártó nyűgjeit kiismerni, és fejben tartani. :-)
Nem, ipari fejlesztési környezetben semmiképp. Ott is az van, hogy ha nagyon gyorsan kell valami, az még nem indok arra, hogy szarból építkezzenek. Gondolj bele, mi van, ha az első go/no-go teszt úgy fut le, hogy bukik a projekt, később pedig kiderül (már túl későn), hogy a probléma nem a koncepcióval volt, hanem azzal, hogy valaki, valahol egy arduino könyvtárat szarul csinált meg.
Másfelől. Egy ipari fejlesztőkörnyezet logikája és szabadságfoka nem említhető egy lapon az Arduinoéval. Erről kár vitát nyitni. Az a mérnök, aki évek óta dolgozik fejlesztőként, ismeri a saját eszközeit, és nem fog csak azért egy totál új környezetbe beletanulni, hogy a egy PoC (igen, proof of concept) projektet végigtoljon. „a katalógus adatok nem mindig adnak kellő információt” -- Ez sajnos semmilyen megközelítésben nem áll meg. Elvétve és viszonylag jól dokumentáltan [Errata] jelenik csak meg valami hiba egy-egy normálisan összerakott fejlesztői eszközön. Akár ha kínában készül, akár nem. Az STM mikrokontrollerei egy részénél például hardveresen van elbaltázva az i2c implementáció. Az összes fejlesztőeszköz is érintett, szívnak is vele, akik úgy akarják használni, ahogy nem lehet (máshogy lehet, de szar). Az ESP8266 igen rossz példa. A legolcsóbb wifis modul, de amit tud, hááát... Borzalom. Nincs normális fejlesztői környezete (egyáltalán), a gyári támogatás annyira bugos, hogy hetek kellettek ahhoz, hogy egyáltalán éleszteni tudjam (nem perifériaként, önálló mikrokontrollerként). És az Arduinoból nincs átjárás a profi világba. Sehogy. A nem annyira jó, de működő IoT rapid prototyping platform, az mbed.org. A WiFi fejlesztéshez van három féle modul. Ezt úgy tudod használni, hogy teljes, működő könyvtárrendszere van mindegyiknek, egészen elfogadható dokumentációval (a hardveres oldalról mindenképp). Ezeket a modulokat pedig 1:1-ben tudod a production vázisba implementálni úgy, hogy nagyüzemi gyártásba mehet a cucc. Tehát ha breadbordon működik, akkor csak a körítést kell hozzátervezned a nyákra, a többi csak forrszemek (és elhelyezés) kérdése. Ha van otthon ilyen fejlesztőpaneled (nyilván dugpaneles változat), kb. ugyanolyan hatékonysággal tudsz köré elektronikát rittyenteni, mint Arduinoban. Csak ez működni fog.
Én nem találkoztam még beágyazott fejlesztővel (mérnökkel meg pláne), aki képes volt akár csak érintőlegesen komolyan gondolni az Arduino-t. A legközelebbi, amivel találkoztam, az RPi-volt, amihez moduláris hardveres fejlesztői csomagot fejlesztett egy barátom (BME mérnök, már akkor mikrokontrollerekkel foglalkozott, amikor a nagyközönség még a mikrohullámú sütöt és az internetet is jobbára csak hírből ismerte). Csak mellékszál, de engem is kerestek meg fejlesztési igénnyel, hogy "ez a hardverszett van, ebből kell ezt csinálni". És volt némi hiszti, amikor azt mondtam, hogy alkalmatlan rá és kb. a háromnegyedét másikra kell cserélni.
Azért nagyon köszönöm a tájékoztatást :) Én eddig úgy tudtam hogy tudok UNO-val egymástól függetlenül vezérelni akár 4db szervót.
Még nagyon nem tudok semmit és éppen ezért nem is értem hogy miért adódnak össze a sebességek itt? Szeretném ha egy időben tudnék külön parancsokat adni. Tud valaki segíteni?
void loop() { // scan from 0 to 180 degrees for(angle = 10; angle < 50; angle++) // szervo szog le tol ig { servo8.write(angle); delay(20); // szervo8 sebessége - } { // scan from 0 to 180 degrees for(angle = 10; angle < 50; angle++) // szervo szog le tol ig
servo9.write(angle); delay(20); }
// now scan back from 180 to 0 degrees for(angle =50; angle >10; angle--) // szervo szog fel tol ig { servo8.write(angle); delay(2); // szervo8 sebessége +
} // now scan back from 180 to 0 degrees for(angle =90; angle >20; angle--) // szervo szog fel tol ig {
Kicsit elvetitek a sulykot, úgy érzem. Nem kell messzire elkerülni az Arduino-t - állítólag nem vagyok teljesen kezdő fejlesztő - hiszen pont leírtad, hogy mi az az előny, ami miatt értékelhető, akár ipari fejlesztő környezetben is :) Az, hogy pillanatok alatt össze tudsz dobni egy deszkamodellt, és a használni kívánt áramkör sajátosságait ki tudod tesztelni, a komolyabb rendszer működésének kockáztatása nélkül. Erre viszont szükség is van, mert a katalógus adatok nem mindig adnak kellő információt - vagy nem mindig érthető, amit közölni kívánnak. Nos, ekkor igencsak jól jön egy olcsó, működőképes 'csavarhúzó' ! ( A PoC rövidítés a Proof Of Concept lenne ? ) Szerintem megvan a helye minden ilyen eszköznek, és pl. én szívesebben dolgozom a kőbaltás Arduino környezetben pl. egy ESP8266-tal, mint bármi mással, pontosan a kőbaltás jellege miatt. Megy a leggagyibb, 19 éves Notebook-omon ugyanúgy, mint a sokkal korszerűbb darabokon - talán ez sem elhanyagolható szempont. Igaz, a MicroChip általam használt fejlesztő környezete is ment az említett őskövületen :)
Egy apróság: nagyon régen, talán az EOS 300D fórumon találkoztunk először, és örömmel látom, hogy újra találkoztak útjaink :)
Kissé árnyalnám a képet, mert ez cseppet a ló túlsó oldala.
Egy mikrokontroller kártya. Eredetileg Atmel AVR 8 bites, ma már sokféle mikrokontrollerrel szerelt hobbi fejlesztőeszköz.
Az Arduino soha nem volt egyetlen hardver eszközre korlátozva. Minden esetben a teljes fejlesztői környezet + hardver + tömeg viszonylatot használták rá. Persze a tömeg a kezdetek kezdetén nem volt meg, de ettől még úgy gondolták, hogy egy oktatási platformra előbb-utóbb gyűlni fognak.
Pont az ilyen félreértések elkerülése végett szoktam mondani, hogy az Arduino egy keretrendszer, amit oktatási és hobbista szempontok figyelembe vételével raktak össze. Az, hogy ez mennyire sikerült (részben jól), már más kérdés.
> Tulajdonképpen jelentős szerepe van az Arduinonak abban, hogy manapság minden gyártónak van kimondottan olcsó, debuggerrel összeépített fejlesztőpanelje.
Igen. De ennek a hátterében nem az volt az elsődleges szempont, hogy n+1 hobbi felhasználót eszközzel (és esetleg hardverrel) szolgáljanak ki, mert e tekintetben elég nehéz lenne versenyezni a kínai gyártók tömegtermékeivel (hobbi körökben ugyebár az ár elég fontos szempont), hanem az, hogy egy működő modell volt. PoC szintű rapid prototyping viszont, a néhol kompromisszumos, mégis többé-kevésbé működő gyári könyvtárakkal brutálisan lecsökkentette egy-egy fejlesztést megelőző nulladik körök fejlesztési költségeit. És nem azért, mert a kártya olcsó volt (a fejlesztésben soha nem a kártya a legdrágább), hanem azért, mert az adott fejlesztési fázisban nélkülözhetetlen tesztek elvégzéséig töredék mérnöki munkaórát kellett beáldozni. Aztán nyilván a második-harmadik go/no-go pont után az egész prototípust kódostul, mindenestül kidobták a kukába és nulláról, a célnak és ipari sztenderdeknek megfelelően újraépítették az egészet. De ezt már úgy, hogy elvileg termék lesz belőle, és nem csak egy PoC. 10-15 PoC eddigi költségéből 9-14-et így meg tudtak spórolni.
> Választanék mikrokontrollert, és vásárolnék hozzá debuggert. Egy Atmel ICE jelenleg 15 ezer, egy ST Link pedig kb a fele. A legtöbb komoly, debuggert is támogató IDE mostmár képes Arduino projekteket is kezelni.
Igen. Mert te kb. képben vagy. De egy átlagos hobbista (pláne tanuló) nem a normális utat fogja választani (vagyis nem az adott célnak megfelelő hardvert fogja kiválasztani a -- mondjuk -- kb. 100 fejlesztői panelt tartalmazó ST Nucleo sorozatból), hanem a gombhoz keres kabátot, mert mondjuk tetszik neki, hogy mennyire rengeteg mindent tud és milyen rohadt olcsó --mondjuk -- az ESP32. Az, hogy az adott célra van sokkal jobb eszköz is, számára nem szempont. És ha már programozni kell, hát ott a jó öreg „Arduino”, mert ahhoz minden van.
Én mostanában két forgatókönyvet ajánlok. 1. Ha valaki hobbizni akar és esze ágában sincs soha, semmilyen formában profiként foglalkozni az üggyel, akkor Arduino / mbed / micro:bit. Arduinoban Nano elsősorban, ha az kevés, akkor Mega2560. Ha az is kevés, akkor inkább valami komolyabb cucc (Nucleo).
2. Ha valaha bárki is tovább akar lépni a hobbista létből, akkor mbed kezdésnek (bár elképesztően szar egy ideje), de még inkább egy jobb/erősebb IDE a választott gyártótól (ez lehet tőlem Atmel, illetve ugye Microchip is, ez a szíve joga). De az Arduino-t olyan messzire kerülje el, ahogy csak tudja (még úgy is, hogy sajnos vírusként portolják a szarabbnál szarabb arduino könyvtárakat minden létező on- és off-line IDE alá.
A kezdők kedvéért összefoglalom, hogy mi nem az Arduino. :-)
Nem mikrokontroller.
Nem programozási nyelv.
Nem professzionális fejlesztőeszköz.
Akkor mi az Arduino?
Egy mikrokontroller kártya. Eredetileg Atmel AVR 8 bites, ma már sokféle mikrokontrollerrel szerelt hobbi fejlesztőeszköz.
Egy nagyon buta IDE. (Integrált fejlesztőeszköz.) A Processing IDE-re épül. Arról is tudnék pár keresetlen szót írni...
Egy függvénykönyvtár. C++ nyelven írt, nem következetes, erőforrás pazarló, hülyéket megvédeni akaró, mégsem hülyebiztos. Példa: Egy kimenet írásakor MINDIG leellenőrzi, hogy nincs-e ott PWM, nem analóg bemenet-e, stb. Ez rengeteg idő.
Egy önsegítő közösség. Ahol a naiv kezdőtől a profiig mindenki osztja az észt. Válogasd ki belőle a használható tanácsokat. ;-)
Egy fejlesztő közösség. Ahol bárki írhat bármilyen elv alapján függvénykönyvtárakat, amiket aztán megoszt. Senki sem ellenőrzi a minőségüket, vagy az interfészük használhatóságát. Te letöltöd, és nem érted, miért nem működik. Rengeteg horror példa van. Például sok I2C eszközkezelő szoftver. A "könyvtár" úgy veszi, hogy rajta kívül senki más nincs a rendszerben. Tehát lefoglalja az I2C buszt, és busy waiting (delay) segítségével időzít... Semmi más nem fog mellette működni.
A különféle mikrokontroller gyártók általában komplett hardver, szoftver, fejlesztőeszköz, debugger megoldásokat dobnak piacra. Ezek jelenleg már olcsóbbak, és jobbak, mint az Arduino. Tíz évvel ezelőtt az Arduino pont a csóró hobbisták miatt hozott egy csomó, profiknak vállalhatatlan kompromisszumot. Aztán akkorára nőtt az egész népszerűsége, hogy a gyártóknak lépniük kellett. Tulajdonképpen jelentős szerepe van az Arduinonak abban, hogy manapság minden gyártónak van kimondottan olcsó, debuggerrel összeépített fejlesztőpanelje.
Példa: Egy eredeti Arduino UNO jelenleg 7-8 ezer forint. Egy ugyanilyen MCU-t használó ATMEGA328P-XMINI 3000 ft, és van rajta beépített debugger chip... Az ingyenes Atmel Studio IDE-vel lehet rá fejleszteni, minden perifériájához van C kód (AVR LibC), és lehet debuggert használni. De ugyanígy 3-4 ezer forint egy debuggerrel egybeépített STM32 Nucleo, ahol 32 MHz és 180 MHz közötti ARM mikrokontrollerből választhatsz. Az IDE és a HAL szintén ingyen van. De elérhető hozzá az Arduino függvénykönyvtár is.
Ha szeretnéd az Arduino szoftveres környezetének előnyeit élvezni, mint gyors fejlesztés, sok előre megírt könyvtár, akkor én ezt tenném:
Választanék mikrokontrollert, és vásárolnék hozzá debuggert. Egy Atmel ICE jelenleg 15 ezer, egy ST Link pedig kb a fele. A legtöbb komoly, debuggert is támogató IDE mostmár képes Arduino projekteket is kezelni.
Vállalkozó szellemű, intelligens Arduino-s személyt keresek aki tartana nekem egy rövid diskurzust. Személyesen vagy telefonon.
6v-8.4v RC szervó működtetésével és programozásával kapcsolatos infók érdekelnek. Hozzáértőnek nem túl bonyolult ám nekem még az, de tudom hogy idő pénz szóval beszéljük meg :) Nagyon köszönöm!
Arduino esetén az van, hogy ha fut egy adatküldés az eszközről a gép felé, akkor foglalt az USB/soros átalakító. Ha az IDE soros monitora figyel, akkor az IDE nem fogja engedni a küldést, hanem szól. Ha más alkalmazás figyeli (bármilyen soros terminál), akkor pedig hibára fog futni, mert nem azt kapja vissza a feltöltés inicializálásakor, amit kellene. Ha nincs figyelés (nem veszi semmi az adatokat a számítógép oldalán), akkor simán elindul a feltöltés.
Nem. Nincs op. rendszere. Van egy betöltője, ami adott szekvenciára elindul, és a soros porton fogadja a byte-okat, majd letárolja, végül egy Reset, és elindul a letöltött kód. Ehhez túl sok közöd nincs, legfeljebb, ha új boot loader-t akarsz írni :)
Értem. Szóval akkor a modul belső op. rendszere az USB portot megosztva használja az futó alkalmazás és az op. rendszer belső dolgai között, mert gondolom, hogy miközben fut az én programom (ami adott esetben használja a soros portot), továbbra is figyel arra, hogy a PC megszólítja-e egy újabb progi letöltése érdekében.
1. Semmi akadálya, de ki kell választanod az IDE-ben a kontroller típusát és az USB virtuális COM portját (minimum), amin megszólítod a kontrollert
2. Majdnem :) Az IDE szólítja meg a modult, mire az letöltés üzemmódba kerül.
3. Felesleges neked az USB porttal külön bajlódni, a Serial kezelő betöltése és inicializálása után a Serial.print(...) utasítással tudsz a PC-n elindított soros vonalat kezelő rutinnak ASC-ben adatot küldeni. Az IDE debug modulja pl. erre alkalmas, de ha bármely soros terminált használod , mind jó lehet.
Olvasgatom a hozzászólásokat, élvezem, hasznosak nekem is. Én még csak most ismerkedem az Arduino-val, bár sok évvel ezelőtt (kb. 20-25) uP-s fejlesztéseket én is csináltam, de ilyen Arduino-szerű rendszerek akkor még nem igazán voltak (max. az i8052AH BASIC környezet), azóta meg másfelé vitt az élet, a témával is felhagytam nagyjából, úgyhogy most egy kicsit elölről kell kezdeni az egészet. Nemrég jártam az egyik bécsi Conrad-ban, és hogy ne jöjjek el szuvenír nélkül, vettem egy Tesco-gazdaságos Arduino Nano-t (helyesebben egy C-Conrol Duino-t). Hogy mire fogom használni, arról még fogalmam sincs, de majd csak kitalálok valami értelmes feladatot a számára (elsősorban ismerkedési szándékkal vettem).
Az első alapvető kérdésem a következő lenne:
1. Rádugom a modult a PC-re, és elindítom az IDE-t
2. A modul folyamatosan figyeli az USB portját, hogy le akarok-e tölteni neki valami kódot?
3, Ezt azért kérdezem, mert ha a kód, amit rá akarok tölteni a modulra, szintén használná az USB portot (pl. a bemenő analóg portok értékeinek visszaküldése a PC-re), akkor az megoldható?
Az Arduino szintjén nem. Ott 99% humán. Jelentős rendszerekben van olyan szintű tesztautomatizálás, ami külső elemmel csinálja ugyanezt, de ott a külső elem is egy beágyazott rendszer (vagy egyedi vagy gyári), de az ellenőrzés alapelve nagy vonalakban ugyanez. Az IDE csak a szintaktikát ellenőrzi, illetve bizonyos fokú előre megírt protokoll alapján optimalizálja a gépi kódot. De ebből kb. semmit sem látsz (és a célnak megfelelően jól van ez így).
Mivel hobbiról van szó, a "házi kód policy" kb. az, amit magadnak kitalálsz. Elképesztően ritka, hogy valaki többedmagával dolgozzon Arduino platformon.
Amit leírtam lépésről lépésre, pont a unit teszt. Mert ez alá nincs értelme menni (sérül a funkcionalitás), feljebb pedig már nagyobb egység van. Alapvetően baromi hülyén van megcsinálva, de ez van, ha a gyári keretrendszert használod, akkor máshogy nem lehet. Illetve lehet, csak az máshogy szopás.
Sziasztok, nem is gondoltam, hogy akkor nalatok is vannak deploy elotti szintaktikai stilus, szemantikai automata ellenorzesek es human codereview a hazi code policy val ? Jol ertettem ?
Unit es funkcionalis etc tesztrendszerek amikben mock frameworkok biztositjak az izolalsagot es a modularitast ?
Tenyleg rosszul gondoltam, en totalisan el vagyok tevedve ...
Nem látom ennek értelmét így. Egy szál 328p-vel megoldható ez a feladat, az idő 99,9%-ában úgyis csak a változásfigyelés pörög. Ha nincs túlhúzva, az i2c és az spi is megy egymással gond nélkül, ha valaki nem akar egyidőben mindent megoldani. De itt a másodperc töredéke alatt futnak le a teljes adatküldések, így nincs jelentősége, ad abszurdum, másodperces frissítést is lehetne csinálni (nem lehet, mert a kijelző lassú). Ha képes lenne rá (keretrendszer hiányosság) én elküldeném deep sleep-be, oszt jónapot. Az einknek úgysem kell felügyelet.
Amit én csinálnék:
-- RTC kezelés. Minden adatot ki, manipulálás mindenféle formában, eredmények soros vonalon ki. Addig, amíg úgy nem fut, ahogy nekünk a legjobb.
-- eink kezelés. Ismert formátumú adatok kiküldése először kötött formátumban, utána változó adatként (léptetés, switch/case stb.), a végső feladat, hogy az rtc-ből kijövő formátum (nem a konkrét adat) menjen ki rá úgy, ahogy azt elképzeltük. -- eink második menet: frissítési gyakoriság változtatása állapotgéppel (gombnyomásra, fényerőre, eltelt időre, stb.).
-- kódoptimalizálás olyaténképpen, hogy az adott modul egy függvényben legyen, ha szükséges, paraméterhívással. Így is teszt.
-- aztán mehet az összegyúrás. A loop csak figyel, mint a korábbi példában is, állapotgépként, a többit csinálják a függvények.
Amíg egy modulteszt nem 100%-os az összes szóba jöhető állapotra, addig kell ütni, amíg nem lesz az. Utána lehet esetleg optimalizálni (de nem muszáj). A "majd megoldjuk a teljesben" NEM megoldás.
És verziótörténet végig, nyilván.
Ami az Arduino-t illeti. Pontosan, nem több, nem kevesebb. Csak ugye mindenki azzal kezd, hogy holdmodult, okosházat és motorszabályozó elektronikát akar építeni belőle. Pedig ezekre így pont teljesen alkalmatlan.
Az Arduino azért felkapott, mert arra, amire kitalálták, parádés. Másra a lehető legrosszabb.
Ahogy én látom, az Arduino egy kiváló terep : kicsit tüskés, így a nagy mellény gyorsan sérülhet :) Azt gondolom, hogy arra teljesen jó, hogy egy-egy részfeladatra deszakmodellt pillanatok alatt össze tudj dobni, a deszkamodell igazolja vagy elvesse a gondolatod megvalósíthatóságát. Pont a rögzítetlen játékszabályok és a perifériák sokfélesége adja az Arduino kiválóságát és egyben csapnivaló tulajdonság halmazát is. A sokféleség mellé igencsak elférne, hogy nem egyszerre sokfélét, hanem jellemzően külön-külön kötögetjük , illetve ha a rákötött perifériák pl. egy 'érzékelő, több relé' értelemben vett közel homogén együttest alkotnak, akkor semmi baj sincs (az esetek jelentős részében). Akkor kezd a derült ég sötétedni, ha több, real-time kezelést igénylő eszköz van egy procira kötve - erre csak nagyon korlátozottan alkalmas.
Visszatérve az eredeti problémára, az utóbbi mondat szerint:
- egy Arduinora kötött RTC (A porc.) , I2C-vel egy másikkal (B proc.) összekötve, amelyen rajta lóg a kijelző
- Az 'A' feladata az RTC kezelése, és időnkénti szinkron átküldése a 'B' felé (pl. 2 percenként). Az indításkor természetesen a pontos időt is átküldi.
- A 'B' feladata az aktuális idő nyilvántartása, és adott időnkénti kijelzőre írása. Az I2C buszon érkező csomagok fogadása, értelmezése.
Így kettétörtük az eddigi bonyolulttá vált feladatot, és két, egyszerűen kezelhető, az Arduino tervezési filozófiájának megfelelő taskot hoztunk létre. Ha ez korrekten megy, meg lehet próbálni konszolidálni, azaz, egy rendszerbe ültetni mindent, kivéve a második Arduino-t.
