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/
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).
Honnan tudod, hogy van reset? Szoftverfutásból, kijelzőről vagy máshonnan?
Azt megnézéted, hogy a meghajtón (Nucleo mass storage) van-e valami más is?
USB kábel jó?
Vannak csodák, de elvileg úgy bír működni, hogy külső táp + USB rádugva, nem tartom kizártnak, hogy más felállások is mennek. Bár egy kártyánál még előfordulhat, hogy lecsúszott és rossz helyre került vissza, de többnél ez szinte kizárt.
Én megpróbálnám mindenekelőtt egy blinky szintű komoly szoftverrel, illetve ha van rá bármi mód, akkor a releváns portok (external reset) állapotát figyelni szkóppal, hátha.
Próbáltam közvetlenül a gépre is dugni, meg másik gépre is. Az eredmény változó. Mármint változik, hogy milyen gyakran történik a reset, mert el nem múlik.
Az összes friss driver telepítve, minden működik. Ha a Nucleo-t csatlakoztatom, akkor látszik a flash drive, lehet programozni, debuggolni a cél MCU-t. A különálló ST-LINK is használható feltöltésre, debuggolásra.
A probléma: Ha a Nucleo-t csatlakoztatom a számítógéphez, akkor induláskor kb 10x reseteli a célt, mielőtt elindulna a program. Majd véletlenszerűen néhány percenként megismétli ezt. Ha csak tápot kap, akkor nem csinálja, ha USB-n kapcsolódik a géphez, akkor igen. Hat különböző Nucleo is csinálja, úgyhogy nem a board lesz a hibás. Arra tippeltem, hogy a Win próbál írni a meghajtóra, és az okozza. Kikapcsoltam a System Volume Information létrehozását, letiltottam az Avast-ot, de nem segített.
Valakinek ötlete? Mármint azon kívül, hogy használjam a különálló ST-LINK-t...
Nagyon durva a cucc... A saját IDE-jével (Simplicity Studio) valós idejű fogyasztás-elemzést lehet csinálni, plusz a tok összes lábát majdnem tetszőlegesen paraméterezni. Alapvetően nagyon alacsony fogyasztást igénylő alkalmazásokhoz van kitalálva (a kijelző kicsit e-ink-szerűen gyakorlatilag csak váltáskor fogyaszt, akkor sem sokat. Egyelőre annyi hátránya derült ki, hogy legalábbis ránézésre (kb. 1 órát szöszöltem vele, amiben egy hajmeresztő firmware-frissítés is benne volt), elég kevés mintaprogram van hozzá, cserébe viszont ezeket szinte kizárólag a Silabs írta, vagyis valószínű, hogy elég minőségi darabok (könyvtárakat is beleértve).
Csak mondjuk egy i2c vagy (most épp soros) debugging korábban kb. 3 órát tartott, sokszor sikertelenül, most 15 perc (se) volt, és olyan hibákat is megmutatott, amire álmomban sem gondoltam volna (TPIC6B595, ha az output enable nincs földre húzva, akkor 50% körüli duty cycle megy ki, nem konstans magas).
Nem tudom, hogy merre ment tovább. ;-) De majd ha erre jár, küldöm feléd is.
