decimaltal, och tal som är större än 255 ?

[choppertony]

Jag är ju som sagt nybörjare och då blir frågorna enkla. eller som för min del, svåra. jag undrar hur man gör om man behöver använda tal större än 255. det finns säkert i ngn bok från 70 talet beskrivet. Men man kanske gör lite annorlunda nu? samma sak angående decimaltal? Jag har sökt på forumet om detta. Men jag har inte lyckats hitta något. Tackar på förhand.

[persika]

För tal 0-255 kan man använda 8bitar (1byte), och för tal mellan 256-65535 kan man använda 16bitar (2byte), osv med flre byte. Det är inget som hindrar att man använder ex.vis 2byte för ett litet tal mindre än 255.
Decimaltal... Det går att ha tal i ascii-format, men annars är talen bara decimala vid in o ut matning från o till tgb och display, processorn får jobba med binäratal.

[cyr]

Om man skriver i C eller liknande är det bara att använda en datatyp med fler bitar (t.ex. "short" eller "long").
Om du kör assembler på en 8-bitars processor är det lite jobbigare, du får dela upp talet i flera byte själv och använda instruktioner som "add with carry" och liknande.

När du säger decimaltal, menar du då floating point? Typ 1,6473? Åter igen är det jättelätt i C, bara använd en datatyp som "float" eller "double". Dock så går det åt mycket minne och många instruktioner för att hantera det på en liten 8-bits processor, så det är bättre att ta till lite andra trick. Allra enklast är att bara byta enhet. Säg att du vill lagra temperatur i grader celsius, med minst upplösning på en hundradels grad. Byt enhet till hundradels grader!

Alternativt, sök på "fixed point".

Men det är kanske bra om du talar om vad det är för processor och språk du använder och ungefär vad du vill göra...

[choppertony]

"short" eller "long" känner jag igen ifrån den tiden då jag höll på med pascal eller C . och jag känner suget efter att använda någon av de språken för att lättare komma vidare. Men jag vet inte om det är ngn genväg. ASM är krångligt och kanske inte så lätt att förstå. Men jag tror att om man bara tar sig tid att lära sig det så är fördelarna större än nackdelarna.

Jag Försöker mig på ASM en tid till *L*... Och då får det ju ta lite tid att lära sig saker....

om jag t,ex använder en givare som jag läser av analogt så får jag ett värde mellan 0 och 255. Om det är t,ex en tempmätare så kan jag kanske visa det värdet på displayen. Men då får jag hänga en miniräknare bredvid och skriva en lapp vad talet skall beräknas med för att ngn skall förstå hur varmt det är. Här är ju ett exempel på hur jag kanske måste använda Decimaltal 19.6 grader.

Det är till och med så man är sugen på Basic. Men jag tror att jag kör fast ganska snabbt och blir tvungen att lära mig ASM i alla fall.

[Nerre]

Jag tycker C är det vettigaste att när man jobbar med mikrocontrollers, C är ju tämligen hårdvarunära, även om man i vissa lägen kanske behöver använda assembler för att göra vissa saker. Man kan då antingen använda inline assembler eller (bättre) skriva funktioner i extern assembler som slås ihop med C-programmet vid länkningen.

Ett bra sätt att lära sig är att ta ett litet program man skrivit i assembler och skriva om det i C, och prova att kompilera med olika nivåer av optimering.

[sodjan]

Kolla Piclist för lite exempel.
http://www.piclist.com/techref/piclist/index.htm
http://www.piclist.com/techref/microchip/math/basic.htm

Man kan säg att att "räkna" i ASM är lite som att räkna med papper och penna.
Då beräknar man förts ental, sedan total o.s.v. Men i ASM så blir det (om man
räknar helt binärt) 256-tal, 256*256-tal o.s.v. Beräkningar i BCD är dock
mer lika papper och penna, då kör man ental, 10-tal, 100-tal o.s.v.

Sedan, när det gäller givare och beräkningar med "verkliga" värden så
handlar väldigt mycket om att skala både insignaler och beräkningar på
ett sådant sätt så att beräkningarna blir enkla. Det är väldigt sällan som
man behöver använda floating point ("float" i C), och tror man att man
behöver det så har man oftast gort något misstag i förarbetet.

[choppertony]

Finns det ingen sida här på forumet som visar hur olika språk löser ett bekymmer? Det kanske hade varit ett bra tema att ha på ett sådant forum annars.

Skapa ett uppdrag. Enkelt nog från början för att nybörjare oxå skall kunna hänga med. Lös problemet i olika språk.

Åter till mitt bekymmer. Hur slår jag ihop 2 byte så jag kan läsa större tal än 255.. med ASM.. Tackar på förhand!

Skall kolla Piclist exempel... Tackar

[sodjan]

> Hur slår jag ihop 2 byte så jag kan läsa större tal än 255.. med ASM..

Du "slår inte ihop" någonting alls.

Att två olika bytes är två delar av samma tal är något som du får
hålla reda på, PIC'en har inte en aning om det. Precis på samma sätt
som om nu skriver så här på ett papper :

Kod: Markera allt

  12
+ 34
----
  46

Först räknar du ihop "2+4=6" och skriver ner det (ingen minnessiffra).
Sedan räknar du ihop "1+3=4" och skriver ner det (och lägger eventuellt
till minnessiffran). Varken pennan eller pappret har en susning om vad
"ental" eller "tiotal" är för något, det är något som du får hålla redan på.
PIC'ens register motsvarar "pennan och pappret" och koden är du själv...

Varje siffra ovan skulle i ett ASM program motsvaras av en 8-bitars variabel.
PIC'en i sig har som sagt inte en aning om vad du tänker/vill använda dom till.
Det är hanteringen i koden som du skriver som bestämmer det.

Alltså, antag att vi har 2 st 16-bitars tal. Det ena lagras i variablerna
A1L och A1H och den abndra i A2L och A2H. "L" och "H" symboliserar
"low" och "high", d.v.s den läga eller den höga delen av talet. Antag
också att vi vill ha resultatet i R1L och R1H.

R1L = A1L + A2L (notera minnessiffra, d.v.s "Carry" eller C-biten).
R1H = A1H + A2H (+ eventuell Carry från raden ovan).

That's it. Och det är (nästan) precis vad 16-bitars exemplet från Piclist gör.
Skillnaden är bara att ett 16-bitars tal läggs till till ett annat, vi har inte
något tredje resultat i detta fall.

Kod: Markera allt

16 Bit addtion with borrow  
by Rasmus Riber enspire by Rudy Wieser

        movf    SourceL,W
        addwf   DestL
        movf    SourceH,W
        btfsc   STATUS,C
        incfsz  SourceH,W
        addwf   DestH  

Sedan är det enkelt att utåga till 24, 32 bitar o.s.v.

[choppertony]

Här är nog ngt som jag får undersöka ordentligt tills jag förstår det. Tackar! Jag tror jg har sett det innan i bgn tråd där någon vill dela upp sitt värde i ental,tiotal och hundratal. Kanske var det detta han ville åstadskomma.

[sodjan]

Ja, det är ju en lite annorlunda sak, det har bara med hur ett visst tal
presenteras/representeras, det ändrar ju inte värdet på talet i sig. Om
man vill omvandla ett binärt värde till BCD så är det nästan alltid för
att fixa en presentation på t.ex en LCD eller överföring till ett annat
system som kanske förutsätter ett visst format. Sällan för att underlätta
vidare beräkningar i sig. Visst, det går helt OK att skriva kod för att
göra beräkningar i BCD, och i vissa fall kanske det medför något fördel.
Men oftast är det enklare att köra rent binärt. Dessutom är det ju väldigt
beroende på det aktuella fallet, vad man håller på med, så att säga.

[choppertony]

Det decimala räknesättet skulle förbjudas *L*.... Då hade det varit så mycket lättare just nu. Tänk att bara lära ungarna Binärt och Hex i skolan. Det kanske hade fört oss framåt. Evolution !!!!

[Icecap]

Har faktisk läst om en mattelärare som lärde barnen binär räkning från början. Hur man adderade osv enbart i binärt. Detta gick bra och då de senare blev introducerat till decimalsystemet hade långt fler lättare att hänga med, de kunde ju redan räkna men nu var det bara lite fler tal... Historien förtäljer dock inte hur det gick sedan, det kan ju vara att det gick bättre enbart pga. en entusiastisk lärare.

[choppertony]

Vem vet. Antingen gick det kanonbra, eller blev det ingen förändring, eller gick alla barnen o sänkte sig i sjön..... Att förvandla från bin till hex är ju enkelt.

101101111 man skall gruppera talen om 4 siffror åt gången. de översta 1011 och de lägsta 1111 de första blir B och de sista blir F Alltså Hex "BF" som blir 191 Decimalt, Alltså är det lättare att räkna och omvandla hex och bin än bin och dec eller dec och hex... Någon som har ett lika lätt sätt att från Hex komma till Dec utan att använda miniräknaren Hex 1a49 vad blir det ?

[Icecap]

Faktisk är det enkelt att göra:
Valfri storlek tal som inkommande värde, sedan en buffer som talet sparas i och en pekare som visar var i buffern vi har kommit till.
Start:
Bufferpekaren ställs till att peka på siste platsen i buffern.
LOOP:
Talet delas med 10, resten sparas i buffern där pekaren pekar.
Bufferpekaren räknas ner ett steg.
Om talet > 0 gå till LOOP
Räkna pekaren upp ett steg
; Nu pekar pekaren på första siffra (MSD = Most Significant Digit) och det är bara att skriva ut allihop.

[choppertony]

Man skulle kanske kunna använda ett antal byte.... Kanske lite slarv med minnesplats. Tänkte mig att man har en startbyte som har värdet 00001010 När man läser igenom minnesplatserna efter denna startByte så kan efterföljande talen bara vara från nio till nio fast i binär form. kommer man till en byte med talet 00001011 så blir det som en SlutByte

Om man använder en tangentmatris så får man först tala om att man skall knappa in ett värde med att välja den menyn i ens display t,ex. då skapas startbyten. Den läser av knapptryckningar fram tills man trycker enter. Skulle kunna se ut så här

00001010 ;Startbyte talar om att efter denna byte kommer ett nummreriskt värde
00001001 ;första inknappade talet 9
00001000 ;andra inknappade talet 8
00001001 ;tredje inknappade talet 9
00001000 ;Fjärde inknappade talet 8
00000111 ; Femte inknappade talet 7
00001011 ; slutByte , Talar om att talet inte är längre

Då har man talet 98987 som är ett högre tal. Redan uppdelat och lättare att beräkna efter hand.

Jag säger som i yrrol " Man kan göra så , Men det är inte rätt *S*...

Är det onödigt dumt sätt eller är det okey?