Hej!
Jag ska (på en PIC12F683) avkoda en signal som kommer i Miller format. Det kallas visst även MFM i floppy sammanhang och Delay i telefonsammanhang.
Men har lite problem med att göra det så smart och snabbt som möjligt. Nu kollar jag på att använda en timer och ett interrupt på flank på en pinne och beroende på tiderna så blir det olika utdata, men har inte fått det att fungera än.
Har suttit flera timmar på google men hittar inget konkret, någon som har erfarenhet av detta eller vet var man kan hitta information?
Miller/MFM/Delay-avkodning
Avkodning av Miller kod är det det gäller.
Hur det ser ut vet jag, beskrivning finns på http://en.wikipedia.org/wiki/Delay_encoding.
Enkelt sett så kommer datan i tre olika tidsperioder
1T = nästa bit är samma som förra
1.5T och förra var 0 = 1
1.5T och förra var 1 = 00
2T = 01
Mitt problem är hur jag gör detta så snabbt som möjligt. Kör för tillfället på 8MHz intern klocka och kortaste tidsperioden (T) mellan två flanker är ~38µs vilket ger ~76 clockcykler, säg 70 för att vara på säkra sidan. Och på dessa ska jag hinna läsa av timer, byta interrupt flank, avgöra om periodtiden är T, 1.5T eller 2T och placera in lästa biten i ett 64bitars register, och säkert en del till jag inte minns just nu.
För tillfället använder jag flaggan på flank på INT-pinnen, problemet är att det inte är så exakt som jag vill ha det, vid manuell pollning så blir avlästa tiden för T antingen 0x41 eller 0x44, likadant med 1.5T och 2T, det blir antingen två värden som skilljer med 3. Detta är väl pga den manuella pollningen.
Om jag kör med interrupt, dvs hopp till 0x0004 så är det även här lite vajsning med tiden vilket det även står i databladet, det kan ta 4 eller 5 instruktioner vid triggning på INT-pinnen.
Så vad finns det mer för allternativ tro för att få det exakt? Skulle iofs kunna kolla alla sex värdena (T, T+3, 1.5T, 1.5T+3, 2T, 2T+3) men det känns fullt
Hur det ser ut vet jag, beskrivning finns på http://en.wikipedia.org/wiki/Delay_encoding.
Enkelt sett så kommer datan i tre olika tidsperioder
1T = nästa bit är samma som förra
1.5T och förra var 0 = 1
1.5T och förra var 1 = 00
2T = 01
Mitt problem är hur jag gör detta så snabbt som möjligt. Kör för tillfället på 8MHz intern klocka och kortaste tidsperioden (T) mellan två flanker är ~38µs vilket ger ~76 clockcykler, säg 70 för att vara på säkra sidan. Och på dessa ska jag hinna läsa av timer, byta interrupt flank, avgöra om periodtiden är T, 1.5T eller 2T och placera in lästa biten i ett 64bitars register, och säkert en del till jag inte minns just nu.
För tillfället använder jag flaggan på flank på INT-pinnen, problemet är att det inte är så exakt som jag vill ha det, vid manuell pollning så blir avlästa tiden för T antingen 0x41 eller 0x44, likadant med 1.5T och 2T, det blir antingen två värden som skilljer med 3. Detta är väl pga den manuella pollningen.
Om jag kör med interrupt, dvs hopp till 0x0004 så är det även här lite vajsning med tiden vilket det även står i databladet, det kan ta 4 eller 5 instruktioner vid triggning på INT-pinnen.
Så vad finns det mer för allternativ tro för att få det exakt? Skulle iofs kunna kolla alla sex värdena (T, T+3, 1.5T, 1.5T+3, 2T, 2T+3) men det känns fullt
Lägg ett intervall. T.ex:
T-10 < tid < T+10 betyder 1T
1,5T-10 < tid < 1,5T+10 betyder 1,5T
2T-10 < tid < 2T+10 betyder 2T
Det tycker inte jag är fult. Är signalen verkligen så stabil att du borde kunna få ett exakt värde varje gång?
T-10 < tid < T+10 betyder 1T
1,5T-10 < tid < 1,5T+10 betyder 1,5T
2T-10 < tid < 2T+10 betyder 2T
Det tycker inte jag är fult. Är signalen verkligen så stabil att du borde kunna få ett exakt värde varje gång?
Senast redigerad av bearing 18 april 2006, 18:46:03, redigerad totalt 1 gång.
Wikipedias beskrivning var inte mycket att ha, men behöver
timing diagram för att se det tydligt...
Bearing har naturligtsvis rätt i att du inte ska testa mot
diskreta värden, eftersom de (som du har upptäckt) kommer
att ha lite jitter.
Jag skulle testköra lite och se vilka timervärden man får, sedan se
om man inte med en eller ett par bit-tester på timer värdet kan
avgöra vilken puls-typ det var.
När det gäller fördröjningen kanske du kan mäta med capture enheten ?
Då sker det i hårdvaran istället för i din kod.
> Så vad finns det mer för allternativ tro för att få det exakt?
Det varken går eller är nödvändigt. Det räcker med att du säkert kan
avgöra vilkan puls det var.
Eftersom signalens källa och processorns klocka inte är synkroniserande,
så måste lösning alltid kunna hantera gränslägen där det avlästa värdet
ligger och pendlar mellan ett par värden.
Vad gör processorn mer under själva avläsningen ? Kan man tillåta att
processorn är helt upplåst av detta ? En "brute force" lösning skulle
kunna vara något i stil med :
(Antag att det just har varit en flank)
- åteerställ interrupt, flank m.m.
- sätt en flagga "1T"
- delay ca 1.25 T
- sätt en flagga "1.5T"
- delay ca 0.5 T (nu framme vid ca 1.75 T)
- sätt en flagga "2T"
- delay ca xxx T
- sätt flagga "overrun"
Sedan i ISR'en behöver du bara kolla vilken flagga som
är satt och beräkna vilken/vilka bitar som ska in i shiftregistret.
Delayerna ovan kan (om du har plats) helt enkelt vara en rad med NOPs.
Slutligen,
> ~38µs vilket ger ~76 clockcykler,
Ska vara 76 *instruktions* cykler. Vilket är = 304 *klock* cykler...
timing diagram för att se det tydligt...
Bearing har naturligtsvis rätt i att du inte ska testa mot
diskreta värden, eftersom de (som du har upptäckt) kommer
att ha lite jitter.
Jag skulle testköra lite och se vilka timervärden man får, sedan se
om man inte med en eller ett par bit-tester på timer värdet kan
avgöra vilken puls-typ det var.
När det gäller fördröjningen kanske du kan mäta med capture enheten ?
Då sker det i hårdvaran istället för i din kod.
> Så vad finns det mer för allternativ tro för att få det exakt?
Det varken går eller är nödvändigt. Det räcker med att du säkert kan
avgöra vilkan puls det var.
Eftersom signalens källa och processorns klocka inte är synkroniserande,
så måste lösning alltid kunna hantera gränslägen där det avlästa värdet
ligger och pendlar mellan ett par värden.
Vad gör processorn mer under själva avläsningen ? Kan man tillåta att
processorn är helt upplåst av detta ? En "brute force" lösning skulle
kunna vara något i stil med :
(Antag att det just har varit en flank)
- åteerställ interrupt, flank m.m.
- sätt en flagga "1T"
- delay ca 1.25 T
- sätt en flagga "1.5T"
- delay ca 0.5 T (nu framme vid ca 1.75 T)
- sätt en flagga "2T"
- delay ca xxx T
- sätt flagga "overrun"
Sedan i ISR'en behöver du bara kolla vilken flagga som
är satt och beräkna vilken/vilka bitar som ska in i shiftregistret.
Delayerna ovan kan (om du har plats) helt enkelt vara en rad med NOPs.
Slutligen,
> ~38µs vilket ger ~76 clockcykler,
Ska vara 76 *instruktions* cykler. Vilket är = 304 *klock* cykler...
Bearing: Signalen är stabil men RC-oscillatorn i picen är det inte. Provade att testa timern på 2MHz och den diffade upp till 10 enheter mellan kroppstemperatur (min handflata) och sprayad med kylspray. Usch och fy 
Sodjan: På grund av att jag lite målat in mig i ett hörn sitter jag för tillfället fast på <=14pin pic (PICkit1 labkortet, eller vad det nu heter) och där finns ingen 14pins pic med allt det jag behöver och CCP enhet. Men vid behov får jag väl köra med t.ex. 16F88 och ICD2.
Tack så mycket för "brute force" lösningen, det ser lovande ut. Har inte använt assembly så mycket innan och har lite svårt för att vänja mig vid interrupt där. Ska prova detta nu.
Sodjan: På grund av att jag lite målat in mig i ett hörn sitter jag för tillfället fast på <=14pin pic (PICkit1 labkortet, eller vad det nu heter) och där finns ingen 14pins pic med allt det jag behöver och CCP enhet. Men vid behov får jag väl köra med t.ex. 16F88 och ICD2.
Tack så mycket för "brute force" lösningen, det ser lovande ut. Har inte använt assembly så mycket innan och har lite svårt för att vänja mig vid interrupt där. Ska prova detta nu.
> Usch och fy...
Det är inte helt tydligt vad du har upptäckt som aviker från
vad som är specat i databladet. Kan du förtydliga.
> där finns ingen 14pins pic med allt det jag behöver och CCP enhet.
Nu förstår jag inte vad du yrar om !
Du skrev ju "Jag ska (på en PIC12F683) avkoda en signal", eller hur ?
I alla fall enligt *min* kopia på databladet finns det med en CCP enhet.
Varför tror du att jag nämnde den alls ???
Du kanske skulla ta och plocka fram ditt datablad du med...
> Har inte använt assembly så mycket innan och har lite svårt för att
> vänja mig vid interrupt där. Ska prova detta nu.
Ska prova vadå ??
Menar du att du har försökt få till detta med *något annat* än ASM ??
Det är inte helt tydligt vad du har upptäckt som aviker från
vad som är specat i databladet. Kan du förtydliga.
> där finns ingen 14pins pic med allt det jag behöver och CCP enhet.
Nu förstår jag inte vad du yrar om !
Du skrev ju "Jag ska (på en PIC12F683) avkoda en signal", eller hur ?
I alla fall enligt *min* kopia på databladet finns det med en CCP enhet.
Varför tror du att jag nämnde den alls ???
Du kanske skulla ta och plocka fram ditt datablad du med...
> Har inte använt assembly så mycket innan och har lite svårt för att
> vänja mig vid interrupt där. Ska prova detta nu.
Ska prova vadå ??
Menar du att du har försökt få till detta med *något annat* än ASM ??
Varför skulle det inte funka med C?sodjan skrev:Menar du att du har försökt få till detta med *något annat* än ASM ??
Enligt min erfarenhet kan man - om man vet vad man gör - skriva C-kod som bara ger någon enstaka instruktion mer per 100 instruktioner jämfört med motsvarande assemblerkod. (I alla fall om man har en bra kompilator.)
> "...om man vet vad man gör..."
> "...I alla fall om man har en bra kompilator..."
Jo, kanske det...
Men det är inte lite du kräver...
*Personligen* verkar C lite over-kill på detta problem.
Och sannlikt får man skriva det ganska "asm-likt" i alla fall, så
eventuella fördelar med C (eller något annat) blir ganska små.
Det är ju ganska "tajt" timing i problemet, så lite ASM kod är
lättare att ha "kontroll" över.
Hur som helst, det jag *igentligen* reagerade över var att
*om* det nu var något annat än ASM som hade använts,
så borde det ha nämnts i första inlägget...
> "...I alla fall om man har en bra kompilator..."
Jo, kanske det...
Men det är inte lite du kräver...
*Personligen* verkar C lite over-kill på detta problem.
Och sannlikt får man skriva det ganska "asm-likt" i alla fall, så
eventuella fördelar med C (eller något annat) blir ganska små.
Det är ju ganska "tajt" timing i problemet, så lite ASM kod är
lättare att ha "kontroll" över.
Hur som helst, det jag *igentligen* reagerade över var att
*om* det nu var något annat än ASM som hade använts,
så borde det ha nämnts i första inlägget...
Sodjan: Med Usch och fy menade jag att det är tråkigt att världen inte är perfekt 
Upptäckt att man kan bli lite virrig när man sitter och skriver assembler hela dagarna så jag skriver ekvivalent virrigt kanske. För debug-möjligheter använder jag för tillfället 16F688 och dess uart. Slutligen ska det färdiga programmet ner i en 12F683. Då skulle jag kunna använda CCPn men för tillfället blir det inte så. Nu i efterhand så hade nog en ICD2 varit det bästa, kan man tänka.
Angående språket så har jag gjort hela detta projektet i assembly, och det är det första där jag inte använder C. Det jag skulle prova var ditt förslag. Det blev en liten variant av det och det fungerar klockrent nu, även vid högre och lägre temperaturer
Bearing: Att sitta och flippa bitar hit och dit på detta sättet i C skulle nog garanterat resultera i tokigt klyddig och svårläst kod. Måste säga att det ger en härlig tillfredsställelse i själen av att skriva bra assembly
Upptäckt att man kan bli lite virrig när man sitter och skriver assembler hela dagarna så jag skriver ekvivalent virrigt kanske. För debug-möjligheter använder jag för tillfället 16F688 och dess uart. Slutligen ska det färdiga programmet ner i en 12F683. Då skulle jag kunna använda CCPn men för tillfället blir det inte så. Nu i efterhand så hade nog en ICD2 varit det bästa, kan man tänka.
Angående språket så har jag gjort hela detta projektet i assembly, och det är det första där jag inte använder C. Det jag skulle prova var ditt förslag. Det blev en liten variant av det och det fungerar klockrent nu, även vid högre och lägre temperaturer
Bearing: Att sitta och flippa bitar hit och dit på detta sättet i C skulle nog garanterat resultera i tokigt klyddig och svårläst kod. Måste säga att det ger en härlig tillfredsställelse i själen av att skriva bra assembly
