STM32 a ST-Link v GNU/Linuxu

31.3.2012 11:57 | Přečteno: 3067×

Před nějakým časem (rok, dva?) začalo ST dodávat malé vývojové modulky za cca 200kč s názvem STM32VLDiscovery..

Jednalo se o kit s MCU typu STM32F100..Tehdy jsem ten kit zakoupil s radostí, že přejdu na něco lepšího z AVR.. Ukázalo se, že free vývojové prostředí AtollicStudio je přímo nasíravé a IAR a KEIL zase ve free verzi omezeny.

Takže se naskytla otázka co na to GNU/Linux? S GCC Code Sourcery a stm32 knihovnami není problém, ale do nedávna byl problém s ST-Linkem, který prostě neměl podporu. Čas plynul, já kit hodil do kouta, až teď jsem objevil článek, že ST-Link v linuxu funguje.

Zde je dostupný ST-link pro linux, který umožňuje přes aplikaci st-util propojení s arm-gdb a aplikací st-flash programování/čtení STM32.

Zde je dostpuná povedená template s Makefile pro vytvoření testovací aplikace a nalití přes st-link v GNU/Linuxu.

Pozn: Archlinux obsahuje stlink balík v AURu

Template i stlink jsem odzkoušel v i686 Archlinuxu a vše běží jak má. Pouze example kód dodávaný přímo k stlink z githubu nemusí být zrovna funkční. Uvedená template (druhý link) funguje bez problému což bylo ověřeno na aplikaci typu blikej LED :)

Jakmile úspěšně zakončím diplomku (ještě s AVR), přijde na řadu zakomponování st-link a arm-gdb do Codeblocks pro jednoduchý vývoj a ladění, stejně jako to mám pro AVR..

Konec nudného zápisku

       

Komentáře

[SAM:]

S Texane/Stlink mám dobré zkušenosti. Pár dalších poznámek lze nalézt v naší HWWiki. U některých verzí ST-Link bylo potřeba přidat výjimku, protože se tvářili jako mass-storage a chytal se na ně modul usb-storage. Údajně by měl ST-Link chodit i s OpenOCD, což je takové systémovější řešení než Texane/Stlink, ale nezkoušel jsem ho.

[luta]

diky. mrknu na to. openocd znam ovsem netusil jsem ze jiz ma podporu pro stlink. dost dlouho jsem se o to nezajimal. zajimaly by me rychlosti prenosu dat. stlink mi hlasil default 4KB/s coz je dost ubohe pro nedepresivni ladeni kodu.

[Jiří Němec]

Díky za článek, nedávno mi st-link dorazil, ale zatím jsem neměl odvahu namontovat to do nějakého IDE, nebo spíš nebyl čas.

Sourcery G++ je asi nejlepší dostupný toolchain pro linux - bohužel . Doporučuju kompilovat s -O0. Schválně jestli na něm třeba rozchodíte (soft) reálná čísla. Známý už kvůli tomu přešel na Apple. Ale stále lepší, než stav u jiných toolchainů u kterých mi třeba nefungoval memcpy. Momentálně jsem z stm32 stavu v linuxu tak znechuceny, že jsem projekt trochu odložil.

Jo jaký používáte rtos? Jsem chvíli zápasil s FreeRTOS, ale naprosto základní věci mi padaly, tak se nyní snažím pochopit Chibi/OS.

[luta]

presne z toho duvodu delam i diplomku na Avr kde je vse za ty roky odladene. realna cisla jsem prozatim nepotreboval. vse se dalo s urcitou presnosti na x desetinnych mist pocitat celociselne. zatim jsem na stm32 prilis casu nemel. 2 roky mi lezi doma. Avr mi do ted stacilo a komfort jeho vyvoj. nastroju a knihoven zatim nic neprekonalo. rtos a jine nepouzivam, prozatim.

[Limoto]

Pěkný, ale teda AVR mi přijde na první pohled otevřenější. Kde to kupuješ?

[luta]

AVR je přehlednější a mnohem otevřenější..Rád bych našel podobnou levnou platformu na 32bit jako staré dobré AVR..s AVR se dá udělat stále hodně práce a až do teď mě výkon zas tak moc neomezoval..

Ten kit je přímo od farnellu..Teď je tam tuším jiný kit i s LCD displejem..tutoriály pro to strašné AtollicStudio (zpoplatněné eclipse) vycházely na mcu.cz

[Jiří Němec]

Tak avr je naprosto primitivní, jak se do toho člověk trochu dostane, tak je stm32 taky naprosto v pohodě. A dokumentace od st se mi čte mnohem lépe jak od atmelu. Jediný problém jsou ty toolchainy, ale na druhou stranu ty jsou zabugované i v avr, zrovna v týdnu jsem řešil že mi atmega počítá špatně s uint32_t.

[luta]

tak ten špatněj výpočet s uint32_t by mě zajímal a verze gcc taktéž.. zatím mi to počítalo v pohodě i uint64_t :) zabugovanost avr oproti novějším platformám je minimální..takový rtos v ftdi vinculum - to bylo teprve maso..

[Jiří Němec]

V archu community/avr-gcc 4.6.3-1, community/avr-libc, 1.8.0-1 community/avr-binutils 2.22-2, přešel jsem na avr-gcc-atmel 4.5.3-1, aur/avr-libc-atmel 1.7.1-1 a avr-binutils-atmel 2.20.1-2 z auru a vypadá to ok. Právě že v gcc 4.6.2 byla spousta oprav AVR.

[luta]

díky. Já zrovna před nějakou dobou odblokoval aktualizace avr-gcc a spol. Takže jdu testovat výpočty, protože v diplomce se mi většina věcí ukládá a počítá v uint32_t na 4.5.3 mám někde ještě pkgbuild snad..v čem byla chyba? násobení dělení? 4.6. měla jednu dobu trable s pgm konstantama  const u PSTR a spol..

[Jiří Němec]

Třeba jsem jen já dělal něco špatně, byla to čísla někde na hranici uint16_t, asi o řád jsem to násobil a pak dělil (kompenzace různé frekvence procesoru v mých sleep rutinách). Dle rady na nějakém diskuzním fóru jsem použil int32_t a pak to bylo ok.

[luta]

hmm zatím to vypadá, že mi to počítá dobře. tak doufám,že to tak zůstane nerad bych ty výpočty všechny procházel znova ..v uint32t běžně počítám provozní data spalovacích motorů..dřív uint64, ale to bylo už dost náročné na flash.. přepínání bank registrů udělá svoje