Dela med 10 utan matte-bibliotek

[Nerre]

Jag har letat upp funktioner som jag använde för en massa år sedan för att skicka 16-bit och 8-bit tal över serieporten. Detta kan kanske få poletten att trilla ned. Här har jag dividerat med 10000, 1000, o.s.v. för att få ut siffrorna i rätt ordning utan att mellanspara dem innan de ska läggas på serieporten. Om man mellansparar i en array går det att enbart dela (med rest) med 10 i varje steg.

Problemet är ju att din kod innehåller en massa divisioner... Och det är ju de som tar en massa processorkraft.

[bearing]

SLNAÖGAÖFGAÖDFGADFJKGNADKFLJGNDFLKJGNSDFLKJGNASDFLJKGSNDFKGLJSNDFLKGJSNDFGKLJSDNFGLKJSNDFGLKJSDNFGLKSJDNFGLKSJDNFGLKSDJNGSKLDJFNG

Suck.

Mina funktioner var ju i hela friden exempel på varför en snabb div/rest med 10-funktion behövs, eftersom att du och TomasL inte verkar förstå det. När man skriver ut en variabel som decimalt dividerar man normalt med 10 för varje siffra. Hur ska det annars gå till?
Att skriva ut den som hex är väldigt snabbt i jämförelse. Ett par enkla maskningar och swapningar bara.

Den här "double-dabble" metoden verkar ju lovande, men den är något som varken jag, Icecap, eller Sodjan har känt till. Nu kommer ju du förstås mörka, och påstå att du kände till den metoden innan. Och om du gör det antar jag att jag får avreagera mig genom att banka ett hål i genom isen här utanför med pannan, och sedan hoppas att jag inte tar mig upp.

[Nerre]

Jag har inte argumenterat för huruvida den behövs, det jag argumenterade för var att man inte behöver presentera decimaltal som decimaltal utan kan presentera som heltal med ett "falskt" decimalkomma.

Ska du visa 12,3 på en display behöver du inte konvertera till ett flyttal, du kan konvertera till heltalet 123 och placera kommat där du vill ha det.

För att presentera ett heltal som BCD så behöver man såklart dela med 10.

[bearing]

För att presentera ett heltal som BCD så behöver man såklart dela med 10.

Och det är ju det här som hela tråden handlar om.

Och det visar sig att med metoden Double-dabble kan man slippa den där divisionen.

[TomasL]

Var i jösse namn kommer BCD in i diskussionen?
Dessutom, man behöver inga mattebibliotek för att utföra division, eftersom detta är inbyggt i C-kompilatorn.
Mattebiblioteken behöver man bara om man skall använda trigonometri, logaritmer och liknande.

[bearing]

Ni har helt enkelt inte läst tillräckligt noggrant för att se vad den riktiga bakgrunden till Icecaps fråga är. Alternativt inte har tillräcklig erfarenhet av små mikrocontrollers med bara ett tiotal byte RAM och liknande.

I en del miljöer för små mikrocontrollers blir kodstorleken mindre ifall man inkluderar ett mattebibliotek. Dels för att bibliotekets funktioner för multiplikation/division kan vara bättre skrivna, dels för att kompilatorn annars lägger multiplikations-/divisionskoden inline vid varje operation, istället för att anropa en funktion.

[Nerre]

Om man ska presentera ett heltal en siffra i taget blir det en omvandling till BCD (även om man bara använder en nibble i taget).

[TomasL]

Nej det blir det inte, skall du skicka det till en terminal, så skickar du text-strängar, annars går det inte att läsa, och terminalen i fråga kan heller inte tolka saker rätt.
BCD är något helt annat.

[Icecap]

TomasL: printf (stdio.h) innehåller division och en massa annat man ofta kan klara sig utan. Ska det importeras för att skriva ut en debug-grej kan det vara omöjligt i trånga applikationer, därför vill jag vara utan!

I en FMMC 16-LX har jag testat skillnaden mellan att låta bli att ta med stdio.h eller inte och det var en hel del minne som gick åt om jag hade det med, minns inte exakt storlek men det var några kB. En Q&D-lösning kostade ~100 bytes - men var långsammare.

Därför vill jag se om jag kan göra en "universell" rutin som kan det hela men inte kostar speciellt med minne eller hastighet.

Men du verkar helt enkelt inte förstå hur man gör om binära värden till decimal presentation när det kommer till "bits & bytes".

[bearing]

Nej det blir det inte, skall du skicka det till en terminal, så skickar du text-strängar, annars går det inte att läsa, och terminalen i fråga kan heller inte tolka saker rätt.
BCD är något helt annat.

Visst visst. Ni kallar det ju olika bara. Om du tar en nibble av en BCD, och adderar '0', så blir det ASCII. Bakgrunden till tråden är i alla fall en önskan om att omvandla en variabel till en sträng av ASCII-siffror, på ett snabbt och utrymmessnålt sätt. Även om den här Double-dabble metoden ger BCD i exemplena på Wikipedia, kan man så klart använda metoden för att få ASCII-siffror istället.

[TomasL]

Om du tar en nibble av en BCD, och adderar '0',

öh, det där får du allt förklara
0x99 är 99 i BCD, kan inte se hur det kan bli 0x57 0x57 genom att addera en nolla

[Icecap]

TomasL:
"en nibble" = 4 bit.
Alltså ta höga 4 bit, shifta ner dom, addera '0' = ASCII
Sedan tar man de låga 4 bit och adderar '0' = ASCII
osv.

pbgp:
Det var ingen hjälp heller, den gör som många andra: tar ungefär 1/10 av värdet man matar med. Ska man kunde ta t.ex. ett WORD eller större variabler behöver man ganska många shiftningar och additioner för att hamna rimligt rätt och då kan det kostar en hemula massa minne och tid.

Vid någon storlek når man en break-even mellan att subtrahera 10000/1000/100/10 och alla shiftningar.

[bearing]

Precis. '0' är 0x30 eller 48 decimalt. Så om man adderar 9 med '0' blir resultatet '9' eller 0x39, eller 57 decimalt.

[TomasL]

Ok, så du menar med '0' inte en binär nolla (såsom jag tolkade det), det förändrar naturligtvis saker lite grand.

[Nerre]

Nej det blir det inte, skall du skicka det till en terminal, så skickar du text-strängar, annars går det inte att läsa, och terminalen i fråga kan heller inte tolka saker rätt.
BCD är något helt annat.

Ja, men för att omvandla ett heltal till en textsträng så måste du först omvandla talet till BCD.

Heltalet 123 måste först omvandlas till talen 1, 2 respektive 3. Dessa tal omvandlas sen till ASCII-tecknen "1", "2" och "3".