PIC16F886 lookup tables

[Scorpiion]

Jag håller på och ska göra lite lookup tables på min 16f886 efter att ha läst av lite analoga värden med ADCn. Jag funderar nu dock på hur det nu är med begränsningen för dom...

Jag vet att för baseline chips så är det en begränsning som gör att tabellen måste vara inom dom första 256 wordsen på en page, men är inte helt säker på om detta gäller för en 16f886 också? Eller kan jag göra lite längre tables med den..?

[sodjan]

886'an har ju även direkta table-read kommandon direkt från flash.
Alltså behöver du inte RETLW tabeller som på tidigare modeller.

[Scorpiion]

Mhm.. det låter intressant.. jag har läst nått lite löst om det men inte riktigt fattat hur det fungerade...

Jag ska ta och titta igenom de tillgänliga kommandon som står med i databladet igen och leta efter något om detta.

Men om någon vill förklara lite mer kontrekt vad detta innebär så skulle det uppskattas! Är just nu inne på att göra flera tables för att komma runt det med 256... Hittils så går det bra i teorin för 0-255, 256- 511 men sen funderar jag lite på hur jag ska skilja på 512-766 och 767-1023... (innan finns det en alltid en bit jag kan testa med men eftersom 512-1023 båda börjar ser ut b'1xxx xxxx' så kan jag inte göra lika som för dom mindre..)

Men om det du Sodjan sa innebär att jag kan använda en stor lista skulle ju det vara kanon!

[Marta]

Vad är det som Du skall göra med dessa enorma tabeller? Känns lite som att Du kanske har hamnat snett och valt en onödigt stökig lösning.

Som ett exempel: Är det t.ex. linearisering kan man ofta dela in mätområdet i block och lagra en offset för dessa istället utan att tappa nämnvärt i noggrannhet.

Ju mera information Du ger, ju bättre svar kan vi ge Dig.

[sodjan]

För det första, glöm allt som har med "base-line" modeller att göra.
De har (arkitekturmässigt) ganska stora skillnader (och begränsningar)
jämfört med de senare "midrange" modellerna (som PIC16F88x serien).

> jag har läst nått lite löst om det....

Det är inte speciellt mycket att läsa, ca 1/4 sida på "10.1.4 READING
THE FLASH PROGRAM MEMORY".

Sen är jag inte med alls på vad "256 problemet" är. "Table read" läser
så vitt jag vet linjert genom hela programminnet utan något "256 gräns".
Sannolikt rör du ihop det med med table-lookup med RETLW instruktioner.

[Scorpiion]

@Marta, jo visst är det väl så att tabelen kanske är lite "overkill" men ibland kan det vara roligt, sen så om man inte kan göra det på det "korta och smidiga" sättet så försöker man ju med det "långa och krångliga"... iallafall tills man lärt sig det enklare och kanske rätta sättet! Det jag ska göra är att läsa av ADCn som får ett värde från en trycksensor och en tempsensor, sen lägga ut det och "meter under ytan" på en display.. (är en sort dykdator i ett skolprojekt) Och ja ADCn är 10 bitars och därav min tanke med en lookup table med en post för varje värde... (och nej jag hade inte tänkt skriva alla värden för hand utan bara skriva ett "vanligt" datorprogram för att göra den koden..)

Just nu så har jag fått LCD'n att funka bra och läsning av värderna tror jag också gått bra och jag har sparat dom i PRESSURE_HI och PRESSURE_LO... Och det jag håller på med nu är då att göra någon table lookup eller liknande för att kunna behandla resultatet.

Men smidiga lösningar och förslag är välkomna! Det här är mitt första "stora" projekt i assembler och jag anser att jag har mycket att lära...

@Sodjan, ja självklart vet jag att jag inte ska blanda ihop dom! och ja jag vet att det är mycket som skiljer men jag vet inte exakt allt som skiljer sig och det som jag tänkte på, nämligen table lookup med retlw var jag osäker på och vad jag förståt så är det samma "begränsning" med table lookups på midrange? Men uppenbarligen så finns det ju en annan lösning som du lite antyder om...

"Det är inte speciellt mycket att läsa"... Jo Sodjan, på internet så finns det väääääldigt mycket att läsa! Och det är där som jag "läst lite löst" om det du föreslog... Men som sagt jag vet riktigt exakt hur det funkar jämfört med table lookup som är det jag kan hittills...

Jag har aldrig ens använt en PIC från "base-line", men jag har nu under några dagar läst igenom alla 10 lektioner från gooligum.com.au och eftersom dessa behandlade "base-line" så refererade jag till det.. Varför läser jag om base-line när jag använder en midrange? Ja eftersom jag vill lära mig "allt" från grunden så ansåg jag att det är bäst att läsa om base-line först för att sedan fortsätta läsa om midrange... Det är dock ett ganska tight tidschema på projektet och därav har jag hittils bara läst om base-line och då kanske missat lite grejer som man kan göra med midrange...

Mvh

EDIT: Både mina sensorer är linjära så vitt jag vet... Är några andra som har hand om sensorerna men jag är ganska säker på att dom är linjära..

[sodjan]

> "Det är inte speciellt mycket att läsa"... Jo Sodjan, på internet så finns det väääääldigt mycket att läsa!

Jag fattar inte vad du talar om. Det är ca 1/4 sida i databladet. Vadå "på internet" ?

> Och det är där som jag "läst lite löst" om det du föreslog... Men som sagt jag vet riktigt exakt hur det
> funkar jämfört med table lookup som är det jag kan hittills...

Vad är det du undrar över ? Exempel 10-3 är väl ganska tydligt ?

> så ansåg jag att det är bäst att läsa om base-line först...

Helt bortkastat, om du inte faktiskt kommer att programmera en "baseline" modell.
Annars glöm det bara, helt bortkastad tid som sagt. Å så säger du att du har
ett lite tight tidsschema...

Jag förstår nu vad du menar med det där "256 problemet", det är ett helt unikt
problem med CALL i baseline arkitekturen som du gör bäst i att glömma att ens
har läst om (om du inte faktiskt kommer att använda en baseline modell, vilket
är ganska osannolikt, i alla fall på ett bra tag).

[Scorpiion]

> Vad är det du undrar över ? Exempel 10-3 är väl ganska tydligt
Jag såg inget direkt koppling mellan det och en table lookup... (som jag trodde var mitt problem)

Kunskap är aldrig bortkastad... Så ser jag på saken iallafall, och att förstå hur base-line kretsarna fungerar från början gör det enklare att se hur mer avancerade kretsar funkar då man inte behöver tänka på så mycket på att pinnar delar massa funktioner mm... Sen i dom tutorialsena så förutsätter han lite att man har läst den första serien för base-line i midrange serien...

> Jag förstår nu vad du menar med det där "256 problemet", det är ett helt unikt
> problem med CALL i baseline arkitekturen som du gör bäst i att glömma att ens
> har läst om

Tack! Det var precis det jag ville höra! Härligt, jag misstänkte det var något som jag inte behövde tänka på men var inte så lätt att hitta svar på frågan...

Så då funkar det bra med en så pass lång tabell iallafall det var ju bra! Men jag är fortfarande lite intresserad av vad det kan finns för andra lösningar om man använder sig av en 10 bitars ADC... För det är väl kanske inte alla gånger som man behöver sån pass noggrannhet, hur brukar man göra då? En annan sak jag funderat på är hur man överhuvud taget gör eftersom värdet från ADC ligger i två register, PRESSURE_HI och PRESSURE_LO... Och W-reg rymmer 8... Hur löser man det på rekommenderat sätt?

[sodjan]

> För det är väl kanske inte alla gånger som man behöver sån pass noggrannhet, hur brukar man göra då?

Ja, du kan ju helt enkelt bara använda så många bitar som du behöver
för dina behov och strunta i bitarna "under" det. Ett vanligt sätt är nog
att bara strunta i de två lägsta bitarna så får man ett 8-bitars värde
som man kan använda vidare. Kolla bara "9.1.6 RESULT FORMATTING"
så att det blir rätt.

> En annan sak jag funderat på är hur man överhuvud taget gör eftersom värdet från
> ADC ligger i två register, PRESSURE_HI och PRESSURE_LO...

Så heter de inte. ADRESH och ADRESL heter de.
De där PRESSSURE-någonting måste vara något du har hittat på...

> Och W-reg rymmer 8... Hur löser man det på rekommenderat sätt?

Med fler-bytes mattematik. Det beror lite på vad värderna ska vara till. Hur de ska användas.
Men vill man ha hela 10-bitars upplösningen så är det bara att räkna med t.ex 16-bitars
matte. Ena byten kommer naturligstvis bara att använda 2 bitar, men alla rutiner som
man hittar är normalt för hela bytes, och det spelar ju ingen större roll.

[bearing]

Visst är det så att djupet är en linjär funktion av trycket? (om vattnets densitet kan anses konstant)

I så fall borde trycket kunna uttryckas som:
p = k*ADC + m

För att få högre upplösning på ADCn kan översampling användas. Jag brukar översampla 64 gånger, alltså 64 st 10-bitsamplingar adderas för att få en 16-bitars. Detta ger inte 16 bitars upplösning, men faktiskt upp till 13 bitar.

En fördel med 16-bitars samplingar är att de enkelt kan konverteras till önskad storhet genom endast en multiplikation.

[JimmyAndersson]

"Jag brukar översampla 64 gånger, alltså 64 st 10-bitsamplingar adderas för att få en 16-bitars. Detta ger inte 16 bitars upplösning, men faktiskt upp till 13 bitar."


Antal samplingar som krävs för att få n antal "extra bitar":
samples = 2²n

Det kräver förstås att PIC-kretsen hinner med att sampla så fort som behövs, men i det här fallet borde det vara lugnt.

[Scorpiion]

> Så heter de inte. ADRESH och ADRESL heter de.
> De där PRESSSURE-någonting måste vara något du har hittat på...

Nu börjar du låta lite gnällig... Det är klart att det är någonting som jag "hittat" på... Det är mina register som jag kopierar in värderna i... Så det är inget konstigt med det..

Hm.. Tror jag försöker köra på 8 bitar då.. Jag var inne på det tidigare men var inte riktigt hundra om man kunde göra så.. men tack för tipset ska läsa om det i databladet!

Det med översampling låter ju intressant! Dock känner jag att tiden är lite knapp nu för att börja testa med "nya" grejer... Tror jag får köra med 8 bitar istället, det "duger" till det här projektet..

EDIT: Ja det hade jag ju redan läst i databladet förstås.. Trodde det var nått jag hade missat.. Men var lite osäker på om man kunde göra så att man bara "strunar" i dom två lägsta.. Men när jag tänker på saken så borde ju det funka hur bra som helst.. tror jag.. eller är det något som man måste tänka på eller kan man bara "låtsas" att det var en 8 bitars ADC?

[sodjan]

> eller är det något som man måste tänka på eller kan man bara "låtsas" att det var en 8 bitars ADC?

Nej, det blir bara som att avrunda resultetet. Klippa ett par decimaler.
Eller hur du vill se på det. Det dynamiska "omfånget" (d.v.s min/max värde
som du kan mäta) är fortfarande detsamma fast med större "steg". Se bara till
att ställa formatteringen av resultatet så du får de 8 högsta bitarna i ett
eget register, men det är väldigt enkelt...

[Scorpiion]

Ja jag förtod det lite bättre när jag ritade upp bitarna och drog en linje för dom två sista... (ritade upp till 11011) Då kunde man se hur talen var likadana i set om 4..

Har suttit och gjort en litet python program nu som skriver ut en table åt mig för 255 värden (körde med ett fullt register och skippade två bitar). Den ser ut så här:

Kod: Markera allt

PRESSURE_TABLE   addwf     PCL,f
                          retlw       d'10'
                          retlw       d'11'
                          retlw       d'12'
                          retlw       d'13'
                          retlw       d'14'
                          retlw       d'15'
                          retlw       d'16'
                          .......

Jag funderade lite på om det är ok är göra så med d'XX' ? För om jag förståt det hela rätt så får jag då tillbaks det talen som står där fast binärt i w-reg... Är så det är tänkt.. Men jag sitter nu och klurar lite på hur jag ska få ut det på displayen.. Så här ser en del av koden ut:

Kod: Markera allt

        call                   ADC
        call                   TEMP_TABLE
        movwf               TEMP_SCREEN
        call                   PRESSURE_TABLE
        movwf               PRESSURE_SCREEN

Efter det vill jag ju få värdet på displayen, använder ju det macrot som var med i exempel filen för hd44780 och för att skicka nån text gör man ju såhär:

Kod: Markera allt

clock		data	d'1', d'12', '0', '1', ':', '1', '9', h'00'

Men jag vet inte riktigt hur man göra för att få det såhär:

Kod: Markera allt

clock		data	d'1', d'12', PRESSURE_SCREEN, h'00'

Antar att det inte funkar så som jag skrev nu men lär väl gå att skriva om på nått sätt kanske?

[bearing]

Separera Hundratal, Tiotal och Ental.