Ciao a tutti
Per progetti hobbistici di solito uso microcontroller della serie PSoC di Cypress (ora acquisita da Infineon).
Recentemente un amico mi ha imbarcato in un progetto che forse diventa open source e insomma, per farla breve mi serviva un microcontroller con ambiente di sviluppo gratuito e che si potesse programmare senza un J-Link o roba simile (deve quindi avere un bootloader integrato quando lo si compra).
Visto che tutti usano STM32 in tutte le salse e che soddisfa queste condizioni mi ci sono buttato.
Ho usato STM32Cube per configurare le periferie (GPIO, UART, eccetera) e per scrivere il codice.
Lo trovo abbastanza terribile. Soprattutto la struttura del codice generato da CubeMX per l'HAL è dispersa ovunque e bisogna stare attenti ad aggiungere codice utente solo negli spazi prestabiliti.
Voi cosa usate?
Vi configurate le periferiche a mano o con CubeMX?
Come gestite la coesistenza di codice generato e codice vostro?
Lo sto usando in modo sbagliato?
Boiler
STM32: che ambiente di sviluppo usate?
Moderatore:
Paolino
9 messaggi
• Pagina 1 di 1
2
voti
CubeMX permette di esportare il progetto a Makefile. Io uso toolchain scaricato dal sito ARM e librerie LL, se un Middleware viene con le HAL (Tipo USB o Ethernet) allora mantengo le HAL...
La generazione di codice mi ha fatto cagare, scusa la sincerità ma fa acqua da tutte le parti: errori nel makefile, librerie mancanti etc. Per questo ho deciso di lasciare perdere la tool.
Per il progetto a cui sto lavorando, ho generato il codice di setup con CubeMX per risparmiare tempo, ma ho mollato per i motivi esposti. Vado di TRM.
EvitoCubeIDE/Eclipse etc. Lento come una tartaruga.
La generazione di codice mi ha fatto cagare, scusa la sincerità ma fa acqua da tutte le parti: errori nel makefile, librerie mancanti etc. Per questo ho deciso di lasciare perdere la tool.
Per il progetto a cui sto lavorando, ho generato il codice di setup con CubeMX per risparmiare tempo, ma ho mollato per i motivi esposti. Vado di TRM.
EvitoCubeIDE/Eclipse etc. Lento come una tartaruga.
1
voti
Dimenticavo: per programmare il micro ST offre la tool STProgrammerCLI. Funziona bene. Offrono pure una API in C e external loader per QSPI esterne.
GDB server viene in CubeIDE. È l'unico motivo per cui l'ho installato.
Tutto questo su Linux. Debian.
GDB server viene in CubeIDE. È l'unico motivo per cui l'ho installato.
Tutto questo su Linux. Debian.
0
voti
Grazie per aver confermato la mia impressione.
In effetti mi ero dimenticato che uVision ha una licenza gratuita per l'uso con STM32. Immagino tu intendessi questo quando hai parlato di un programma scaricato dal sito ARM.
Trovo deludente anche quello.
Probabilmente Cypress mi ha viziato, tutto il resto mi risulta di difficile uso
Anche NXP non è malaccio.
E forse non sono fatto il mondo del progetto collaborativo o open-source, dove bisogna accettare soluzioni sub-ottimali per permetterne la fruizione al vasto pubblico.
Boiler
In effetti mi ero dimenticato che uVision ha una licenza gratuita per l'uso con STM32. Immagino tu intendessi questo quando hai parlato di un programma scaricato dal sito ARM.
Vado di TRM.
Trovo deludente anche quello.
Probabilmente Cypress mi ha viziato, tutto il resto mi risulta di difficile uso
Anche NXP non è malaccio.
E forse non sono fatto il mondo del progetto collaborativo o open-source, dove bisogna accettare soluzioni sub-ottimali per permetterne la fruizione al vasto pubblico.
Boiler
0
voti
boiler ha scritto:Immagino tu intendessi questo quando hai parlato di un programma scaricato dal sito ARM.
No no, mi riferivo a arm-none-eabi-gcc.
Volevo evitare CubeIDE, quindi ho corretto errori di makefile etc. ed volevo usare GCC standalone senza ingombri, ma poi ho dovuto scaricarlo (l'IDE) per via del fatto che GDB server (così come GCC
Studiarti il TRM secondo me è necessario ma sono opinioni. Quelli di ST non mi sembrano scritti male.
Di nulla!
0
voti
Scusa, stavo pensando al manuale dell'HAL, non al TRM:
https://www.st.com/resource/en/user_man ... ronics.pdf
Lo trovo pessimo.
Il TRM lo uso come referenza per cercare di capire cosa fa l'HAL e -secondo me- è uno dei peggio scritti, avendo come termini di paragone Cypress, NXP, Analog Devices e Atmel.
La prossima volta che impreco a causa sua, posto qui il paragrafo relativo
Boiler
https://www.st.com/resource/en/user_man ... ronics.pdf
Lo trovo pessimo.
Il TRM lo uso come referenza per cercare di capire cosa fa l'HAL e -secondo me- è uno dei peggio scritti, avendo come termini di paragone Cypress, NXP, Analog Devices e Atmel.
La prossima volta che impreco a causa sua, posto qui il paragrafo relativo
Boiler
0
voti
Ah no. Io il manuale delle HAL e LL non lo guardo nemmeno. Uso l'header e sorgenti. Sufficiente.
Purtroppo con le MCU a 32bit ho sempre usato ST quindi non posso giudicare il resto più di tanto.
Apprezzo molto le doc di Analog Devices. Ma poi ognuno ha i suoi pro e contro.
Pero scaricare una tool release e riscontrare ovvi bug che con due prove dopo 5 minuti di uso te ne accorgi (p.e. makefile con errori, librerie e sorgenti mancanti etc.), mi dà l'impressione di superficialità. E mi fa girare le sfere.
Riguardo al TRM, sto imprecando ultimamente con il GPDMA ed SPI. Mi mancano gli 8bit con i mitici datasheet PIC ed AVR con gli esempi in assembly.
Purtroppo con le MCU a 32bit ho sempre usato ST quindi non posso giudicare il resto più di tanto.
Apprezzo molto le doc di Analog Devices. Ma poi ognuno ha i suoi pro e contro.
Pero scaricare una tool release e riscontrare ovvi bug che con due prove dopo 5 minuti di uso te ne accorgi (p.e. makefile con errori, librerie e sorgenti mancanti etc.), mi dà l'impressione di superficialità. E mi fa girare le sfere.
Riguardo al TRM, sto imprecando ultimamente con il GPDMA ed SPI. Mi mancano gli 8bit con i mitici datasheet PIC ed AVR con gli esempi in assembly.
1
voti
Ah, l'ironia...
Email arrivata oggi:
Praticamente ho travasato questo thread nel formulario del sondaggio
Boiler
Email arrivata oggi:
ST ha scritto:Hi XXXX
We hope you’re enjoying your experience with our STM32CubeIDE software.
As part of our ongoing effort to provide better services and support, we would like to request your feedback on your experience with the software via a short online survey. It only takes about 2 minutes to complete.
Praticamente ho travasato questo thread nel formulario del sondaggio
Boiler
0
voti
Hai fatto bene. Ovviamente i problemi bisogna segnalarli, per essere corretti. E non importa se via mail o forum, semplicemente si contribuisce alla loro correzione anche solo con una segnalazione.
Io a suo tempo lo feci notare nel forum. Che forse è peggio
ma uno sviluppo più attento può evitare critiche pubbliche. Non è colpa mia se il prodotto è fastidiosamente diffettuoso, anche se free.
Io a suo tempo lo feci notare nel forum. Che forse è peggio
9 messaggi
• Pagina 1 di 1
Torna a Realizzazioni, interfacciamento e nozioni generali.
Chi c’è in linea
Visitano il forum: Nessuno e 2 ospiti

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)


