Svenska ElektronikForumet

Såklart ska man se till att jobbet blir gjort. Är det ett projekt som är "det enda" är det knappast lönt att uppgradera µC (och därmed utvecklingsmiljö) men är det en rad projekt inom överkomlig tid ska man definitivt ta steget att faktisk använda något modernt.

En sak en del glömmer är att det kan ha ett stort värde att det finns flera olika tillverkare och leverantörer av komponenten. Det hjälper inte att ha en skitbillig och ytterst välfungerande µC om man inte kan få leverans av den.

Förvisso är det så, men hur många helt kompatibla ARM processorer finns det från olika
tillverkare, d.v.s. bara att byta rakt av utan något som helst speciellt mellan dem?

Sedan skall TS göra 100 kort om året... har svårt att tro att oavsett processor så blir det omöjligt att få tag på tillräckligt
många för att rädda situationen om en omkonstruktion skulle behövas.

Swech

funderar på om jag ska använda denna STM32:

STM32F030RCT6TR
https://www.digikey.com/product-detail/ ... ND/6833533

Vilken IDE borde man i så fall använda?
Är det system workbench på openstm32.org som gäller eller är nån annan bättre?
http://openstm32.org/HomePage

vad ska man ha för programmerare?

Förvisso är det så, men hur många helt kompatibla ARM processorer finns det från olika tillverkare, d.v.s. bara att byta rakt av utan något som helst speciellt mellan dem?

Med till visshet gränsande sannolikhet inga.

Här finns en del intressant om utveckling med STM32F4xx:
https://istarc.wordpress.com/category/e ... s/stm32f4/

Troligen är Atollic ett bättre val.

Som programmerare och debuginterface kommer du långt med ST-Link. Köp ett Discovery- eller Nucleo-kort med processorn du vill använda så har du en ST-Link och en processor att utvärdera.

Edit:
http://www.st.com/content/st_com/en/pro ... 030r8.html

Icecap skrev:Jag har kört 8-bit i MÅNGA år - och övergången har varit enkel.
Jag hade en källkod där jag isolerade hårdvara-delen som var en I80C320, sedan skrev jag ny hårdvara-del till en Fujitsu 16-bittare och kompilerade det hela - och det fungerade i första försöket.

Visst, hårdvara-delen hade en del trial-and-error men resten fungerade utan anmärkning.

Så att migrera till mer än 8 bit är mest en fråga om att dels finns et mer hårdvara att leka med och dels går mycket snabbare.
Ja, det blir mer nötande av datablad för att det är ny hårdvara - men allvarligt: kan man starta en UART i en ATmega kan man det i många andre versioner µC också.

Det som kanske kan skrämma är interrupt-prioriteter, mängder av hårdvara och kommer man från PIC16/18 är det oftast en shitload interruptvektorer att ta hand om - men när man har tagit en sak i sände blir det enkelheten själv.

Om man t.ex. som jag ofta använder en UART till att kommunikera med och då har interruptstyrd sändning och mottagning är det lite extra arbete första gången. Sedan har JAG kopierat filen och ändrat registernas namn till att motsvara nästa UART och sparat i en egen fil så nu har jag en fil för UART RS232-1 och UART RS232-2 samt RS485.

Behöver jag endera i ett projekt är det bara att lägga filen för enheten till projektet och allt är klart.

Igen är det totalt likgiltigt om det är en 8-bitars eller annat, det viktiga är att det passar till hårdvaran man använder.

Migrera program från X bit till Y bit = se till att samma funktioner finns till den nya hårdvara och saken är biff.

MEN en brasklapp: LÅT BLI att använda variablerna int & unsigned int.
Menar man int som i 16-bitars variabel är det short som gäller!

Har du lust att dela med dig av nåt faktiskt exempel på hur du delat upp din kod och hårdvaruimplementationen?
Jag är van C#-utvecklare men känner att jag har en del att lära när det kommer till C. (Även om det var det första språk jag kom i kontakt med när jag började gymnasiet.)

papabear: Det är ju tämligen enkelt.
Skriv egna funktioner för allt hårdvarurelaterat. Typ "init_uart()", sen "getc()" och "putc()" för läsning och skrivning. Sen är dessa bara till att använda rakt upp och ner i programmet.

Byter man sen processor är det enbart dessa tre funktioner som behöver skrivas om för att få igång uart'en igen.
Motsvarande gäller ju då i princip alla periferienheter...

Ok, då är jag med. Är ju egentligen samma jag gjort med mitt nuvarande projekt, men då med syftet att strukturera lite.
Men rent konkret då, säg att man skapar en foo.h med div funktioner, och sen switchar man bara foo.c-filen beroende på µC?

Det är väl just där som preprocessormakron har en funktion, även om jag personligen hatar dem.

Å andra sidan kör man MPLABX med Harmony, så vill jag minnas att exakt samma funktion används oavsett processor, må det vara en PIC16/PIC18/PIC24/PIC32.
Då slipper man dessa problem, dock storlekarna på de olika typerna varierar har jag för mig, så där kan det vara farligt att använda standard, dvs int, short etc.

Hur mycket flashminne borde räcka för en enklare meny på den grafiska skärmen som jag tänkte använda?
(vet att det inte går att svara på exakt men en grov uppskattning från någon som gjort något liknande.
Har ingen aning själv..)

https://www.digikey.se/product-detail/e ... gJhj_D_BwE

För en enkel meny går det inte så himla mycket flash-minne. Med 234 byte får man plats med hela alfabetet och 0-9 om tecknen är 6x8 pixlar. Sen med lite symboler och liknande så kan man väl säga att typ 1k flash är tillräckligt för en enkel meny.

Edit: Räknade fel

Faktiskt fullständigt omöjligt att säga, det beror ju bland annat på hur du skriver ditt menysystem.
Din fråga är ungefär som "hur långt är ett snöre"
Du behöver ju ingen processor för att skriva koden, och IDEet talar ju om hur mycket flash och ram du gör åt.

Dock, vad du måste tänka på är att eftersom du skall använda en grafisk dispaly, så har du inget fontstöd i displayen, utan du måste generera en bitmapfont i flash, och beroende på storlek så tar fontfilen säg 5-10 kB.
EN normal 8x16 font tar väl runt 15kB.
En fontfil kan se ut så här:

Kod: Markera allt

const unsigned char font_8_16_uc[] = {
         0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 
         0,0,0,0,0,0,252,25,252,25,0,0,0,0,0,0, 
         0,0,14,0,14,0,0,0,0,0,14,0,14,0,0,0, 
         96,6,252,31,252,31,96,6,252,31,252,31,96,6,0,0, 
         56,0,124,12,204,12,254,31,140,13,140,15,0,7,0,0, 
         56,12,68,6,68,3,248,7,240,8,152,8,12,7,0,0, 
         128,15,248,25,252,24,204,25,108,31,56,30,128,11,0,0, 
         0,0,0,0,0,0,30,0,30,0,0,0,0,0,0,0, 
         0,0,224,3,240,7,24,12,12,24,6,48,2,32,0,0, 
         0,0,2,32,6,48,12,24,24,12,240,7,224,3,0,0, 
         0,0,16,0,240,0,60,0,240,0,16,0,0,0,0,0, 
         0,0,128,1,128,1,224,7,224,7,128,1,128,1,0,0, 
         0,0,0,0,0,44,0,28,0,0,0,0,0,0,0,0, 
         0,0,128,1,128,1,128,1,128,1,128,1,0,0,0,0, 
         0,0,0,0,0,12,0,12,0,0,0,0,0,0,0,0, 
         0,48,0,28,0,7,192,1,112,0,28,0,6,0,0,0, 
         0,0,240,7,248,15,12,24,12,24,248,15,240,7,0,0, 
         0,0,8,24,12,24,252,31,252,31,0,24,0,0,0,0, 
         0,0,12,28,12,31,204,27,252,24,120,24,0,0,0,0, 
         0,0,12,24,140,25,204,25,108,31,60,15,28,6,0,0, 
         0,0,128,1,224,1,48,1,248,31,252,31,0,3,0,0, 
         0,0,124,24,252,24,196,25,132,31,4,15,0,6,0,0, 
         0,0,240,15,248,31,156,25,140,25,140,31,140,15,0,0, 
         0,0,12,24,12,30,140,7,236,1,124,0,28,0,0,0, 
         0,0,56,15,252,31,204,24,204,24,252,31,56,7,0,0, 
         0,0,120,24,252,24,204,24,204,28,248,15,240,3,0,0, 
         0,0,0,0,0,0,96,12,96,12,0,0,0,0,0,0, 
         0,0,0,0,96,44,96,28,0,0,0,0,0,0,0,0, 
………………………………………………
};

Nästan noll, beroende på hur många "bilder" du vill ha. En "bild" som täcker hela displayen tar max 8kbyte. I ett menysystem skriver du knappast om hela displayen för varje "bild".
Troligen har du en loop som raderar hela (eller en del av) displayen och så skriver du det du vill skriva.
Om du bara ska skriva text har du förmodligen en teckentabell med 8x8-tecken eller liknande. Då tar tabellen max 2kbyte och du behöver bara en byte per tecken i texten.

TomasL: Snöret är kort om man inte lullar iväg i onödan.

en byte per tecken

Öh, nej, för en grafisk display, så måste definiera varje pixel i fonten.

Dags för John Blund?
En byte per tecken pekar i teckentabellen där du har åtta byte per tecken. Jag gjorde en gång en lösning med proportionell font och då blev det lite mer stök men helt OK.

Svenska ElektronikForumet

vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?

Re: vilken mikrokontroller bör jag välja till mitt projekt?