AVR AD-omvandlingsfråga

[monstrum]

Ursäkta, upptäckte just att jag skrev fel tidigare... Alltså, det är det låga registret, ADCL, som måste läsas först, då latchas ADCH som sedan "måste" läsas för att registren skall uppdateras igen.

[ASTRX]

Skall snart själv koppla några linjära temperatursensorer till en atmega8, och har några frågor. Jag vet ju att om man bara vill ha 8-bitars noggrannhet så räcker det att läsa ADCH. Men om man vill ha 10 bitars noggranhet så måste man ju läsa in båda. säg att man då kör med right adjust.
Hur sker då själva tolkningen av det 10-bitars-talet?
jag menar hade ADCH och ADCL tillsammans kunnat läsas som ett 16-bitars register-vore det väl lätt, men det går väl inte, eller?
om man lagrar de i 2 enskilda variabler, hur slår man de då samman till ett korrekt tal?

Allt kodande sker i C.

[sodjan]

Hx256+L

I princip...

[Kaggen]

Om du skall ha 8-bitars nogranhet räcker det väl inte med att läsa ADCH? Där ligger ju bara de två mest signifikanta bitarna (om A/Dn är 10 bit)?

Att slå ihop ADCH och ADCL är ju annars bara:

Kod: Markera allt

  int result;
  result = ((ADCH & 3) << 8) + ADCL;

Ditt 10-bitars A/D värde ligger nu i result.

D.v.s. maska ut de två lägsta bitarna i ADCH shifta upp dem 8 bitar och addera ADCL. Med microcontrollers är det bra att kunna bitar, bytes, aritmetiska AND, OR och EOR och typkonvertering. Något man ofta har lyxen att strunta i i "normal" programmering.

Edit: Oops! Ändrat till << 8 istället för << 10. Höll på att bli helgalet... Som sagt det är bra att ha förståelse för binära tal

Edit2: Ett tips om man är osäker på binära/hexadecimala tal och omvandlingar är att använda miniräknaren i windows i avancerat läge. Där kan du växla mellan binärt, decimalt, octalt och decimalt. Om man i binärt läge skriver t.ex. 101 och växlar till decimalt, ser man vad det decimala värdet för 101b är o.s.v.

[monstrum]

Skifta 10 gånger? Snarare 8 i så fall. Men eftersom multiplikation bara tar tar två klockcykler (för AVR:erna som har det i hårdvara, vilket t.ex. alla ATmega har) så går det fortare att bara multiplicera med 256.

Dessutom så behöver man inte "ocha" bort övriga bitar, helt onödigt.
Och det är rätt, ska man bara ha 8 bitars upplösning så ställer man ADC:n till left adjust och läser då bara det höga registret, dvs ADCH.

Japp det höga registret multiplecerat med 256 plus det låga. Eller så läser man ADC, som är ett pseudo-16-bits-register. Alltså, GCC tolkar det som att göra precis ovanstående och du kan enkelt lägga detta i t.ex. en unsigned short int som är två bytes lång.

[Kaggen]

> Eller så läser man ADC, som är ett pseudo-16-bits-register.

Ok, bra tips!

[ASTRX]

Om du skall ha 8-bitars nogranhet räcker det väl inte med att läsa ADCH? Där ligger ju bara de två mest signifikanta bitarna (om A/Dn är 10 bit)?

Jo om du left skiftar så får de 8 mest signifikanta bitarna i ADCH.

aha sjävlklart så gör man ju (ADH*256)+ADCL. blivit förmånga timmars Assemblerkodande i skolan och hemma så jag börjar bli virrig måste börja tänka C nu igen

dock är det slappare att läsa det 16-bitars pseudo-registret ADC, knepigt att jag inte hittade nåt om det i databladet.

[ASTRX]

Om du skall ha 8-bitars nogranhet räcker det väl inte med att läsa ADCH? Där ligger ju bara de två mest signifikanta bitarna (om A/Dn är 10 bit)?

Jo om du left skiftar så får de 8 mest signifikanta bitarna i ADCH.

aha sjävlklart så gör man så som du säger Kaggen. blivit för många timmars Assemblerkodande i skolan och hemma så jag börjar bli virrig måste börja tänka C nu igen

dock är det slappare att läsa det 16-bitars pseudo-registret ADC, knepigt att jag inte hittade nåt om det i databladet.

[monstrum]

Nja, det är inte så knepigt att du inte hittade i databladet. Det är inte processorn själv som har något 16-bits register utan det är snarare GCC som fixar det åt dig.