STM32CubeMX

[jesse]

Hej på er.

Jag har hållit på några timmar (= veckor) med att försöka förstå mig på STM32 och dess mjukvara, speciellt när man startar med STM32CubeMX. Och jag känner att jag fastnar totalt hur mycket jag än läser / försöker.

Vill man testa en funktion så är det superenkelt att bara plocka ett av alla exempel som följer med biblioteken... Man kan göra snygga layouter på displayen, en enkel HTML-server, blinka lysdiod eller nåt annat skoj. Dessa är ju relativt enkla att modifiera till egen önskad funktion. Tyvärr verkar det dock som att dessa exempel inte är kompatibla med den kod jag får fram när jag skapar ett nytt projekt i STM32CubeMX. FUnktioner är annorlunda, de anropas i annan ordning och strukturen verkar annorlunda rent generellt.

Vad jag egentligen saknar är en ordentlig referens till de bibliotek som utgör "drivers" och "middleware"... Men jag hittar inget. Det enda jag hittar är doxygen-genererade filer som inte säger ett dugg om vad funktioner och variabler har för syfte och funktion - bara att de existerar och vilka argument man ska skicka med.

När man har ett API med runt 50 funktioner med massor av obegripliga argument så är det för mig lika omöjligt att gissa hur jag ska använda dessa som att försöka dechiffrera uråldriga inskriptioner från Indus-dalen....

Finns det ingen vettig referensdokumentation? Jag hittar inget och vet inte hur jag går vidare?

[lillahuset]

Du får nog visa lite mer tålamod om det ska bli något.
Jag utgår från att du redan kan programmera C annars bör du lära dig det först.

Du kanske har sett den här tråden: http://elektronikforumet.com/forum/view ... =7&t=92782
Det kanske kanvara en bra början.

[jesse]

Jag har programmerat i C på bl.a. Atmel ARM (32 bit). Där var det lite enklare att komma igång tycker jag. De har en liknande lösning som STM32CubeMX. Varför jag inte vill fortsätta med Atmel ARM beror delvis på deras alla buggar i biblioteken (möjligtvis fixat nu, men ändå - det suger när man måste reparera biblioteken).... Dels att de på sikt troligtvis aldrig kommer att få lika stor spridning som STM32 och därmed mindre support.

Jag har ju läst en del exempel och tutorials (med exempel) och tänkte att den där steg-för-steg nybörjarguiden var ytterligare en sådan av typen "läs in filen och tryck på enter och vips så funkar det"... Men den har ju lite intressanta referenser så kanske jag borde gå igenom den (även om jag inte har exakt ett sådant utvecklarkort som används där)....

Men jag såg i alla fall att de refererade till en HAL Low layer Driver - user guide... och jag hittade motsvarande för min processor: "Description of STM32F2 HAL and Low Layer drivers" vilket är en början i alla fall. Frågan är om jag kommer att kunna tolka den...

Nåja... jag kollar steg-för steg-guiden så får jag väl återkomma med frågor när jag väl ska fortsätta med mitt egna projekt.
Jag tänkte på enklast möjliga sätt få UART att fungera... men bara att skicka data på ett vettigt sätt kräver ju att jag har en timer i main-loopen så att jag inte skickar för mycket data... Så då måste jag ju fixa en timer som ger mig "ticks" eller tidsintervaller. kanske 10 per sekund eller så. Där bör väl jag få nytta av blinka-lysdiod-exemplet - även där lär ju behövas en timer om det inte ska blinka i i Mhz-området...

EDIT: Äsch... de använder en låsande funktion HAL_Delay(100); ööööhhhh , jag får väl stå ut med det tills jag lärt mig hantera timerinterrupt.

[AndLi]

STM32 Hal skulle jag inte säga är buggfri, inte för 2 år sen i alla fall. Och eftersom den ska stödja varenda obskyrt specialfall så är den enormt långsam. Men när man sen vill göra något annat obskyrt specialfall är man ändå där och knappar rakt in i registret.

Men det är en bra referens av vad man behöver pilla med för att göra olika saker.

[lillahuset]

När jag höll på och skrev program på allvar skapade jag alltid en "hal.c" för de periferienheter jag behövde.
Jag studerade hårdvarudokumentationen noga och jämförde med koden i STs HAL och skrev eget. Det blev betydligt snabbare och lättare att förstå.
STs HAL använde jag ganska ofta till att sätta upp periferienheterna men inget annat.

[ToPNoTCH]

Jag känner med dig Jesse.

Den automatgenererade koden fån CubeMX känns som ett tafatt försök att göra det lättare, men i praktiken blir alla automatiska definitioner och anrop hopplösa att följa.
Man måste nästan lära om från början med "vag" dokumentation.

Dessutom var det otroligt buggigt vid lanseringen.

Jag använder CubeMX enbart som dokumentationsverktyg för att hålla reda på vilka pinnar som går till vad.
Genererar ingen kod.

Över tid kommer dom väl droppa native STD pheriphal driver stödet, men jag kommer nog hålla ut i det sista.

[jesse]

Jaha
Så det är inte jag som är hopplöst gammal och obildbar.... STM32CubeMX suger alltså. Men hur sjutton gör alla professionella utvecklare som inte har 400 timmar på sig för ett simpekt projekt? Håller dom verkligen på och tragglar med dessa odokumenterade API:er eller har dom nån hemlig genväg....?

• Jag fattar inte hur man kan göra reklam för såna här och tala om "snabbare väg till lansering" (av ny produkt).... Det tar ju veckor eller månader innan man ens kommit igång.
  Men det verkar ju allmänt vedertaget att det tar flera veckor att lansera ett projekt om det handlar om 32-bitars.
• Det är därför man får så konstiga erbjudanden i inkorgen nuförtiden, som t.ex. "färdigprogrammerad WiFi och Bluetooth-modul: Koppla upp dig utan en enda rad programkod. Koppla denna modul direkt till din 8-bitars controller och du är igång på ett par timmar istället för flera veckor som annars är normalt när man ska utveckla en enkel IoT."
  Va??? Flera veckor? Bara för att fixa en IP-stack? Det borde väl bara vara att ange IP-adress och köra....

OK, skämt åsido, ST har alltså haft minst lika buggiga bibliotek som Atmel.... Men jag får väl förutsätta att det mesta hamnat på plats nu då.

När jag höll på och skrev program på allvar skapade jag alltid en "hal.c" för de periferienheter jag behövde.
Jag studerade hårdvarudokumentationen noga och jämförde med koden i STs HAL och skrev eget. Det blev betydligt snabbare och lättare att förstå.
STs HAL använde jag ganska ofta till att sätta upp periferienheterna men inget annat.

jo, jag har ofta tänkt tanken att göra detsamma. Men det känns lite onödigt. Ska man verkligen behöva uppfinna hjulet en gång till? Men jag håller med dig, jag är helt övertygad att koden hade blivit betydligt bättre och begripligare.

Jag får väl fortsätta att kämpa.... suck.

[Klas-Kenny]

Men hur sjutton gör alla professionella utvecklare som inte har 400 timmar på sig för ett simpekt projekt?

Har förvisso aldrig använt just STM professionellt, men min väg är i princip alltid att läsa i datablad och referensmanual, och skriva egna hårdvarunära funktioner.
Finner det enklare att läsa detta och få veta vad som egentligen händer, än att gissa utifrån halvdåligt dokumenterade API'er med risk att inte få igång saker enkelt när man behöver göra någon liten ändring om fem år och inte har kvar den gamla utvecklingsmiljön.

Med undantag för typ USB, Ethernet (TCP/IP) och liknande där det ligger lite mer mjukvara bakom. Men alla enkla periferienheter typ SPI, timers, UART, räknare, GPIO osv osv. Blir dessutom i princip alltid mycket effektivare kod.

[lillahuset]

Jag är ganska säker på att man sparar tid på att uppfinna hjulet på nytt, det brukar ju räcka med en liten delmängd av hjulet. Och samtidigt passar man på att skriva testkod för sitt nya lilla hjul.
Att skriva HAL för allt junk som döljer sig i en STM32xxx däremot känns kontraproduktivt.
Sedan återanvänder man sina förhoppningsvis ganska väldokumenterade funktioner. Som förhoppningsvis beter sig ungefär som vanliga C-libb med parametrar i liknande ordning så att det är lätt att lära sig att använda dem.

En TCP/IP-stack köper man eller väljer en som verkar seriös och är gratis. Samma om man behöver ett RTOS.
Vi köpte en CAN J1939 stack, källkod inkluderad, för en massa pengar. I den hittade jag en bugg och kontaktade tyskarna vi köpt den av. Fick otroligt bra support. Den stacken hade vi alldeles för lite kunskap för att skriva själva.

[jesse]

lwip är en stack som finns inbyggd i STM32CubeMX. Jag tänkte försöka använda mig av den. Har i alla fall egen dokumentation.

[SvenW]

Det verkar som ni är överens med mig om att STM32CubeMX trots sin tjusighet inte är
helt lättanvänt för oss icke-experter.
De har väl för många varianter för att kunna sköta underhållet!

Vad gäller HAL_Delay() så låser den sig tydligen om inte SysTick-avbrottet är aktiverat.
STM32CubeMX borde aktivera detta självmant men tydligen inte??
Någon som vet hur man gör detta?? Jag använder STM32F407 disc1-kortet.

[lillahuset]

Jag tror STM32CubeMX är frampiskat av marknadsavdelningen för att "alla andra" har liknande produkter.

Jag tror få erfarna programmerare skulle basera sina produkter på verktyg liknande STM32CubeMX.

[jesse]

Tack för input.... det luta alltså åt vad jag redan känner själv... att STM32CubeMX inte är det proffsverktyg som de försöker påstå i reklamen. Tyvärr när man söker på ST's sidor så hittar man inga alternativ. Man hänvisar hela tiden till att all mjukvara är obsolit och ersätts med STM32CubeMX..