Varför 8 bit?

[TomasL]

OT, Får man nu inte längre se på datablad via Elfa ?
Jag får " Unauthorized. You are not authorized to enter this page. Click here to be redirected to startpage. "
när jag trycker på "datablad" på Elfa-sidan som länken går till.


>PIC32 28-pin DIL på elfa:
>https://www.elfa.se/elfa3~se_sv/elfa/in ... &toc=20970

Nått tillfälligt fel, gissar jag.

[psynoise]

Förorden till boken The Definitive Guide to the ARM Cortex-M0 av Joseph Yio innehåller några intressanta kommentarer

• Since 2004, the microcontroller market has made some dramatic changes. Previously, the
  microcontrollers on the market were mostly 8-bit and 16-bit types, and 32-bit microcontroller
  applications were limited to high-end products, mainly because of the cost. Although most of
  the 8-bit and 16-bit microcontrollers could be programmed in C, trying to squeeze all the
  required functionalities into a small microcontroller was becoming more and more difficult.
  You might spend one day writing a program in C, and then find that you needed to spend
  another two days rewriting part of the program in assembly because the processing speed of the
  microcontroller was too slow for all the required processing tasks.
  
  Even if you are developing simple applications and do not require high processing power in
  the microcontrollers, occasionally you might need to switch to a different microcontroller
  architecture because of project requirements, and this can take a tremendous effort. Not only
  will you need to spend the money to buy new tools, but it can take weeks to learn to use the
  tools and months to become familiar with a new architecture.
  

[blueint]

You might spend one day writing a program in C, and then find that you needed to spend
another two days rewriting part of the program in assembly because the processing speed of the microcontroller was too slow for all the required processing tasks.

Inte helt okänt

Sen får man inte glömma de extra dagarna för att minska kodstorleken

[AndLi]

Efter 15 år som embedded utvecklare har jag ALDRIG skrivit om ett C program till ASM, en gång har jag dock plockat bort en ASM interruptrutin eftersom det inte fanns något behov att ha den i ASM längre...

Och då lever jag i en volymproduktions värld där det ska vara den billigaste µC hela tiden, skumt

[Swech]

Har inte heller behövt byta processor på grund av för klen prestanda hastighetsmässigt
Däremot kan Flashen ha tagit slut

En annan interessant aspekt är om man kollar på de frågor folk har.
Gälller det ASM är det. "hur gör jag xxxx på processorn"
med C är det " hur fixar jag så att compilern inte sabbar xxxx eller optimerar bort..."

Så personligen räcker det att slåss med processorn... att ha ytterligare
verktyg som man måste slåss med är inte interessant
Swech

[Birger1234]

ARM i DIP till lågt pris skulle intressera mig.

Eller i SO28 vore fasligt trevligt! Nu fins de ju ARM i både dip och SO men de
är så slöa och saknar merparten av perferi krettsar som en standard STM32 har t.ex
och nej tänker tamefan inte berätta vilka tillverkarna är, det är krimminelt att sälja så här slöa 32 bitare!

[psynoise]

Vet inte om det tagits upp tidigare i tråden men något att beakta angående 32 bitars är också strömförbrukning och elektromagnetisk kompabilitet.

Använder man sig av en avbrott i sitt program med vila i mellan finns det fördelar. Då kan en snabbare 32-bitars processor utföra algoritmen vid avbrott snabbare än en 8-bitars för att sedan gå ner i vila. Eftersom minne och annat runt om även går ner i vila finns det mycket att vinna.

Har man istället en programslinga som snurrar runt hela tiden finns det också fördelar. Med en 32-bitars processor kan man använda sig av lägre klockfrekvens. Även om en 32-bitars processor har fler grindar än en 8-bitars kan detta vara fördelaktigt. Dock har Cortex-M0 endast 12 000 grundar och uppåt.

Då man kan använda sig av lägre klockfrekvens blir den kapacitivakopplingen mindre. Elektromagnetisk kompabilitet är viktigt i stora system och kraven på kommersiella produkter är hårda.

[sodjan]

Det beror ju lite på vad "programslingan" gör. Om det till största delen
är logiska operationer (lite "PLC-light") så har ord-längden kanske mindre
intresse, det är viktigare hur effektiva bit-operationer (test/set/clear)
arkitekturen har. Är det därimot beräkningar med t.ex 32-bitars precison
så är det ju en helt annan femma...

Jag tror även att många 8-bitare är mer robusta mot miljön de sitter i
genom t.ex grövre/större processgeometrier. Jag tänker typ miljön kring
de där knapparna som sitter vid övergångställen och liknande.

Som jag sa tidigare. Frågan som den ställdes från början går inte att svara
på och den är mer eller mindre ointressant om man inte har ett faktiskt "fall"
att rellatera den till. Det finns inget generellt rätt svar.

[vespaman]

Något som ingen har tagit upp (tror jag?) som en fördel för 32-bitarna är att man kan använda GNU:s toolchain, och man slipper alla knäppa IDE:er, och kan välja ett för hela kommande livet (nåja!). Dessutom slipper man windows om man vill i utvecklingsmaskinen.

Dock, det vore inte en snygg lösning att hysta in en omap i en liten konstruktion för att blinka en led och liknande, så i väldigt enkla konstruktioner kan 8-bitars fortfarande vara ett bra val.

Sista 8-bitaren jag designade in var för 4 år sedan, jag misstänker att det blir den sista för min del (professionellt), Cortex M0 gissar jag blir ersättare i min värld framöver.


Ni som fortfarande kör DIL har ju ett problem förstås. Tänker på 68000 - kommer ni ihåg den 68 pinnars DIL:en? (visst var den 68 pin?). Stooor.


Edit: Visste inte att jag var medlem här, så trots några år på nacken som medlem så blidde detta min första post..

[SvenW]

och man slipper alla knäppa IDE:er,

Ja, det var det bästa som sags på länge i detta forum.
Och det är inget skämt från min sida!!!

[sodjan]

Man kan ju inte *enbart* utgå från en så teknik-nörd orienterat perspektiv
som att det *måste* vara GNU-toolchain eller liknande. Det kanske kan vara
en parameter ifall man redan är "inkörd" på just det, men annars är det bra
en parameter som vilken som helst annars.

De flesta vill sannolikt ha något som "gets the job done" så att säga.
Och gärna ha en single-point-of-support när det strular.

> som en fördel för 32-bitarna är att man kan använda GNU:s toolchain,

Vilka "32-bitare" ?

> och man slipper alla knäppa IDE:er...

Självklart. Märkligt argument. Vem vill använda något "knäppt" ?

[grapetonix]

Det handlar bara om att använda den arkitektur som passar tillämpningen bäst.
Fungerar tillämpningen lika bra med en 8-bitars som 32-bitarsarkitektur och båda kostar lika mycket att implementera... hugget som stucket.

Dock brukar jag alltid rekommendera nybörjare att börja lära sig på en mikrokontroller som har så lite nooks and crannies som möjligt för att inte bli förvirrad.
Ett exempel är att välutrustade mikrokontrollers ofta har hårdvara som måste stängas av för att få I/O funktionaliteten att flyta.

Och så tycker jag att det är synd att gå på C direkt för att strunta i Assembler. Själv insåg jag mening och innebörd i C's uppbyggnad först efter att ha hamrat lite assembler för 16F84A.

[vespaman]

Man kan ju inte *enbart* utgå från en så teknik-nörd orienterat perspektiv
som att det *måste* vara GNU-toolchain eller liknande. Det kanske kan vara
en parameter ifall man redan är "inkörd" på just det, men annars är det bra
en parameter som vilken som helst annars.

De flesta vill sannolikt ha något som "gets the job done" så att säga.
Och gärna ha en single-point-of-support när det strular.

Nja, fast jag skriver ju inte att det måste vara det. Jag skriver att det är en fördel, eller hur?

Tycker faktiskt inte att man måste vara inkörd på det, i dagsläget finns många bundlade halvkomersiella förpackningar med debugger BDM/JTAG som gör steget lika kort som något annat alternativ. Och single point supprt om man så vill.

*Är* man väl inkörd på detta så är livet som utvecklare genast enklare eftersom gcc håller hög klass, bra dokumentation. Och utan kostnad.

> som en fördel för 32-bitarna är att man kan använda GNU:s toolchain,

Vilka "32-bitare" ?

Tja, jag har i mina senaste projekt använt olika Coldfire V2, olika ARM (just nu en trevlig Cortex A8 från Ti). På köpet får man ju direktkompabilitet med x86/amd64.

> och man slipper alla knäppa IDE:er...

Självklart. Märkligt argument. Vem vill använda något "knäppt" ?

? Vad är det som är märkligt med argumentet ??

[sodjan]

> Tja, jag har i mina senaste projekt använt...

Det var retoriskt. Du verkar utgå från att alla 32-bits miljöer
med automatik alltid har GNU-miljöer för utvecklingen.

> ? Vad är det som är märkligt med argumentet ??

Att det saknar värde. Ingen vill ju använda något "knäppt".
Det gör det ju inte att argumentet är fel, så klart, bara utan värde.
Men du kanske räknar allt som inte är GNU som "knäppt".

[bearing]

Det måste ju finnas GNU-verktyg till flera sorter av 8-bit MCU, i alla fall Atmels. Och i princip alla GUI har ju kompilator/länkare som separata binärer för den som föredrar en egen utvecklingsmiljö.