Nybörjarfunderingar, bootloader, ICP och microcoden

[Maxx]

Hej, har några nybörjarfunderingar!

Har lite svårt att hitta svaren på detta... Det är lite blandning av frågor och påståenden. Rätt eller fel? Tacksam för svar! /M

För att ladda ett program seriellt (ICP), i en mcu (flash), krävs det att kretsen innehåller en sk bootloader!?

Isf finns detta program (bootloader) i kretsarna märkta ex (Pic) F. Eller har detta endast att göra med hur kretsarna raderas!?

Den sk "microcoden" är det den som exekverar asm-komandona, som överförts hexadecimalt!?

Isf, microcoden kan inte ändras och är specifik för varje processor. Ligger där den ligger från fabriken!?

Det går även att hårdbränna en krets, med en speciell brännare (dyrare). Isf parallellt över fler dataledningar! Det är så här man lägger in bootloadern, eller överför program utan bootloader!?

ICP innebär det att kretsen innehåller en bootloader? Isf har dessa några begränsningar jämfört med "hårdbränning"?

[sodjan]

> För att ladda ett program seriellt (ICP), i en mcu (flash), krävs det att kretsen innehåller en sk bootloader!?

Nej. Inte för att ladda via det inbyggda ICSP (In Curcuit Serial Programming) gränssnittet. Processorn
behöver inte innehålla någonting alls (och normalt är första operationen en "Erase All" i alla fall).

En bootloader används för att kunna uppdatera applikationen "under drift" så att säga. Det
kräver bl.a att den aktuella processorn stöder "Self Write", d.v.s att den kan skriva till sitt eget
programminne ("flash") från själva programkodem, vilket inte alla kan. Personligen anser jag att
bootloaders bara stöker till det för hemmapularen...

> Isf finns detta program (bootloader) i kretsarna märkta ex (Pic) F. Eller har detta endast att göra med hur kretsarna raderas!?

Nej och nej. "F" betyder bara att de har ett program minne som bygger på "Flash" teknik. D.v.s
att de är elektriskt raderbara och omprogrammerbara.

> Den sk "microcoden" är det den som exekverar asm-komandona, som överförts hexadecimalt!?

Oklart vad du menar med "microkoden". Och det finns inget som "exekverar" ASM-kommandona,
i alla fall ingen "microkod" eller något annat som skulle kunna tolkas som "kod". Allt är byggt
i hårdvara.

ASM filen (källkoden) körs genom MPASM/MPLINK (görs via MPLAB när man klickar "Build")
för att skapa en HEX fil med *maskinkoden* (plus lite mer t.ex CONFIG inställningarna).
Denna maskinkod körs sedan direkt av processorns hårdvara.

> Isf, microcoden kan inte ändras och är specifik för varje processor. Ligger där den ligger från fabriken!?

En PIC är inte microkodad, den har en hårdvara som är specifikt uppbyggd för att köra
de maskininstruktioner som är dokumenterade i databladet. Hela denna körning sker enbart
med "vanlig" sekvensiell logik precis som vilka andra digitala/logiska kretsar som helst (i princip).

[Maxx]

Tack Sodjan, blev lite klarare! /M

Följdfrågor:

Går det att överföra en bootloader till mcu-n genom ICSP?

I och med ICSP, är all hårdbränning onödig (behövs ej längre)!?

[Glenn]

om kretsen klarar ICSP så ersätter det helt det gamla sättet att flytta över kretsen till en programmerare och skriva den där (som ett EPROM typ)

[sodjan]

> Går det att överföra en bootloader till mcu-n genom ICSP?

Det är absolut inget speciellt med en bootloader.
En bootloader är utifrån processorn sett som vilket annat "program" som helst,
alltså överförs den till processorn precis som vilket annat program som helst...

> I och med ICSP, är all hårdbränning onödig (behövs ej längre)!?

Och vad 17 är "hårdbränning" ???

Det finns inget annat sätt att programmera en PIC (av "F-typ") en genom "Serial Programming".
Antingen gör man det "In Curcuit" (smidigast, rekomenderas) eller genom att flytta processorn
till en hållare på som sitter på själva programmeraren (avrådes, väldigt klumpig metod
om man inte ska flasha flera hundra kretsar direkt från rör t.ex.).

[Maxx]

Glenn, Sodjan! Tack för svar.

"Och vad 17 är "hårdbränning"

Ja säg det Lade till hård, men det heter väl bara bränning, trots att det ordet är synonymt även med dagens seriella programöverföring.

Jag menar den metod där koden överförs parallellt till kretsen. Mcu-n matas med en förhöjd spänning på något ben! Det är väl pga den högre spänningen det kallas bränning!

Vet inte det korrekta namnet, någon får gärna upplysa mig... /M

[vfr]

Koden överförs aldrig parallellt till PIC:ar. Även ISCP är seriell, som namnet antyder. Däremot används en "programmeringsspänning". På gamla "C"-varianter så hade den programmeringsspänningen betydelse för själva programmeringen då den användes för att ändra "läge" på bitarna som programmerades. På flashenheter ("F"-varianter) så är programmeringsspänningen bara en styrspänning som talar om att kretsen skall gå in i programmeringsläge. Namnet är nog bara generellt "programmering".

[Nerre]

Oklart vad du menar med "microkoden". Och det finns inget som "exekverar" ASM-kommandona,
i alla fall ingen "microkod" eller något annat som skulle kunna tolkas som "kod". Allt är byggt
i hårdvara.

Man kan ju se sekvensmaskinen som sköter detta som en slags mikrokod. Men mikrokodad CPU och RISC är i princip två olika sätt att konstruera CPU:er (finns andra sätt också).

En mikrokodad CPU kan normalt göra mer komplexa operationer med en enstaka instruktion. RISC kan normalt inte både läsa och skriva från minnet i en och samma operation eftersom det skulle kräva flera "steg" av operationen.

Z80 är ett exempel på en mikrokodad CPU (och i Mikrodatorns ABC så går de igenom hur mikrokoden fungerar). Även Intels och AMD processorer för PC är väl mikrokodade?

Men AVR och PIC är alltså RISC, och har ingen egentligen mikrokod.

[sodjan]

> Jag menar den metod där koden överförs parallellt till kretsen.

OK, det är alltså inte rellevant för PICs. Det finns ingen sådan programeringsmetod för PIC.

(AVR, däremot, har en sådan som man i vissa fall får ta till när man har ställt till
det för sig med "fuses", vilket då stället speciella krav på programmeraren...)

[Marta]

"RISC kan normalt inte både läsa och skriva från minnet i en och samma operation eftersom det skulle kräva flera "steg" av operationen."

Det finns inget hinder för en RISC att ha RWM-instruktioner eller en mera utbyggd hårdvara. PIC har det och varje maskincykel är 4 klockor. Det är även en harward-arkitektur så där är inga konflikter mellan data och programaccesser. Breda instruktionsord med operator/adress/data i ett stycke. Läs i databladet, där finns lite av hur instruktionerna exekveras.

Tror här är lite sammanblandningar på gång kanske. Interpreterande BASIC (som i BASIC-stamp) har en programkod som i sin tur exekverar användarprogrammet, men detta är inte microcode, men kan kanske uppfattas så av en nybörjare. Den termen används bara för sådan kod som direkt styr processorlogiken och låter den utföra dess instruktionsset.

När BASIC-programmet överförs så är detta i princip en bootloader, eftersom det inte är en grundfunktion i processorn. BASIC-tolken hanterar laddningen av användarprogrammet och att skriva detta till det FLASH-minne som är avsett för detta ändamål.

Kan även vara sammanblandning med AVR, de går att flasha med parallellt gränssnitt för att snabba upp vid massproduktion. Genom oaktsamhet kan de även ställas i ett läge där denna metod är den enda möjliga för att flasha om kretsen.

[Nerre]

Det finns inget hinder för en RISC att ha RWM-instruktioner eller en mera utbyggd hårdvara. PIC har det och varje maskincykel är 4 klockor.

Men grejen är ju att om varje instruktionscykel är 4 klockpulser så måste det finnas något som bestämmer vad som skall göras under dessa fyra klockpulser. Och det kan ju ses som en slags "mikrokod".

Äkta mikrokod är ju i princip långa "ord" med en bit per latch i processorn, så genom att stega igenom "orden" som hör till aktuell opkod så öppnas latcharna i rätt ordning.

En processor med mikrokod kan addera två minnesadresser och lagra resultatet i en tredje, på en instruktion. En processor utan mikrokod måste ladda de två minnesadressernna till varsit register och sen kopiera resultatet från ett register till minnet.


Men som sagt var, AVR och PIC är RISC-baserade och har ingen egentlig mikrokod.

(Värt att notera, med tanke på en annan tråd, är väl att RISC tydligen togs fram främst eftersom kompilatorer hade svårt att utnyttja alla finesser hos processorer med mikrokod, så RISC är alltså inte optimerat för att koda i assembler utan för högnivåspråk:-)

[Marta]

"En processor med mikrokod kan addera två minnesadresser och lagra resultatet i en tredje, på en instruktion. En processor utan mikrokod måste ladda de två minnesadressernna till varsit register och sen kopiera resultatet från ett register till minnet."

Ja, en sådan instruktion går att göra, men den görs då med hjälp av ett "osynligt" register. Inte ens en harward klarar det direkt. En ovanlig instruktion som jag aldrig sett. Add immediate är det närmaste jag sett, på 8086 en seg sak som slukar kring 25 klockor. PIC gör samma sak med två instruktioner och 8 klockor/2 cykler, långt snabbare.

[sodjan]

> är väl att RISC tydligen togs fram främst eftersom kompilatorer hade svårt att utnyttja alla finesser hos processorer med mikrokod,...

Den största drivkraften för RISC var att RISC gör det enklare att höja klockfrekvensen
jämfört med de mer komplexa CISC arkitekturerna. Tanken var att den totala prestandan
på så sätt skulle bli bättre (och så blev det nog också, även om det är lite svårt att
bedöma eftersom mycket mer pengar lades på RISC utvecklingen...).

När det gäller kompilatorer så är det snarare tvärtom, det är svårare att skriva
effektiva kompilatorer till RISC processorer eftersom kompilatorn måste "göra mer"
och ta fler beslut för att få det hela optimalt. Detta motverkas delvis av att visa
RISC arkitekturer hade mer eller mindre avancerad egen optimering, t.ex Alpha
processorerna med sin OOO (Out Of Order) exekvering av kod. D.v.a att processorn
själv kunde fixa till en del kod som inte var optimal.

Det stämmer dock att många av de tidigare CISC arkitekturerna var enklare att
programmera i assembler eftersom maskininstruktionerns låg på en högre "nivå".
T.ex arkitekturen i VAX hade olika sträng operationer (copy, compare o.s.v), hantering
av köer och floating-point instruktioner direkt implementerat i hårdvaran.

[Nerre]

Enligt vad som står på Wikipedia (de kan ju ha fel) så var motivet bakom RISC att kompilatorerna inte använde alla de instruktioner som processorerna hade.

In the mid 1970s researchers at IBM (and similar projects elsewhere) demonstrated that the majority of combinations of these orthogonal addressing modes and instructions were not used by most programs generated by compilers available at the time. It proved difficult in many cases to write a compiler with more than limited ability to take advantage of the features provided by conventional CPUs.

[Icecap]

Nja... den drivande kraften var att man ville flytta "smartheten" från µC'n till kompilern, detta medgav som sodjan skriver att man kunde höja klockfrekvensen en hel del men den största del var att själv CPU-kärnan blev mindre rent fysisk vilket gav lägre pris då kisel kostar per ytenhet.

Av samma orsak har MicroChip fått över till flash-tekniken då varje minnescell är mindre i flash jmf. den "gamla" EPROM-cellen, detta ger att samma krets kan göra på 2 olika sätt varav den nyare ger mindre chips rent fysisk = lägre tillverkningskostnad.

Så att "optimera" bort sällan använda instruktioner har aldrig varit ett mål i sig, tillverkarna sparar helt enkelt pengar, därav utvecklingen.