PIC | AVR | ARM | o. motsv.

[Lennart Aspenryd]

När det gäller tidtagning så kan det aldrig bli för exact.
Vi kör bilbana och där måste det vara tusendel. Så räkna med decimaler

[Icecap]

Upplösningen har inget med noggrannheten att göra! Man kan ha mycket hög upplösning och ändå låg noggrannhet, vill man däremot ha ett bra system med mycket hygglig noggrannhet kan man använda en TCXO som klocka. Skulle precis till att ge ett exempel i form av DS8000 - men den verkar vara utgått! Det verkar bara finnas 32768Hz oscillatorer, fast t.ex. DS3231 är ganska hygglig exakt. Tidigare hade Dallas/Maxim en 8MHz som TCXO, jag har faktisk ett par samplade liggande.

[Repaterion]

gick lite händelserna i förväg och kollade som hastigast 18F och såg att en del tycks ha "stöd" för usb i sig, vet inte om 16F har detta men vilken kan vara lättast att senare skriva en drivrutin för mellan seriel eller usb, kanske skall skriva RS232 eller USB båda är ju seriella men sedan är väll liknelsen slut...

För någon form av rutin antar jag att det kommer behövas om den skall kunna prata med dator och skicka över tiderna, eller finns det "färdiga" som man bara kofigurerar till det man behöver.

Kanske skulle lägga upp detta framtida projekt i idé tråden istället för att dilla om det i denna.


För att gå lite offtopic i ämnet cpu kraft vs tålighet mot yttre påverkan.
Sitter det inte en 486 i Hubble, har för mig att de bytte från en 386 för några årsedan
Nu är väll iofs rymden en ganska mycket mer extrem...

[sodjan]

> vet inte om 16F har detta [USB]

Nej.

Hubble (och allt annat i rymden) använder speciella "hardened" processorer.
D.v.s som har extra skydd mot strålning. Samma sak gäller minnen o.s.v.
Ofta är det dessutom äldre arkitekturer med större geometrier eftersom
de i sig är mindre känsliga mot strålning.

> RS232 eller USB båda är ju seriella men sedan är väll liknelsen slut...

Ja, det är en väldigt stor skillnad. Om du kan nöja dig med att köra RS232
så är det väldigt mycket enklare på processorsidan. Du kan ju även använda
en krets mellan som sköter USB <=> RS232 bitarna.

[blueint]

Har PIC 18F och "bättre" processorer en linjär minnesarkitektur?

[sodjan]

Det beror lite på hur man ser på det.
Ja, både de nyare PIC16 och PIC18 har en linjär minnesaccess (också).
Den kan användas från t.ex indexregister för att linjärt accessa större
buffrar eller liknande. För annan access så spelar det egentligen igen roll
hur minnet är allokerat, det är bara intressant för större samanhängande
strukturer.

Och det är mer linjärt än t.ex AVR (d.v.s ingen uppdelning mellan
"register" och "RAM"). Allt är samma sak och hanteras på samma sätt.
Hela minnet kan hanteras som "register" och med alla instruktioner.

[Gimbal]

Äsch det är inte så svårt att ge tips om µprocessorer, en Atmega328 blir bra, välj yt- eller hålmonterad och saken är klar. Funkar till det mesta. Billig, relativt potent, lätt att labba med. Se det var väl inte så svårt?

[Repaterion]

[sodjan]

Repaterion, hur menar du ?
Vad visslar du åt ?

[thebolt]

Och det är mer linjärt än t.ex AVR (d.v.s ingen uppdelning mellan
"register" och "RAM"). Allt är samma sak och hanteras på samma sätt.
Hela minnet kan hanteras som "register" och med alla instruktioner.

Att kalla en processor med dedikerad registerfil (och arbetsminne) för "inte linjär" är i mitt tycke helt felaktigt. Linjärt minne ("flat memory model") innebär att allt _minne_ kan addresseras direkt och linjärt utan nån form av segmentering (banking) eller paging.

Därmed skulle jag säga att en hel del PIC18 (jag tittade på databladet för 18F8722) _inte_ har linjär addressering, då du fortfarande har banker och de fyra högsta bitarna i addressen för de flesta instruktioner hämtas från BSR (Bank Select Register). Det finns ett undantag då MOVFF instruktionen specificerar hela 12-bitars addressen och därmed inte behöver bankselekteras. Att sen register och "RAM" är ekvivalent kan ju ses som att du bara har register och inget internt RAM, men det är ju eg egalt. Det som skulle tala emot det är att många instruktioner på PIC(18) har W-registret som underförståd operand (dvs alla instruktioner kan inte hantera hela minnet), så man skulle också kunna säga att du har ett register och sen bankselekterat RAM.

AVR å andra sidan följer RISC-traditionen (AVR bygger på ARM som är väldigt RISC-ig) med en relativt stor registerfil, ett helt linjärt RAM (16 bitars addresser) och en åtskillnad mellan "vanliga" instruktioner som opererar på registerfilen och minnesinstruktioner (load/store) som accessar hela RAM:et.

Vilket som är "bäst" är väll en fråga om tycke och smak, men det man kan konstatera iaf är att PICens sätt att göra det inte fungerar när man börjar få mer RAM, och i lite större MCU:er och CPU:er är arkitekturen med separat registerfil och RAM samt (ofta) dedikerade load/store-instruktioner totalt regerande.

[sodjan]

> Det finns ett undantag då MOVFF instruktionen

Och indexregistren. Man *kan* adressera minnet linjärt, och att många
instruktioner väljer att lägga ett par adressbitar i ett separat register
ändrar inte på det.

> (dvs alla instruktioner kan inte hantera hela minnet)

OK. Det jag menade var att alla instruktioner *som hanterar data i "minnet"*
kan göra det över *hela* minnet. Det finns ingen uppdelning mellan register och RAM.
På en AVR så kan t.ex shift/rotate/bit instruktioner bara användas mot en
begränsad del av minnet (den del som kallas "register"), på en PIC kan de användas
mot hela minnet (eftersom det inte är uppdelat i två olika typer av minne).

> Att sen register och "RAM" är ekvivalent kan ju ses som att du bara har register och inget internt RAM, men det är ju eg egalt.

Nja, egalt och egalt. Skillnaden är att på en PIC har du kanske 1024 register som alla har i princip
samma funktionallitet som AVR's 16/32 "register". Det ger lite mer flexibilitet om man t.ex behöver
många räknare, inga load/store för att flytta data från RAM till ett register där man kan göra INC.

> Det som skulle tala emot det är att många instruktioner på PIC(18) har W-registret som
> underförståd operand...

W är också mappad som ett register WREG i den vanliga minnes arean, så alla "file" instruktioner
kan även köras direkt mot W om man vill.

> men det man kan konstatera iaf är att PICens sätt att göra det inte fungerar när man börjar få mer RAM,

Självklart men irrellevant för den aktuella diskussionen.

> och i lite större MCU:er och CPU:er är arkitekturen med separat registerfil och RAM samt (ofta) dedikerade load/store-instruktioner totalt regerande.

Lika självklart och lika irrelevant.

[Repaterion]

@Sodjan
Inget av vikt.

[jesper]

Dsc_0279.jpg

[Icecap]

jesper: helt korrekt - och månen är gjort av grön ost! Sedan är min pappa starkare än din!

Jag älskar sådana faktafyllda inlägg som klargör på vilket sätt en viss enhet är bättre än andra och på vilka sätt. Jag skulle t.ex. påstå att Atmels produkter inte på långa vägar nåt ikapp t.ex. Renesas' dito, helt enkelt för att Renesas' produkter har så pass mycket mer hårdvarafunktioner inbyggda, precis som det finns bootloader med från fabrik och en del andra saker.

Men om man ska blinka en LED är det synnerligt likgiltigt om en µC har 15 timers när det behövs 1 - och just därför anser jag att det reklamslogan som Atmel har tagit fram där visar deras brister. De måste själv lyfta sig över andra tillverkare och slutsatsen borde då vara att det är för att ingen annan gör det...

[blueint]

Utbudet av utvecklingsprogramvara är av propietär modell från få tillverkare.