Az jutott eszembe, hogy a Maker-nek is van egy csomó könyve Arduino projektekről, illetve az Instructables.com-on is elérhető egy csomó olyan projekt, ami jó/hasznos/érdekes lehet. Mondjuk mindkettőben találtam már hibát, de ettől még működhetnek.
Tényleg mindent végigtúrtam a neten, a legtöbb megoldási javaslat arra vonatkozott, hogy a bootloader hibás és nem reseteli, ezért lehet próbálkozni azzal, hogy amikor megszólítja a - most már tudom - AVRDUDE akkor pont a megfelelő pillanatban nyomni egy resetet.
Én is attól féltem, hogy bootloader gond lesz, de kicsit megnéztem hogy mit csinál az arduino IDE és elkezdtem játszani a parancssori paraméterekkel.
A megoldás az volt, hogy a 115200-ról visszavettem a sebességet a felére, azóta csinálja mint a kisangyal és "örülünk Vincent" van :D
Mindenesetre köszi a tippeket! Volt már nagyobb szívásom is triviális dologgal, ez még nem is a legalja kategória volt. A nagyon furcsa az, hogy a neten fellelhető case study-k szerint ebben az irányban senki nem próbálkozott
Eszerint a leírás szerint magadnak kell rá firmware-t tenned, úgyhogy kell rajta bootloadernek lenni.
Szerintem az OP érdeklődjön náluk, hogy mi a helyzet.
A legelső alkalommal hogyan töltötte fel a firmware-t?
Jó soros porttal próbálkozik? stb
Ha semmi más nem segít, akkor ki kell mérni, hogy az ISP lábak hová vannak kivezetve, vagy ráforrasztani az IC-re, és csinálni egy ISP csatlakozást rá.
Egyrészt azért maradt kii az ESP8266, mert nem a teljességre törekedett a felsorolás. Másrészt azért, mert nekem ugyan képbe került, de semmi olyan projekt nem akadt eddig, aminél hasznát vehettem volna. Sok éves amatőr múlt után van némi fogalmam a vezetéknélküli átvitel nehézségeiről (ezért nézem inkább az mdot-ot, mert amihez kellene, ahhoz ez sokkal jobb).
Az az alapelvem, hogy adott célra kell megfelelő fejlesztői környezetet és eszközt találni.
Az első felvetésre: pont arra akartam felhívni a figyelmet, hogy a végső kód a könyvtárakon és a fordítón múlik, ahogy te is írtad. A fordító az IDE-ben van, a könyvtárak is rendszerint.
A második felvetésre. Ez így összefoglalva hasznos volt, így nagyon köszönöm! Jobbára angolul olvasok és előfordul, hogy a magyar szakszótár híján rosszul ültetek át valamit érthető magyar szöveggé, ezt meg néha hibás értelmezésekből tévesen levont következtetések nehezítik.
A lényeg azonban remélem tiszta volt, hogy rettentő nagy a sokszínűség minden tekintetben.
Nincs rajta bootloader, ami a soros feltöltést intézné. Kell egy programozó hardver, amivel fel tudod tölteni. A boardon ki van vezetve az ISP? (2x3 tüske)
Segítségre lenne szükségem, elnézést hogy mindjárt így nyitok de "ég a ház"...
Adott egy GT2560 lapoc és nem tudok rá frissítést tölteni. Ez egy 3D nyomtatót hajt és tudom hogy arra van külön topic de itt szerintem a Ti hozzáértésetek fog segíteni.
Szóval ardunio progival próbálnám rálapátolni a firmware-t ami a nyomtatóhoz kell, de nem sikerül, sync timeouttal elszáll.
Pontosan úgy néz ki, hogy egyszer megvillantja az RX ledet (piros) aztán ennyiben is marad a dolog.
Túrom a netet 3 napja a probléma miatt és az egyszerűbb 5leteket végigjátsztam. Nagyon úgy tűnik hogy ez valami bootloader probléma, de ehhez nem igazán tudok hozzászagolni, plusz olybá tűnik hogy egy USB kábel ezt nem is fogja megoldani.
Segítenétek elindulni valamerre? Valami rémlik, hogy egy másik arduino-val lehet orvosolni a problémát, de nincsen a közelemben. Raspberry nem lenne jó esetleg? (csak ötlet volt)
Szóval merre tovább?
Azért kéne mindenképp frissítenem mert vettem hozzá sokpízér HW "imprúvmentet", de így nem tudom aktíválni csak ha...
Lehet túl aggódónak tűnik a dolog, nekem egy jól működő boardom szállt el pár hét aktív fejlesztés után minden előjel nélkül. Fejlesztgettem, írtam és az egyik feltöltésnél kampó. Működik, csak épp írni már nem tudok rá. Persze nem nagy érték, inkább az, hogy mivel nem tárazok be készleteket, így várni kellett heteket, mire folytatni tudtam. Persze azóta van már tartalék, de bennem maradt a tüske :)
> Mert korlátolt az írás szám, és egy nagyobb fejlesztésnél simán akár százas nagyságrendben is történhet fordítás.
És akkor mi van?
Az eszközök adatlapját nézted már? Két példa hirtelen: Az Atmel a modern AVR eszközöknél (pl: ATmega328), és az ST az STM32 eszközöknél 10000 írást garantál. A gyakorlatban ennél többet bírnak.
Mennyibe kerül egy MCU board? Arduino pro mini ATmega328: 700-1400 ft, Maple Mini (STM32f103) 1200-2000 ft.
A fejlesztés költségéhez képest a hardver ára általában elenyésző. És ez igaz akkor is, ha nem ilyen filléres, hobbi eszközökről van szó. Egy komolyabb fejlesztői kártya 10 és 100 ezer forint között kapható. (Természetesen vannak jóval drágább, speciális, nagyfrekvenciás, stb eszközök, de ott sem az MCU a drága, hanem a körítés.) Mennyibe kerül egy fejlesztő egy napra? De ha hobbiból csinálod, akkor meg a szabadidőd kevés, vagyis az az értékes számodra.
Válaszd azt az utat, amin a leggyorsabban haladsz. Ha éppen az emulátor, akkor azt, ha egy nap 100x töltesz fel új programot, akkor éppen azt. A megoldandó problémától függ. A flash miatt pedig ne aggódj, legfeljebb kidobod az MCU-t a végén, és egy újat raksz az élesen működő rendszerbe.
Alapvető algoritmusokat természetesen érdemesebb számítógépen fejleszteni. De erre a legjobb egy egyszerű, parancssoros C/C++ program, amit később adaptálni lehet a beágyazott rendszerre.
Az emulátorokkal az a legnagyobb probléma, hogy külső komponenseket nem, vagy csak korlátozottan emulálnak. Ráadásul egy beágyazott rendszernél a legnagyobb szívásokat az okozza, hogy kiderüljön, hogy miért nem jön időben a megszakítás, miért nem fér meg két periféria az I2C buszon, stb. Ezek emulátorban nem derülnek ki.
De erről meséljen többet olyasvalaki, aki sokféle emulátort ismer.
A más környezetben C kód tesztelésen már magam is gondolkoztam, sokszor van, hogy tényleg nincs jelentősége hol fordul, főleg ha debugolható. Egyébként pont ilyen alap dolgok se mentek emulátoron, nem ismert konkrét utasításokat, amelyen minden további nélkül működtek a board-on.
Más. Egyébként csak én vagyok az egyetlen, aki beleszeretett az ESP8266-ba? Csak mert pl. a te felsorolásodból is kimaradt. Én amióta rátaláltam, arduino-t nem is programoztam, gondolkoztam is rajta, hogy eladom a nano-kat, van kettő amit semmire nem használok és szerintem nem is fogok. A mega fog most sorra kerülni, mert azzal tudom megoldani az LCD mellett más kezelését is, meg UNO-m végképp nincs, csak nano, micro és mega. De nálam a nano szerepét teljesen átvette az ESP.
Mert korlátolt az írás szám, és egy nagyobb fejlesztésnél simán akár százas nagyságrendben is történhet fordítás. Főleg, ha úgy mint nekem, vagy egy fejlesztő board és van éles. Engem zavar, jobb lenne, nem minden csip-csup vacak miatt égetni. Vannak arduino emulátorok, de én még jót nem találtam.
> Tippem szerint, ha leradírozol egy Arduino bootloadert egy Atmel MEGA328P-ről, és rátöltesz egy adott célt megvalósító szoftvert Arduino IDE-ből egy soros programozóval és hasonló felállásban az Atmel Studioval, jelentősen más végeredményt kapsz a végső kódban.
A kód a használt könyvtárakon és a fordítón múlik. Tehát egy Arduino IDE alatt fordított program bitre pontosan ugyanaz lesz, akár van az MCU-n bootloader, akár nincs. Annyi lesz a különbség, hogy a memória (flash) más részére kerül feltöltésre.
> -- saját IDE: bootloader nélkül, USB soros programozóval vagy egy másik Arduinoval,
Vagy bootloader nélkül programozóval (AVR Dragon, Atmel ICE, Arduino as ISP, stb), vagy USB soros átalakító és bootloader.
Nincs olyan, hogy soros programozó. USB TTL serial interfész létezik. A gyári Arduino paneleken ez rajta van, egy Atmega16u2 van USB TTL serial firmware-el programozva. Más lapokon CH340, CP2102 vagy egyéb cél IC van. A programozást ilyenkor minden esetben az MCU-n futó bootloader végzi.
Az USB-soros átalakító csak egy virtuális soros portot hoz létre a PC-n, fogalma sincsen, hogy mit kötsz a soros végére. Nem ismer se átviteli protokollt (csak fizikai szintűt), se MCU programozást. Az adatátviteli protokollt a PC-n futó szoftvernek és a bootloadernek kell ismernie, a flash írását pedig csak a bootloadernek.
Ha csak szoftverről van szó, az emulátor mehetne elméletben, de a gyakorlatban mégsem.
Ha mélyebbre ásol a szoftveres implementációban, akkor nagyon gyorsan elérsz oda, hogy a konkrét gépi kód és a C++ (vagy arduino vagy java vagy bármi) kód között rengeteg lépés van, és a konkrét gépi kód (ami magán az eszközön fut) processzorról processzorra változik. És az, hogy miként fordítódik, nagyon nem mindegy. Tippem szerint, ha leradírozol egy Arduino bootloadert egy Atmel MEGA328P-ről, és rátöltesz egy adott célt megvalósító szoftvert Arduino IDE-ből egy soros programozóval és hasonló felállásban az Atmel Studioval, jelentősen más végeredményt kapsz a végső kódban.
Plusz minden ilyen cuccnak pont az a lényege, hogy rengeteg ki- és bemenet működését hangolja össze egy adott formula alapján. Ha emulálsz, akkor egy hibás szenzor működéséből fakadó hibát nem fogod észlelni, amikor pedig az éles prototípuson tesztelsz, órák mennek el azon, hogy miért nem úgy működik, ahogy az emuláció közben működött (pedig csak az történik, hogy a bemeneti adatok eltérőek). Kiváló példa erre az AnalogRead: elvileg 0-tól 1024-ig ad vissza értékeket, ahol 0 a 0 V-nak, 1024 az 5 V-nak felel meg. Csakhogy. Ha a tápod ingadozik és a konkrét mérés akkor történik, amikor mondjuk épp 4,75 V a rendszerben a feszültség, és te egy külső referencia 4 V-ot mérsz, akkor más eredményt fogsz olvasni, mint akkor, amikor a rendszer tápfesz pontosan 5,0 V-on áll.
Csináltam egyszer egy külső vezérlést/programozót egy berendezéshez. Nagyjából időmérés és kapcsolók noszogatása volt az egész. Asztalon az eredeti (beépített) mikrokontrollerrel pompásan ment, ahogy beépítettem, megborult, és az istennek nem jöttem rá (azóta sem egyébként), hogy mi volt az oka. Ha lenne jelentősége, most elővenném, mert a műszeres háttér megvan már ahhoz, hogy normális hibakeresést tudjak csinálni.
Pár példa a lehetséges felállásokra:
Arduino:
-- saját IDE: bootloaderrel USB porton szoftverből,
-- saját IDE: bootloader nélkül, USB soros programozóval vagy egy másik Arduinoval,
-- Atmel Studio: bootloader nélkül, USB soros programozóval. Ez az eljárás ugyanaz, mint ami egyébként egy DIY Arduino lapkával is menne.
Nucleo:
Alapból a programozó/debugger egység rajta van, nem kell külön szöszölni vele, ha letörnéd, akkor is vissza lehet kábelezni.
-- mbed on-line (letöltöd, mented USB mass storage device-ra)
-- Kiel: vagy debug vagy éles módban csinálsz egy fordítást, azt mented az eszközre (mass storage)
Silicol Labs:
Alapból itt két debugger port van az eszközön plusz egy soros programozó USB-n, alap esetben:
-- Simplicity Studio, USB kábel, debug vagy éles módban áttöltöd és megy,
-- Simplicity Studio, USB programozóval áttöltöd és mehet a tread debug is akár (mondjuk itt fáj azért, hogy maga a soros progrmaozó/debugger kb. 120 000 forint),
-- Kiel: mint fent,
-- mbed on-line: mint fent.
A Simplicity Studio felületén tudod állítani pl. a lábkiosztásokat vizuálisan, ami azért annyira nem egyszerű tisztán kódban (a közel 400 oldalas dokumentációt kell túrni hozzá eléggé).
Az mbed on-line felülete engedi a kiküldést off-line IDE-kbe, méghozzá feltűnően sokba (kb. 8 van most a listán).
Ja, és még valami. Ha a szoftvered nem kezel ki- és bemeneteket (vagy csak keveset), akkor az egészet meg lehet csinálni egy tetszőleges C++ fejlesztőkörnyezetben, pl. Microsoft Visual C++-ban, a bemeneteket esetleg terminálon beolvasva, a kimeneteket úgyszintén a termimnálra kilőve. Ez olyan függvények tesztelésére jó, amelyek pl. bonyolultabb matematikai műveleteket végeznek. Itt mondjuk az lehet szűk keresztmetszet (gyakorlatilag figyelni kell rá), hogy az eltérő típusú változókat az egyes fordítók hajlamosak kicsit máshogy átültetni gépi kódba, plusz ahány gépi kód (szinte), annyi féle foglalást jelent néhány változófajta. Ennek lehet az a következménye, hogy ha nagyon gyorsan akarsz dolgozni és direkt memóriacímről olvasol adatokat, akkor Visual Studioban PC-n menni fog, de amikor az LPC1768-ra írt kódba töltöd a függvényt (vagy elegánsabban a könyvtárat), akkor bajaid lesznek.
4 nap hétvégi elmenetel Balatonra. Kertes ház, kertben 15 köbméteres reservior esővízgyűjtésre, de volt rajta egy automatikus töltő is, hogy ha egy adott szint alá süllyedne, akkor hálózati (kerti különmérő) tölt. Az öntözőszivattyú és annak az logikai/230 kapcsolása az aknában, vezérlés a kert túlsó végében. Annyi történt, hogy felakadt a vízszintérzékelő, így egy adott napi öntözésnél úgy lett, hogy kinyitott a külső töltőszelep (szerencsére passzív zárt), elkezdte betolni a vizet. Mivel a vízszintérzékelő nem oldott le, így töltötte, amígy csurig nem lett, aztán még egy kicsit, mert mint utólag számoltam 25 köbméter víz szaladt ki abban a pár (valószínűleg maximum 2) napban. Amikor az átemelőmotor és a vezérlőelektronika tömítései már nem bírták, akkor rövidre zárták a kapcsolt 230 V-os kört, az levágta a biztosítékot, és mivel (hála az égnek) a töltőszelep ugyanarról a körről kapta a tápot, azt is elzárta. A szivattyú túlélte (magam sem tudom, hogy miként), a jelfogó kb. akvárium, a csatlakozóház kuka (tiszta rozsda). Plusz amikor megjöttünk, sem a riasztó, sem a kapunyitó, sem a garázsajtó nem ment, és mivel az egész szarság még bőven víz alatt volt, a szivattú tápellátásának kiiktatásával lehetett csak visszaállítani a helyzetet (aztán jöhetett a szivattyúzás a normál vízszintig).
Egy ilyet simán meg lehet építeni, mert nem az életed múlik rajta (és ha a ház elektromos rendszere jól van kiépítve, még az életedet sem veszélyezteti egy talajban szaladgáló 230 V). Csak modulárisan kell, egységenként tervezni, tesztelni, akár hosszú távon, ha működik, jöhet a következő rendszer (ezért van nekem itthon kazalni Nano). Szoftverben ugyanez. Az egyik menjen hibátlanul, aztán függvényenként (a globális változókkal együtt) át lehet emelni a kész szoftverbe.
mdot és hasonlóak ... igen, kéne velük játszani. Most pl. rendeltem egy atmel tiny85-ös apróságot, bár az még mindig ez a vonal. Egyáltalán nem ragaszkodom egyikhez sem, legyen hozzá valami fejlesztő környezet és ne kelljen varázsolni a program feltöltésével, kb ennyi az igényem. Nagyon jó lenne valami olyan platformot találni, ami megbízható, van hozzá jó fejlesztő környezet és ne adj isten egy emulátor, hogy ne kelljen minden vacak miatt beégetni a kódot. Namost ezek közül kb egyiket sem teljesíti az arduino :D
Én alapvetően csak arról írtam , hogy a riasztó alapbető működése gyk. annyi, hogy megszakadt-e az áramkör. Természetesen az üzembiztonság, a redundancia, tápellátás stb más tészta, bár ez is egyéni izlés kérdése. Lehet azzal is játszani, hogy intelligenciát belevinni az érzékelőkbe, ne kiabáljon minden hülyeségre, de alapvetően az, hogy csinálni egy riasztót nem akkora csoda.
Az teljesen igaz, hogy az arduino nem feltétlen alkalmas kritikus helyekre, sőt az esp-ben se nagyon bízok. Gondolkoztam pl. öntöző vezérlésen (füvet, veteményest, miegymás), de végül nem bíztam eléggé egyikben sem annyira, hogy magára hagyjam rákötve a vízre, hogy aztán ha valami gebasz van és elárassza az udvart. Ez időjárás kütyü most pl arra is jó, látom mennyire megbízható, mert az 7/24 megy pl. Most a tél is jó próba lesz, bát papíron -40 fokig üzemel, majd kiderül :)
Azért ez a riasztós dolog marhára nem így megy ám... Ott 100 százalék üzembiztonság és legalább kétszeres redundancia nem árt, plusz elemek függetlenítése és a többi. Minden lehetséges forgatókönyvre és a lehetetlenek többségére is illik felkészülni. Egy korszerű riasztó szoftvere sem egyszerű, de a herdveres rész nem épp az Arduino kategória. IoT vonalon az Arduino most éledezik, (bocs, hogy megint ezzel jövök de) az mbed-et viszont nagyjából erre találták ki, és sokan mások is borzasztó erősen nyomulnak (felhővel, kész támogatással, eszközökkel stb.). Bár az igaz az ESP8266 hobbi célra elég jó. De nézz meg mondjuk egy mdot kártyát.
Engem pl. érdekelt, hogy mekkora szél van nálunk, érdemes-e elindulni bringázni vagy sem. Mivel a közelben nem volt széladat, ezért adta magát, hogy csinálok egy időjárás állomást. Egyébként ez eléggé "hello world" ahogy nézem az arduino világban, úgy értem, előbb-utóbb mindenkinek lesz egy. Most épp a kliens oldalán gondolkozom, ha lesz rá időm, alkatrészek megvannak hozzá (tft, hőmérő, wifi, óra, controllerek wifivel, táp), nagyjából megvan mit akarok (időjárás adatok saját állomány + netes előrejelzés, google naptár és mail adatok, benti hőfok, páratartalom), csak neki kell állni.
Ha IOT-ben gondolkozol, lehet nem arduino hanem ESP8266 vagy hasonló vonalon érdemesebb elindulni. Ugyanúgy arduino környezetben azon a nyelven programozod, csak nem kell szenvedni 3.3v-5v illesztéssel, külső wifi modullal, az ára meg olcsóbb is mint egy arduino+wifi, és gyorsabb, cserébe kevesebb a pin rajta. És már jön(jött) az új ESP, azon bluetooth is van pl.
Riasztót készíteni nem nagy kaland alapvetően, hiszen gyk. kapcsolók figyeléséről szól, mozgásérzékelő, nyitásérzékelő stb elég egyszerű, csak megszakítja az áramkört és csók. Ráraksz egy gsm modult és kész.
Ha van kerted, csinálhatsz öntözés vezérlést, ha van akvárium vagy kertitó, ahoz etetést, vizijátékot pl.
Itt pontosan az van, mint a cégnél: akkor működik jól, ha van egy jól determinált feladat, amit végig kell csinálni adott esetben nulláról. Érdekes projekt?! Hm. 4 bináris szenszor, két hőmérő, két nyomásmérő, PID alapú hőmérsékletszabályyozás, több bináris kimenet időérzékeny kapcsolása, hall szenzorok értékeinek feldolgozása és ez alapján bizonyos kimenete állítása. Plusz az egészen egy 256×64 pixel, 4 bites grafikus OLED kijelző, valamint gombok a vezérléshez. Később távfelügyelet, moduláris bővíthetőség (pl. frekvenciaváltó 230 V AC meghajtómotor fordulatszámszabályozáshoz) stb. Kb. 1 év múlva lesz belőle működő proto, most nagyjából 8000 sorra tippelem a kész kódot C-ben (mbed platformon, de KIEL-ben).
Az elmúlt pár évből pár projektterv: kerékpáros féklámpa gyorsulásérzékelővel, napelemes töltővezérlő (arduinohoz), teljes ledes óra ébresztéssel, környezeti fényhez igazodással (MAX7221-gyel), WBC barista bajnokság időmérő óra (ez fent van az Instructables-ön is), önszerveződő időjárásfigyelő és riasztó rendszer (Mediatek LinkIt One alapon), és ez csak az, amire emlékszem.
Ha nincs ötleted, akkor motivációd sem lesz szerintem. De ne legyen igazam!
Sajnos, amiket én csinálok, az nem 10-100-1000-s széria, a környezet meg azt igényli, hogy ipari kivitel legyen, ezek általában biztosítják, hogy ami az asztalon működik, az a terepen is fog.
Ezért írtam, hogy hobbi lenne... és ezért kérdeztem anno az mbed topicon, hogy van-e valami érdekes projekted. Amin el lehetne gondolkodni.
A villogtatás, SOS kezdésnek jó, de valamennyire tudok Pascalban és C-ben is programozni, és hát a delay, hát az nem az igazi.
Ahogy követtem a dolgokat, a kazánvezérlések és a pálinkafőző érdekesnek tűnt, de hát ha nem kell belőle 50 db, s nincs sok időm a tesztelésre a helyszínen, akkor is inkább valami pár tízezer forintos ipari cucc.
Volt egy ígéretes kolléga, aki egy nap alatt írt volna riasztóközpontot, rég láttam.
Azért beruházok valamibe, és érdeklődve várom a további hozzászólásokat.
Alapból az a véleményem, hogy nulláról kezdve kell:
-- minden, ami az alap kapcsolásokhoz kell (ellenállások, ledek, jumper kábelek mindkét fajtából, tranzisztorok, szervó, esetleg stepper, diódák, kondenzátorok. 1602 LCD, esetleg valami OLED, gombok, kapcsolók, trimmer potenciométerek, hőmérő, fényérzékeny ellenállás, rgb led, shift register, estleg egy 7 szegmenses kijelző),
-- multiméter,
-- megfelelő minőségű táp,
-- legalább két breadboard (nekem van kb. 6, de kicsi is, mert sokszor praktikus),
-- ötletek, hogy miket akarsz megcsinálni, ehhez a szükséges alkatrészek.
És kb. ennyi. A Blinky-t 10 perc kivégezni, de ha szeretnél pwm-mel elhalványuló és felvénylő P13 LED-et a Nano-n, akkor azért ehhez már nem árt gondokodni (jó feladat egyébként). MINDEN, hangsúlyozom, MINDEN fent van a neten, ugynakkor tudni kell szelektálni, mert adott esetben órákat spórolhatsz azzal, hogy nem a rossz úton kínlódsz, hanem egyből a jóból kiindulva érsz el a célodig.
Később majd praktikus lesz egy soros programozó, soros illesztésű perifériák, portsokszorozók, érzékelők, nagyobb panel (Mega2560) stb. stb. stb.
Ami meg a komolyságot illeti... Az Arduino próbának megteszi, de profi fejlesztői környezetek után ide megérkezni jelentős kínokat okozhat. Alternatívaként ott van az mbed, vagy az Arduino a keretrendszer nélkül más IDE használatával (más világ), nekem van Silabs Gecko is, döbbenetes, hogy mit tud (az IDE is, de az eszköz is). Amit érdemes megfontolnod, hogy értelmes célokat válassz, mert a kezdeti lelkesedésbe nagyon gyorsan bele lehet fásulni, ha nincs konkrét cél, amit meg akarsz valósítani.
Pár hónapja olvasom a topicot. Meg persze visszaolvastam az elejéig.
Ha ilyesmire van szükség, Siemens (Logo), Omron (Zen) Eaton (EasyControl) vezérlőkre szoktam programot írni, ipari környezetbe. Néha-néha nagyobbra is, ugyanezektől a gyártóktól.
Hobbi szinten próbálnám ki az Arduinót. Egy abszolút kezdőkészletre esett a választásom, Nano és egy marék üveggyöngy a TAVIRtól. És egy 830 lyukú breadboard, szerintem a 170-es elég kevés.
Szerintetek ez elég, vagy egyből szerezzek be valami komolyabbat? Első közelítésben forrasztgatni nem szeretnék, legfeljebb dugdosni.
Nem tudom, jó kérdés, lehet más tudja a választ, nekem ez az első fejlesztésem. :-D Igazából azért használom integer ként, mivel nincs szükségem a tizedesjegyre, és így a mért értékek is stabilabbnak tűnnek. 1 C-n belül nem ugrál annyira a megjelenítés.
Csak nagyon felszínesen belenézve mert a mélyebb analízishez több idő kellene
" cefrezo = (atlag_c - minn_c - maxx_c) / 3; "
Mennyire "stabil" az ilyen adatkonverzió, mert ugye a cefrezo az int, és a többi meg float amit hárommal osztasz. Nem tudom az Arduino keretrendszer hogy kezeli le ezt az adatkonverziót, én mást használok fejlesztésre. Ez csak egy apró felvetés volt, lehet semmi köze a problémához.
