STM32 discovery-board, lämplig programvara?

[Lennart Aspenryd]

Betyder det att du helt släpper STM32 nu Lemuren! Jag som trodde att gammal var äldst!
Nåväl, jag har uppskattat tråden, speciellt när det man tipsar om har referenser i annat!

Skall bli spännande att höra om fortsättning och syfte med projektet.

[lizerdboy]

Tips på Guide
http://www.muratursavas.com/docs/isildak_en.pdf
http://www.emblocks.org/wiki/tutorials/f401_f429_disco
http://nicot31.fr/en/emblocks-stm32f4-discovery/

Jag har inte använt HAL drivers än (CubeFx biblioteken) så jag kan inte uttala mig om det är.
Men med standard biblioteken som jag kör med så kom jag i gång på nolltid.

[SeniorLemuren]

Betyder det att du helt släpper STM32 nu Lemuren! Jag som trodde att gammal var äldst!
Nåväl, jag har uppskattat tråden, speciellt när det man tipsar om har referenser i annat!

Skall bli spännande att höra om fortsättning och syfte med projektet.

Haha, nej ge upp är det svåraste som finns, (tyvärr, ibland kan det gå för långt). skall kolla lite vad lizerdboy kommit upp med.

[SeniorLemuren]

mri: Vad var anledningen till att du portade till cube?

Har du några andra förslag som är bättre eller vill du bara veta?

[SeniorLemuren]

Tips på Guide
http://www.muratursavas.com/docs/isildak_en.pdf
http://www.emblocks.org/wiki/tutorials/f401_f429_disco
http://nicot31.fr/en/emblocks-stm32f4-discovery/

Jag har inte använt HAL drivers än (CubeFx biblioteken) så jag kan inte uttala mig om det är.
Men med standard biblioteken som jag kör med så kom jag i gång på nolltid.

Skall gå igenom den första länkens pdf. Den behandlar samma kort och µC (STM32F100) som jag har. De andra 2 handlar om STM32F4xx. Vad skiljer sig åt när det gäller programmering av resp. µC?

Jag har utrustat mig med bergkrokar rep och slagborrmaskin nu, hjälper inte det så får det bli semtex, för blinka skall det.

[lillahuset]

Jag vill bara veta.
Att porta ett någorlunda stort projekt från en miljö till en annan är förenat med en hel del arbete om man har minsta ambition att verifiera att det blev rätt.
Om den nya miljön är betydligt bättre kan det vara värt det men är man bara lite grinig på den gamla är oftast inte värt det.
Däremot, att välja en ny miljö för ett nytt projekt är ju inget konstigt bara man är medveten om merarbetet.

[SvenW]

>> Jag har utrustat mig med bergkrokar rep och slagborrmaskin nu, hjälper inte det så får det bli semtex, för blinka skall det. 

Rätt attityd
Om inget annat går så går det alltid med emacs!
http://xkcd.com/378/

[lillahuset]

Rätt attityd! "Eighteen Megs And Constantly Swapping" hette det ju förr. Men jag råkar gilla Emacs.

[mri]

lillahuset: Två orsaker att jag portade till cube. 1) Den SDIO/FatFs kod jag hittade på nätet fungerade inte 100%. Jag chansade på att cube skulle ha en bättre implementation eftersom FatFs finns färdigt med i cube paketet. 2) Standard Peripheral Library är numera "Not recommended for new designs". Eftersom mitt projekt ännu inte är färdigt ville jag inte sitta med ett bibliotek som redan nu är på utgående.

SeniorLemuren: Ja, tyvärr verkar cube endast ha färdiga projektfiler för betal-kompilator-miljöer. Dock innehåller dessa projektfiler ingen magi, de drar ju bara med de källkodsfiler som behövs för att kompilera exempelprojekten.

Att lära sig en ny prosessor är mycket krävande, och STM32 ARM Cortex-M är definitivt inget undantag. Har man begränsad fritid, som de flesta, får man ta sig en funderare var man skall investera den tid man har. Om du faktiskt vill lära dig, go for it! Finns många här som kan svara på frågor.

"Skall gå igenom den första länkens pdf. Den behandlar samma kort och µC (STM32F100) som jag har. De andra 2 handlar om STM32F4xx. Vad skiljer sig åt när det gäller programmering av resp. µC?"

Exakt samma princip för båda att programmera. STM32F4xx är kraftfullare; högre klockfrekvens, häftigare periferiblock, etc.

Angående Cube (eller HAL) bör man ha klart för sig vad det är. Cube är ST-micros SW paket för att de skall kunna skapa och underhålla demo applikationer för sina processorer. Samtidigt är paketet användbart för slutanvändaren. MEN, det är inte alltid optimalt för slutandvändare. I vissa fall kunde de gjort koden mer flexibel. Demo applikationer är ofta ganska simpla, riktiga applikationer blir gärna mer komplicerade var man skulle haft nytta av en mer anpassningsbar HAL. Jämfört med Standard Peripheral Library är Cube högre abstraktionsnivå.

[snigelen]

Nu har jag inte direkt kollat på Cube/HAL, men någon som gjort det tyckte det var jämförbart med Atmels ASF. Inte långt från katastrof om den jämförelsen är rimlig. (Men rätta mig gärna om det är fel, från ST har jag bara använt Standard Peripheral Library, vilket jag tycker är vettigt, och jag vet egentligen inget om Cube).

[lillahuset]

När jag började med STM32F1xx frågade jag en tysk som hade utvecklat en kommersiell J1939 CAN stack vi använde hur mycket av STs bibliotek han tyckte man skulle använda. Svaret blev: Inget!
Själv använder jag det mest för initiering och försöker att skriva egen kod för det som snurrar när allt är initierat.

På sätt och vis känns det skönt att SPL är på väg ut. Men Cube är jag lite tveksam till.

[snigelen]

Nej jag tycker väl inte SPL är jättebra, men rätt OK. Det är ganska komplex hårdvara men ändå inte så svårt att gå på djupet och skriva egna rutiner. Men naturligtvis är det en fördel att använda något som redan är väl testat av många användare, och därmed har relativt få buggar.

Sen finns det naturligtvis poänger med att lägga sig på en högre abstaktionsnivå, särskilt om man skriver relativt stora program. Men så fort det är något som inte fungerar så måste man ändå gå in och se vad det är dom gör och för att förstå det måste man ofta gå ner på lägsta nivån i alla fall (läsa datablad och titta på bitar i diverse register och så).

Så jag tycker att SPL ändå ligger på lagom hög nivå, inte så mycket att lära sig för att kunna använda det och om man behöver gå ner på en lägre nivå så är källkoden till SPL ganska lättläst och ligger ganska nära grunderna. Lägger man en ännu högre abstaktionsnivå så blir det mer jobb att lära sig hur man använder den men dessutom svårare att se vad som verkligen händer när något inte fungerar (gäller i alla fall kluddet ASF från Atmel). Så man måste ändå lära sig vad som händer på djupet, men det blir svårare att se det.

[lillahuset]

Har någon mer än jag noterat att ST glatt ändrar APIt i SPL? Små ändringar men det ställer ändå till det.

Edit: Jo jag har också sett betydligt sämre.

[SeniorLemuren]

Nästa steg i STM-träsket. Jag har kopplat upp mitt kort och det blinkar med sitt originalprogram. Jag kör Win XP Jag har följt From Zero To Blinky slaviskt.. Jag kommer till sista formen, nedan och trycker å OK så hänger sig skiten och stänger ned programmet efter ca 2 minuter. Ing felmeddelanden, ingen info. Som vanligt alltså, den värsta skiten jag sett på länge. Detta blir nog rekord i tid för att få igång en rutin.

ST-LINK DEBUG PROBE SETTINGS.jpg

[mri]

Atmels ASF vet jag inget om, men att använda ordet katastrof om Cube skulle jag inte göra. Cube/HAL är annorluna jämfört med SPL. SPL speglar ganska exakt hårdvaran som ligger under. Dvs. man måste känna hårdvaran och veta vad man måste göra för att få snurr på den. Cube/HAL API't är byggd mera för typiska saker man vill använda hårdvaran till. Förenklat kan man väl säga att SPL är skrivet av hårdvaruutvekclare, och Cube/HAL är skrivet av mjukvaru applikationsutvecklare.

Ett enkelt exempel: I Cube kan man direkt när man väljer att en GPIO pinne skall vara input också ange om den skall trigga ett interrupt (stigande, fallande eller båda flankerna). HAL kommer då själv att konfigurera EXTI när man anropar HAL_GPIO_Init(). Och man behöver endast ange interrpt prioritet samt aktivera det i NVIC.
I SPL måste man själv separat konfigurera EXTI, eftersom EXTI är ett separat block från GPIO.

I professionella sammanhang hittar man säkert olika argument varför man helt skall undvika SPL eller varför det är en bra ide att använda SPL.

SeniorLemuren: Det är alltså STM32VL-Discovery med STM32F100 processor, dvs ARM Cortex-M3 du har. Själv har jag ett STM32F4-Discovery samt ett STM32F0-Discovery hemma. Jag skall ta en titt på den där tutorialn.