La pagina si chiama “stm32” ma per ora parla solo del blue pill (ovvero stm32f103c8)

Perché¶

perché usare questo microcontrollore? non ne capisco molto di microcontrollori, ma questo mi piaceva perché

• costa poco(1.70EUR) ma è abbastanza potente (32bit, 128kB ram…)
• il programmatore è molto economico (non come i PIC…) e comunque puoi anche usare direttamente la porta USB
• la stm32 è una famiglia che parte da cose come il bluepill e arriva fino a roba parecchio potente. Quindi più o meno puoi scalare senza dover reimparare tutto da 0.

tra i difetti c’è:

• meno cose già fatte rispetto ad arduino o anche solo ad atmega
• non è in formato DIP, insomma ingombra un po’ di più
• è una famiglia abbastanza “ricca”, quindi ci sono un mare di librerie e di framework. Molta gente che lo usa, usa gli IDE, e non tutti lo stesso. Il risultato e’ che usare una libreria fatta da altri per stm32 e’ davvero una rarita’. da questo punto di vista il mondo avr è più facile.

Come¶

Panoramica di strumenti e piattaforme¶

Allegato c’è un libro utilissimo per usare l’STM32 con freertos+libopencm3 “Beginning STM32”. È un buon modo di sistemare una toolchain in modo pratico e abbastanza unixoso, usando solo sw libero e senza richiedere interfacce grafiche. Il libro viene insieme a questo repository che contiene soprattutto il porting di freertos preciso per il blue pill.

Altrimenti come toolchain si può usare anche platformio che crea facilmente la toolchain ma NON quella freertos: platformio può fare libopencm “nudo” (senza RTOS) oppure supporta mbed (quindi c++ e livello più alto, ma ho avuto brutte esperienze con i suoi thread).

Una mia recensione dei framework:

• libopencm3 fa quel che deve. Ma non ha alcuna nozione di RTOS quindi ad un certo punto i loop diventano più complessi
• mbed (C++) è molto ad alto livello, molto semplice, tutto simpatico. Include sia un suo RTOS sia delle librerie per l’hardware. Ha delle librerie con cui astrae (parecchio!) le periferiche, che sono degli oggetti utilizzabili in maniera molto molto semplice.
  Purtroppo i thread non funzionano davvero, funzionano per finta. Le code e altri meccanismi di comunicazione tra parti del programma invece funzionano bene e di fatto sono sufficienti per fare tutto.
• freertos ( C ) è un RTOS vero, ha i thread che funzionano, le code, le mutex, eccetera. Come RTOS è paragonabile sulla carta, e migliore in pratica, di quello di mbed. Non include, di suo, alcuna utility per gestire le periferiche in modo astratto. Per semplificarti la vita puoi integrarlo con libopencm3, che un pochinopochino astrae, ma comunque non tantissimo. Non ho capito se si possono scrivere pezzi in C++ integrati con freertos, ma credo proprio di sì

In pratica il grosso delle cose che faremo sarà libopencm3 + freeRTOS

Workshop¶

Primo appuntamento: 5 settembre¶

Abbiamo installato tutto il necessario su debian e su archlinux. (TODO: inserire dettagli).

per arch:

pacman -S arm-none-eabi-gdb arm-none-eabi-gcc stlink

per debian 10:

apt install gcc-arm-none-eabi gdb-multiarch build-essential ca-certificates git cmake pkg-config dfu-util stlink-tools libusb-1.0-0-dev

Per debian è un po’ antipatico compilarsi st-link perché la compilazione funziona a calci. Bisogna fare a vanvera robe tipo

git clean -fxd
cmake .
make release

finché la directory build/Release non compare, alché possiamo fare make install.

Siamo partiti dal tarball stm32.tar.gz (vedi la colonna allegati sulla destra) in cui dentro ci stanno varie cose, alcune sono dipendenze e altri sono semplici progettini con cui iniziare.

I progettini sono dentro la directory my/. Lì ci sono anche alcuni appunti, nei file APPUNTI.md e ORDINE.md.

Abbiamo visto i progetti button1, button2 e button3_int. Il primo gestisce i GPIO in maniera “banale”; il secondo introduce i Task (una specie di thread fatta da FreeRTOS) il terzo mette insieme Task e interrupt, usando le code (xQueueSend / xQueueReceive) per mandare i dati ad un task “worker”. In questo modo il codice è pulito e il feedback è immediato.

Abbiamo visto appena appena i Makefile, in particolare non abbiamo visto come i Makefile cambiano man mano che ci servono pezzi di libreria nuovi (prima freertos, poi anche le code).

Il programma button3_int sembrava essere buggato, beccava il primo interrupt e poi basta. Per capire che succedeva abbiamo usato gdb con st-util:

st-util -n -v0 &
arm-none-eabi-gdb -ex 'target extended-remote localhost:4242'  -se=main.elf

ma poi ci siamo stancati. Comunque non solo a me funzionava tutto, ma ho ritestato e continua a funzionarmi tutto. Scoperto il motivo: qualcuno aveva attaccato la 5V invece della 3.3.

Possiamo aggiungere queste righe al Makefile.incl in modo che dopo possiamo fare make flash debug quando ci serve:

debug: elf
	st-util -v0 &
	$(GDB) -ex 'target extended-remote localhost:4242' -se=main.elf

Reference¶

• libopencm3
  • gpio
  • rcc
• FreeRTOS
  • task: xTaskCreate
  • code: xQueueCreate, xQueueSend, xQueueReceive
• vApplicationStackOverflowHook che però non ha funzionato

Secondo appunamento: 13 settembre¶

Dato che al primo eravamo in pochi, facciamo qualche passo indietro. Però siate bravi, arrivate con già le cose installate, vedi info nella sezione sopra e dentro il tarball

Ennesimo: 17 ottobre¶

vediamo come mettere le cose su usb, come gestire menu e schermo e altre cose avanzatissime. siamo sostanzialmente in chiusura del workshop, quindi cerchiamo di ripassarci le cose già viste

share.riseup.net/#p7mZHKIW8lr-2lO0Ay9d9A

share.riseup.net/#FO1CEf6xaR3zltT8dKh05g