Svenska ElektronikForumet

Allt beror på vad du vill uppnå men så länge det fungerar är det väl OK eller hur?

choppertony skrev: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 ?

Har man koll på sina 16-multiplar så är det inga problem: 1*16^3 + 10*16^2 + 4*16^1 + 9*16^0 = 4096 + 10*256 + 4*16 + 9 = 4096 + 2560 + 64 + 9 = 6729

tack BOS det hjälpte en del i alla fall.

Och igentligen är ju inte skillnanden så stor mot vanlig decimal räkning :
Enda skillnanden är basen 16 istället för basen 10...

Om via "bara" nu hade räkneord för A-F och motsvarigheter till "hundra", "tusen" (fast
för "256" och "4096") så skulle vi kunna "läsa" hex tal direkt precis som vanligt...

Alltså, istället för "tvåtusentrehundraförtiofem" ovan, så skull det kunna bli något motsvarande för "1a49".

"1a49"

Ettusenahundraförtionio...

Problemet är att ordet "tusen" betyder just 1000 *decimalt*,
och det står inte den första "1" för. Vi behöver helt nya
namn/uttryck om det ska bli något vettigt av det...

choppertony skrev:
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.

Du får exakt samma problem i basic dessvärre, det är ju alltid ett helvete med flyttal, även om basickompilatorerna jag känner till (framförallt PBP) har mycket inbyggt så är flyttal inte en av dom sakerna, så man får böka som fan ändå.

Det finns ju dock program som "fuskar" åt dej, som spottar ur sej hur du löser det med aktuell bitlängd (bit/byte/word/long osv) och vilken precision det blir. Alltså, ett program du kör på en vanlig dator då, tex MiscEL

..Däremot är ju PBP väldigt enkelt att använda på många andra sätt och är exakt lika maskinnära som C, även om C-khmererna har lite svårt för att erkänna det

Man får hitta de genvägar som kan hjälpa en igenom lärandet av ASM. Det finns ju i bland hjälp att få. T,ex med att fixa delay'er för en viss tid. Upphittat hos Sodjans exempelkod .... http://www.piclist.com/techref/piclist/ ... /delay.htm

Som jag sa innan så är det nog ingen ide att titta på ngt annat språk. Man kommer att köra fast där oxå på ett eller annat sätt. Man får läsa vad man kan och plugga o undersöka och prova sen får man ställa frågor här så kommer man oftast vidare.

Off topic, men...

Det finns programbibliotek(för PC) som t.ex. Torbjörn Granlunds GMP http://gmplib.org/
och MPFR http://www.mpfr.org/
för att göra beräkningar med godtycklig precision.

Vad sägs om att beräkna pi med hundra miljoner siffror,
eller besselfunktioner med 10000 siffror ... lätt och kvickt!

Dock ännu icke för PIC-kretsar såvitt jag vet!

Detta kan inte jag svara på för det var inget jag förstod. Men kanske ngn annan som vet vad det handlar om?

Kontentan är nog att kommatal (flyttal) är ett problem i alla applikationer då de kräver mycket datorkraft. Behöver man t.ex. att väga något i 1/10 gram kan det nästan alltid löna sig att använda enheter om 1/10g och sedan bara lägga ett komma rätt i utläsningen.

12,3g blir då "internt" 123 och plötsligt blir allt heltal vilket är enkelt att jobba med och som inte alls kräver lika mycket kraft & minne som flyttal.

Självklart kan man använda valfri upplösning till de "interna enheter", bara man ser till att det fungerar ordentligt.

Detta var precis vad jag tänkte. Kommatecknet är ju bara en extra utgång för att visa för menniskor vad värdet är. -Utgången för att tända komatecknet på vissa displayer. Det finns ju inga pic'ar som är ntresserade av dec-tal..... Alla dessa tal som inte behövs visas på display kan ju vara bin eller Hex. och som sagt 225 bin kan oxå vara 2,25 eller 22.5 eller 225000 . Det beror ju på vad man vill ha det till.

Min temperaturmätare på min Volvo 945 hänger o dinglar, Kan det vara för att den inte har kontakt med Gnd att den visar att det är -188 grader kallt....,,,, Visserligen så är det ingen värme , men så kallt är det inte *L*

> och som sagt 225 bin kan oxå vara 2,25 eller 22.5 eller 225000...

Nja... Jag tror inte man ska blanda bin/dec och heltal/"fixed point" på det där sättet.

Eller menar du ett värde "225" *decimal* ? Jo, det gör du antagligen...
"225" är inget binärt värde.

> Det beror ju på vad man vill ha det till.

Exakt, och det är själva kärnan i hela diskussionen. Det blir ett väldigt
gissande fram och tillbaka när man inte vet vad det aktuella behovet är.
I praktiken så behöver man veta vilka givare som är aktuella, vilka värden
(min/max) som man förväntar sig, hur presentationen ska ser ut o.s.v.
*Sen* kan man säga något om hur beräkningarna enklast fixas...

Klart jag menade Decimalt.

som ett exempel med Tempgivare. Där får man in ett värde mellan 0 och 255. Skall detta värdet visas i en display så vill man kanske ha en decimal.

Det jag tror att du menar är att värdet från tempgivare skall in i 8 bitar dvs 0-255, där 255 inte behöver betyda grader utan du får kolla min och max på givaren.

inspänning till AD/antal bitar. antar 12V(bil) in och 8 bitar ger 12/256 = 1LSB = 0,046875V.

Har du sedan en tempgivare som ger 0-100 grader och vid noll grader levererar 0v till AD och vid 100grader lev 12 v.

Så ger detta att 12V in = motor temp = 100 grader, 6v in ger 50 grader osv.... med upplösingen 0,046875V.

Med den upplösningen går du många decimaler