Mikorvezérlő, de milyet? (Arduino...)

 ( makgab | 2016. december 17., szombat - 22:11 )

Üdv!
Milyen mikrovezérlőt javasoltok? A hoszt gép RPi lenne és szenzorokat tennék majd a mikorvezérlőre, amiket a hoszt lekérdez időnként. Pl. DHT22
Arduino-ból melyiket javasoljátok? Tudom, van aki nem az Arduino-t javasolná. Érdekel más megoldás is természetesen, de az Arduino is!

Milyen kommunikációt javasoltok a RPi és mikrovezérlő között? I2C?
A tapasztalatok érdekelnek.

(A nemrég indított és kitárgyalt téma miatt kérdezem.)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Az én véleményemet ismered. Azért választanék PIC-et, mert nagyon jó a dokumentációja, ismerem, dolgoztam már vele, jó áron elérhető, a legtöbb példány működik 3.3 V-ról, természetesen belül van az órajel generátora és reset áramköre - tudom, ezt manapság a többiek is tudják.

Még az is lehet, hogy nem fárasztanám magam olyan eszközzel, amelyik hardware-ben tudja az I2C-t, implementálnám a kontrollerben software-ben.

Lehet, többen elég elítélhetőnek tartják, amit írok, de kis darabszámú hobby project esetén a gombhoz szoktam venni a kabátot. Megnézem, a kereskedőnél melyik mikrokontroller kapható olcsón, számomra megfelelő tokozásban - például DIP tokban, ha tiszta lyuk nyákra építkezem -, majd megnézem, az adott eszközzel akár kompromisszumosan is meg tudom-e valósítani, amit szeretnék. Ha igen, megveszem. Itt a kompromisszum jelentheti azt, hogy valamilyen interface-hez nincs hardware támogatás, azt le kell programozni, de persze végig kell gondolni, hogy ez lehetséges-e, belefér-e futásidőbe, nincs-e elvi akadálya a megvalósításnak.

Szempont lehet még a fejlesztői környezet. Hogyan kerül a program az eszközbe? Elérhető áron lehet-e ehhez eszközt venni, vagy amatőr módon megoldható-e ez olcsón? Az én esetemben még: a programozót tudom-e Linuxról használni? Van-e Linuxra assembler a kontrollerhez?

PIC-ekre van assembler és C fordító is a Gputils csomagban. Nekem egy régi PicKit2 programozóm van, ehhez van linuxos támogatás, bár forrásból kell fordítani. Fedora 25-re le lehet fordítani. Október végén fordítottam utoljára. Tudom, akkor még nem volt hivatalosan Fedora 25, de nekem már az volt a gépemen.

Ha jól látom, az Arduino már valami előemésztett, kész nyák egy kontrollerrel, néhány perifériával. Ha nincs kedved, lehetőséged forrasztani, akkor lehet, hogy ez a jobb megoldás.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Valamilyen Atmel (már egy ideje Microchip) ATTINY-t. A programozó nagyon olcsó hozzá, az USBasp kb. 2$. Az ATTINY85 így ránézésre elégnek tűnik, programmérettől függően akár a kisebb testvérei is megfelelhetnek (45 ill. 25). A 85-ből csináltak egy USB-n programozható panelkát (DigiSpark), ha azt veszed, akkor még USBasp se kell hozzá (de jó, ha van egy-két olyanod - azért kell egynél több, hogy a kínai firmware-t könnyen ki tudd bennük cserélni). A DigiSparkos cuccot bele tudod integrálni az Arduino IDE-be, egy-két dolgot kell csak letölteni hozzá.
Kommunikációra nem javaslom az I2C-t, mert mindkét kütyü, a Málna is és az AVR is master szeretne lenni alapesetben az I2C buszon (nem lehetelen egyikből sem slave-et csinálni, de nem érdemes). Sima soros vonal (TxD és RxD) jó lehet a célra, egyszerű, kiforrott dolog, ismeri "mindenki". Ha nagyobb távolságra van egymástól az RPi meg a mikrovezérlő, akkor csavart érpár lenne jó, ekkor RS422/RS485 meghajtók is kellenek, egyébként pár cm esetén a TTL is elég, pár méternél meg az RS232.

Kommunikációra nem javaslom az I2C-t, mert mindkét kütyü, a Málna is és az AVR is master szeretne lenni alapesetben az I2C buszon

Hát... minden az szeretne lenni, amivé programozzák. I2C slave-et hardware támogatás nélkül, port lábakat használva is lehet csinálni akár, ha valakinek van kedve, ideje hozzá.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem vitás, hogy lehet, mivel azt írtam én is, hogy meg lehet azt is csinálni, viszont én nem erőlködnék vele - nincs kedvem hozzá :)
Szerintem az sem vitás, hogy az I2C alapfilozófiája viszont az volt, hogy van a buszon (pl. a Philips tévéiben) egy master, amire csatlakoznak a kitenyésztett (hardverben megvalósított) slave-ek. Az egésznek az volt a mozgatója, hogy minél kevesebb drót legyen a NYÁK-on.
Azokhoz az időkhöz képest kicsit megerősödtek a mikrovezérlők, órajelben is, bitszámban is, belső felépítésben is, ennek ellenére még mindig nem érzek ingert, hogy szoftveresen csináljak slave-et.

Voltam olyan őrült, hogy mint munka, csináltam valaha CPLD-ben I2C master kontrollert, beleértve a clock stretching implementálását is. Állapotdiagramokat rajzolgattam, aztán kapcsolási rajzként megcsináltam chip-re. Ugye a host felé párhuzamosan történő adat átadás, illetve onnan történő átvétel is feladat, meg az acknowledge, meg a címzés, read, write, minden nyalánkság. Elszánt voltam, na! :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Volt idő, amikor a relatív ugrásokat is magam számoltam ki Z80-hoz, mert nem volt hozzá semmim. Én voltam az assembler, ráadásul változó hibával dolgoztam, minél fáradtabb voltam, annál több volt a hiba :) Nehezítésnek volt egy kézi adatbevitellel működő EPROM-programozó, amivel egy PLC-be lehetett beletuszkolni a működtető programot (a PLC se volt semmi, 1 bites, "Bool algebrai" CPU-ja volt, összesen 19 utasítást ismert). Ezzel programoztam hexa billentyűzeten keresztül a gépi kódot a 2716-ba, de előtte még negálni kellett a biteket (egyes komplemens), mert ez a hülye programozó úgy gondolta, milyen hülyeség az, hogy az üres EPROM-rekeszben 255-nek kell lennie, ő azt 00-nak mutatta, és úgy is kérte, ezért pl. a NOP 00-ja helyett FF-et kellett beütni, a LD D,L 55-je helyett meg AA-t :)

off

Hm... Z80, 2716, 2732, 4118 (4801), 6116, letört búrájú higanygőz lámpa fénycsőhöz való fojtótekercs előtéttel EPROM törléshez, ózon szag. Micsoda nosztalgia! :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem volt germicidcsövem :)

...burzsoá... :D

Gyakorlatilag mindegy milyen márkájú eszközökhöz nyúlsz, bármi jó lesz a feladatra. Persze a konkrét eszköz specifikációját nézd meg!

A legnagyobb problémád a programozás menetének kitalálásával lesz. Ha nem programoztál még mikrokontrollert, akkor használj Arduinot, azt a legkönnyebb összehozni. Bármi máshoz szükséged lesz külön programozó eszközre.

Az Atmega sem rossz választás, az Arduinos körítés nélkül is viszonylag könnyű elindítani az ingyenes Atmel Stúdióval. OpenSource alapon kicsit nehezebb összerakni de én eclipse + avr-gcc + avrdude kombinációval is szoktam programozni őket, az is megy.

Mikor utoljárra PIC után érdeklődtem, akkor még nem volt hozzájuk ingyenes C fordító. Hacsak azóta nem lett, akkor ne válassz PIC-t, mert az assembly kezdetnek elég fájdalmas.

Ha komolyabb dolog is kellhet mint az 8-bites kontrollerek, akkor STM32-t vagy ESP8260 vonalat is érdemes megnézned. Ezek komolyabb eszközök, nehezebb is őket életre bírni, de sokkal több mindenre képesek. (Az ESP8260-hoz ugyan van arduino támogatás, de sok benne a rejtett buktató, főleg ha real-time feldolgozást is szeretnél.)

Az STM32-t illetően az Ebay-en a kulcsszó STM32F103C8T6. A board hasonlít az Arduino Nano-ra, de az USB itt csak tápellátásra szolgál, kell hozzá programozó. (Bár elvileg a Boot jumper pakolgatásával egy FTDI FT232-vel is programozható.)

Szintén jó tudni, hogy újabban már ez is működik Arduino-s környezettel.

Érdekes, ezt nem is tudtam. Én GNU ARM Eclipse + ST-LINK-kel használtam őket. (A leírások alapján érdemes lett volna egy J-Linket szerezni, de annak az árát nem emberi léptékben mérik.)

Ez egy ST-Link, ilyenem van is. A J-Link seggerek használtan 100000Ft környékéről indulnak.

Hát ennek fényében kíváncsi lennék hogyan kerül fel e-bayre 10$-ért. Kamionról leesett darabok lennének?

Egyszeru. Nem a gyartasa kerul sokba (az megvan 10e -bol), hanem a fejlesztes. Irja is, hogy 10 ev alatt eladtak 400K darabot - hat erre eleg komoly haszon kell, hogy kifizesse a ceg koltsegeit.

Kinaiak lemasoltak, ocson adjak. Szokasos.

Reagálnék mindkét előttem szólóra.

PIC előnyök: kapsz egy használható IDE-t és fordítót (persze ezt ki szereti, ki kevésbé). Ha megveszel egy ICD3-at, akkor jól tudod debuggolni, valamint ezzel akár később 16 és 32 bites kontrollereket is fel tudsz programozni.
A nagyobb PIC-ek már komolyabb projektekhez is alkalmasak, sok jó kis periféria van bennük (aszinkron logika, DMA, ethernet, stb.).
PIC hátrányok: elavult architektúra (főleg a 8 bites), 4 órajel/utasítás, a free fordító gagyi (nagyon). Sok errata.

AVR előnyök: nagyon jó free fordító és libek vannak hozzá, 1 órajel/utasítás, energiahatékonyabb a PIC-nél. Programozót fillérekből lehet hozzá építeni, de nem is drága. A procik egyszerűbbek, de könnyebb (szerintem) őket megérteni, találkoztam olyan atmega-val is, aminek nincs ismert errata-ja!
AVR hátrányok: miután a microchip megvette az Atmelt, a jövője kérdéses, nem valószínű, hogy túl sok új eszköz jön még majd ki. Debug képességek csak a nagyobb változatokban érhetőek el. Az egyszerű programozó nem jó a nagyobb tudású kontrollerekhez.

Attiny-t én nem javasolnám, annyival nem olcsóbb, amennyivel butább. Gyakran nincs bennük rendes hardveres I2C/SPI vagy UART. Bootloadert is nehezebb hozzájuk írni.

I2C-t én javasolnám, ha van benne tapasztalatod, szerintem sokkal jobb az UART-nál, és több eszköz is simán felfűzhető. Slave funkciók természetesen nem problémásak.

Az AVR-ek jövője valóban kérdéses lehet, de most még kaphatók. Ha továbbra is lesz rá igény (sokan fejlesztenek rá, úgy tudom, csak nálunk népszerűbb a PIC, máshol az AVR vezet), akkor nem biztos, hogy a Microchip kidobja, miért tenné, ha van belőle tisztességes bevétele?
Az ATTINY nyilván butább a többinél, de egy mezei soros portot meg lehet oldani benne szoftveresen. A kis méret miatt érdemes rajta elgondolkodni, csak 8 lába van a 85-nek. Ha a méret nem számít, akkor kényelmesebb egy ATMEGA, pl. ATMEGA8, az már elég jól el van látva perifériákkal.
Ha nagyobb távolságokra lennének az adatgyűjtő mikrovezérlők a Málnától, akkor az I2C nem annyira szerencsés, ott jelszintnövelés kellene, ha nem akarsz a zavarokkal küzdeni. Az RS422/RS485 bevált dolog, a csavart érpár is az, én azzal csinálnám.

Ahova egy RPi belefér a költségvetésbe ott nem igazán szempont hogy 100Ft-os spórolsz-e a mikrokontrolleren, akkor meg nem érdemes Attiny-vel küzdeni.

Az ATMEGA-k jövője érdekes kérdés, mert egyrészről az Atmel vastagon veszteséges volt, úgyhogy logikus lenne megszüntetni, másrészről viszont az AVR-ek jóval elterjedtebbek a kistételes eszközökben, és volt már korrekt portfólió frissítés is a felvásárlás óta, ami pozitív jel.

Köszönöm a javaslatokat, tapasztalatokat!
Ha az Arduino-t nézzük, akkor milyen kit-et, board-ot javasoljátok? Egyelőre csak hobbi projekt lesz, otthonra néhány szenzorral.

A szenzorok felé valószínűleg I2C-re vagy SPI-re lesz szükséged, a RaspberryPi felé valamilyen sorosportra. Ezt ha jól emlékszem bármelyik arduino modell tudja.

Ha igazán lusta vagy akkor választhatod az ArduinoNanot. Ezen az atmega tud USB-t, amin gyárilag egy RS232 over USB emulátor program fut. Így csak összedugod a raspberryvel USB kábelen, és megoldott a táplálás is, meg a kommunikáció is. Magától megjelenik neked a ttyUSB0 az rpi-n, és már küldheted is rá az adatot. Persze hogy csináljon is vele valamit, ahhoz előtte fel kell programozni, ezt rendes PC-n érdemes.

Amúgy a Nano annyira univerzális, olcsó és kicsi, hogy konkrétan a táskámban is tartok egyet qucik&dirty javításokra. Ha valami vacak elektronikát egy fél óra alatt gyorsan ki kell váltani, akkor életet tud menteni. Készült már belőle index relé időzítő, DMX pult kommunikációs adapter, stúdió adásvisszajelző lámpa vezérlése, multiméter adatgyűjtő, ...

Egy Arduino Starter KIT jó választás lehet?

Erre a célra finoman szólva nem költséghatékony. Neked már egy nano vagy micro is elég de kínából rendelve még jobb ajánlatok vannak.

Ettől függetlenül amit linkelsz az egy nagyon jó kit, érdekes dolgokkal, tanulásra kiválóan alkalmas.

Jó, csak marha drága :)
Amikor legutóbb Arduino Nano V3-at vettem, 2,14$-ba került :)
Egy Uno 3,5$ körül kapható, a MEGA meg 7$ környékén.
Ha nem érsz rá várni (soha nem tudhatod, mikor jön meg Kínából a cucc, van, hogy 10 nap alatt, van hogy 50 is kell hozzá), és az ára se nagyon számít, akkor jó választás, amit írtál. Én nem adnék ennyit érte, az biztos, és szerintem nem vagyok egyedül ezzel a véleményemmel :)

A szenzorok felé valószínűleg I2C-re vagy SPI-re lesz szükséged

Nézted a topiknyitó linket? ;) Ha úgy lenne, ahogy írod, közvetlenül az R-Pi is kezelhetné a szenzort. De nem. Azért kell a mikrokontroller, mert a szenzor úgy ad vissza egy bitet, hogy néhány 10 µs-ra alacsony szintre húzza a vonalat. Ezt az időt kell mérni, s ez egy nagyon valós idejű dolog, amelyre az R-Pi nem igazán alkalmas. Szóval a szenzort saját programmal illeszti majd port lábon, az R-Pi felé meg már lehet valami szabványos kommunikáció.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Akkor ezt elnéztem, úgy emlékeztem a DHT22 I2C-s. Elnézést kérek.

Ettől függetlenül arduino nano-ra így is illeszthető, sőt, van hozzá kész library: http://playground.arduino.cc/Main/DHTLib

Talan azert mert i2c-s. Vagy van oylan is belole. Nekem peldaul 5 is.

https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

aaaa, Hulye vagyok!

http://www.kepfeltoltes.eu/images/711IMG_20161218_194344.jpg

azert vettem mert nem i2c-s es igy tobbet is ra tudok kotni barmire.

Ha I2C-s lenne, akkor meg feltehetően lenne három olyan lába, amin címezni tudnád (A0, A1, A2), így max. nyolcat lehetne egy rendszerben használni mindenféle trükkök nélkül (legalábbis ilyen jellegű I2C-s kütyüknél ez a megszokott) :)

Azert sajnos nem mindenki koveti ezt:

Si7021: 6 lab, SDA, SCL,VCC, GND + 2db NC :-(

Kotve hiszem, hogy ket cim vonalat ne lehetett volna kibondolni valahogy a ket nem bekotott labra...

/sza2

Azt írtam, hogy feltehetően, nem azt, hogy biztosan.

Annyit érdemes megjegyezni a linkelt IC gyártójának védelmében, hogy a tokozása arra utal, hogy ebből egy eszközben csak egyet akarnak használni, felteszik valahova pl. egy mobilelefon, esetleg egy karóra NYÁK-jára, ahol csak egyetlen hőmérsékletforrásra van szükségük. Ez csak tipp, de ezt látom valószínűnek.

OK, no offense, nem azt irtam, hogy rosszul mondod, csak megjegyeztem, hogy _sajnos_ nem mindenki el ezzel a megoldassal.

Az IC gyartojat eleg jol ismerem, nekik dolgozom :-) Azert koszi, hogy megvedted ;-)

Valoban, pl. a wearable piac eleg jelentos resze vevokornek, ahol tenyleg altalaban csak egy ilyen szenzor van egy eszkozben. Az is igaz, hogy az I2C nem nagy tavolsagokat osszekotni hivatott, ez tovabb erositi, az egy eszkoz / egy szenzor dolgot.

De egyreszt lehet olyan alkalmazas ahol aranylag kozel kell merni homersekletet tobb helyen, illetve van meg egy aspektusa a cim valaszthatosaganak: mivel az I2C eseten a cimtartomany elegge korlatozott, igen konnyen megesik, hogy pl. egy masik gyarto termeke ugyanazzal a slave address-szel van megaldva, ilyenkor szinten nagyon hasznos, ha nem csak egy fix cimet tud a cucc.

/sza2

7 illetve 10 bit lényegében sokkal több, mint ami kell, hiszen open drain hajtják az eszközök az SCL és SDA vonalat, amelyeket ellenállásokkal húznak fel. Éppen ezért sok eszközt nem lehet a vonalra lógatni, hiszen az összeadódó kapacitások megengedhetetlenül alacsony slew rate-et, illetve nagy időállandókat eredményez. Ez a sebesség csökkenését okozza, már feltéve, hogy erről tudnak az eszközök, s nem tartják a specifikációt, hanem lassan járnak. De a specifikáció betartása mellett nem lehet akármilyen sok eszközt kiszolgálni. Akkor meg minek több cím? Ez nem hash, hogy arra törekedjünk, ne legyen hash ütközés. A konkrét hardware-ben konkrét címei vannak az eszközöknek.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Lehet, hogy felreertetted, en nem azt mondom, hogy a 128db cim (minusz a specialis cimek) keves.

Arrol beszeltem, hogy ha nincs cimvalaszto laba az adott periferianak, akkor szivas, ha ugyanaz a slave address - es ehhez nem kell szamtalan eszkoz, eleg csak ketto, ami miatt kulon busz kell nekik (ami plusz ket lab a masteren, ugye).

"Éppen ezért sok eszközt nem lehet a vonalra lógatni" - persze, en sem lattam meg olyan berendezest amiben 100 I2C-s periferiat tettek volna egy buszra, de mondjuk a sajat IC-inkbol siman volt 6db ugyanazokon a vonalakon, es tudjak az 1MBps-ot. A kapacitasok osszeadodnak, de egy bizonyos szintig ez kompenzalhato a felhuzoellenallasokkal es a meghajtok erossegevel (es egy konkret hardware-ben konkret szamu eszkozod lesz, tehat kalkulalhato).

/sza2

Nem is ez a probléma, hanem
- azonos típusú eszközből többet, vagy
- különböző eszközök esetén a véletlenül ütköző címet kell kiküszöbölni.
Léteznek olyan i2c eszközök is, amelyeknek programozható a címe.

Jobban kiépített hardver esetén a nagy kapacitás vagy az ütköző cím egyáltalán nem probléma, mert léteznek igen változatos busz arbiterek illetve vonalmeghajtók. Az előbbieknek azért vizsgálni kell a kompatibilitását...

Ezekre a megoldásokra azért van szükség, mert az eredeti specifikáció legfeljebb 10cm busz hosszt enged meg, méghozzá körültekintő nyomvonallal. (No, meg az i2c alapja nem a pic-ekben keresendő. ;))

az eredeti specifikáció legfeljebb 10cm busz hosszt enged meg

Ehhez képest meg a monitor vezetékére simán ráakasztották az EDID információkat I2C buszon.

Valóban nem nagy távolságokra találták ki, csak érdekesség...

Röhögni fogsz!
Pont olyan differenciális dI2C Fast-mode Plus (1MHz) drivert használok, amit pont egy monitorkábelnyi hossz (3m) meghajtására terveztek.

A helyedben először elolvastam volna az eredeti specifikációt.
De azért tényleg érdekes. :)

Csak az már nem I2C. Az I2C az a valami, amit a Philips alkotott meg összesen két szál dróttal.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Philips -> I2C
NXP -> dI2C
...
???? -> ?I2C
Ez a fejlődés! :)

Komolyra fordítva a szót, az I2C is elvihető nagyobb távolságra dupla RS485, optikai vagy CAN vonalakra ültetve. A protokoll ugyanaz, illetve mindkét végén I2C cuccok vannak. A fentinek pl. az az előnye, hogy 100-120 Ohmos csavart érpárhoz illesztett, mindkét végén lezárt. Ha kiszámolod a vonal késleltetését, akkor a sebesség csökkenésével hosszabb lehet a kábel. Az a lényeg, hogy a buszmeghajtó kimeneti és bemeneti L logikai szintjének különbségénél (90mv) lényegesen kisebb legyen a zavar. Ha ezt nem sikerül teljesíteni, akkor "visszabeszél".

Értem, amit beszélsz, átviheted felőlem modemen is, csak az már nem I2C.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Fogd fel "média konverternek"!
A protokoll I2C, a fizikai kapcsolat meg OD, amit többen is lehúzhatnak. Mindössze zavarvédelmi okokból csináltak egy ellenütemű duplikálást, igy szimmetrikus a jel. Másképp fogalmazva: ez csak egy erősítő.
És mindkét végén egy-egy PIC I2C lábai lógnak. Csak nem hívod ezen túl ethernetnek? ;)
Asszem megint elfelejtettél a linkre kattintani. ;)
Vagy nem tudtad, hogy Philips==NXP?
Ha elfogadod a fenti egyenlőséget, és lusta voltál az információt megszerezni, akkor ide rakom:
The PCA9614 is a Fast-mode Plus (Fm+) SMBus/I2C-bus buffer that extends the normal
single-ended SMBus/I2C-bus through electrically noisy environments using a differential
SMBus/I2C-bus (dI2C) physical layer, which is transparent to the SMBus/I2C-bus protocol
layer. It consists of two single-ended to differential driver channels for the SCL (serial
clock), SDA (serial data).

Ráadásul az eszközöket is ugyanúgy lehet összekötni az így kialakított buszon. (Lásd 7. ábra)

Röviden: Nem én mondam! Ők mondták! :))

DHT22 helyett javasolnám a Honeywell szenzorait. Azok valóban I2C-sek, így a RPi közvetlenül is tudja őket olvasni, ráadásul még a feszültségszintek is stimmelnek.
HIH8121-021 vagy HIH8131-021.
Drága, de 2% garantált pontosságot ad.
De az is igaz, az I2C nem való nagyon messzire!

Javítás: Az arduino micro-n fut emulált USB over Serial, a nano-n dedikált chip van. Én az emuláltat jobban szeretem, de jelen felhasználás szempontjából mindkettő megfelel. Az emulált előnye hogy szabadon marad egy fizikai tx/rx párod amit tudsz használni.

Hirtelen találtam egy ilyent:
http://www.instructables.com/id/Mini-weather-station-with-Attiny85/
Ehhez még drót is csak a tápláláshoz kell :)
Ebben a példában két 85-ös beszélget egymással, de nyilván meg lehet oldani úgy is, hogy a terepen használsz n darab 85-öt, a Málnára teszel egy nagyobb mikrovezérlőt, ami foglalkozik a 85-ökkel és átadja a mérési adatokat a Málnának.

Ha RaspberryPi + mikrovezérlő ---> http://xham.myiot.hu/forum/index.php?topic=183
A helyzet annyit javult bő 3 év alatt, hogy a mai Raspbian-ban levő avrdude-ba emlékeim szerint bele van fordítva az Rpi SPI eszköze, így ma már fordítanod se kell avrdude-t, csak simán felrakni a repóból.

Minek ehhez mikrovezerlo? Miert nem kotod az rpi-re? I2C-vel meg lehet hajtogatni.

Ha meg messze akarod rakni, akkor hasznalj esp8266-ot es wifi-n keresztul elkuldi az anyagot peldaul.

Lehet, csak nem érdemes. ;) Az időkkel operál az eszköz.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

sub

Én egy NodeMCU boardra (fejlesztői board ESP8266-hoz) kötöttem a DHT22-t. Így vezeték nélkül (WiFi) töltheti fel a mért adatokat és nem csak lokális serverre. Programozhatod LUA-ban, de az Arduino IDE is ismeri. Ez fejleszteni jó, végső termékbe meg csak ESP8266-ot tennék.
Nekem annyi rossz tapasztalatom volt a NodeMCU boarddal, hogy csapnivaló pinekkel szállították, ami tönkretette az egyik breadboardom. Így most beforrasztottam fixen egy prototype boardba, ami nagy pazarlás.
Jó lenne az MKR1000 is, ha nem aranyáron mérnék.

Ave, Saabi.

Pont ilyesmi dolgozok most. Aramellatast hogy oltottad meg? Nekem ez a legnagyobb probelamam, raknek 1-2 olyan helyre is szenzort aholnincs 230V(120V). Napelemen gondolkozom, meg nem gyujtottam ki az alkatreszeket mennyivel dobna meg.

Egyelőre a NodeMCU-ba kötött USB-vel, de szeretnék majd elemest is csinálni.

Ave, Saabi.

8-bites környezetben ATXmegákat használunk (128A, 192A, 256A), nagyon szeretem őket, mert:
- olcsó hozzá a PDI programozó, könnyű programozni;
- logikus HW felépítés;
- jó dokumentáció (de nem olyan jó, mint 5-10 éve);
- jó teljesítmény, megbízható (asszem a 192A3U-t 63MHz-re overclockoltam :D, a gyári ajánlása 48MHz);
- könnyen használható linux alatt, akár magad is fordíthatsz hozzá toolchaint (én megtettem);

Néhány probléma, amivel találkoztam:
- az AVR libc bugos, nem igazán fejlesztik;
- a GCC AVR portja szintén bugos;
- a fenti kettő miatt olykor hajmeresztő hibák jönnek elő a kódban, amikre rájönni bizony nem két óra;
- ha jól tudom, akkor nem is tartják már igazán karban az AVR-es dolgokat, így az ember vagy megszokja a gondokkal és a workaroundokkal való együttélést, vagy keres másik MCU-t;
- az USB stack működik, de ott is vmi memory alignment gond van, nagyon sokat vacakoltunk, mire rájöttünk, hogy mitől fagy;
- az ADC-je botrányosan pontatlan;

Ha meg közel van egymáshoz az RPI és az MCU (mondjuk 10-30 cm), használhatsz SPI-t is, egyszerű és egészen gyors is tud lenni.

Ez tokeletes neked, es eredeti: https://www.hestore.hu/prod_10035528.html

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Feleslegesen sok szerintem.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Most valoban sok lehet, de jellemzoen noni szoktak az igenyek gyorsan, foleg hobbi teruletem, igy hosszutavon jobb befektetes szvsz.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Igazad van, de ha a méret is számít, akkor: https://www.hestore.hu/prod_10035527.html

Szinte ugyanazt tudja, de sokkal kisebb. Régen kínából rendeltem, de amióta 10e alá ment az ára, nem. Most meg látom, hogy két kabátgombért kapható. Mondjuk érdemes 4-5-öt tartani otthon. A múltkor rosszul adtam rá az áramot. A szaga kijött, vele együtt a tudása is...

Jut eszembe:
En ilyen celokra, arduino helyett elgondolkoznek egy esp8266-os torteneten is (nodemcu pl.), kicsi,olcso,beepitett wifi...

http://www.beerandchips.net/2015/12/26/making-nodemcu-lua-esp8266-weather-station/

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Sub

Ugyanezen a dilemmán voltam, ami te, van arduinom, kinlodtam vele,(valljuk be játékszer) de sok pöcsölés után arra gondoltam, hogy akkor stm32. és akkor milesz? semmi, mivel ahhoz sem értek. A kínai espvel meg robosztus alklmazást csinálni felér egy varázslattal, túl sok erőforrást igényel, olcsobb mint egy ST-s chip, de többszörösét szopod le szoftveresen. Az adafruitos scriptek semmire nem jók, ha az ember rendszerben akar gondolkodni, akkor tényleg valami komolyabb kell. Mérjük a szoba páratartalmát. Jaj de jó. És akkor milesz? Ügyes, de nem jó semmire.
Én amellett döntöttem, hogy akkor ebben is linux lesz, nem kell beszarni, kell választani egy jó SBC-t, aminek van doksija, fejlett, magaszszintű programozási nyelven lehet HATÉKONYAN fejleszteni rá, debugolható, stabil, haladós.
Raspberry pi is jó kezdetnek, de rájön az ember, hogy valojában játékszer az is. Ezért esett a választás a beaglebone blackre, aminek a lelke egy AM335x proci.

Overview , 5000 oldalas doksi

Az image builder scriptekkel olyan linuxot állítok össze, és az van rajta ami kell(4.9-es kernel már van). Csináltunk hozzá nyákot a házhoz, fűtés, szellőzés, napkollektor, külső világítás kapcsolók, kapuk stb. Rá lehet bízni. Rendszer lesz.

http://dev2.hu/gumiszoba/bb1.jpg

PL mindenhol az mcp23017 port extnder scriptekkel van i2c-n keresztül kezelve, holott van hozzá kernelmodul, GPIO deviceként mutatva az eszközt. Sikerült MINDEN végpontot úgy megcsinálni, hogy sysfs-en keresztül sima fájlírás/olvasással le tudok kezelni.

Hogy mi fut? C#-ban megírt, monoban futtatott webről konfigurálható logika.

Lesz az agy, a képen, de lesz még egy ilyen, ami a távolság miatt máshova kell tenni, a két eszköz ModbusTCP-n keresztül kommunikál. Lesz egy harmadik is, utban van egy wifi-s beaglebone, ami egy harmadik helyre megy.
Szóval én elgondolkodnék a linuxon....


------------------------
Jézus reset téged

jól hangzik! ilyesmi rendszert gondoltam ki a ház átalakításával együtt beépíteni

(sub)

Nem beszélve arról, hogy BB Blacknek van ipari változata is, ami -40 C és +85 C között is működik. Ez elég hasznos, ha padlásra kerül mondjuk.

Olyat amihez van jó debugger. A többi egy szint után önszivatás.

En most epp egy PSF-A85 -ot tesztelek. Ez egy ESP8285 alapu kis cucc, valszeg az uj arduino lesz -- mar most 2-3$ kinabol rendelve, es a beepitett wifi nagyon hasznos tud lenni, amikor rajossz, hogy interface-elni akarsz valami egyebbel.

https://www.itead.cc/wiki/PSF-A85

Amit nagyon gazosnak talaltam, az a 1.5mm -es lyukhezag. En, aki mar a .1" -essel is tokoresztem, ez bazi kicsi. Viszont hasznos, amikor a vegeredmenynek pici helyre kell befernie, fejleszteshez meg raforraszt az ember dupont kabeleket.

Szerintem ESP mellé érdemes még kipróbálni az RTL8710 alapú SoCokat. Például: https://www.pine64.org/?product_cat=padiiot-stamp

Vagy majd az ESP32-őt..

Ez a padi szinten erdekes, bar nem tudom, mennyire megbizhato az SDK-ja, sose lattam.

ESP32 iszonyat draga, 10-20 euro/db, annyival nem tud tobbet az esp8285-nel.

Off: áruld el, mikor mikró? :)

http://imgur.com/a/SkDzt

amikor pici

A cmabrigde-i etegyemen kéüszlt eigyk tnuamálny állístáa szrenit a szvakaon bleül nnics jlenestőgée aannk, mkiént rdeneőzdenk el a bteűk, eegyüdl az a fnotos, hgoy az eslő és az uolstó bteű a hlyéen lgyeen. Ha a tböbrie a lgenogyabb övsszeiszsaásg a jleezmlő, a sövzeg aokkr is tleejs mrtébéekn ovasalthó mraad. A jnleeésg mgyazraátaa az, hgoy az erbemi agy nem eyedgi btűeket, hneam tleejs sazakvat ovals.

Sziasztok,

nem nyitok új topikot. Engem is hasonló projekt érdekelne, amelett, hogy az érdekelne, ki mivel oldotta meg a hőmérséklet/páratartalom mérést vezetéknélküli technológiával a lehető leghosszabb akkumlátor üzemidővel.

Jelenleg egy esp-01-es működik egy ds18b20 modullal + 1 kondi), forrasztottam, hogy menjen rajta a deep sleep. 15 perces mérési ciklussal, 2 db mezei natúr energizer elemről elmegy olyan 15-17 napot és küldi az adatokat wifin Thingspeakre. (Gondoltam 18650-es cellákra is, de akkor meg step down konverter kellene, az is vesz fel valamennyi áramot, egyenlőre nem csináltam meg.)

Jó lenne elérnem valahogy azt, hogy 2-3 hónapig elketyegjen, mivel a lakás több pontján helyezném el, nem kellemes fél havonta körbejárni a házat, hogy cserélgessem az elemeket.

nRF51822 + OpenWRT-s router be USB-n dugva egy 4.0-ás Bluetooth adapter. Nyilván függ a szükséges hatótávtól. Kínából lehet venni fillérekért ilyen devboardokat, meg venni kell hozzá egy Segger Jlink klónt az ebayről és még debugolni is tudod majd akár Linux alól is.

Északi cég ez is mint az Atmel, jó doksijuk és példakódjaik vannak (nemcsak Keilhez hanem gcc-hez is). Arra kell figyelni, hogy a kínai modulokon random van kisebb/nagyobb flashhel rendelkező és a linkerscriptet át kell írni.

Ha mikrokontrollerrel csinálod, azt le tudod vinni alacsony fogyasztású alvó módba, amikor alig néhány nA-t, azaz észrevehetetlenül keveset fogyaszt.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mint írtam a hozzászólásomban, hogy az ESP-01-en aktív a "deep sleep", csak ettől is kevesebb erőforrásigényű cuccot keresnék.

Mondom, én hogy csinálnám. Vennék egy rádiófrekvenciás modult. Picike, elfogadható áron van. Vennék egy szenzort, mindegy, hogyan kommunikál, lényeg, hogy legyen róla doksi. Nagyjából átolvasnám, nehogy beleszaladjak valamilyen pofonba később. Vennék egy mikrokontrollert. Az én esetben kis 8 bites PIC-et, mert erre nem kell több, olcsó, miegymás. Néhány alkatrész még, hidegítő kondenzátorok, ahova kell, felhúzó ellenállások. Megtervezném a hardware-t. Ha több kell, lehet, hogy nyákot gyártatnék, bár ez nyűgös és megdobja a költségeket. Aztán megépíteném. Megírnám a software-t rá assembly-ben. Utána keresném a nyilvánvalóan létező hibákat. Az gyanús, ha elsőre működik. Az a normális, ha semmit sem csinál elsőre, egy két triviális bug úgyis lesz benne. Ezeket kijavítanám, aztán boldogan élnék, míg... :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szia,

nem értelek. Az, hogy keresek egy kevesebb fogyasztással bíró mikrovezérlőt, mint amit jelenleg használok, hogyan is jutunk el odáig, hogy tervezzek hozzá nyákot, kondit, felhúzó ellenállást és ha összerakom a végén akkor tuti lesz valami baja, mert ez így elsőre normális.

Nekem bőven elég ezek után is egy mikrovezérlő + az általam használt szenzor. Semmi konkrétumot nem írtál, így a hozzászólásod elég "nesze semmi fogd meg jól"....Abban az egyben értek egyet az alábbi hozzászólásodban, hogy felesleges erre egy bárminemű pc, minipc (raspberry és társai) + egy komplett OS.

Valahogy összekeveredtek a dolgok. Amit javasoltam, az az egyedi célhardware tervezése. Az csak megjegyzés volt, hogy nyilván nem elsőre fog működni, de ez nem probléma, ez a fejlesztés természetes része. Tapasztalat. :) Mire vagy kíváncsi? Keressek konkrét mikrokontrollert a Microchip honlapján? Annyi van, mint égen a csillag, különféle perifériák vannak beléjük integrálva. Egy ilyen szenzor olvasása lényegében hardware támogatás nélkül, esetleg egy timerrel - de az meg mindegyik mikrokontrollerben van - megoldható.

Nem tudom, mennyi tapasztalatod van ezekben a dolgokban, így nyilván kínos részemről, ha Ádám-Évától kezdem ezt mondani, miközben teszem azt, villamosmérnök vagy, de a másik véglet is szerencsétlen, ha csak körvonalazom a dolgokat, de ezzel semmit sem segítettem.

Én úgy szoktam, hogy a feladatot előbb a perifériák és a peremfeltételek felől közelítem meg: hőmérsékletet akarunk mérni kis fogyasztással, wireless elküldeni a nyerő számokat. Ehhez vagy olyan hőmérő szenzor kell, amelyik digitálisan ad eredményt, vagy analóg módon magunk mérünk, de nyűgös az utóbbi kalibrálása, a referencia pontossága, a zaj, a linearitás, a drift, szóval legyen az előbbi. Kérdés, milyen felbontás kell. Aztán mi elérhető a piacon. Le lehet-e tenni az eszközt standby-ba? Ha nem, akkor sincs baj, úgy tervezzük a hardware-t, hogy két mérés között elvesszük tőle a tápfeszültséget.

A másik a rádiós modul. Hogyan kommunikál a mikrokontrollerrel? Vélhetően intelligens, tehát vannak parancsai is, de lehet, hogy nem az. Milyen protokollt szeretnénk? Ha ezekre megvan a válasz, az is szempont, hogy 5 V, vagy 3.3 V a tápfeszültség? Tudnak-e az eszközök alkalmazkodni az elemes táplálás 3 V-jához, megspórolva a feszültség stabilizátort, így annak fogyasztását is?

Utána jön a mikrokontroller választása. Mihez van fejlesztői környezetem? A kódot hogyan tudom az eszköz flash memóriájába tölteni? Kell-e nagyon pontos időzítés, kvarc az órajel előállításához, vagy elegendő az on chip RC oszcillátor kb. 2-5 %-os pontossága? Ha ezekre mind megvan a válasz, akkor nézzük, mit árul a kereskedő, mégpedig olcsón. Ha nem lesz nyák csinálva neki, csak tiszta lyuk panel, akkor nem jó az SMD kivitel, legyen kapható DIP tokban. Teszem azt, a rádiós modul aszinkron soros kommunikál, akkor legyen a kontrollerben USART.

Ennél konkrétabb már csak úgy lehetnék, ha megtervezném. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nekem ESP-07 és ESP-12 van, öt percenként mér, 18650-es cellával, átlag kéthavonta cserélem a foglalatban a Li-ion cellát, ha azt látja az ESP, hogy csökken a tápfeszültsége.

Kicsit fáj nekem, mert nehezen dolgozom fel azt a fajta szemléletváltozást, amelyet a hozzászólásokból leszűrök itt. Van egy tipikusan mikrokontrolleres feladat, amelyet legcélszerűbb, legolcsóbb egy mikrokontrollerrel megoldani, assembly-ben programozni, a fogyasztása is elenyészően kicsi lenne. Erre ott tartunk, hogy sokan javasolnak komplett operációs rendszert, óriási hardware-t, magas szintű programozást, függvénykönyvtár hegyeket, és ennek következménye a nagy fogyasztás, az alacsonyabb üzembiztonság, a magasabb ár, a nagyobb méret.

Miért olyan nagy probléma nem előre gyártott félkész eszközökből legózni, hanem a feladatra megtervezni és megépíteni a célhardware-t, különösen, ha az igen egyszerű lesz, tiszta lyuk nyákon kivitelezhető akár? Vagy mennyivel jobb operációs rendszerrel, annak megannyi bugjával megvalósítani valamit, mint egy mikrokontroller 35 utasításából álló utasításkészletén assembly-ben programozni az egészet hatékonyan?

Tudom, változnak az idők. Azt hiszem, ezek már generációs ellentétek. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

- Time to market
- Karbantarthatóság
- Hardvertervezés költsége
- Bővíthetőség

És még sorolható. Van egyfajta romantikája az assemblynek, de azért... főleg úgy, hogy léteznek ultra low power ARM-ek, amelyek szintén programozhatóak C-ben. Ha bonyolult dolgot akarsz csinálni, akkor jó, ha van egy RTOS-ed (ha még bonyolultabbat, akkor egy OS-et, mert pl. az lwip-s tökölést nem kívánom senkinek, eleget szívtam vele ;-)), ha meg egyszerűbbet, akkor sincs túl nagy overheadje egy bare metal C alkalmazásnak, cserébe viszont
- portolhatóbb tudsz lenni
- olvashatóbb kódot tudsz írni
- stb.

Különben meg ASIC FTW!

[Off troll again]
Forth..? ~OS + nyelv egyben. Bármire hiperkönnyen rajzolható forth interpreter és AZ lesz az igazán hordozható. A C csak álmodhat a forth portabilitásáról. :D

ASIC FTW

Ez mit jelent?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

FTW = For The Win, ASIC = application-specific integrated circuit. Azt jelenti, hogy éljen az ASIC.

Köszönöm. ASIC? Hát... nem tudom. Jobban szeretem az általános eszközöket, aztán majd olyan lesz, amilyenné álmodom.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Különben meg ASIC FTW!
Azért nem mindenkinek lapul 1-2M zöldhasú otthon az ágybetétben, hogy ilyenbe belekezdjen.

Háát.
A "Time to market" egy hobbiprojektnél igen ütős érv!
A karbantahatóság egy célhardvernél szintén.
A bővíthetőségre is érdemes gondolni! Én is olyan autót szoktam venni, aminek 4 kereke van, de szükség esetén 6..8-ra is bővíthető.
Az előbbi a hardvertervezés költségéhez sorolható (lásd még: hobbiprojekt), de inkább úgy hívnám: számold meg mit akarsz. Akkor nem kell bővíthetőségben gondolkodni. Szerintem itt legfeljeb pl. 1..5 hőmérőről van szó, ami nem lehet hirtelen harminc. ;)
Azért lásd be: az itt fórumózók java része nem csak az Ohm törvénnyel nincs tisztában, de eszébe se jutna alkalmazni. Ha adatlapot olvasna, akkor sem tudná értelmezni. Sőt, arról is legalább 3-4 topic indul, hogy egy ellenállás melyik végét kösse be! ;)
Van bizony az assemblynek is egy bizonyos romantikája! Pl. egy kisebb mikrokontrollernél előforduló 3-400 szimbólumot (ami megegyezik az adatlappal) használhatod direkt. Ugyanez C-re átültetveltetve szimbólumonként lehetővé teszi, hogy 3-4x annyi szimbólumot kelljen használnod. Nem beszélve a sok tökölésről, amikor a gagyi lib hibáit kerülgeted, vagy inlájnolod azokat a dolgokat, amit a C nyelv sajátosságai miatt nem lehet kifejezni. Tudjuk, egy java programozó számára szinte lehetetlenség megtanulni azt a 35..90 utasítást, mert szegénykének tele van a feje azzal a jó néhán ezer class összes propertijével. Amiről persze az igazi java programozóknak fogalma sincs, mert általában pongyola. :( Szóval assembly=szar, mert gondolkozni kell a pontos kifejezésen és kiejtésen!
Azért megemlíteném, hogy egy ARM inkább magasszintű nyelv támogatására készült, míg a 8 bites PIC családok meg nem (van olyan, aminél van ilyen mód, de az inkább kínlódás). Ha megnézed a PIC választékát, ezerszer jobb célhardvereket tartalmaznak. A hardvertervezés java része sok esetben a megfelelő típus kiválasztásával megtörténik. Természetesen nem a gugli által talált "népszerű" kapcsolásokban, amik 10++ éves típusokat használnak.
Persze egy DHT22 driver (lásd a forrását a github-on) portolása biztosan lényeges lehet. Valamint könnyen megoldható, ha pl. soros interrupt kezelésről vektorosra írod át, mert utána már csak pár sor marad. És különben is egy célhardvert hova szeretnél hordozni? Talán egy 6 lábú pic kódja fusson mainframen is? Megoldható, de minek? Hiszen a magára az rpi-re írt kód sem fut rpi-n. ;)
Az assembly (legyen inkább macro assembler) kiválóan olvasható kód írását teszi lehetővé. Persze kicsit hazudtam. ;) Sokkal jobban tette a dolgát, amíg C és C++ agyúak nem kezdék el írni! Persze csalódott lehetsz, ha egy magasszintű struktúrált nyelvként szeretnél olvasni egy olyan kódot, ami "közvetlenül a hardverrel beszél". Megfordítva pedig egy mikrokontroller utasításkészlete pont olyan dolgokat támogat, amit a struktúrált nyelv nem nem szeret. Tehát az assembly jól olvasható annak, aki el tudja olvasni. ;)

Azért mikrokontroller alatt nem feltétlen a PIC-et kell érteni... lehet helyette pl. i8051, AVR vagy MSP430-at is használni.
Ha berendezkedsz valamelyik mikrokontrollerre, akkor nagyon jól el lehet lenni vele assembly-ben is, makrókkal tényleg kényelmesen lehet programozni.

Átjárni viszont gyakorlatilag nem fogsz közöttük, C nyelven viszont írhatsz olyan kódot, amit nem túl nagy erőfeszítéssel más kontrollerre is le tudsz fordítani.
...és nem feltétlen kell C alatt sem mindenféle "gagyi lib"-et használni, ha adott funkciót magad implementálod (ahogy tennéd assembly esetén pl.).

Kicsit másképpen: alapvetően a C nyelv használata nem feltétlen hoz az ember számára akkora hátrányt, mint amennyi előny származik belőle...

Épp csak elbukod, amit assembly-ben lehet. Például azt, hogy elágazás esetén ugyanakkora legyen a futásidő.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Miert buknad? A legtobb fordito tamogatja az assembly beteteket.

Egyebkent meg ugy kell megtervezni a programot, hogy ne legyen szukseges egy elagazas ket aganak pont ugyanannyi ido alatt vegrehajtodni ;-) De tenyleg, mi van, ha jon egy nagyobb prioritasu interrupt kozben? Maris buktad az ugyanannyi idot.

/sza2

Egy olyan kontrolleren, amelyen még megszakítás kezelés sincs? Talán 2 mélységű a stack, de nincs push és pop, csak call és ret. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

De az a baj, hogy ma már egy annál többet tudó kontroller is hozza a pici előnyeit. Avagy: miért használj olyat, aminél "művészkedned" kell, ha a picivel nagyobb is van olyan jó, és sok felesleges kört megspórolsz?

Vannak ilyen kontrollerek, ez tény.

Ha nem abból indulok ki, hogy ismeri az adott kontrollert az ember, akkor viszont nem biztos, hogy ilyen kontrollert használnék...
...és a végeredmény nem feltétlen lenne rosszabb, sem nagyobb fogyasztású.

Ha ismeri az ember és ezt akarja használni, nyilván nem fog rá C-ben programozni.
...de manapság nem kevés olcsó kontroller van, ahol nyugodtan írhatod a programot C-ben is...

Azert valljuk meg, mindig ugy alakitani a felteteleket, hogy Neked legyen igazad, nem tul elegans ;-)

Legalabbis eddig Te is hoztad a interruptos peldakat, most meg azt mondod: "amelyen még megszakítás kezelés sincs".

Volt / van egy-ket kollegam akiknek hasonlo volt a velemenyuk, de igazabol csak arrol volt szo, hogy mivel a C-hez nem ertettek, konnyebb volt azt mondani, hogy assemblyben mindent / jobban meg lehet irni. Mostanra azert rajottek, hogy ez nem mukodik igy, muszaj (pl. / leginkabb) C-ben is tudni kodolni.

Egy USB vagy mesh networking stacket megirni assemblyben nagyon kenyelmetlen tud am lenni, pedig a mai kontrollerek siman elboldogulnak vele.

BTW, a forditott assembly kodot is megtekintheted a legtobb esetben, es ha latod, hogy a forditonal esetleg jobbat tudnal csinalni, megteheted. De azert lassuk be, akik a forditokat csinaljak, azok sem teljesen hulyek, meg ha vannak is hibak a forditok kornyeken.

/sza2

Az, hogy mozgó célpontra lövünk, nem kiszúrás volt részemről, valóban csináltam ilyen kontrollerrel valami triac-os időzítő kapcsolót, magam sem emlékszem pontosan már. Lényeg, hogy ehhez nekem egy 8 lábú, legolcsóbb, legbutább PIC épp tökéletes volt. Egy olyan feladatra, amelyet majdnem egy monostabil multivibrátorral is meg lehet oldani - na jó, azért nem -, valahogy eszembe nem jutna ágyúval verébre, 32 bites kontroller, vagy sok RAM, oprendszer, toronyóra lánccal.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Pedig építhettél volna diszkrét áramkört is PIC helyett, micsoda pazarlás a PIC...

...meghúztál egy vonalat - szinte teljesen szubjektíven, ami szerinted egy racionális vonal, mások pedig máshol húznak meg ilyen szubjektív vonalakat, mert szerintük máshol van a racionális határ.

Persze, lehet azt mondani, hogy megspóroltál tíz centet az olcsóbb eszközön és lifetime megspóroltál további tíz centet a fogyasztásán, de közben két nappal tovább használtál egy 50-100 wattot használó számítógépet, hogy megírd C helyett alacsonyabb szintű nyelven a szükséges programot és további napokat, hogy kiegyensúlyozd a program összes ágát. Nem mindig az olcsóbbnak tűnő megoldás az olcsóbb...

Milyen mcu-ra gondolsz, ami ennyire low-end?

Én a legalja RS08-at ismerem, azon ugyan SPC (shadow program counter) van, így max szoftveresen tudsz nested subrutine call-t, de azért kezel interruptokat (bár nincs vektor tábla és szoftveresen kell kideríteni a forrást). Freescale időkben 50-100 Ft/db között mérték.

A PIC10F200, ami most hasonló árkategóriájú, ugyan csak 2 mélységű hw stacket tartalmaz, de van egyfajta interrupt kezelése, annak ellenére hogy az interrupt szó nem szerepel a datasheeten.

Az Attiny4/5/9/10 pedig tök normális stacket és megszakítás-kezelést tartalmaz.

Mindennek van előnye és hátránya is...

Másrészt manapság elég jól ellátott kontrollereket kapni olcsón, amivel megvalósítható az adott feladat.
Ha meg annyira időkritikus valami, akkor még mindig fordulhatsz assembly felé...

Most már beszéljétek meg bucko-val, mit akartok: hobbiprojektezni (ahol ez elég ritka), vagy "céges" tervezést - ahol meg jó esetben ellenjavalt, l. a hozzászólásom, amit bucko lehúzott. Speciel ott tapasztalatból írtam, amit írtam: fölösleges időket vett el egy projektnél az, hogy az egyik szintaxissal írt inline assemblyt (ami a proprietary fordítóhoz járt) kellett átírni egy másik szintaxisra (ami meg valami gcc-szerűhöz kellett). Minden más része a kódnak rendben volt, hordozható volt, de ez a része nem. Kellett az assembly-betét (lényegében cache prefetch meg hasonló dolgok voltak implementálva), de rengeteg időt elvett, amit sok esetben nem engedhet meg magának az ember.

Van értelme az assemblynek, persze. Viszont a trendeket nézve azt tapasztalom, hogy a tiszta assembly nyelven készült projektek szorulnak ki. Lehet utána szomorkodni, de attól még tény.

Egyébként pont a példád olyan, hogy szép, de sérülékeny (l. az említett IT-t, vagy a később hozzáírt kódot, stb.). Van eset, ahol kell, de azért... Dolgozzatok kettőnél többen egy ilyen munkán, akkor azért már gondolom, macerásabb. Vagy ha át akarod adni a kódot másnak. (Ne jöjjetek a hobbiprojekttel, mert akkor meg fogom kérdezni, hogy oda meg tipikusan miért kell assembly)

Azért jó az assembly, mert egyszerűbb, mint a C, látod, mit csinálsz, s hogyan, optimális, gyors, minden pont úgy történik, ahogy szeretnéd. Kényelmes nyelv, minden úgy kezelődik, ahogy megírtad, nincsenek kötöttségek, csak a fantáziád és a hardware szab határt.

Egy kis mikrokontrolleren miért dolgoznának többen? Egy 1500 soros assembly kódon? Minek?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha nem látod a C programozás előnyeit, akkor minden bizonnyal nem ismered eléggé.

Nagy tételben merek fogadni hogy a compiler gyorsabb kódot fog összerakni mint amit te meg tudsz írni. Nagyon ritkán van szükség _pontos_ lefutási időre, általában az a kérdés hogy lefut-e elég gyorsan. Ezt a compilerrel is simán hozható.

Ha pontos időzítesre van szükség, akkor is jó eséllyel inkább timerrel kell megoldani, gondolom ennek az előnyei egyértelműek. (Ha másra nincs is szükség, legalább mehet sleepbe a controller)

Persze van olyan hogy ezek ellenére inlineolni kell, de egyrészt ha normális fordítód van akkor ez nem nehéz. Meg a makrók megkönnyítik az életet ilyenkor is. Tipikus adatkiviteles időzítéseket remekül el lehet rejteni inline fgv jellegű makrók mögé.

Ne érts félre, nem azt mondom hogy lehet a controller ismerete nélkül C-ben jól programozni. Nyilván az ember elolvassa az assembly utasításkészletet, becslést csinál a futásidőkre, és figyel arra hogy a fordító rendes munkát végezzen. De egy C-kód nagyságrendekkel átláthatóbb, hordozhatóbb lesz. Ma már szerintem tisztán assembly programhoz foggal-körömmel ragaszkodni nem több mint fanatizmus.

De függetlenül az assembly-c vitától: a témaindító egy komplett raspberryt üzemel be egy pár szenzor miatt - és miért ne tehetné? Ebben a felhasználásban szerinted nem teljesen mindegy hogy az illesztésre használt mikro ki van-e használva vagy optimális program fut-e rajta? Ha arduinoval össze lehet ütni tized annyi idő alatt - már pedig lehet - akkor össze kell ütni. Már a ”jó megoldás” kigondolása többe kerül, mint amit a cucc teljes élettartama alatt nyersz árban és fogyasztásban együttvéve.

Én is a compilert tartom jobb választásnak az assemblerrel szemben, de arra nem mernék mérget venni, hogy egy adott részfeladatra gyorsabb kódot generál egy compiler, mint az assembler, mivel a compiler íróinak egy csomó általános dologra is kell figyelniük, amiket az assembly-ben programozó ki tud hagyni a kódból, mert ő nem általános esetet old meg, hanem azt a konkrét esetet, amin dolgozik.

Számomra nem vitás, hogy melyik kód lesz a kisebb és gyorsabb, de az esetek többségében nem kicsi és gyors kód kell, hanem rövid fejlesztési idő, amiben viszont sokkal jobb egy magasszintű programozási nyelv az assembly-nél.

Én is ezt gondoltam a compiler vs assembly esetről, aztán volt egy egyetemi előadásunk ahol élőben verték rá köröket a professzorok kódjára compilerrel.

(*Igaz, itt 8085-ről van szó, és csak sebességről. A kódméret általában nagyobb)

A "trükk" a C-kód megfelelő hintekkel ellátása, így a compilert, meglepően specifikus kódot tud adni. (inline, volatile, const, enum-ok)

No igen, ha a változó nem volatile, s az valójában egy memóriába ágyazott periféria, vagy RAM ugyan, de az üres ciklus időt húz, akkor a compiler az optimalizálás oltárán áldozza fel, amit a programozó nagy műgonddal leírt. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt így nem deklaráltam, de amire válaszoltam az PIC vs AVR volt. Az i8051 egy jócskán felturbózott, de ősi processzor. Annak idején megnyaltam volna a tíz ujjamat, a töredékét tudja a mainak. Az MSP430 kifejezetten tetszik, viszont nincs lehetőségem foglalkozni vele. Mivel "termelek".
Tényleg az "ősi" időkben i8085-tel dolgoztam, gyakorlatilag 3 tokból kész volt a mikrogép. Ma viszont a munka tárgya a PIC. Mivel hardverfejlesztő és assembler programozó (is) vagyok vagy 33 éve, de C-ben is programoztam már úgy 25 évet, (mások szerint is) értek hozzá egy keveset.

Most éppen itt tartok:
Program Memory Bytes Used: 9762
Program Memory Bytes Free: 6622

A kódhoz még hozzáfejlesztek két funkciót. Ugyan van egy másfélszer nagyob flash-sel rendelkező típus ugyanebből a kontrollerből. Tíz megszakítás forrást kezelek, szinkron mérek, miközben néhol legfeljebb 6us hézag van az időben. Maga a szerkezet 4x4cm és van rajta 85 alkatrész. Kontroller cserére nincs lehetőség, mert a harmadik hasonló terméket programozom, közben tervezem a negyediket. Szóval nem modhatom, hogy holnaptól áttérek rpi-re, vagy bármi másra.

Saját libet fejleszteni nincs értelme. Ha egyszerűbb és lassú a feledat, akkor az ahhoz tartozó szubrutinokat kirakom egy .inc-be (elfelejtetem említeni: csak abszolút kódot írok), és felhasználom többször is. A gyorsabb futást igénylő részeket a feladat függvényében általában újra meg kell írni. Az egyes szegmenseknek - itt 3 van - más a kódvédelmi beállítása, emiatt "kézzel linkelek". Így oldom meg a kódvédelem miatt más-más szegmensbe kerülő programrészek elhelyezését. Közben ügyelek az egyes szubrutinok elhelyezésére, hogy egy-egy bájttal rövidebb legyen a szubrutin hívás. Természetesen a felesleges paraméterátadások és regiszter mentések számát is csökkentem.
Szóval legyen a 16k helyett 24k flash! Azt állítom, hogy ezt meg lehet írni C-ben is. A munka legalább 2-3x annyi lenne, amíg
- elmagyarázom a fordítónak, hogy mit hova tegyen, bár ez csak akkor derül ki, amikor a keletkezett kóddarab mérete is kiderül
- az időkritikus részeket mégis megírom asm-ben, ráadásul a konvenciótól eltérő módon
- mivel a C sokszor értelmetlen dolgokat is művel, néhol bizonytalan lesz a futásidő, amivel külön foglalkozni kell
- végezetül talán bele sem fér a 24k-ba.

Tehát ez a 8 bites PIC már "elfogyott"! A PIC18 típusra készült programot hordozni kellene egy PIC24-re, azaz 8 bitről 16 bitre. Van egy makró gyűjteményem, és néhány szubrutinom. Pici munkával ezeket utasításokra fogom cserélni, mivel "teljesen véletlenül" úgy írtam meg őket. ;) Van egy csomó munkaregiszterem a ram-ban, de a PIC24 1 helyett 16 munkaregiszterrel rendelkezik. Ezt egyszerű "rename tevékenységgel" át lehet írni. Az aes256 meg hardveresen benne van, védett kulcstárral...
Csak egy példa: Van egy másfél oldalas 10x16bit->24bit szorzásom, a PIC24 meg rendelkezik kb. ilyen utasítással. Ha ezt C-ben írom, akkor le kellet volna cserélnem asm betétre a futásidő, memória használat stb. miatt. Ennél egyszerűbb volt csak úgy megírni.

Amivel egyáltalán nem vitatkozom: Egy ledvillogtató program mondjuk 10 sor. Bármiben írva! :)

Apropó, optimalizálás. Z80-as kódom nem fért bele 4 kiB-ba a 2732-be. Megnéztem, melyik rutint hívom a legtöbbször, majd az összes 3 byte-os hívást 1 byte-os RST 0-ra cseréltem. Azt, hogy a nullás címre ugrás reset vagy RST 0 miatt volt, úgy állapítottam meg, hogy talán az R regiszter legfelső bitje törlődött reset hatására, vagy fene sem tudja, de valahonnan ez kideríthető Z80-on. A frissítés 7 bites, csak az R[6:0] inkrementálódik, a felső bitje létezik, írható, olvasható, de nem romlik el. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyfelől: assembly és Java közt van azért rengeteg szint. Másfelől kérlek, ezt az arrogáns, lenéző stílust ne nekem (inkább senkinek). Ezt köszönöm szépen.

Elég sűrűn olvasok assembly kódot (már csak a hobbi-processzorom miatt is), de ennek ellenére továbbra is állítom, hogy az esetek 90%-ban nincs igazán előnye. Hobbiprojektnél - hacsak kifejezetten nem assemblyzés a cél - elveszi a hangsúlyt a lényeges dolgokról, ipari munkánál meg l. fentebb.

Amikor szükség van rá, akkor persze marha jó dolog.

Ha úgy érzed megbántottalak, akkor bocsánatot kérek!
Azért egy kicsit kimagyaráznám. Az egyik rész nem arrogancia, hanem csak cinizmus volt. Az azért nem annyira súlyos. Csak annyit próbáltam érzékeltetni, hogy a hobbiprojekthez képest túlságosan nem ide illő szempontokat soroltál fel.
Az assembly-java nem összehasonlítás, hanem egy java (C++, C#, stb.) programozó kifogása. Ez tényleg egy harmadik személy lenézése, de nem érzelmi (vagy antihumánus) szempontból, hanem sok-sok esetben tapasztalt, pontatlanságból eredő kollegiális szivatás ellenérzése.
A lásd fent az a cache prefetch assembly betét? És már megint mellélőttél! Melyik 8 bites mikrokontrolleren történt ez? :)

Ami viszont tényleg arrogáns a kezdő, avagy mindenhez érteni vélő hardveresekről szólt. Ha magadra vetted, garnatálom másokról van szó.
Egyik az "elődöm" a jelenlegi munkahelyemen. Még egy ilyen pocsék, dilettáns, felületes munkát végző emberrel nem találkoztam! Igaz nem is találkoztam vele, csak a termékein keresztül. A mindennapos rutin kb. így néz ki: Szól a főnök, hogy ebből a (kb. 5 alkatrészből álló) termékből már eladtunk X csilliót. Most meg összeraktunk 20db-ot és mindegyik téveszt! Állítsál már át rajta egy értéket! Megnézem, és rögtön találok vagy 10 dilettáns tervezési hibát. Nem, ez soha nem volt megtervezve. Talán csak irigykedek, hogy ilyen felületességgel hogyan sikerülhetett ebből ennyi példányt eladni? ;)

Úgy gondolom nem kifogásolod azt a munkamenetet, hogy a hardvert megtervezzük, majd programozzuk.
Tehát pl. egy ADC alkalmazása esetén
- a szükséges mitavételi frekvencia
- mintavételi törvény ->bemeneti szűrő
- a bemenet alapján beállítjuk a mintavételezési időt
- egyéb jellemzők alapján esetleg szoftveres szűrés kiszámítása és alkalmazása
- megjelenítés

Mindez C programozás esetén a következőképp történik
- ReadADC()
- megjelenítés

Tudom, ez pesszimista, rasszista, arrogáns, elítélő stb. vélemény. De az esetek 90%-ában ezt tapasztaltam, ha a program C-ben készült.

Time to market
Egy perifériát akartam programozni.
1) Beegereztem az adatlap mintaprogramját. Meg se nyekkent.
2) Mikroelektronika C libből, a helyzet változatlan.
3) Microchip C, nekik csak működik, de a helyzet változatlan.
4) Megírtam, működött.
Közben méricskélni is kellett, és legalább 4 esetben előfordult hasonló.
Az 1-3 pontok általában 1-2 napig tartottak, míg a 4. 1-2 órát. Ha Te lennél a főnököm, mit javasolnál?
Tudom, kirúgnál. ;)

Ettől én is falnak megyek. Találkoztam olyan esettel, ahol 30 másodpercig bootolt a !villanykapcsoló!, mert egy kapcsoló és egy relé vezérlése egy teljes rpi-re lett bízva. wtf? why?
Egyébként meg ugyan úgy lehet legozni egy arduino-val is mint egy rpi-vel, csak töredékébe kerül és megbízhatóság tekintetében messze veri, szóval ez nem lehet érv. Szintén nincs szükséged assembly-ben való programozósdira, mert minek (vannak olyan feladatok ahol kell, de az esetek 99%-ban nem).


// Happy debugging, suckers
#define true (rand() > 10)

Jó, nem is a C nyelv volt a legnagyobb bajom, hanem a többi. Bár a magam részéről jobban átlátom, amit assembly-ben írok. Érdekességképpen csináltam triac-os kapcsolót, amely néha adott hangot, ha úgy tetszik, csipogott. Nagyon kis PIC, még megszakítás kezelés sincs. A hang generálásához fix ciklusidőkre van szükség, de a programban itt-ott elágazások voltak bőven. Minden esetet végig kellett diszkutálnom, az összes elágazás esetén ugyanakkora futásidőt kellett biztosítanom. Jó, és? Megcsináltam. Ez assembly-ben minden nehézség nélkül kézben tartható, de ötletem sincs arra, C-ben hogyan lehetne. Szerintem sehogy.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Persze, ahol az időzítés kritikus, ott az ember nem ússza meg az assembly-t. C-ben erre esélyed sincs :)


// Happy debugging, suckers
#define true (rand() > 10)

Egyrészről minden elismerésem annak hogy ezt meg tudtad oldani. Másrészről viszont - hacsak nem milliós darabról van szó - biztosan kirúgnám aki így választ hardwaret, mert a fejlesztés jó eséllyel sokkal többe került mint egy nagyobb, megfelelő IC.

én nem mennék olyan helyre dolgozni, ahol a főnököm hozzá nem értése olyan szintig fokozódik, hogy egy egyszerű probléma esetében az ágyúval verébre megoldást alkalmazza, sőt, nem feltétlen hosszabb idővel (inkább rövidebbel) és olcsóbb megoldásom ellenére még ki is rúgna


// Happy debugging, suckers
#define true (rand() > 10)

Nem mondtam, hogy kötelező lenne a ló túl oldalára átesni. :-)

A jelenlegi piaci trendek alapján általában a fejlesztői idő nagyon drága.

amit ha választani lehet, célszerű lenne a szövegértési problémák orvoslására fordítani


// Happy debugging, suckers
#define true (rand() > 10)

+1,
En is igy latom, ilyen feladatra boven eleg egy mikrokontroller, nem jell ide linux meg egyeb hibalehetoseg.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

És akkor még a valósidejűség problémájáról nem is beszéltünk, ami egyébként ezt a topikot ihlette.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

C-ben is vígan írnak valósidejű programokat, véletlenül tudom. Ijesztő talán számodra, de biztonságkritikus rendszerbe is.

Sőt - bár ez tényleg durva, már én is csóválom a fejem - Linux alatt is írnak (és nem az RT ütemezési szintre gondolok).

Az L4, L4Linux és társairól meg nem is beszélve: ahol megfér egymás mellett egy RT és egy nem RT OS: ugyanazt a processzort használva.

Nem is beszélve az ARM Big.Little-ről.

Szóval azért árnyaltabb a világ.

Jó, csak amikor azon sakkozol, hogy az IT rutinban valamit hamarabb csinálsz meg, mintsem ments egy regisztert, mert különben valamiről valamelyik hardware lemarad, akkor nem tudom, hogyan segíthet a C fordító. Tudom, lehet assembly betétet írni bele, de szerintem egyszerűbb, kényelmesebb - nekem mindenképp - az egészet assembly-ben intézni. De el tudom fogadni azt is, ha valakinek meg nem.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

No, konszenzus alakult ki, ez is ritka manapság a hupon, köszi! :-)

A magam példájából kiindulva azt mondanám, hogy aki most ismerkedik ezzel a témakörrel az talán azzal szemlélettel találkozik inkább, hogy oldja meg amennyire lehet szoftveresen (hordozható, könnyen másolható stb). A szoftveres megoldás készen van már milliószor és "csak" portolni kell vagy még azt sem. Talán ezért a sok szoftveresebb szemléletű válasz.
Sose tanultam hardware "fejlesztést" és momentán azt se tudnám, hogy a megfelelő alap tudást honnan is szedjem össze (nyilván internet), de azt még zöldfülűként is látom, hogy ha az ember valami megbízható, alacsony fogyasztású, kevés elemmel operáló (= alacsony hibaszázalék) cuccot akar, akkor bizony magának kell összelegóznia.

De ez csak szvsz.

szerk: Részemről egyébként lenne igény tematikus hardware fejlesztéses "szakkörre". Ezért is örültem meg, hogy ilyesmi témában indult meetup mostanság.

Na jó, de mit vár valaki üzembiztonság terén, ha mindenféle fércművekből összeollóz valamit, de nem biztos, hogy tudja, az eredeti megalkotó milyen feltételekhez hozta létre azt a library-t? Még saját magamnak sem írok könyvtárakat, mert annyira egyedi, feladattól függő minden. Nagyon nem mindegy, hogy néhány kHz-cel csapkod be valami timer IT, vagy néhány 10 Hz-cel, mire van idő, el kell-e altatni a kontrollert az alacsony fogyasztás miatt, vagy azért, hogy az A/D konverzió zajmentes környezetben történjen. Ezeket napestig sorolhatnám. Ezek után hogyan oldanád meg néhány billentyű kezelését? Hosszú gombnyomást detektáljon? Olyat tudjon, hogy adott időn belül többször nyomják meg a gombot? Pergésvédelem nyilván legyen. Esetleg 230 V-ról jár az egész, s lehet, hogy kis kitöltéssel ott az 50 Hz a porton, amit viszont nem zárnál le túl kis ellenállással, mert akkor meg a portot elhúzó ellenállásnak több wattosnak kell lennie, s nem kályhát terveztél? Igen, semmi baj, ez is eliminálható software-ből. Van az IT rutinnak futásidő szempontjából kritikus része? Egyáltalán mátrixban vannak a billentyűk, mert elég sokan vannak ehhez? Hosszabb ideig elalszik a berendezés, s gombnyomásra fel kell ébrednie, mint például egy TV távirányítónak? Ez megannyi egyedi igény, s mind-mind más megoldásért kiált.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Aki összeollóz valamit, azt örül, hogy működik és nem igénye az üzembiztonság. Különféle tudásszint különféle kivitelezési minőséget produkál. Aki hobbiból először csinál valamit, az örül ha van egy boardja ami leméri a hőmérsékletet pontosan, aki a saját házába rakná be 0-24 wireless és alacsony fogyasztásra, az meg hegeszt amíg el nem éri a célját.

Szerintem te erosen felrertesz minket kokanyolo hobbistakat. En pl a felet nem ertem annak amit fent irtal, es legyunk oszintek, nem is akarom erteni. Es ASM-ben sem akarok kodolni. Viszont szeretnem tudni mennyi a homerseklet _nagyjabol_ a furdoszobaban, a teraszon, a nappaliban, stb. Az eloregyartott alkatreszeket $1-$3-ert lehet megvenni, ergo pitianer osszegbol lehet itthon legozni es ilyen projectekkel elb*szni az idot, meg mindig jobb mintha piaznek/szerencsejatekoznek vagy cigiznek. Uzembiztonsag? WUT? Nem, arra nincs szukseg, csak tudni akarom hany fok van a furdoszobaban. Valoszinuleg sokan vannak hasonlo cipoben mint en. Szoval azt kene megertened hogy itt mi nem szakmai igenyessegre torekszunk, hiszen nem igeny, es a tobbsegunknek messze nincs hozza megfelelo tudasa ehhez, es nem is kell hiszen ez egy otthoni hobbyproject.

Régebben nem volt ennyire kinyalva az ember segge, mint most. Volt egy vagy több assembler az adott CPU-hoz, és kész. Nagyjából azt tudtad megírni benne, amire önerőből képes voltál, nem lehetett "guglizni", ahol özönlenek egy problémafelvetésre a találatok, már csak ki kell választanod a neked tetszőt (meg ki kell dobni a használhatatlan, hibás és félrevezető információkat). Abban az időben nekem mindent assembly-ben kellett megírni, a legszörnyűbb matematikai műveleteket is, amíg nem tudtam hozzájutni egy compilerhez. Ez történetesen egy Pascal compiler volt, ami tetszett, mert amúgy is Pascalt tanultam korábban. Nekem baromi sok időm elment a programírással assembly-ben, annak ellenére, hogy használt az ember makrókat is, szubrutinokat is. Amikor lett Pascal compilerem, látványosan felgyorsult a programfejlesztés, utána már csak azt írtam assembly-ben, amit muszáj volt ilyen-olyan sebességpoblémák miatt. Először furcsa volt a nagyobb lefordított kódméret, de EPROM-ból is lettek egyre nagyobbak, szóval nem volt tragédia. Elkényelmesedtem, hamar meg tudtam szokni a jót. Természetesen látom az assembly előnyeit, finoman szólva nem hátrány, ha az embernek van fogalma róla, hogy mit csinál belül a CPU, de a hátrányait nagyobbnak érzem. Minden tiszteletem azé, aki a mai napig assembly-ben programoz, de azért örülök neki, hogy nem kötelező mindenkinek :)

Amúgy a hobbistáknak is ajánlom, hogy egy kicsit ismerkedjenek a gépi kóddal, mielőtt nekiesnek pl. egy Arduino IDE-nek (csak elsőre ránézésre tűnnek olyan szörnyűnek a mnemonikok), mert olyan szemléletet ad, ami mindenkinek hasznára válik a későbbiekben.

+1

(meggondoltam magam...)

Nem mindegy, milyen projektről van szó. A szoftvert egyszer kell megírni, a hardvert minden egyes darabhoz meg kell venni.
Ha csak egy-két darabról van szó, akkor inkább többet kell megoldani hardverből, úgy hamarabb megvan a szoftver.
Ha százezer darab kell valamiből, netán még sokkal több, akkor minden egyes alkatrész beépítését jól meg kell gondolni, és inkább a szoftverre kell bízni a dolgokat (de ez nem az én asztalom, 10-20 darabnál többet még nem kellett csinálnom semmilyen kütyüből).
Saját dolgoknál, kisszámú példány esetén a kettőt lehet ötvözni is, ha úgy tetszik, optimalizálni, kicsit lehet spórolni a hardveren, viszont kicsit többet kell írogatni.
Az sem mindegy, mennyi idő van a fejlesztésre, a határidő nagy úr. Ha valaki csak magának barkácsolgat, az nem ugyanaz, mintha ott áll mögötted a megrendelő, és már be akarja építeni az elektronikát a berendezésébe, mert rajta meg azt kérik számon.

Van azért itt más is. Például watchdog illetve brown out reset. Jön egy megbicsaklás a tápon, vagy egy lórúgás hálózati tranziens. Az említett okok valamelyike miatt reset lesz. Mennyi idő alatt áll fel ebből egy mikrokontroller? Néhány 10 ms jellemzően. Ha ügyesen csinálja az ember, megfelelő állapotváltozók segítségével, s azzal, hogy különbséget teszünk ezek, és a power on reset között, észre sem fogjuk venni az eseményt. Ezzel szemben mennyi ideig áll fel egy oprendszer? Mellesleg ez utóbbinak vagy RAM-ban van az a filerendszere, amelyikre dolgozik, de a reset hatására ugrik minden, vagy valami háttértáron, de akkor meg a konzisztencia meg a disk cache, vagy ha az nem, a korlátozott írhatóság fog gondot okozni. Ebből nem igazán tud jól kijönni egy oprendszer, pláne nem úgy, hogy az átmeneti bajság észrevétlen maradjon.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Eszemben sincs a mikrovezérlős megoldással szemben az oprendszerst erőltetni. A hardver/szoftver arány alatt azt értem, hogy ha pl. nagyobb teljesítményű, nagyobb tudású, több perifériával rendelkező mikrovezérlőt választok, akkor nem számít annyira, hogy mekkkora lesz a szoftver, mennyire lassan fut, amikor nem kell pl. egy soros kommunikációnál szoftverből kezelnem minden egyes bit küldését és fogadását stb. Régebben ez nem volt mindegy, minden alkatrésznek súlyos ára volt, ma megvan minden szinte fillérekért. Az őskorban kellett külön-külön CPU, EPROM, RAM, timer, U(S)ART, ADC, DA stb. A mikrovezérlők megjelenésével ez sokat egyszerűsödött. Később már I2C, SPI, CAN, USB, akármi is került bele, ma már olyan hardvert választasz, amilyent akarsz. Ha meg inkább szoftvert "akarsz" írni, akkor veszel olyan mikrovezérlőt, ami kevesebbet tud, vagy azért használsz olyant, mert valamelyik projektből megmaradt pár, és ott van a fiókban.

+1

Azért, mert hobbiprojektet is a legtöbbször fejlesztési időre optimalizál az ember. Én amúgy nagyjából veled értek egyet, de mivel a forrasztgatást nem szeretem, én Arduino UNO-val csinálnám. Az egy jó kopromisszum, mert biztosan működő HW-t kap az ember, de amit csinál, az egy az egyben átültethető egy kisebb uC-re, ha már a kellő magabiztosság megvan a tervezés terén. Ha valaki új területre lép, akkor a lehető legkevesebb bizonytalansági tényezőre vágyik. Ezért nem akar egyszerre három új dologgal kezdeni: HW tervezés, HW építés, Assembly programozás. Arduinoval C-ben programozva jóval kevesebb új dolgot kell tanulni kevesebb hibalehetőséggel.

Jó, végül is ez egy teljesen legitim érvelés.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért elmesélem, hogyan működik ez profi módon. ;)
A halacskánknak (szemünk fénye!) készítek akvárium vezérlést. Sikerült finanszíroztatnom egy hasonló, de látszólag teljesen más projektet. Ezt - bár icipicit keresek rajta, de nagyjából nonprofit csinálom.
Melléktermékként Ficánka is kap egy IP alapú akváriumot. :)

Nagyjából én is így csinálom, csak Atmega32u4 alapú boardokat használok kínából mert az olcsóbb. Rendes avr C-t szoktam írni, az arduino kód túl lassú tud lenni.

Ebben a topicban mostmar eleg szeles paletta elojott a leggyengebb 8 bites kontrollerektol a Raspberry Pi-ig.

Ha a sajat tervezes belefer a projectbe, erdemes elgondolkodni 32 bites mikrokontrollerekben szerintem. Manapsag egyre tobben gyartanak valamilyen (leginkabb ARM Cortex) eszkozt, igy az aruk szinte osszemerheto a 8 bitesekkel. Fogyasztasban is lassan jobbak mint a 8 bitesek, a legtobbnel a nem hasznalt periferiak kikapcsolhatok ha eppen nincsenek hasznalatban. Nagyreszuk tobbfele sleep modot tamogat, adott esetben extrem alacson fogyasztassal (pl. 1+ ev CR2032-rol). Rengeteg fele periferiaval osszerakjak oket, szinte biztosan talal maganak mindenki olyan ami eppen szukseges. Altalaban jelentosen tobb RAM es flash all rendelkezesre mint a 8 bitesek eseten, es nem kell olyan elcseszett memoria strukturaval szenvedni mint pl. 8051 eseten (tapasztalat, hogy mit lehet szivni, mikor nem fer bele az ember 256 byteba). Raadasul eleg sok gyarto ad hozza IDE-t, legtobbszor ingyenesen.

Nekem eleg eros ervek kellenek a 8 bites mellett, hogy azt hasznaljak, a merleg nyelve altalaban az 32 bitesek fele billen mostanaban, kulonosen hobbi project eseten, amibol nem 1 millio darab lesz, csak nehany (esetleg egy), ahol nem az a legnagyobb tetel, hogy az 200Ft-os 8 bites helyett 400Ft-os 32 bites lesz a "termekben"

Ha mar szoba kerult az eszkozok kozotti kommunikacio, akkor ez
<reklam>
EZR32
</reklam>
erdekes lehet. Kis fogyasztas, radio + Cortex [M0|M3|M4], eleg sok IO. Gyakorlatilag erre talaltak ki (IoT rulez! ;-)

/sza2

Én az STM32 családot kezdtem el használni néhány helyen... egész jó kiindulási alapot adnak hozzá, van hozzá támogatott GCC fordító és library-k is, valamint egyszerűen üzemre bírható Linuxon.
Igaz, magasabb szinten kezeli az ember a hardvert (bár attól is függ, melyik library), de gyors, nagy tudású és erős hardver, széles termékpalettán.

Némely eszközt kényelmesebb először ezen felélesztenem. :)

elvezettel olvasom a thread-et. :DDD
az hogy egy szaros homerseklet sensortol hogyan lehet 3lepesben eljutni a SOC-okig es a 32bites mikrokontrollerekig valamint az assembly kod optimalizalasig..hat nem semmi.

remelem azert az OP is kapott vmi segitseget.

Ez a HUP. Hogy az OP kap-e választ a kérdésére, úgy általában senkit nem érdekel. :-D

Ave, Saabi.