Att gå från AVR till STM32F4 ARM

[MicaelKarlsson]

Har lite funderingar på att testa STM32F4 ARM men är lite osäker på vad som är de största skillnaderna, då tänker jag inte på prestandaskillnaderna som står listade i de olika kretsarnas datablad. Det jag helst vill ha svar på är hur du som testat dels 8-bitars AVR/PIC/annan 8-bitars upplevt steget över till STM32F4 ARM (eller liknande 32-bitars ARM).
Har ni råd om utvecklingsmiljö och liknande för Ubuntu 12.10 64-bitars

Datablad till STM32F4 Discovery

[Klas-Kenny]

Jag har gått från 8-bitars PIC till STM32F3 litegranna och det har varit lite blandade känslor. Det är mer som behöver göras för att få ingång saker och ting, som att starta alla klock-moduler och liknande.

Men det största problemet jag haft är att man inte kan finna all information i ett enda datablad som hos mindre processorer, utan det finns något litet datablad med de processorspecifika sakerna, sen är allt annat utspritt på olika generella dokument för många olika processorer.

Det är väl de grejerna jag tänkt mest på, annars har det gått helt Ok så långt.

Utvecklingsmiljö kör jag CooCox under Windows, tror att det ska finnas till Linux också, rätt smidigt att få allt man behöver i ett enda paket.

Edit: Hoppsan, inte F3 utan F1, blandade ihop det med M3.

[Micke_s]

Har också gått från 8-bit till 32-bit. Mer att lära sig, men värt det i slutändan. 8-bit med mer flash är ju lika dyra som 32-bitars nuförtiden

[Icecap]

Jag har just tagit steget från Fujitsus FFMC-16LX (16 bit, 16MHz) till Renesas RX-serie (32 bit, 50MHz för RX210) och skillnaden är i grunden inte stor.
För en del år sedan tog jag steget från I80C320 (8 bit, 8MHz) till FFMC-16LX och precis som nu var skillnaden i programvaran minimal - men att hitta alla viktiga bitar i databladet var en bitch.

Numera är Fujitsun död (efter skalvet i Japan) och jag håller på att uppgradera ett par projekt till Renesas RX210. detta medför att jag testar lite grejer och - precis som vanligt - är det ett letande i datablad så man blir galen.

Men när det är avklarat är det inget skillnad - förutom att jag nu plötsligt har en krets som tuggar på i 50MHz (intern oscillator), har minne i överflöde och periferkretsar så man kan bli galen av att välja vilken man vill använda.

Sedan är Renesas kanske lite extrema: för att välja att använda en portpinne till UART-funktion måste man:
* Öppna ett säkerhetsregister.
* Slå på UART'en (strömmässigt).
* Stänga säkerhetsregistret.
* Öppna ett annat säkerhetsregister.
* Ställa in portpinnens funktion till UART tx/rx. Ett register per portpinne! Många tabeller blir det!
* Ställa in nästa portpinnes funktion till UART rx/tx.
* Stänga säkerhetsregistret igen.
* Ställa in portpinnernas in/ut-register rätt.
* Ställa UART'en rätt med funktion, baudrate osv.
* Byta över pinnarnas funktion till den alternativa funktionen.
Sedan kör det.

Omständigt - men man ska göra det första gången, sedan fungerar det ju.

Tar man PIC som exempel är det ju talrika exempel på fel som består av att folk inte har läst de gråa informationsrutor i databladet så något så enkelt som en PIC kan ställa till problem rimligt lätt. AVR kan inte vara helt lysande övertydlig i databladet heller, en googling på "bricked avr" ger 79.500 träffar och databladet är inte speciellt otydlig på det område.

[SvenW]

STM32F4 ARM är väl ungefär tre gånger så jobbig som AVR att läsa in och att sätta upp.
Men är man väl igång så är det tre gånger lättare att få saker gjorda.
Har man discoverykortet så behövs bara en usb-kabel förutom mjukvaran.
CooCox kanske fungerar, annars kan man hämta delarna var för sig:
Gnu toolchain GCC ARM Embedded 4.7 finns här:
https://launchpad.net/gcc-arm-embedded
sedan behövs t.ex. OpenOCD och en del annat, se t.ex.
http://jeremyherbert.net/get/stm32f4_getting_started
Ett gissel är att de som skriver hårdvarumanualen
och de som skriver peripheral_library tycks tala olika språk.
Väl igång tänk på tre saker:
Alla portar måste sättas upp.
Alla periferienheter måste initieras.
Klocksignaler till periferienheter måste distribueras.

[Korken]

Jag kör med Eclipse (samt täller in så man kan debugga via Eclipse) och GCC i Ubuntu.
GCC laddar jag från Linaro (https://launchpad.net/gcc-arm-embedded/ ... 2-q4-major) och det fungerar mycket bra!
Själva steget från AVR till ARM tyckte jag va stort och jobbigt. Inget va lika självklart tyckte jag, men efter ett par månader så kom jag in i tänket och då vart det lika enkelt tycker jag.

[MicaelKarlsson]

Tack skall ni ha för era tankar, låter intressant. Speciellt att använda eclipse som jag redan använder för AVR.

[LHelge]

Har också tagit steget från 16-bit PIC till STM32F3/4. det är en liten tröskel som man ska över, största problemet tycker jag är att hitta en trivsam utvecklingsmiljö. Jag fastnade tillslut för Coocox efter att ha prövat ett par Eclipse/gcc/OpenOCD varianter i både Windows och Linux (Virtualbox) samt Keil och Atollic. (Ja, jag vet att Coocox också är Eclipse/gcc/OpenOCD, men det är snyggt förpackat).

Nackdelen med Coocox är att de inte har stöd för STM32F3xx än, men det går att lura den att det är en STM32F4 och stödet för F3 dyker nog upp när som helst.

Bästa tipsen jag kan ge dig:
* Skit i allt vad register heter, låt Standard Peripherals Library göra jobbet
* Njut av flyttalsprocessorn och aldrig mer behöva bry dig om fixed point aritmetik.

[MicaelKarlsson]

Tack LHelge!

Låter bra, speciellt flyttalsprocessorn.

[SvenW]

För att använda flyttalsprocessorn måste man använda rätt flaggor vis kompilering:

CFLAGS+= -mfloat-abi=hard -mfpu=fpv4-sp-d16

och så måste man starta den med följande kod:

Kod: Markera allt

// Att använda fpu c-code  ref: http://www.triplespark.net/elec/pdev/arm/stm32.html
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */

Sedan finns en del kod i CMSIS dsp som kan vara bra att testa.

[Korken]

Har också tagit steget från 16-bit PIC till STM32F3/4. det är en liten tröskel som man ska över, största problemet tycker jag är att hitta en trivsam utvecklingsmiljö. Jag fastnade tillslut för Coocox efter att ha prövat ett par Eclipse/gcc/OpenOCD varianter i både Windows och Linux (Virtualbox) samt Keil och Atollic. (Ja, jag vet att Coocox också är Eclipse/gcc/OpenOCD, men det är snyggt förpackat).

Nackdelen med Coocox är att de inte har stöd för STM32F3xx än, men det går att lura den att det är en STM32F4 och stödet för F3 dyker nog upp när som helst.

Bästa tipsen jag kan ge dig:
* Skit i allt vad register heter, låt Standard Peripherals Library göra jobbet
* Njut av flyttalsprocessorn och aldrig mer behöva bry dig om fixed point aritmetik.

Det som jag tycker är synd när man använder färdigförpackade IDEer är att man förlorar insynen i allt som händer i bakgrunden.
Jag lärde mig mest av att sitta och kriga lite med Makefiles, startup koder, interruptvektorer, få debugg att fungera osv - sådant som man missar i tex CooCox.
Men jag håller med om att det är en skön IDE, jag skulle byta till den om jag inte ville ha koll på allt själv i mina projekt.
Det kan vara en sak som är värd att ha i åtanke iaf.

[Micke_s]

Korken: Inte alltid intressant heller.

Du kan köra makefiler i coocox också. Coocox är enligt mig det bästa kostandfria alternativet för cortex-m*

Har mest negativa erfarenheter att sätta ihop IDE+kompilator+debug.
Versioner som är inkompatibla med varandra.


Edit: Linkerscript får man slåss med nästan oavsett IDE när man gör lite mer advancerade saker.

[Krille Krokodil]

Det som jag tycker är synd när man använder färdigförpackade IDEer är att man förlorar insynen i allt som händer i bakgrunden.
Jag lärde mig mest av att sitta och kriga lite med Makefiles, startup koder, interruptvektorer, få debugg att fungera osv - sådant som man missar i tex CooCox.
Men jag håller med om att det är en skön IDE, jag skulle byta till den om jag inte ville ha koll på allt själv i mina projekt.
Det kan vara en sak som är värd att ha i åtanke iaf.

Visst, egen problemlösning är oftast den bästa läromästaren, men jag tycker det är rätt tråkigt när man är grön, tuggar datablad och gör massa enkla misstag att ovanpå detta ha en krånglande utvecklingsmiljö att tampas med.

[LHelge]

Det som jag tycker är synd när man använder färdigförpackade IDEer är att man förlorar insynen i allt som händer i bakgrunden.
Jag lärde mig mest av att sitta och kriga lite med Makefiles, startup koder, interruptvektorer, få debugg att fungera osv - sådant som man missar i tex CooCox.
Men jag håller med om att det är en skön IDE, jag skulle byta till den om jag inte ville ha koll på allt själv i mina projekt.
Det kan vara en sak som är värd att ha i åtanke iaf.

Jag håller egentligen med men som nybliven småbarnsförälder finns inte riktigt tiden. Nu vill jag bara att det ska funka så jag kan brottas med att lära sig arkitekturen med den lilla hobbytid jag har.

[Korken]

Jo, det är den enkla och snabba vägen.
När jag lärde mig så hade jag en som hjälpte mig så jag visste att kod fungerade och kunde fråga när verktygen krånglade.
Så har man tiden och lusten så rekommenderar jag min väg, annars kör mer integrerade IDEer som tex CooCox.