Avbruten ADC

[lillahuset]

Då tycker jag du ska formulera om frågan i ett nytt inlägg.

Och jo, sodjan är hjälpsam men emellanåt lite vrång. Och det är bara mänskligt tycker jag.

[sodjan]

Såja såja...

Ja, det var två olika modeller som figurerade i tråden och jag tog den som
hade varit med senast. Just då reflekterade jag inte över att det var en
annan modell i början av tråden. Jag svarade helt enkelt på ditt inlägg
från "02-apr-2016 14:38" och inget annat. Varför du tog en helt annan
modell som exempel förstår jag inte, den tabell som du refererar till är
på i princip samma ställe i båda databladen.

Hur som helst, funktionen vid en avbrott av en konvertering är
uppenbarligen lite ändrad. Frågan är dock om det är tillförlitligt.
Och varför vill du avbryta i förtid? Om du har bråttom så kan du ju
köra snabbare, att det ligger utanför "recommended range" kommer
sannolikt mest att påverka de lägre bitarna. Du kan ju jämföra bitarna
från en långsam/avbruten körning med en snabbare/komplett dito.

[lillahuset]

Som sagt, hjälpsam.

[Erik M]

Det går inte att samla in snabbare än 1us per bit (PIC12F1572), inte inom de säkra parametrar som anges.

Varför jag tycker mig behöva göra detta är egentligen av föga intresse, frågan om det går göra är vad som är aktuellt.

Men för att ge lite av anledningen...

Jag skall göra sisådär fem - sex ADC, två primära och minst tre sekundära, innan ett beslut ska tas. Detta bör ske flera gånger inom 100us.

Om varje ADC tar 10us (plus ställtider etc) så är vi raskt uppe i över 50us, och får således endast in ett beslut inom given tidsram.


Jag kan för allt i världen göra detta i flera omgångar, dela upp så att de två primära tas tillsammans med en sekundär i taget.
Typ...
Sek1 Pri1 Pri2 Beslut
Sek2 Pri1 Pri2 Beslut
Sek3 Pri1 Pri2 Beslut
Sek4 Pri1 Pri2 Beslut
...etc.

Just denna gång kan jag möjligen göra så, men frågan kvarstår.
Och det blir ändå knappt om antal beslut per period.

Om cykeln är 1us ändras givetvis värdet på ADC_ON till vad som passar då.
Sedan skall det, givetvis, till en avrundning på ADRESH:ADRESL, för att behålla de senaste bitarna. De man ska använda. Typ MOVLW b'11110000' // ADDWF ADRESH, W för att erhålla ADRES<9:6>.
Åsså passade jag på rätta ett slarvfel i kodsnuttarna.

[sodjan]

Du får nog som sagt göra en del praktiska tester och se om du får stabila resultat.
När du frågar om det går att göra som du föreslår så beror det ju på vad du menar
med "att det går". Du får kanske en uppdatering av de höga bitarna, men är de stabila?
Om det är gissningar du vill ha, så skulle jag gissa att ja, det bör nog fungera...

[lillahuset]

Jag valde PIC efter egenskaper, det sodjan tar upp är inte relevant. Framförallt inte efter mitt förtydligande.

Och svaret står inte i databladet, vilket jag bevisligen läst.

Jaha, så pass. Svaren står i databladet och du har valt fel processor. Så enkelt är det. Eller också, om du absolut vill använda den här processorn, får du väl ändra kravspecen. Det är så det funkar i verkliga livet. Det är bara när mamma är med det hjälper att skrika jag vill jag vill haaaaaa.

[Erik M]

(lillahuset, vad pratar du egentligen om?
Inget om vad som avhandlas i denna tråd iallafall, det är ett som är säkert.
Att du sedan hyfsat genomgående uttrycker dig generande ohyfsat hjälper inte till.)

Janne, det är sällan man arbetar med annat än, mer eller mindre, kvalificerade gissningar.

Och när de som vanligen har tur med sina gissningar diskuterar så blir det allt som oftast ett fungerande resultat.

Och nu har både du å jag tittat på och diskuterat om detta, och båda kommit fram till att det troligen fungerar. Suveränt samarbetat helt enkelt!

[sodjan]

Va bra... Sen så kanske det är så att det du egentligen
behöver är en processor med en snabbare ADC så att
du kan göra "rätt" från början...

[Erik M]

Fast när du säger så blir det lite konstigt.
Hastigheten på processorn inverkar väldigt lite, tycker jag mig ha funnit.
Det är väl tiden för urladdning det hänger på?
Dvs det spelar ingen roll om processorn ställs att gå på 32MHz eller 500kHz, omvandlingstiden är den samma oavsett.
Men visst - PIC12F683 omvandlar på 2us eller 4us per bit medan PIC12F1572 även klarar göra det på 1us.
(Åsså lite udda andra värden i båda fallen som kan tas med men inte har någon direkt inverkan.)

Men om jag sedan läser EXAKT vad du skriver så står det inte riktigt som jag tolkar det ovan.
Du menar att jag ska hitta en PIC, inte egentligen en processor som så, som omvandlar kvickare än övriga.
Korrekt?

[hcb]

Ja, så tolkar jag sodjans svar, och i den kontexten är PIC==processor.


ErikM>Varför jag tycker mig behöva göra detta är egentligen av föga intresse, frågan om det går göra är vad som är aktuellt.

Jag håller inte alls med. All erfarenhet pekar på att frågor som innehåller en bra beskrivning av _vad man vill uppnå_ får bättre svar än frågor som enbart handlar om problem i en befintlig lösning.

[sodjan]

Jag skrev "snabbare ADC" (som du senare upptäckte).
Det kan vara externa ADC eller en helt annan processor.

Jag har inga synpunkter på vad du väljer, men det du
nu försöker köra med räcker uppenbarligen inte riktigt till
(vad det nu är som du tänker göra...).

PIC24 finns med 1.1 M omvandlingar per sek och dsPIC33
med upp till 10 M omvandlingar per sek.

> Ja, så tolkar jag sodjans svar, och i den kontexten är PIC==processor.

Inte alls. Jag bara konstaterade att den valda hårdvaran inte räcker till.
Jag har inga som helst synpunkter på vad man använder...

[lillahuset]

(lillahuset, vad pratar du egentligen om?
Inget om vad som avhandlas i denna tråd iallafall, det är ett som är säkert.
Att du sedan hyfsat genomgående uttrycker dig generande ohyfsat hjälper inte till.)

OK, din åsikt kan jag leva med. Rör mig inte i ryggen. Lycka till.

[Erik M]

Då tillkommer en parameter, som iofs kan anas med de PIC som figurerat hittills, och det är storlek på PIC. SO-8 är att föredra.
Och den enda anledningen till detta är det uppkomna förslaget att leta reda på en PIC med kvickare ADC omvandling.
Priset på en dylik PIC är givetvis oxå en faktor.

[Magnus_K]

Skulle en 12F1840 fungera bättre?

[Erik M]

Inte som jag kan se direkt, Magnus.
Den har väl samma omvandling som 12F1572, eller vad tänkte du på?