MCU Fejlesztői panel érkezett

A múltkori FPGA panel után, most egy mikrokontroller fejlesztői panelt dobott be a postás.
Szó szerint! Mert becsengetett, én kirohantam és már csak a távolban láttam elsétálni, közben a dobozt az ajtó előtt hagyta... 
Még jó, hogy semmi érzékeny nem volt benne, ami megázhat, ellophatják... - jah nem!
Na de nem is ez a lények, lássuk a cuccot!

A cucc lelke egy STC89C516 MCU, Erre lehet írni tetszőleges programot. De kis ügyeskedéssel (adapter építéssel), más mikrokontroller is beletehető, pl ATmega168 amit az Arduinok is használnak. Onnantól fogva pedig tulajdonképen van egy felpimpelt Arduinonk :)

A panel rengeteg kiegészítővel fel van vértezve. Nem is részletezem, itt részletesen látni:

A cucc egyébként egész minőséginek tűnik. Szép, átlátható, minden feliratozott. Igaz egy USB-C csatlakozót tehettek volna rá, de azt majd lehet én lecserélem. Noh meg több kábelt is tehettek volna a csomagba, bár abból nekem is van rengeteg.

Sajnos a világon semmi manual nem járt hozzá, de nyomtatott, sem pedig digitális formában, legalább egy linken keresztül.
Szerencsére nem tartott sokáig fellelni hozzá számos segédletet.
Igaz a hardware képek jó része egy régebbi panelhez van, de a példaprogramok és a leírások azért helytállóak és működnek. 
Leteszteltem minden majdnem minden modult és teljesen jól működnek.
A letölthető csomagban egyébként minden van hozzá: Példa bekötések, programok C és assembly nyelven, program feltöltő.

Hogy mire kell ez?
Jó kérdés! Igazából csak megtetszett és a múltkor rendelt FPGA-val egyszerre dobtam a kosárba. 
Tulajdonképen bármire IS jó lehet ugye! :)
Szerintem valami játékot, vagy demót fogok rá írni, de még az is lehet, hogy valami egyszerű számítógép lesz belőle.
 

Aki esetleg szeretne ilyet, az AliExpress-en megleli!

Hozzászólások

Néha elmélázom azon, hogy milyen jó olyan korban élni, hogy ilyen eszközök könnyen hozzáférhetők. Aztán meg azon, hogy mi az, amit meg kellene valósítani egy ilyennel, s nem találok hozzá feladatot. Legalább is olyat nem, amitől teljesebb, boldogabb lenne az életem. Meg aztán kiélem magam a munkahelyemen, mert elektronikákat tervezek, olykor firmware-t írok rájuk. Van néhány MCU a szekrényemben, de nem kezdek velük semmit. Villogtassak vele LED-et, és naponta nézzem 10 percen át? :)

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

Ugyan ebben a cipőben járok. Valami megtetszik, azzal foglalkozom kicsit, utána olvasgatok, amig megérkezik a cucc, aztán azzal a lendülettel beteszem az íróasztal szekrényébe, vagy fiókjába.

Atmega 8L volt az első. Aztán rendeltem mindenféle Arduino-t. STM is van, talán 32-es is.

Jók ezek a 8051 alapú mikrovezérlők. A 40 éve megírt dolgok is mennek rajta, de a gyártók szépen kiegészítették modern perifériákkal is. Aki anno abba ásta bele magát, ma is tud dolgozni velük. Persze nem veszik fel a versenyt az ARM alapúakkal, de ahová nem kell annyi izom.

Ez inkább mérnököknek való, prototípus fejlesztésre. 

Bár igaz, tanulgatni is lehet rajta.

Az ára nagyon korrekt és az MCU is túlmutat egy arduino UNO-n. 

Van. Hogyne.
Az MCU-k életciklusa, örökélet, plusz három év az egyéb CPU-khoz képest. A 8051 meg etalon. Nem véletlenül gyártja még ma is boldog-boldogtalan. Ahova nem kell 32 bit, meg cortex mag oda jó ez is és még mindig az ilyen feladatokból van több.  
De ha mégis ARM.  Perifériát illeszteni megtanulhat ezen is bárki.

Programoztam 8051-et - helyesebben 80C32-t, ami lényegében ugyanaz - is, Z80-at is, meg kis PIC-eket is assembly-ben, nagy PIC-et pedig C-ben. Ezeknél a régi CISC-eknél a mai RISC-ek hatékonyabbak. Kellemesebb, hatékonyabb egy PIC-et programozni, mint egy Z80-at vagy 8051-et. Azt egyébként sem bocsátom meg, hogy 16 bites regisztert lehet inkrementálni, de dekrementálni már nem, a dekrementáláshoz már szubrutint kell írni.

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

Azt már máshol is észleltem, hogy sokaknál bejátszik az ötlethiány. Ez nem csoda, hiszen a legnehezebb rész ez, az életképes ötletet megszülni. Ha ez megvan, a megvalósítás már csak ujjgyakorlat.

Leginkább az iparban kapnak szerepet az MCU-k, de otthoni környezetben is megvan a maguk helye.

- Akvarisztika,
- kisállat etetés/itatás/gondozás,
- időjárás előrejelző, adatgyűjtő rendszer /pl. napkollektor, szélgép telepítéséhez előzetes adatgyűjtésre/,
- home automation system, ez utóbbi egész nagy területet felölel,
- Általános fogyasztás /víz/gáz/elektromos energia/ kontroller. 

Ezek mind hasznos, értékes dolgok. Hosszú távon még meg is térülnek, bár hobbi projectek esetében nem a megtérülés a legfőbb jellemző.
 

koszonom a valaszt! hobbikent megertem hogy jo ezekkel bibelodni, de amiket irtal, azzal tob gondom is van... :)

- akvarisztika: veszek kesz berendezest
- kisallat etetes: ooo, nem ertek hozza, ez akar jo is lehet
- erre vannak olcso megoldasok, en most szereltem fel aqara szenzorokat az osszes szobaba, raspbi + conbee felallassal, zigbeen megy. nem latom az MCU hol segit :)
- a home automation szinten
- ahol en lakom ezeket nincs jogom babralni (hozza sem nyulhatok), viszont minden digitalis.

ugyhogy a kisallatetetes meg a home automation marad, de a home automationhoz jellemzoen azt a felallast hasznalja mindenki, amit en is (vagy hasonlot). influxdb nem fut ezen a boardon :-)

Ez inkább mérnököknek való, prototípus fejlesztésre. Bár igaz, tanulgatni is lehet rajta.

Hat, leginkabb :) Es az is akkor hogy ha van az USB-s programozoval egybeepitve legalabb egy altalanosan hasznalhato kommunikacios csatorna (pl. UART). Cserebe ez nem derul ki a leirasokbol: szoval vagy nincs, vagy lutri. De inkabb nincs. 

Ezen egy kicsit sírva fakadtam. :(

Egy áramkört megtervezek, legyártatom, programozom. Biztosan nem vagyok mérnök. :(

Prototípust (nevezzük deszkamodellnek) nagyon ritkán építek. Akkor is legfeljebb az áramkör egy kis kritikus - általában analóg - részletét. Az meg biztosan olyan, amit ezen a panelen nem lehet kialakítani.

A mérnöknek inkább az adatlapokra van szüksége.

Egy ilyen inkább a kezdő hobbiprogramozóknak való, akik csak most ismerkednek az alapokkal.

Egy ilyen inkább a kezdő hobbiprogramozóknak való, akik csak most ismerkednek az alapokkal.

Már amennyiben a kezdő hobbista égető szükségét érzi infra vezérlésnek, mindjárt két féle léptetőmotor meghajtásának és nyilván egy napig sem tudna meglenni pontmátrixos kijelző, vagy a kizárólag iparban használatos RS485 nélkül. A kezdők már csak ilyenek, igaz?
Na meg, feltétlenül egy 48 Mhz-es, full extrás 8051 klónnal akar elstartolni, mert hát, hogy is érné be egy 12-16 Mhz-en ketyegő darabbal, elvégre, ő egy kezdő hobbista, vagy nem? 

Nem bizony.
Messziről világít, hogy ez egy profi board, már a perifériákat is egy 8051 klón hajtja meg. Egy másik. 
 

Idézem neked magadat:

Leginkább az iparban kapnak szerepet az MCU-k

Nem. Az van a távirányítótól a villanytűzhelyen keresztül a mosógépig mindenben. Jobb helyeken legalább 35 éve.

Abban igazad van, hogy profi - legalábbis minden vacakot összehordtak egy panelre. Ezt a funkcionalitást egy nagyobb lábszámú 8 bites PIC MCU egyedül (*), elengedett kézzel, védőháló nélkül tudja. Még egy kisebb is, csak az arra készült, hogy a perifériáknak csak egy részét választod ki, vagy esetleg belül kötözgeted össze. Csak sokkal gyorsabb.

A "kizárólag iparban használatos RS485" csak egy driver. Az iparban használt protkollokat - ha az olcsóság a fontos - esetleg ráültetik a rs485 hardverre.

már a perifériákat is egy 8051 klón hajtja meg. Egy másik.

Ami nem egy olyan nagy csoda, hiiszen az "egyikhez" képest sokkal több perifériát adtak hozzá az eredeti 8051-hez. (Tudod: adatlap!)

(*) Még a dupla processzorra is igaz.

Az igazi kezdők 120MHz-es dsPIC-en programoznak DSP funkciókat C-ben (szerintem vagy 30x gyorsabb ennél a 8051 klónnál), mert gyors - a DSP kihasználása nélkül. ;) Ha az órajel határozná meg az ipari jelleget, akkor a gamer gépek a legprofibb ipari gépek. :-D

Az alant linkelt készlet is elég profi. Még motor is van benne.

Nem. Az van a távirányítótól a villanytűzhelyen keresztül a mosógépig

Na, ezt hívják úgy, hogy ipar.

 

Ha az órajel határozná meg az ipari jelleget, akkor a gamer gépek a legprofibb ipari gépek.

Félreérthettél. Az órajel a felhasználás jellegét határozza meg. Azért vannak 48 Mhz-es klónok, mert van rájuk igény, bizonyos területeken. Ahova nem kell, oda meg jó a 12 Mhz-es is, vagy a 8 Mhz-es, kettőn járatva. Mindenesetre, a kezdőknek nem divat 48 Mhz-eseket osztogatni, mert egy led billegtetéséhez, netán stepper motorhoz, 2 x 16-os LCD-hez meg esőjelzőhöz nem kell teljesítmény.

:-D

Ha a tévéhez való $1 árú távirányító "az ipar", akkor egy bányabiztonsági berendezés nyilvánvalóan a sarki trafik, egy komolyabb gyártósor meg maga a nintendó.

Az órajel a felhasználás jellegét határozza meg.

Ez az általános frázis igaz lehet. Például most tervezek egy olajnyomás mérő műszert, amelynek legrosszabb esetben 120 °C hőmérsékleten kell működnie. Az áramkör kb. 10x12mm méretű lesz. Az MCU működhet 31,5kHz-64MHz tartományban. Ilyenkor a lehetséges legkisebb órajelet kell választani, mert a hőtermelés mértéke egy CMOS eszköznél az órajellel arányos.

Egy régi konstrukciónál az órajel állandó, vagy külső áramkörrel kell kapcsolgatni. A mai MCU-k, ha szükséges, nem állandó órajellel mennek. Egyrészt futás közben is lehet órajelet váltani. Közben a többféle sleep módban változhat, hogy melyik perifériák kapnak vagy nem kapnak órajelet. Másrészt létezhet egy ún. DOSE mód, amikor a CPU kisebb órajellel "botorkál", de interrupt alatt felkapcsol egy magasabb órajelre. Ezek a trükkök általában a fogyasztás minimalizálását támogatják, ami jól jön az elemes vagy akkus készüléknél. Vagy akkor, amikor az MCU vezérli a saját tápfeszültségét előállitó tápegységet.

Szóval a frekvenciának köze nincs az expert módhoz.

Szóval a frekvenciának köze nincs az expert módhoz.

 

Nem, kedves bucko. Neked nincs közöd ehhez az egészhez, amiről itt szó van. 
A szüntelenül benned tomboló bizonyítási, ellenkezési kényszert meg éld ki valaki máson. Én a hülyeségeidre, az okostóni stílusodra nem vagyok kiváncsi. Ha adhatok egy jótanácsot, fordulj orvoshoz vagy legalább pszichológushoz. 

 

:-D

a hülyeségeidre, az okostóni stílusodra

Tudod, jónéhány évtizede ebben a szakmában dolgozom. A hülyeségek és az okostóni stílus csak számodra tűnik annak, mert szart sem tudsz, de arra büszke vagy. Sőt, a nemtudás  magabiztossággal is párosul! Nem csoda, ha bármely téves állításod kijavítását ellened irányuló merényletnek, a másik részéről bizonyítási kényszernek érzed. (Pedig mennyivel okosabb dolog lenne akár csak egy töredékének utánanézni, hátha a dolgok nem is úgy vannak, mint gondolnád.) Hidd el, az én tudásomból nem von le egy fikarcnyit sem, ha bárki - hozzá nem értő - szakmailag hülyének néz.

Azt a cihológust meg cihiáternek híjják. - Látod, még ezt is rosszul tudtad! Tán ezért nem találtad meg. ;)

Tudod, jónéhány évtizede ebben a szakmában dolgozom.

Dehogy dolgozol ebben a szakmában. :D
Mire is mennének veled, te szerencsétlen?
Ezzel a nevetséges szöveggel próbálj meg hülyíteni valaki mást, bár jobban tennéd ha végleg felhagynál vele.
Te ebben a szakmában - meg még vagy hat másikban is - csak próbálod osztani a nem létező eszedet, aztán az lesz belőle ami; a hülyeség dobolása, magad lejáratása és mások zaklatása, b.sztatása, jobbára ok nélkül. Csak egyetlen példa az ezer közül.
Ezt írod:

"az NE555 által keltett 1MHz órajelre roppant kíváncsi lennék! A gyártó szerint 150kHz a csúcs. ;)"

Úgy látszik, az a jó néhány évtizedes szakmai múlt (már ha nem lenne veretes kamu) még az alapokra sem elég. 
A Youtube-on találhattál volna több videót is -  ha nem a kötekedés lett volna a célod -, ahol 555-ből egy MHz körüli, feletti időalapot hoztak ki. Itt van mindjárt több is: 

https://www.youtube.com/watch?v=q1Nr1aexXAM
https://www.youtube.com/watch?v=SSwN8P0gkpM
https://www.youtube.com/watch?v=TCz1erC2onQ

Ez a téma sokakat érdekel, legalábbis azok közül, akik, veled ellentétben, valóban a szakmában dolgoznak. Neked is tudnod kellett volna az 555 ebbéli képességeiről. De hát, te csak az eszedet játszod. Azt a nemlétezőt.
Veled is csak többen vagyunk. :/

Belekötsz sokakba, kártékony ember vagy. Lásd be ezt és ahogy tanácsoltam, fordulj orvoshoz (ez a pszichiáter) vagy pszichológushoz. Sokakat kímélnél azzal, ha ezt a lépést megtennéd.
További kellemes protopype-less fejlesztést, de még inkább jellembeli fejlődést kivánok [LOL].
Engem azért, ha csak lehet, kerülj. Köszi.

Vettem a fáradságot, és megnéztem a szakmai videókat. ;)

Sajnos rossz hírem van! Az első kettőben nem ismerjük a potos típust, ezért nem hiteles.

Viszont a harmadikban egy ST Micoelectronics által gyátrott NE555 szerepel, amely 500kHz (-nél is nagyobb) határfrekvenciájú, és egyben jó negyed századdal később készült, mint az eredeti Signetics NE555. A Signetics típus után nem sokkal készült a CMOS ICM7555, ami 0,750-1MHz-ig ment...

Van Texas TLC555 2,1 MHz-ig, a fiókomban meg TS555 2,7MHz-ig. Mit ír erről a gyártó?

(ff(max.) TS555 = 2.7 MHz versus f(max)NE555(a)= 0.1 MHz)

Pedig ők gyártották az 500kHz-es bipoláris típust is, de még nálam is rosszabbul tudják - biztosan hülyék hozzá. ;)

Esetleg az is előfordulhat, hogy a szakember általában az eredeti NE555-öt veszi referencaként? Mert ugye a többit meg másképp hívják.

A videókban bemutatott maximális frekvencia lenyűgöző. Én is tudok 100km/h sebességgel repülni - ha beleugrok egy szakadékba. No, ez is lenyűgöző.

Sajnos, a szakember munkaeszköze soha nem a youtube amatőr videó, hanem az adatlap. Ez meg azért van, mert veled szemben nem szoktam az ügyfeleknek videót linkelni: Hülye vagy! DE MŰKÖDIK! - Amit én tervezek, az csak működik. ;)

ahol 555-ből egy MHz körüli, feletti időalapot hoztak ki.

Nézd meg Te is a videókat! Ha egy áramkört sikerül valamilyen frekvencián berezgetni, azt még nem hívják időalapnak.

Ahonnan a hozzászólásomat idézted, ott egy házi építésű CPU-ról volt szó. Ahhoz tényleg nem árt egy időalap, aminek van stabilitása és reprodukálható. Hiába sikerül magasabb frekvencián rezgetni az áramkört, a frekvencia a környezeti hatások miatt  instabil lesz, és az 555 cseréjekor is változhat. Magyarul: alkalmatlan.

Az 555 vizsgafeladat övön aluli egy MCU topicban. Már a 80-as évek végén is igaz volt, hogy 3 RC tagot (időzítést) már gazdaságosabb processzorral csinálni. ;)

Remélem, a fentieket mind régen tudtad. Mert az igazi kártékonyság az lenne, ha tanulnál is valamit.

Ezúttal buckoval értek egyet. A profi az, amit megtervezel, legyártatsz, eladsz termékben. Az ilyen boardok azoknak valók, akik ismerkednek a területtel, tanulják ezt a szakmát. Nem mondom, hogy a mérnöknek mindig elegendő az adatlap, mert nem mindig írják le azokat a mocskos részleteket, amitől függ, hogy valamit hogyan tervezzél, s akkor muszáj kipróbálni. Olyankor jó egy ilyen teszt board.

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

Igen, időnként ki kell próbálnin egy olyan boardon, amin biztosan működik a dolog, mert a legrosszabb, amikor a hardverben és szoftverben is van potenciális hibalehetőség.
Pl. STM32 Ethernet felélesztéséhez inkább választottam először egy kész boardot, és csak ezután terveztem saját panelt a feladathoz.

Másfelől az ember hajlamos egy új projektnél először saját korábbi áramkörein elindulni (amin elérhetőek a szükséges eszközök), és csak akkor tervezni az adott feladatra saját panelt, ha valóban szükséges (nagyobb példányszám vagy speciális igény miatt).

Az ilyen egybe panelok inkább gyakorlás / tanulás célra használhatók, de arra valóban jók.
Hobbisták olykor úgy gondolják, hogy megvesznek egy "evaluation board"-ot, és aköré építenek egy megoldást, és ez termék lesz... no, ez nem a megfelelő irány.

Ennél kicsit rosszabb a helyzet - locsemege arra gondolhatott amit néha PIC platformon lehet tapasztalni.

Úgy néz ki a dolog, ha új MCU-t kezdenél használni, hogy van az adatlap + errata. Meg amit ebből a kettőből kifelejtettek. ;) Rossz nyelvek szerint érdemes figyelni a revíziót is. Ha az változik, akkor van amit kijavítottak, van amit nem, de jöhet újabb hiba is.

PIC-et nem ismerem (valójában inkább elkerültem), de valóban errata-ja gyakorlatilag mindennek van, jó esetben javasolt workaround-dal, amennyiben megoldható egyáltalán.
...és igen, revíziótól függően egy kicsit más. Atmelnél egész jól leírták egyébként revíziók szerint, bár már az is Microchip lett (igaz, ott is volt "not sampled" revízió...).

pl. valamelyik "magasabb" porton mégsem elérhető a jelzett SPI vagy I2C (TWI) interfész egyes revíziókban, esetleges ADC problémák, konfigurálási sorrend, tudom is én.

Ez sajnos vele jár, de a "komolyabb" processzoroknál is...

Vagy például PIC-ekben Timer2/4/6 típusú timereknél van egy blokkvázlat, mely szerint a timer előre számlál, van egy komparátor, a komparátor egyik bemenete a timer, másik egy regiszter. Ha a két érték azonos, visszatörli a timert. Igen ám, de szinkron vagy aszinkron módon? Ha a regiszterben 5 van és aszinkron módon resetel, akkor a szekvencia 0, 1, 2, 3, 4, (5) 0, 1, 2,...

Ha viszont szinkron töröl, akkor 0, 1, 2, 3, 4, 5, 0, 1, 2,... Ebben az esetben a regiszterbe n-1-et kell írni, ha n-nel akarunk frekvenciát osztani.

Egyébként szinkron a törlés, csak ezt néha elfelejtik leírni. Nézed a blokkvázlatot, olvasod a leírást, s közben kétségek között vergődsz, hogy n-et, vagy n-1-et írj abba a regiszterbe.

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

És ki a hülye? ;)

Ezért vannak a szoftvermérnökök, akik el sem tudják olvasni a kapcsolási rajzot, de nem is akarják. Nekik semmi ilyen problémájuk nem fog támadni. Egyszerűen, csak programozzák a hardvert, amit terveztél. És jön az ismétlődő történet:

Egy jóval nagyobb cég - akik firmware-t vásárolnak tőlük - vezetője (aki szoftvermérnök) specifikálta: Mindig a legújabb drivert kell használni!

Én meg egy személyes találkozáskor leütöttem a magas labdát:

- Mire gondoltál?

- USB driver.

- Ja, azt én írtam (assembly) pár éve, azóta minden termékünkben ez van.

Később a főnökünktől hallom: Az ő driverük elég gyakran le is akad... ;)

Másféle történet... adott szenzorhoz a gyártó kiadott egy függvénykönyvtárat, alapvetően átlátható felépítésű kóddal.
Kell hozzá mindenféle kompenzáció, hibás terület kezelése, alapvetően bonyolult dolog jól kezelni.

Nosza, élesszük fel a szenzort vele.
Az egy dolog, hogy első körben a szenzor kommunikációja nem volt tökéletes, az meg egy másik, hogy emiatt a library-ben került végtelen ciklusba, mert addig szorzott egy változót, amíg be nem került egy tartományba... csakhogy a nullát szorozhatod a végtelenségig...

Nem szabad lebecsülni ezeket a dolgokat! Ha jól belegondolsz, a side effect kutatása nélkül sok embertársadnak nem lenne munkája. Sőt, a gondolkodni képtelen szoftvereseknek is felkopna az álla! :-D

Én viszont szívtelen vagyok, nem adok másnak lehetőséget. Kizárólag adatlap -> firmware módszerrel dolgozom. Ez a munkamódszer igen hosszadalmas és pepecselő tevékenység. Ráadásul megfosztom magam attól az élvezettől, aminek a szoftveresek igen gyakran hódolnak: Az évekig tartó és gyakran eredménytelen javítgatás. Aztán kiderül, hogy a pepecselés volt a hatékonyabb. Az üzleti sikerben egyáltalán nem vagyok biztos, hiszen a hibásan működő szoftvert is ugyanannyiért lehet eladni - legalábbis egy jó darabig.

Az adatlap -> firmware egyszerű szenzorok esetén működik is, bonyolultabb esetben meg az időt nem fizetik ki, amit ráfordítasz...
Másfelől a fenti esetben nagyon egyszerű mikrokontroller nem elég a feldolgozáshoz, van némi bonyolultabb számítás- és memóriaigénye is a feladatnak.

Egyébként éppen az ünnepek előtti munkanap (mármint 23-án) futottam bele az egyik üzletláncban, hogy fizettem volna kártyával, meg is történt a tranzakció, de valahol a folyamat során lefagyott a kártyaelfogadó terminál.
Két gomb együttes nyomva tartásával kellett újraindítani az eszközt...
Persze újra kifizettették, mondván, hogy vissza fogom kapni a pénzt - de azóta is valid tranzakcióként látom, vagyis lesz még vele köröm...
...persze elgondolkoztam rajt, hogy mindezt 2020-ban hogyan engedhetik meg maguknak - nem ismerem a pontos háttér-kommunikációt (pl. kapcsolat újra felépülésekor tudod-e kezelni az előző tranzakciót), de feltételezem, sztornózást tudnának csinálni... nem nagy dolog manapság akár FRAM-ban "büntetlenül" tranzakciós folyamatként kezelni az egész folyamatot, akár watchdog-gal újraindítani és _normális_ hibakezeléssel lezárni a folyamatot, ne kelljen a hülye ügyfélnek rohangálni a pénze után... hova tovább, két, pontosan azonos összegű tranzakció ugyanattól a kasszától pár percen belül sem tűnik túlságosan valószerűnek.
Ilyenkor jut eszembe, hogy kapnék a fejemre, ha ilyen terméket sikerülne összehozni...

...aztán másnap, másik kártyával, egy mobil szolgáltató applikációból feltöltése közben ismételték el pontosan ugyanazt a lezáratlan, de nem lekezelt folyamatot... és nem sztornózzák maguktól.

Így állunk manapság...

Így van, de nem ennyire bonyolult a dolog. A szenzorok általában egyszerűek, legfeljebb a használt üzemmódot kell felprogramozni. Olyan műszereket készítek, ami jóformán csak dumpolja a méréseket. Hogy könnyű legyen a szoftver cseréje és szoftver nélkül is lehessen tesztelni, általában valamilyen mértékegysegnek megfelelő értékeket állítok elő. Pl. a szoftver nem látja, ha erősítést vagy mérési módot váltok egy analóg érzékelőnél, csak a mért értéket olvassa ki helyesen. Ehhez beépítet hitelesítési eljárások is tartoznak, amit terminálon is el lehet végezni. (Érdekes módon a főnök is kukázta a szoftvert, inkább megtanulta a terminálos hitelesítést. Csak a szoftveres meg ne tudja! ;))

A bonyolultabb számítás kétféle lehet. Ha nem ér rá a szoftveres, akkor én írok FIR filtert, stb. Ha a szoftveres nem bír egy gyári C forrást (BME280) belerakni/átírni a C# programhoz, akkor lefordítom, felrakom egy Olaszországban üzemelő VPS-re,  és a szoftveres onnan hívja json alapon. Mint láthatod, elég bonyolult a hardver fejlesztése. :-D

A szoftveres feldolgozás (bonyolultabb számítás, vagy ha >3-4 buffernyi adat kell hozzá), és a megjelenítés a pécén megy.

A "tranzakciót" csak akkor hívnám annak, ha tényleg az. ;) Ha bármelyik oldal rosszul van programozva, akkor nem az. Ehhez persze a szoftveresnek is tanulni kell. Ha mondjuk egy geographical cluster lock lehetőségeit tanulmányozta volna (ami egy könyv), annak a tizede-százada elegendő egy kártyaművelet helyes kezeléséhez. Vagy ha van, józan paraszti ész is elég. De mit mondjunk az olyanról, aki a "Van-e internet kapcsolat?" kérdés megválaszolásához a "connect(https://www.google.com)" függvényt használja. :-D A cél egyébként egy másik szerverhez kapcsolódás. Úgy két év alatt sikerült rábeszélni (bár őszintén nem hitte, hogy igazam van, mert én nem értek hozzá), hogy mi lenne, ha a cél szerverhez kapcsolódna - ami sikerül vagy sem - és abból döntené el a továbbiakat. Az ilyen gondolkodásmód begyűrűzik! Folyományként, ha nem volt kapcsolat, akkor feljött egy ablak a hibaüzenettel és megkérdezte: Felküldjem a szerverre a hibát? XD

Állítólag ez egy "befejezetlen program volt", én meg nem vagyok hiszékeny. ;) Nálam egy befejezetlen program sem csinál ilyet.

Persze egy ideje semmin nem csdálkozom.

Attól függ, mi a cél (milyen műveletvégzés, hol / min jelenjen meg)...
BME280 egy egész jól kezelhető szenzor amúgy.
BME680 sem bonyolult, csak vagy használod a BOSCH-féle blob-ot, vagy keresel mások által kikísérletezett megoldást, ha a gázszenzort is használni szeretnéd levegőminőség jelzésére - vagy megpróbálod te ugyanazt előállítani, csak az hosszabb idő lesz...

Egyébként a BME280 / BME680-nak emlékeim szerint egész korrekt volt a gyári C szoftvere is.

Nem tudom, a bankkártyaleolvasó termináloknál pontosan hogy működik az API (vagy egyáltalán hányféle megoldás létezik), amin keresztül kommunikálnak, így nehéz bármit írni korrektebb működés kapcsán.
...de azt azért letárolhatná, milyen folyamat indult, milyen műveletet készül épp' végrehajtani, és egy automatikus reboot során eljuthatna oda, ténylegesen hol szakadt meg a kommunikáció, és vagy folytathatná ott, ahol abbamaradt (amennyiben az API engedi), esetleg generálhatna a tranzakcióra egy sztornót (ha az API engedi), vagy legalább egy riportot arról, hogy hibás tranzakció történt - feltételezem, nem mindegy, hogy adott üzenet elküldése előtt vagy után hasalt el, ami egyébként kiderülhetne.
Ha az API nincs felkészítve ilyen hibalehetőségekre, az már eleve elég nagy hanyagság.

Egyébként a BME280 / BME680-nak emlékeim szerint egész korrekt volt a gyári C szoftvere is.

Nono. Az int32 (vagy 16, már nem emléxem) pontatlan. A float, ha C libbel fordítom (jól kigyomlálva), csak 2db MCU-ba fér bele. ;) Ebből csak 2db nyomásmérő "hitelesítő" készült, ezért nem írtam át asm-be. Az awk átirat (55 bites float) kiválóan működik.

A tranzakció kezelése szerintem:

Nyitok egy tranzakciót, amire kapok egy azonosítót, amit tárolok káryával és összegel együtt.

stb. és jön a villámcsapás ;)

A nyitott tranzakció azonosító a szerver oldalon adott idő után elévül, legyen mondjuk 10 perc.

Ha X idő múlval újra kapcsolódunk, a tárolt adatokból látom, hogy "valami volt". Ha a kártya és az összeg egyezik, akkor a tranzakció azonosítóra hivatkozva megkérdezem, hogy volt-e ilyen, és sikeres volt-e?

A többi már kitalálható. A kártyát mégegyszer be kell kérni, hátha elment az ügyfél.

Ha le sem tudtam menteni a műveletet, akkor új tranzakció - a régi meg elévül.

Egy ilyen műveletsor elfér egy 64 bájtos (!) FRAM-ban.

Van egy kis probléma a papír kezeléssel, de azt még bele lehet szőni az algoritmusba.

Arra nincs megoldás, ha nincs tartalék papír. ;)

Sajnos ennél kisebb hibák is vannak. A kenyérboltban mindig kétszer dugom a kártyát és írom a PIN-t, mert a PIN felirat után 10-15 másodperccel indul az input. ;)

Nem emlékszem pontosan, a BME regiszter szinten mit csinál és a library mit csinál, azt tudom, hogy átlátható volt a kód és amikor a szenzort használtam, hozta azt, amire szükségem volt.

Alapvetően egy program működőképessége és jól működése között (hibakezeléssel együtt) van egy nagyságrendnyi különbség.
Nem addig kell eljutni, amíg úgy-ahogy esik-kel a megoldás, hanem lehetőleg odáig, hogy a hibákat is kezeli és igyekszik felállni belőle.
Itt úgy tűnik számomra, mintha egyszerűen nem lett volna befejezve a fejlesztés.

Nyilván ilyen tranzakció-szerűséget át kell gondolni, de lehet neki tranzakciós azonosítója (ami egyeztetve van a szerver oldallal), lehet időbélyeg és ismerheti a konkrét lépéseket, mit tett meg és mit fog megtenni.
...és fontos lenne a definiált működés, tehát
- pl. egy nem lezárult tranzakciót vissza kell vonni
- vagy mindenképpen történjen meg a tranzakció, de ez nem lehetséges, mert nem ismert a bank válasza a fedezetről

Ergo legalább vonjuk vissza a sikertelen tranzakciót, mert úgy egyébként a boltban ki fogják fizettetni, ha mást nem készpénzzel, mert nem fogják hagyni, hogy veszteség legyen belőle.
Így viszont benne van a pakliban, hogy a bolt kétszer szedi be az összeget, és neked kell utánajárni, ha kell még a pénz valaha is...

Nem feltétlen kell túlbonyolítani a feladatot, de egy deklarált működést azért elvárnék, ne az ügyfél utánajárásán múljon a tranzakció kimenetele (veszteség).

Tranzakciós műveletnél alapvetően mindig a művelet státuszának mentésével indítunk, ergo, ha nem mentett semmit, akkor tranzakció sem indulhatott el.

A BME gyárilag hitelesített. A mért nyers adatok mellé kiolvashatod a hitelesítési adatokat is. A gyári lib ezeknek a felhasználásával korrigálja és hőkompenzálja a kiolvasott mérési eredményeket. Pl. a nyomás olyan pontos, hogy a tengerszint feletti magasság ismeretében még azt is meg tudom állapítani, hogy hányadik emeleten vagyok. A "gaming mode" olvasásakor először sajtóhibára gyanakodtam. De ezek még azt is komolyan gondolják. ;)

A bankkárya tranzakciók kezelése - bármit is hazudnak - ősrégi. A folyószámlámra pillantva - itt az 5 másodperces utalások közepette - gyakran szívinfarktust kapok. Ki a rosseb vásárolt a kártyámmal "ma" és mi az a sok lefoglat pénz. Ja, én voltam egy hete! Bár levonták a pénzt, nehogy mégegyszer elköltsem, de még nem sikerült lekönyvelni. (?) Mert ez egy VÁSÁRLÁS!!

Magyarázza el valaki, hogy egy konzolhoz képest (~átutalás) miben különbözik egy bankkártyás vásárlás (~terminál) - azon kívül, hogy hosszabb a drót! Ráadásul mindkettő működik ugyanarról a fostalicska lapostelefonról, így semmi különbség a kettő között.

Ha a piacon vásárolok, akkor az ötödik helyen az esetek 70%-ában miért nem fogadja el a terminál a kártyámat? (Állitólag másik bank hálózatát használják.)

Miért nem tudok a lejárat előtti hónapban külföldön vásárolni? A legfrappánsabb magyarázat: A rendszer látja, hogy a következő kártya már gyártásban van. :-D (Hülye!)

Úgy érzem, zavar van az erőben és nem csak a tranzakciók körül.

Igen, a BME kifejezetten jó szenzor szerintem is.
Kísérleteztem anno BMP085, majd BMP/BME180-nal is, élesben BME280-at használtam.

A bankok rendszere sajnos alapvetően ősrégi, ezt próbálják patkolni folyton.
Anno talán vagy 15 éve lepődtem meg azon, hogy a bankfiókban az ügyintéző elmondta, hogy X Ft van a számlámon... mondom az nem létezik.
Ja, ő látja a zárolt összegeket is, amit én már rég elfeledtem... ez kb. most is így van.

Itt egy kicsit más fajta nyomásmérő: MPXHZ6130ACU (repülőgépre is jó :))

Megjegyzem, ezt csináld meg developer/bread boardon - a panel 12x76. :-D

Itt meg a felhasználása.

 

A MagNet-nél pontosan látok mindent. Még 98-ban volt egy eset (BB) - amikor lakást vettem, ösze-vissza vásárolgattam - és este több százezer hiányzott a számlámról. Most kb. egy millió lenne. Éjjel kettőkor már minden stimmelt. Néztem egy kivonatot, de nem látszott semmi.

"A profi az, amit megtervezel, legyártatsz, eladsz termékben."

Ezt előzi meg a prototípus fejlesztés. Na, ez a board meg éppen arra való.
Hogy a mérnöknek ne legyen gondja alapvető perifériák MCU-hoz való illesztésével, kitalálták az un. development board-okat. Ezek olyan fejlesztői segédeszközök, amelyek meggyorsítják a munkát, segítenek mindjárt a lényegre koncentrálni, így a fejlesztési idő lerövidül.

Amikor valaki, a megrendelő/munkáltató kitalál valamit,és ahhoz MCU kell, akkor a mérnök, az igények alapján kiválaszthatja a megfelelő fejlesztői board-ot és ezen kezdi el a munkát. Nem kell azzal piszmognia, hogy breadboardon alakítja ki a szükséges áramkört, hanem az már készen áll, Kiválaszthatja, hogy mi kell neki, hét szegmenses kijelző, netán egy-két LED is elég, vagy interaktivitást igényel a készülék és valami komolyabb monitor kell, LCD, grafikus LCD vagy mindjárt touch screen. Van még egy rakat más, shift regiszterek, RS232, RS458, annyi nyomógomb, hogy egy komplett mérnöki pult-hoz is elég (mert ez volt a cél). Neki csak a speciális igényekre kell megoldást találnia. Hát erre valók a különféle development board-ok, ahogy ez is.

A kezdők igényeit meg a starter kitek, discovery board-ok elégítik ki. Még a szakmát intézményes keretek között tanulók is többnyire ilyen boardokon építik meg az első kapcsolásaikat.

Ez a szóban forgó panel viszont nem kezdőknek készült. Már fentebb, más hsz-ben elmondtam, hogy miért. Nem fogom leírni ugyanazt. Eleve, felületszerelt az egész. Ha egy kezdő vesz ilyet kézbe, tízből három-négy, jó eséllyel tönkre is tenné.
Persze te és buckó is, tőlem hihettek amit akartok.
Ettől még az lesz az arduino, ami eddig is volt, egy hobbi board ABSZOLÚT kezdőknek és lesz negyed, vagy fél millás, mérnökök (hallod, buckó? Valódi mérnökök) számára kifejlesztett, általános, vagy esetenként egészen speciális igényekre épített development board is.

buckó. Ezt írod:

"Ezért vannak a szoftvermérnökök, akik el sem tudják olvasni a kapcsolási rajzot, de nem is akarják. Nekik semmi ilyen problémájuk nem fog támadni. Egyszerűen, csak programozzák a hardvert"
 
Látod, az ilyen nevetséges, ujjból szopott dumákon csúszol te el. Itt derül ki, hogy 'közöd semmi' dolgokba ártod bele magad, nem jó  szándékkal, rosszindulatúan és öncélúan.
Nincs ugyanis olyan szoftvermérnök, aki (ahogy te hazudod, vagy elképzeled), úgy áll neki  egy komplett készterméket felprogramozni, hogy hardverismerete, villamos előképzettsége nincs.  
Bizony ám, biizsu vagy, buckó. Egy olcsó flame-generátor, semmi több. A nickedben az egyik betűt ki kéne cserélni egy másikra.

Látod, az ilyen nevetséges, ujjból szopott dumákon csúszol te el.

Erre csak annyit mondok: Édes fiam! Fiatal vagy, tapasztalatlan és naív.

Amit leírtam, az megtörtént. A szoftvermérnök definícióját itt a hupon tudtam meg: Az az ember, aki azt a mikrokontrolleres áramkört programozza, amit a hardveres megtervezett.

Ehhez két dolgot érdemes tudni. A PIC MCU-k standardizált perifériákat tartalmaznak. A "hardver tervezése" nem merül ki a csip áramkörbe helyezésével. Igen gyakran a belső elemek összekötésével alakul ki a feladatot végző hardver. Na jó, ezt esetleg megbeszélik.

A szoftveres fekete dobozként esetleg lib-eken keresztül látja a hardvert, bár programozni tudja. Részletes ismeretek nélkül - szerintem - ez nem túl hatékony dolog.

Ideális lenne, ha hardverismeretét és villamos előképzettségét használni is tudná, de nem így volt. Egy nálunk nagyobb cégnek adtunk át egy terméket, amit ők nagyobb sorozatban gyártottak volna. (Sajnos nem jött össze, mert ők kütyüket, mi meg műszereket árulunk.) Hónapokon keresztül fasszágokról levelezgettünk - talán még rád is rádvertek egy kicsit. ;) Hiába idéztem az adatlapból, vagy nem értette, vagy nem hitte le.

Csak egy apró gyöngyszemet idéznék: - Itt nem RF (rádiófrekvenciás) áramkörről van szó. - Tényleg. A processzor 48MHz-en jár, és 12MHz-en kommunikálunk. (Az, mint tudjuk, szinte egyenáram.)

A következő termék átadását megakadályoztam. Csak annyit kértek, hogy a műszer topológiáját fordítsuk meg - mikoris az USB kábel keresztezte volna a mért 1200A-es kábelt. A szoftvermérnök úr mellett van egy villamosmérnök úr is.

No, ennyt a hardverismeretről és a villamos előképzettségről.

Nem kell azzal piszmognia, hogy breadboardon alakítja ki a szükséges áramkört

Egy kis hardverismereti óra következik. A breadboard a 80-as évek technológiája. Manapság rengeteg olyan áramkör van, ami csak smd kivitelben készül. Esélyed nincs breadboardba tűzni a 10 lábú 0,5mm osztású ic-t, de ráforraszthatod egy átalakító panelre. Persze azzal sem sokra mennél, mert a nagyfrekvenciás paramétereknek annyi. Egy development boarddal se kerülsz nyerő helyzetbe. Ezt hogyan oldanád meg?

Egyébként tűkön ülök és várom válaszod a NE555 stabil 1MHz-es időalapként alkalmazásáról. :-D

Szerintem egy ilyen nagyon korlátozottan használható fejlesztésre. Egy USB stack felélesztésére valóban jó, mert az nem evidencia, s jó az, ha egy stabil hardware-en elkészül nagyjából a software, mert a saját tervezésű kártyán lehet topológiai probléma miatt - pl. reflexió, nem megfelelő hullámimpedancia - labilis az USB átvitel. Bár itt meg a software hordozhatósága lesz a gond az új, teljesen más hardware környezetbe, hiszen nincs alatta operációs rendszer, ami elfedné a hardware-t.

Ugyanakkor egy LED kijelző illesztésében mi a nóvum, ami nem fog elsőre menni a saját tervezésű hardware-ben, s ki kell próbálni?

Proto fejlesztésében igazad van. Kár, hogy sok olyan műszaki probléma van, amire egy ilyen kártya az égvilágon semmilyen megoldást nem ad. Teszem azt, folyadékos és optikai mérések, alacsony zajú erősítők, speciális kapcsolástechnika. Egy ilyen moduláris bőrönddel nem tudnék protót építeni. Már ahhoz is bőven saját tervezésű elektronika kell.

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

Ez egy őrülten jó tanulópanel. Nagyjából mindent tud, amivel a alapvető vezérlési és mérési feladatokat meg akarhat tanulni az ember.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ez határozottan így van, rengeteg dolgot körül lehet vele járni. Sokkal egyszerűbb fejlesztőlapon dolgoztunk annó.

Digitális elektronikát, uC-t és standard perifériákat tanulni kiváló. Nekem csak annyi a bajom vele, hogy utána 99% hogy nem ezt a platformot fogod használni.

multkor valamelyik topikban valaki felreirt egy fel betut valamiben, es ki lett javitva 20 soron keresztul, felek en mar leirni itt barmit is, mert ehhez a temahoz aztan teljesen noob vagyok :D

 

en bennem tobbszor fellangolt hogy megtanulom az elektronikat (tudom, tudom, "azmiaz, inkabb teruletet irj") valami ertelmes szinten, nekialltam PSU-t epiteni az EEVblog sorozata alapjan, kacerkodtam AVR/STM32-vel; az egyetemen sok sok evvel ezelott robotika projektem az egy elore bejelolt GPS koordinatapont-listan vegigmeno robot volt, amihez az elektronikat en epitettem a nullarol (vettem valami olcso kinai "nagykerekes taviranyitos kiautot", kibeleztem, vettem bele rendes szervot, epitettem hozza vezerlest, etc), viszont a konkluziom mindig az, hogy kurvara nem ertek hozza, es 50x-100x idot kene beleraknom, hogy tudjak ertelmesen beszelni errol a temarol.

ennyi idobefektetest az er meg, ami elorebb juttat az eletben, tehat marad az IT, vagy a tozsde; "ez a szakma" (nem konkret egyre gondolok, hanem ahova ez a tudas kell) akkor erne meg, ha erre valtanek, de 100%-ig meg vagyok gyozodve arrol hogy se izgalomvan se penzben nem erne meg.

 

igy marad a hobbikontarkodas, idonkent. most peldaul a lanyom egyik ejszakai lampajaban ment tonkre a microUSB csati, beforrasztottam neki fix kabelt, kikerestem a mouserrol az ekvivalens vertikalis "headert"(?), aztan elakadtam ott, hogy maga a cucc csak 1.25CHF (ha egyet rendelek), de 58 CHF alatt nincs ingyenes szallitas... ergo megint elindulok a lejton lefele, es rakok bele idot meg penzt, vagy hagyom a fenebe, es veszek egy uj lampat, ami olcsobb mint a shipping... :)

Ez az őszinte önvallomás a lelkem csücskét is megbazsalygatta! :)

Igazán nem az volt a cél, hogy egy betűbe belekössek, de így, a vallomás után még értékesebb lenne a véleményed!

Mondom a mottókat.

Még Ifjú Titán koromban (az a Vén Fasz negáltja) találtam olyat szólni, hogy milyen egyszerű lenne processzorral...Mire az öregek rendre intettek, hogy az utcán ezer emberből egy se tudja mi az a processzor. ;)

Ma meg már a számítástechnikát is informatikának hívják...

Ha saját bevallásod szerint nem értesz hozzá, akkor még érdekesebb a véleményed!

(Mi a foglalkozása annak a bácsinak, aki a cipő talpába veri a szögeket? - Hóhér.)

A tápegység az érdekes téma, de önálló technológia. Bár éppen egy világszínvonalú tápegység virtuóz mellett is dolgoztam (aki állítólag szabad idejében Antall Józsefnek is adott tanácsokat), tanítgatott is, de csak 30 év után mertem nekiállni ilyesminek.

Szóval áruld el, (feldobtam a labdát: írd körül) hogy milyen szakmára gondoltál!

Cserébe én is elmondom a mai világról szóló lesújtó véleményemet. ;)