ARM mbed, vagyis ami az Arduinón és a MálnaPC-n (Raspberry PI) „túl” van. Kérdések, válaszok, tippek, megoldások stb.
https://www.mbed.com/en/
https://developer.mbed.org/platforms/
I2C SRAM és ugyanakkora EEPROM egy tokban. Figyeli a tápfeszültséget, és ha elmegy, akkor elmenti a SRAM tartalmát az EEPROM-ba. Bekapcsoláskor visszatölti. Egy kondenzátoron kívül semmi más külső alkatrész nem kell hozzá. 250 ft / db.
Most egy olyan projekten dolgozom, amiben STM32 eszközök vannak. Még nincs saját hardverünk hozzá, így az ST devboardokkal dolgozunk. Viszont most már a Discovery boardokon is V2-1 az ST-Link. Úgyhogy lépnem kellett.
Egy orosz oldalról letöltöttem egy jó régi ST-Link V2-0 firmwaret. Ezzel downgradeltem a beépített V2-1 ST-Linkeket. A firmware update utility felismeri, hogy V2-0, és feltölti rá a legújabb V2-0 firmwaret. Így nincs se mass storage programozás (szerintem azzal van a probléma), se virtuális sorosport, cserébe stabil a kapcsolat és a debug.
Ha az mbed github oldalon jelentem be a hibákat, akkor példásan gyorsan reagálnak / javítanak. De ha javítani is tudom, akkor akár pull requestet is kérhetek.
Újra nekifutottam az mbednek. Rapid prototypinghoz kell, és nincs kedvem regiszter szinten vacakolni az MCU-val.
Úgy tűnik, hogy most az EmBitz export működik. Van benne egy linker opció hiba, amitől nem készül el a bin, meg egy optimalizációs is, amitől fagy. Ezt a két paramétert átállítva viszont hibátlanul működik, fordít, debuggol, stb.
Az EmBitz kódmérettől függetlenül ingyenes. Ez most nekem kell is, LCD is van a projektben, sok a statikus, megjelenítendő adat. (most 128 kB a program).
Maga az IDE tűrhető. Vannak benne jó dolgok, de idegesítőek is. Az autocomplete szépen felajánlja az alsóbb rétegeket, mint STM HAL és Keil RTX, de az MBED magasszintű API-t nem. Pedig lefordul a projekt, tehát látja őket. Próbáltam újra indexeltetni a projektet, de hiába. Bosszantó és lassít, hogy minden MBED API hívást a dokumentációból kell kinéznem.
Aztán találkoztam olyannal is, hogy a TFT lib online NEM! fordul le, de offline igen. Eddig csak a fordítottját láttam.
Találtam több bugot az STM CAN megvalósításban, írtam is az oldalon, de senki sem reagált. Meg fogom próbálni a bug bejelentést a github oldalukon. Az mbed-et az ARM gondozza, a hiba az ST kódjában van, gondolom így kevésbé érdekes nekik.
A kereső nem csal. 8 biten van CAN-támogatás, 32 biten nincs. Vagy-vagy. Ami fontos, hogy ők a nagyon kis áramigényre vannak rágerjedve, amibe a mikroamperes fogyasztás is beletartozik. Ilyen szintű adatgyűjtés, logolás, wearables. Cube-ról ugrott be, mert a Simpicity majdhogynem egy az egyben tudja ugyanazt, csak az nagyjából teljes értékű IDE (bizonyos debug funkciókat is beleértve).
Most volt agyam átolvasni. Csak az érdemi gondolatokat fűzöm hozzá.
X-Nucleo kártyákkal nekem kezdettől az volt az érzésem, hogy valami nem stimmel velük. Néztem, hogy 2-3-4 káryát is (elvileg) egymásra lehet pakolni, és jajj de jó, hogy működnek. Aztán amikor kiderült, hogy a szortiment kb. 1,5-2 év alatt lesz kész és jelentős része third-party, ST-approved, akkor mondtam, hogy azt a szívást, ami az Arduino shield-ekkel van, nem kívánom végigjárni ugyanúgy a szopóágat. Ez tehát fejeltős. Helyette, ha kell valami, akkor egyedi proto "shield"-et csinálok (dupla hüvelysor, próbapanel, oszt had' szóljon. Munkás ugyan, de bevált. Előnye, hogy ha van shield, aminek van bárhol támogatása könyvtár szinten, az rendszerint simán beépíthető.
CubeMX-et éztem korábban, de nem éreztem égető szükségét, hogy belemélyedjek.
Viszont vess egy pillantást alkalmasint a Simplicity Studio-ra (a Silicon Labs saját IDE-je). A saját cuccaival parádésan működik. Nagyon alacsony energiaigényű felhasználásra kihegyezett cuccok.
Nucleo: Kész board. A target, a soros USB és a debugger egyben. Nincs forrasztás, nincs dugdosás. Az ára. Nagyon olcsón lehet
X-Nucleo: Shield-ek, amiket csak rádugok. (Bluetooth, Szenzor, Motor driver, stb)
MBED: Az Arduinonál robusztusabb, mégis hasonlóan egyszerű, néhány sor kóddal el lehet indulni.
Ami ellenük:
Nucleo: Vagy nem kapcsolódik a számítógéphez, vagy menet közben száll el a fenébe. Arra tippelek, hogy az ST-LINK V2-1 drivere összeveszik valamivel Windowson. Jó lenne, ha rá tudnám tenni az ST-LINK V2 fimrwareét. Nem lenne flash programozás, de nem is zavarna. Úgyis offline IDE-t használok, hogy működjön a debug.
Nucleo: Perifériák nem támogatása. Például: CAN busz a kezdetektől van az MBED platformon. Sok STM32 MCU-ban is van, az ST meg is csinálta hozzájuk a drivert. Csak éppen az ST HAL és az MBED API közé nem írták meg évekig az összekötő kódot... Szeptemberben végre belekerült. Egy bug miatt F103on nem megy. Azóta sem javították.
X-Nucleo: Elvileg a Nucleo családhoz tervezett shieldek, gyakorlatilag több esetben is azzal kellett kezdeni, hogy SMD ellenállásokat forrasszak egyik pozícióból a másikba. Hogy aztán jelezhessem a hibát, hogy nem megy a szoftver.
MBED: Kicsit buta az online IDE. Túlságosan leterhelt a szerver, lassú a build, néha elszáll.
MBED: Sokszor nem működik az export to offline IDE opció. Ha működik, akkor sem fordul le azonnal a projekt, egy csomó fordítási és include opciót kézzel kell átírni.
MBED: Keverés az OS verziók és a támogatott boardok között. Figyelem a mátrixot, végre lefordul, de mégsem működik az adott kombináció...
Sok IDE-t próbáltam már: Keil, CoIDE, Atollic, STM32 workbench, Visual Studio +VisualGDB, Em::Blocks, stb. Van, amelyik jó, de drága. Aztán van, amelyik jó, de nincs hozzá támogatás. Aztán van, ami nem működik. Meg az, ami működik.
Vettem egy nagy levegőt, és átrágtam magam a CubeMX-en. Szépen, logikusan össze lehet rakni a konfigurációt. Először mondjuk ijesztő a lehetőségek rengetege. :-) Működik a project export Atollic TrueStudio-ba, ahol aztán AZONNAL le is fordul, és AZONNAL fel is tölti a cél MCU-ra. A TrueStudio pedig kódméret nélkül ingyenes, csak néhány extra debug és kód analizáló feature fizetős.
Elsőre ijesztő volt az 1000 soros main.c, de találtam egy kapcsolót a CubeMX-ben, hogy a hardver init-et tegye külön c/h fájlokba, így lett gpio.h/c, usart.h/c, stb. A main.c pedig csak 300 sor, aminek kb fele komment, a másik fele pedig meghívja az initet az inklúdolt fájlokból. Jó, ez sok az Arduinohoz képest, de teljesen átlátható. Kb 5 perc volt hozzáadni két taskot a RTOShoz, az egyik egy blinky, a másik pedig soros porti kommunikáció. Tetszik, hogy nyugodtan használhatok delay-t, csak az adott szál várakozik. Az CubeMX generált kód bármikor újra generálható, ha szükség lenne funkciók hozzáadására. A felhasználói kód kommentekkel jelölve van, a jelölt részek közötti részek megmaradnak.
Nem, nem (csak) szórakozás, de nem is termékfejlesztés. Prototyping. Szeretném kipróbálni, hogy működik-e az elképzelésem (Proof Of Concept = POC). Optimális esetben egy POC-ból semmi sem kerül át a végtermékbe. :-) Igen, egy termékhez sok minden kell, de csak kevés POC funkcionalitása épül be végül egy termékbe. Én, aki a POC-t csinálom, egy kérdés eldöntésére szánt egy-két napon felül nem szeretnék további napokat vacakolni azzal, hogy működjön egyáltalán a devkit és az IDE.
ha csak szórakozás, akkor ok. de ha igazi, akkor a protoypeból egyszer termék lesz, az egyszer kimegy a kapun, és utánna pár hónapig nem hallasz róla. aztán egyszer bejön egy bug vagy egy enh/feature request. és kiderül hogy közben upgradeltél eszközöket, a mostanival le sem fordul, vagy lefordul de nagyobb lesz és nem fér bele, vagy lefordul de másképp működik. és belerakni egy plusz funkciót, hogy 200msec késleltetéssel induljon inkább az akármi, az teszteléssel együtt félnap helyett két napig tart.
pedig el kell kezdeni virtualis gepezni. megpedig azert, hogy ha bugfixre elo kell venni egy keteves projektet, akkor elo tudd venni a pontosan azt a toolchaint amivel anno buildelted. konben a bugfix helyett a tool upgrade-el fog elmenni az idod.
Most jutottam el odáig, hogy feltegyem a kérdést MBED-en. Link még nincs, a kérdés moderálásra várakozik.
Az a szép, hogy kínomban csináltam ST-LINK V2-t egy Maple Mini-ből, vadásztam rá firmware bin-t, amit sikeresen frissített az ST szoftvere. Azzal bezzeg minden tökéletesen működik...
Csak olyan kényelmes lenne használni a Nucleo-t...
Visual Studio (.net WinForms, WPF), Atmel Studio, CoIDE kell a munkámhoz, és ez mind Win only. Se dual bootolni, se virtuális gépezni nincsen kedvem. Használom a különálló STLINK-et és kész.
> Plusz fórumkérdés a "nagy" fórumokban (mbed, st, facebook, plusz van egy-két embedded engineering fórum is).
Igen, ez még hátra van. Csak még meg kell jól fogalmazni, leírni miket próbáltam, stb. Nem kérdezek bele csak úgy a vakvilágba. :-)
Bármennyire is régi történet, én azt csinálnám, hogy negálnám a Win10-et, amennyire csak lehetséges. Plusz fórumkérdés a "nagy" fórumokban (mbed, st, facebook, plusz van egy-két embedded engineering fórum is).
Bepiheztem rendesen a Gecko-t, MAX7221-et gondoltam róla meghajtani teszt gyanánt, de semmi. Clock van, data van, cs/load nincs. Plusz a kimeneti jelszint (logikai magas) túl alacsony, illeszteni kellene (ez SPI). Úgyhogy mondjuk egy lépést megtettem előre, de ennyi. Most mással foglalkozom jobbára.
Az mindegy. A blinky is ezt csinálja. Valamint mind a négy, teljesen különböző projektem. Nem az én kódommal van a gond. Írtam, USB kapcsolat nélkül teljesen jól működnek.
> Aztán kérdés még, hogy minek az USB? Adatforgalom, vagy csak a szoftverfrissítés végett?
Éppen fejlesztenék... Vagyis pont arra használnám a Nucleo-t, amire való. Az USB a debug kapcsolathoz kell.
MCU oldalon: Nucleo 401 és LPC1768. másik oldalon: i2c 16x2 illesztő (PCF8574), i2c oled (SSD1603), rfid olvasó (azt már meg nem mondom, hogy melyik). Köztük, ha kell, sima soros illesztő.
Bekötés rendben van.
Mindennel mindent kirpbóáltam, a perifériák Arduino környezetben mennek, itt nem. Órajel, adatjel kimegy (illetve az LPC1768 nem nagyon akarja aktivizálni magát), válasz nem jön rá...
A Nucleonak az egyik tesztnél ezt sikerült magából i2c jelként kiköpnie (sárga óra, kék adat).
