STM8 fejlesztői környezet

Fejlesztés

Első lépésben az is jó lenne ha az SDCC (3.6.9) csomagban fellelhető stm8 szimulátort tudnám használni, lehetőleg vizuálisan. Tudtok valami használható leírást?
Ha szimplán elengedem parancssorból, az Intel hex formátumú fájlal, valahol a "beégetni" való program elejére tesz, míg azon végig "next" -elek teljesen kipusztulok.
Valami emberbarátibb megoldásra van szükségem. Amit eddig találtam, az stm8-binutils, ami felrakna egy gdb-stm8 -at? Ráadásul, nem látom a legfapadosabb STM8S103 konfigurációt. Ráadásul ha jól értem kell hozzá az openocd - mondjuk ez nem szimulátor. Nagyon szűkös a leírás.
Találtam egy youtube videót is ahol egy fickó elmotyogja hogy kell az stm8-binutils izét felrakni (Ubuntu), elég "kimerítő".

Határidős projekt nincs.
Mostani stádiumban a szimulátor is megtenné.
Persze az igazi a teljes értékű fejlesztő környezet lenne.
Már láttam az stm8-binutils-gdb -t úgy tűnik, még ez a legjobb opció.

OFF: Lépésről, lépésre szeretném "elsajátítani" ezeket a jószágokat - kicsit gyengébbek mint az AVR, viszont olcsó és nagyon érdekes tulajdonságai vannak. Pillanatnyilag azon akadtam meg, hogy nem tudok assemblerben megírni egy cirkuláris buffer kódot? Na ne. Valamit nem látok, meg kellene néznem.

* Én egy indián vagyok. Minden indián hazudik.

( uid_6201 v | 2017. 12. 14., cs – 08:51 )

Ezt ajánlják Linuxra:
- fordításhoz: sdcc 3.5 és felette
- kódletöltéshez: stm8flash és hozzá a hardver: stlink vagy stlinkv2 ... Alin 2 dolláros tétel.

( icserny | 2017. 12. 14., cs – 11:32 )

Egy kényelmes megoldás: IAR-EWSTM8 az IAR integrált fejlesztői környezete, C fordítóval és nyomkövetési lehetőséggel. Azt hiszem, az ingyenes változat korlátos, de az általam használt STM mikrovezérlőhöz pont elég. Programletöltés és nyomkövetés STlink V2 eszközzel...

( tovis v | 2017. 12. 15., p – 17:52 )

Az a gyanúm marad ez https://stm8-binutils-gdb.sourceforge.io/
Jelenleg Debian Strecth stable 9.3
Gondok:
SDCC - a legfrissebb az 3.6.9 míg a patch a 3.6.0 verzióra szól ráadásul a konfigurációs scriptben letilt minden más portot?
openocd - sosem használtam, fehér folt
binutils - 2.28-5 amd64 a patch 2.27 verzióra szól, ráadásul nem tudom mi lesz az eredetivel (amd64) az avr mindent külön "átkeresztel"
gdb - szintén 2.12-6 a 2.7.12.1
A binutils és a gdb kell a rendszerhez - előfordul hogy Linux -ra írok szoftvert.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 03. 07., cs – 23:33 )

Még mindig nem tudtok valami előrelépésről?
A debug nagyon hiányzik. Ennek az mcu -nak pompás utasítás készlete van de sok olyan címzési mód van amit nem értek, vagy nem úgy működik ahogy gondolnám.
Az assembler (most nem ugrik be olyan fura neve van) nem követi az STM által megadott konvenciókat - kénytelen vagyok itt-ott belenézni a kimenő listába. Nagyon durva címzési módjai vannak.
Az SDCC és az assembler jól működik, jól lehet támaszkodni az SDCC assenbly kimenetére.

* Én egy indián vagyok. Minden indián hazudik.

Nagyon spéci eset kivételével nem helyezném előtérbe ma már a 8 bites "történelem" megismerését. Az ARM Cortex M3 mikrovezérlők sem drágábbak ma már és jövőképesebb tudást adnak. Gyakorláshoz ilyen blue pill lapkát 1,6 dollárért kapsz az Ali-n.

Egyébként ha már ár: az abszolut low end 6..8 lábú mikrovezérlőktől eltekintve ma már nincs különbség a 8 és 32 bites integeres mikrovezérlők árszabása között. Ma az árugrás az FPU-val rendelkezőknél jelentkezik.

Köszönöm. Az STM32 lenne a következő lépés. Tudom, hogy árban nem különböznek. Viszont az STM32 -őt még tanulni kell, míg az STM8 (leszámítva a debuggert) kézben van, ha most kell valamit csinálni rögtön rendelkezésre áll.
Az STM32 sokkal nagyobb "kerítést" igényel (pl. DMA). Még az sem világos, hogy induljak neki - nem akarom pl. a HAL -t használni.
Az STM32 még egy LED villogtatós "programhoz" is hosszas előkészületeket igényel.

* Én egy indián vagyok. Minden indián hazudik.

ASM-ben talan igen. Az emlitett STM32-es laphoz van Arduino tamogatas, a ledvillogas pont egyszeru. Arduino IDE-be beintegralhatod, osszekotod a geppel az - asszem - 2-es UARTjat (tobb, mint egy eve foglalkoztam vele), betoltod vagy megirod az Arduinos Blinket, ratoltod, megy. Talan a lapon levo LED nem a szokasos 13-as pinen van, ennyit kellett atirni a mukodeshez.

Egyebkent rajta van a todo listamon, hogy jobban beletanuljak. Azert az ARM sokkal erosebb egy AVR8-nal, es ez arban is nagyon versenykepes.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Még az sem világos, hogy induljak neki - nem akarom pl. a HAL -t használni.

CubeMX. Ha a HAL bloatwarenak tűnik (mert az) akkor az 5.x-es verziók tudnak LL-es kódot generálni (bizonyos perifériákhoz bizonyos procikon).

Az STM32 még egy LED villogtatós "programhoz" is hosszas előkészületeket igényel.

CubeMX. Árkot ás, habot ver, hó végén kölcsön ad. Legenerálod a kódot vele, azt a 3 sor kódot kell berakni a mainbe. Nem mondom, hogy hibátlan, azt sem, hogy jó, de az adoptációs görbére pozitív hatással van.

Nagyon köszönöm, hogy megosztottad!
A másik feladat, amit eddig nem említettem a fejlesztő környezet.
Most (pusztán elméleti síkon) azt látom, hogy van olyan mint az Atollic TrueSTUDIO, nézegettem olyat hogy OpenSTM32 illetve számtalan (eléggé poros) leírást hogy is kellene telepíteni egy mindenféle finomsággal (értsd pl. standard header fájlok különféle STM32 -hez). Az IDE leginkább az Eclipse (az én öreg szememnek elég szokatlan, bár lehet azért mert egyszerre egy screen shoton akarnak mindent megmutatni). Aztán ott van az OpnOCD ami az STlink és a debuggoláshoz kell. És persze ott van a CubeMX, ami ha jól értelmezem egy grafikus felület arra, hogy kiosszam a lábaknak a funkcióit és ...
A TrueSTUDIO -val aggaszt, hogy a HAL nélkül meg sem fog mozdulni.
Még egy aggodalom, hogy tudok assembly kódot hozzá tenni (van hogy a beágyazott elég, de én szeretek külön assembly fájlokba írni, pl. ISR -t (eddigi tapasztalataim szerint a C nagyon szószátyár tud lenni, ráadásul roppant nehezen olvashatóak a bitmanipulációs kifejezések. (pl. az STM8 eléggé feszesen időzített bitbang a "return" -el együtt mindössze 4 utasítás, a C -ből generált assembly egy oldal - SDCC).

* Én egy indián vagyok. Minden indián hazudik.

Most (pusztán elméleti síkon) azt látom, hogy van olyan mint az Atollic TrueSTUDIO, nézegettem olyat hogy OpenSTM32 illetve számtalan (eléggé poros)

Azt tudni kell, hogy az ST megvette az Atollicot. Integráltságban, működőképességében messze veri az AC6 OpenSTM32 vagy system workbench néven futó IDE gyurmáját. Nem kell szívni openOCD konfig masszírozással, felrakod, megy (szokott menni).

Aztán ott van az OpnOCD ami az STlink és a debuggoláshoz kell.

A Truestudiot nem OpenOCD-t használ az ST debug toolját ami csak JLinket meg STLinket támogat.
STLinket (ha lehet) érdemes átflesselni JLink-re https://www.segger.com/products/debug-probes/j-link/models/other-j-link… mert az Atollic tud vele olyat, hogy live expressions: változók értékét tudod élőben nézni pause nélkül illetve az SWD, meg SWO clock duplája lehet.

És persze ott van a CubeMX, ami ha jól értelmezem egy grafikus felület arra, hogy kiosszam a lábaknak a funkcióit és ...

A CubeMX "skeleton" projektet generál. A kódban vannak ilyen user markerek ami közé írhatsz olyan kódot amit a kódgenerátor békénhagy ha újra generálod.

A TrueSTUDIO -val aggaszt, hogy a HAL nélkül meg sem fog mozdulni.

Az ST egy ideje tolja az SPL helyett az LL API-t a HAL mellé. Én most használom egy projektben, eddig még nem utáltam meg.

STM8-al szerintem hobbiból nem éri meg szívni. Oké, hogy 80 HUF-ért lehet épkézláb kontrollert venni, de hobby méretben nem számít.
Az SDCC kódméretben messze a Cosmic után kullog, a Cosmichoz használható IDE-t meg csak az ellenségeimnek kívánom.

Egy crossplatform, nem kereskedelmi célú felhasználásra ingyenes alternatíva:

Segger Embedded Studio (rebrandelt Rowley Crossworks, viszont csak Segger J-Linket támogat)
https://www.segger.com/products/development-tools/embedded-studio/

ST-Link Reflash Utility-vel az ST board-ok upgradelhetőek J-Link-re (nem kell OpenOCD)
https://www.segger.com/products/debug-probes/j-link/models/other-j-link…

- a fenti CubeMX-et szintén támogatja (eclipse projekt import funkcióval)
- nem kötöd magad gyártóhoz (ST, Nordic, NXP stb... támogatás)

Én ennyit használtam:

- ubuntu desktop
- sudo apt install gcc-arm-none-eabi stm32flash make git vim
Továbbá a mikrovezérlő doksiját.

Debug: arra szoktam rá, hogy LED-re és/vagy UART-ra indikálok debug információt, ha valamilyen részeredményre kíváncsi vagyok. Aztán törlöm a debug sort, ha nem kell, vagy csak nem fordítom bele. Ez utóbbira a
#ifdef DEBUGOLOMAZTAVALAMIT
....
#endif
módszer jól használható. Ha a Makefile-ben nincs -DDEBUGOLOMAZTAVALAMIT, akkor nem fordul bele a kódba ez a LED-re vagy UART-ra kiíró ellenőrző kódrészlet.

Köszönöm az infót.
A LED villogtatás, GPIO kapcsolgatás, oszcilloszkópos megfigyelés stb. durván harminc éve űzöm. Szeretnék úgy embedded cuccot csinálni (vagy majdnem úgy) mint amikor egy PC szoftvert írogatok.

OFF: Persze a legszebb egy igazi hw emulátor lenne de ez olyan drága (lehet), hogy elérhetetlen :(

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2019. 10. 30., sze – 17:12 )

A következőt találtam https://github.com/hbendalibraham/stm8_started

Ahol azt írják

ST-Link programmer or clone used to write your compiled code ( Firmware ) into the micro-controller. For the programmer, you need one that support SWIM (Single Wire Interface Module) mode. You can (recommended) go with the original debugger of STMicroelectronics which is ST-Link V2 (you can get this one second hand as low as 20$) or if you are really want to go economical, you can get away with the fake ones wich cost you under 10$ (please note that these cheap debuggers only support software mode, which works fine, and do not give you full functionality and speed of the genuine debuggers of ST itself). or you can build your own Open source Stlink Tools.

Most akkor a a debug -hoz ezek a klónok használhatatlanok? Ráadásul ha ez így igaz akkor az STM32 -vel is ez lehet a helyzet. Van tapasztalat?

* Én egy indián vagyok. Minden indián hazudik.