Bra tutorials för STM32

[ankan]

Har tänkte börja programmera STM32 och till att börja med STM32F3 i Coocox.

Skulle vilja ha lite tips på bra tutorials så man kommer igång.

Har lyckats få en diod att blinka men vill komma vidare med att använda timers, interupt, uart mm.

[mri]

Inget svar på din fråga, men när du lärt dig grunderna och tröttnat på coocox, ta en titt på Em::blocks.

[ankan]

Coocox blev jag tipsad av en kille på jobbet men det är inget jag är låst till.
På jobbet har vi tidigare kört Raisonance men gått över till Keil så jag har tillgång till dem båda.

Men vid första anblicken så tyckte jag att Coocox bjöd på många färdiga drivrutiner förutom komponent-bibliotek. Men något annat verktyg kanske är bättre?

Oavsett verktyg så behöver jag någon bra tutorial så jag kan komma igång.

Em::blocks har jag inte hört talas om. Vad är fördelarna?

[lizerdboy]

Jag håller med mri, undvik java monstret
Em::blocks är riktigt bra, jag rekomenderar att använda den ist för coocox
själv använder jag crossworks, dock så kostar det.

börja med boken Discovering the STM32 Microcontroller
www.google.se/url?..&url=http%3A%2F%2Fwww.cs.indiana.edu%2F~geobrown%2Fbook.pdf..

fråga här på EF om du stöter på något som inte går i hopp.

[ankan]

Gillar inte heller java baserade program men den här gången märkte jag inte det.

Vad ogillar ni med coocox och vad gör de andra programmen bättre?

Har som sagt keil på jobbet annars som borde vara rätt bra.

Ska kolla den där boken om det kan vara något. Tack för tipset.

[mri]

Jag tycker man gjort ett taskigt jobb med att försöka gömma en massa funktionalitet i eclipse... för att göra IDEn enklare. Den extremt långa kontextmenyn som ännu är kvar skvallrar om att de inte riktigt vet vad de sysslat med...

Sen alla färdiga drivrutiner som ger intrycket av att det bara är kryss-i-ruta för att dra med massor av tevlig funktionalitet.... När det i verkligheten ofta inte är kompatibelt med den processor man valt... koden är föråldrad och inte mera fungerar, osv. Men visst, man får massor av ideer och kod att titta på.

I Em::blocks finns hela original IDEn kvar (code::blocks) med massor av funktionalitet. I övrigt får man inte så myckt hjälp kodmässigt, förutom standard periferibiblioyeken. Som helhet är em::blocks mycket mer polerar och färdigt än coocox, även om det ännu pågår aktiv utvecling och förbättringar av em::blocks.

[Krille Krokodil]

Är där så mycket nytta med att förenkla IDE när det rör sig om en så komplex plattform
där projekten oftast kommer att ha en större storlek?

Visserligen är mina tänder hälften så höga nu av allt tandagnissel med att ställa in Eclipse, men
när man väl har fått rätt på det så går kodknackandet väldigt mycket smidigare än med enklare
IDE.

[ankan]

Har ett kort med STM32F103RB där det finns en USB-kontakt kopplat till USB-pinnarna på processorn.

Har sökt och sökt exempelkod på att få igång USBn som en virtuell COM-port utan framgång. Tycker det borde finnas något färdig bibliotek som skulle göra saken relativt enkel.

[mri]

Osäker på om orden "USB" och "enkel" överhuvudtaget är kompatibla...

[lillahuset]

På ytan är de kompatibla.

Själv använder jag CoIDE men är inte helt imponerad. Det bygger trots allt på Eclipse. Ett mycket passande namn. En kund insisterade på Atollic True Studio. Också Eclipse, bara mycket dyrare. Möjligen bättre men det fattade jag aldrig.

Klandra inte CoIDE för kass källkod till STM32, det är ST som står för den. Kass, ja! Informativ, ja.

När jag får tid över ska jag flytta till emacs och gdb. Jag använder ju redan emacs till all editering och CoIDE/STM32 använder gdb.

Jag vet inte om http://fun-tech.se/stm32/about/index.php kan vara till någon nytta men det är en pekare iallafall.

/GGG

[ankan]

Jag har börjat gå över till Keil då ST har ett smidigt verktyg som genererar grundkoden för STM32 processorerna med projektfil för Keil mm.

Programmet heter STM32CubeMX http://www.st.com/stm32cubevilket jag rekommenderar. Än så länge verkar det fulla stödet bara finnas för F4, med det verkar som de har planerar att lägga in stöd för samtliga vilket skulle göra startup processen bra mycket smidigare. Bara att klicka i vilka funktioner man vill ha och vips så har man grundkoden färdig och man kan koncentrera sig på det man egentligen vill åstadkomma.

[lillahuset]

Är säkert bra på något sätt men...

Med tanke på hur tillgänglig kod från ST ser ut så känns det som att tjata sig till problem.
Just initieringskoden är bland det viktigaste, förstår man den inte kan man felsöka tills fan löser av en.
Initieringskoden tenderar att vara snarlik från projekt till projekt. Fatta! Fatta! Fatta!

/GGG

[ankan]

Det är klart koden är snarlik men efter att ha satt upp tex en virtuell com-port via usb så tycker iallafall jag att det är väldigt skönt få en del serverat. Att sätt upp in och utgångar är en barnlek i jämförelse om man ska skriva allt grunden själv.

Visste inte att STs kod var så himla hemsk. Vad är det som gör deras egen kod så dålig?

Det jag saknar är guidelines för hur man ska sätta upp koden på ett vettigt sätt för att kunna återanvända den på ett effektivt sätt i framtiden.

Om jag bara behöver skriva grunden en gång och kan återanvända den på ett effektivt sätt är jag nöjd.
Måste för övrigt redan finnas andra redan har gjort det så man inte behöver göra så mycket för att få gång det man vill använda på processorn.

[lillahuset]

Mitt möjligen något orättvisa omdöme om STs kod bygger på egna erfarenheter, mest för några år sedan eftersom jag som sagt försöker undvika den numera.

Jag tror att en anledning till att den är/var som den är/var var ett försök att få den att se så lika ut som möjligt för alla processorfamiljerna vilket iofs är en trevlig tanke. Resultatet blev mycke kod och lite verkstad.
Ibland kan man spåra en ambitiös tanke som leder till komplicerad kod som utmynnar i en #define för att fixa till det hela.
Exempelkod går emellanåt inte ens att kompilera. Och när man har fixat till den fungerar den ändå inte.
I ett projekt tänkte vi använda delar av källkoden till ett av STs programmeringsverktyg vi hade tillgång till. Efter att ha studerat soppan insåg vi att det var både enklare och bättre att skriva det vi behövde från grunden.
Flera gånger har vi fått ändra i vår egen kod när vi har bytt till nyare versioner av biblioteken.

Idag undviker vi STs kod. Vi tittar på den som ett komplement till hårdvarudokumentationen. Ibland är vi lata och låter den ingå i projekten. Någon gång har det straffat sig.

Slutligen ska man vara ärlig och konstatera att ST framhåller att deras bibliotek endast är "guidance", vägledning alltså.

[ankan]

Jag kan hålla med om att det är mycket #defines i deras kod vilket gör den rörigare och kodmässigt större men resultatet blir inte större iallafall.

Men jag känner att utan deras bibliotek skulle det ta bra mycket mera tid att åstadkomma något vettigt.

Tycker det är tillräckligt med jobb att få igång funktionerna med deras bibliotek. Utan biblioteken hade jobbet blivit ännu större även om man såklart få djupare kunskap om processorn.

Jag föredrar att producera framför att ullabella programmera sånt som redan finns färdigt.

Om ni inte använder deras bibliotek gissar jag att byte av processor för samma projekt är bra mycket bökigare eller hur har ni löst det?