Svenska ElektronikForumet

om jag har ett 2-siffrigt tal och vill få ut tiotal och ental ur detta... hur gör jag då???
Anledningen att jag frågar är att jag försöker att göra en liten klocka som räknar sekunder, minuter och timmar. Men Jag vill skriva ut klockan på en lcd-display och kan ju bara skicka ett tecken åt gången.... Det borde ju gå att räkna fram, eller????

Om man tar talet och delar med 10 då kommer resten av den delning att vara '1'-torna. Spara i en buffer om det behövs för skrivriktningens skull.

Gör det samma det antal gånger du behöver siffror till, för varje gång ökar värdets placering med 10.

Exempel: 123 ska delas upp.

123 / 10 = 12, rest 3, 3 på ettornas plats alltså.
12 / 10 = 1, rest 2, 2 på 10'ornas plats alltså.
1 / 10 = 0, rest 1, 1 på 100'arnas plats alltså.

Men är detta "för krångligt" är det väl bara att räkna upp så att sekunderna (/minuterna/timmarna) är i ental och tiotal, då är det ju bara att smälla ut dom "direkt".

>Men är detta "för krångligt" är det väl bara att räkna upp så att sekunderna (/minuterna/timmarna) är i ental och tiotal, då är det ju bara att smälla ut dom "direkt".

Det va så jag hadde gjort, men jag tänkte att det kanske fanns något bättre sätt....
Det va ett rätt smart sätt som du beskrev.... men att dela med 10 är inte så enkelt på en pic16f648a som jag använder just nu... men eftersom jag inte talade om det så kunde du ju inte veta d

Det är BCD-kod som du vill ha, kanske finns det något kommando eller applikationsnot om det.

Vilket programspråk?

Minus 10 till det slår över till negativt samtidigt som man räknar upp antal_tior.

psynoise> Nej, BCD är det inte. Han vill ha ut båda siffrorna var för sig för att sedan kunna skriva ut dom, d.v.s omvandla till teckensträng. I BCD är det forfarande en byte av talet, bara kodat annorlunda. Däremot, och jag tror det är det du menar, så är det väldigt snarlika operationer som behöver göras.

v-g> Håller med! Det är nog enklaste metoden om man inte har hårdvarudivision. Det blir max 10 iterationer och då tar det inte speciellt lång tid heller. Alternativt så kan man dela med två först genom en shift och sedan subtrahera 5 istället. Fast då blir det knöligare med resten för entalet, så den varianten blir knappast enklare i det här fallet. Annars är ofta ett bra sätt att dela upp talet man ska dividera med. Är det ett jämt tal och delbart med två så kan man nyttja det.

> I BCD är det forfarande en byte av talet,...

I *packed* BCD, ja. Annars måste det inte vara det.

Den enda variant av BCD som jag hört talas om är med två siffror i en byte. Poängen med just BCD är ju förhållandet mellan ental och tiotal där varje nibble motsvarar en decimal siffra.

Edit: Jo det är klart att man skulle kunna lagra varje decimal siffra som en enda hexdecimal nibble i en byte. Och då kalla det BCD utan "packed". Fast jag har aldrig stött på den varianten. BCD brukar användas för att på ett lite lättare sätt lagra två decimala siffror i en byte så jag tror att "packed" blivit lite överflödigt idag. Att man helt enkelt förkortar det till BCD bara.

> ...som jag hört talas om ...

*I dag* används kanske vanligtsvis "BCD" för den variant där man lägger
två siffror tillsammans i samma byte, men den korrekta benämningen
för det är (fortfarande) "packed BCD". Huvudsaken är dock att man är
tydlig på och överens om vad man talar om...

> BCD brukar användas för att på ett lite lättare sätt lagra två decimala siffror
> i en byte...

Ja, ofta slutar det i det, men det är varken poängen eller syftet med BCD.

Poängen med "Binary Coded Decimal" är att underlätta beräkningar
med basen 10, det har inget specifikt att göra med hur varje "siffra" lagras,
d.v.s var för sig i en egen byte eller tillsammas ("packed") i samma byte.
Faktum är att beräkningsrutiner kan bli enklare om varje "siffra" ligger i en
egen byte, det blir inga "swap" av nibbles och liknande, till priset av
mer lagringsutrymme, så klart...

Och anledningen till att man överhuvudtagit började räkna med BCD är vetenskapligt: med den rätta rutin kan man räkna med godtyckligt stora tal i BCD, då menar jag att man kan utföra matteoperationer på värden med flera hundra siffror om man vill.

Yes, gamla hederliga ABC80 hade BCD-aritmetik!

Gick visserligen väldigt mycket långsammare än vanligt flyttal, men som sagt var, det var inga som helst problem att räkna med tal med flera hundra värdesiffror.

Räknar man med flyttal så finns ju risken att små avrundningsfel (på grund av längden på mantissan) ackumuleras.

Och det är därför som man aldrig ska räkna pengar med "float".

Det var ju bra att vi fick rett ut det!

Det är säkert många som inte har full koll på vad BCD egentligen är och det är bra att få reda lite mer om bakgrunden och definitionen. Jag tycker själv att jag rätt så bra koll på dom flesta sakerna men här var en del nya saker! Även om jag är gammal jämfört med många andra här, så har jag inte egentligen räknat med BCD aritmetiskt i någon större omfattning.

Många, kanske dom flesta miniräknare kör också med med BCD-aritmetik av samma anledning att räkning med binär aritmetik kan ge konstiga avrundningar när det presenteras i basen 10.

Det var också en av anledningarna som free42 som i första implemetationen använde datorna mattelibbar snart gjordes om med BCD-mattemotor istället för att den skall fungera som orginalet - som just använde BCD-aritmetik.


Att ABC80 körde med BCD i sin flyttalstillämpning visste jag däremot inte, att den var slö med flyttal var däremot välkänt så alla körde med heltal så mycket som möjligt... och för att vara en Basic-dator så var den snorsnabb i jämförelse med liknande datorer får samma tid - men så prekompilerade den koden medans den skrevs in och den vägen snabbade upp det hela när koden skulle exekveras.

> Att ABC80 körde med BCD i sin flyttalstillämpning

Nja, man kunde välja, om ja minns rätt.
Det fanns ett BCD läge för exakta beräkningar med många siffror.