Funderingar kring USART och PIC16F887
Re: Funderingar kring USART och PIC16F887
OK, det låter ju inte speciellt mycket...
(1) Läs in ett paket om 3 tecken.
(2) Analysera paketet och gör det som ska göras.
- Om inte tecken 1 = h'BF', gå till (1) och gör om.
- Bit 2:0 av tecken 2 är "kanal". -----xxx
- Bit 5 av tecken 3 är på/av. -x------, alltså 01000000 - 01111111
(3) Gör om igen från (1)
Hur vet man vad som är första tecken i 3-teckens paketet ?
Enklast är kanske att vänta på en h'BF' och först då spara de
två följande tecknen. Alltså lite justering av ovanstående :
(1) Läs in ett tecken.
- Om inte = h'BF' gå till (1)
(2) Läs in två tecken (tecken 2 och 3)
- Bit 2:0 av tecken 2 är "kanal". -----xxx
- Bit 5 av tecken 3 är "på/av". -x------, alltså 01000000 - 01111111
(3) Gör om igen från (1)
(1) Läs in ett paket om 3 tecken.
(2) Analysera paketet och gör det som ska göras.
- Om inte tecken 1 = h'BF', gå till (1) och gör om.
- Bit 2:0 av tecken 2 är "kanal". -----xxx
- Bit 5 av tecken 3 är på/av. -x------, alltså 01000000 - 01111111
(3) Gör om igen från (1)
Hur vet man vad som är första tecken i 3-teckens paketet ?
Enklast är kanske att vänta på en h'BF' och först då spara de
två följande tecknen. Alltså lite justering av ovanstående :
(1) Läs in ett tecken.
- Om inte = h'BF' gå till (1)
(2) Läs in två tecken (tecken 2 och 3)
- Bit 2:0 av tecken 2 är "kanal". -----xxx
- Bit 5 av tecken 3 är "på/av". -x------, alltså 01000000 - 01111111
(3) Gör om igen från (1)
Re: Funderingar kring USART och PIC16F887
Enklast är kanske att vänta på en h'BF' och först då spara de
två följande tecknen.
Det låter ju vettigt.
0xBF ska vara ett kriterie för att byte 2 och 3 ska få behandlas/användas eller hur man vill uttrycka det.
Sen är jag inte riktigt säker på om du har tolkat min förklaring rätt när det gäller byte 2 och 3.
Eller så kanske jag helt enkelt inte förstår hur du menar.
För säkerhets skull, kolla in detta dokument:
Botten på sidan 2 - "MIDI Data Format", t.o.m. sidan 4.
http://www.ziaspace.com/MTC191/handouts ... otocol.pdf
På sidan 4 under "MIDI command set" ser man hur det ska vara för Control Change (dock skrivet som Continous controller i detta dokument).
två följande tecknen.
Det låter ju vettigt.
0xBF ska vara ett kriterie för att byte 2 och 3 ska få behandlas/användas eller hur man vill uttrycka det.
Sen är jag inte riktigt säker på om du har tolkat min förklaring rätt när det gäller byte 2 och 3.
Eller så kanske jag helt enkelt inte förstår hur du menar.
För säkerhets skull, kolla in detta dokument:
Botten på sidan 2 - "MIDI Data Format", t.o.m. sidan 4.
http://www.ziaspace.com/MTC191/handouts ... otocol.pdf
På sidan 4 under "MIDI command set" ser man hur det ska vara för Control Change (dock skrivet som Continous controller i detta dokument).
Senast redigerad av spufuz 25 december 2009, 14:57:08, redigerad totalt 1 gång.
Re: Funderingar kring USART och PIC16F887
Snyggast kanske for en finite state machine, kan enkelt förverkligas med ej hopptabell, dvs i pseudokod:
Snurra:
Vänta på tecken
Gå till "state"
State_Vantar på BF:
Om tecken != BF gå till snurra
State = vantar på första
gå till Snurra
State_vantar på första:
Spara första
State = vantar på andra
gå till snurra
State vantar på andra;
Spara andra
State = vantar på BF
gå till snurra
Snurra:
Vänta på tecken
Gå till "state"
State_Vantar på BF:
Om tecken != BF gå till snurra
State = vantar på första
gå till Snurra
State_vantar på första:
Spara första
State = vantar på andra
gå till snurra
State vantar på andra;
Spara andra
State = vantar på BF
gå till snurra
Re: Funderingar kring USART och PIC16F887
> Eller så kanske jag helt enkelt inte förstår hur du menar.
Det verkar så. Jag vet inte vad jag ska göra åt det...
Det verkar så. Jag vet inte vad jag ska göra åt det...

Re: Funderingar kring USART och PIC16F887
Måste reda ut ett par saker bara...
Är 'tecken' för dig vad jag kallar 'byte'?
"- Bit 5 av tecken 3 är på/av. -x------, alltså 01000000 - 01111111"
Du markerar bit6?
Om så är fallet, så ligger "kanal" i de första 4 bitarna (x) i tecken 1. '0000xxxx'
Hela tecken 2 (byte2) är ju avsett för vilken controller jag ska styra i GCXen.
t.ex. controller #81 = '1010001'
Om men sen i tecken 3 (byte3) tar emot ett tal/värde mellan 0 och 63 så ska utgången bli satt låg resp. hög ifall man tar emot en byte som har decimala värdet mellan 64 och 127.
Ber om ursäkt om detta är solklart för dig och jag inte förstått hur du menar i ditt exempel.
Är 'tecken' för dig vad jag kallar 'byte'?
"- Bit 5 av tecken 3 är på/av. -x------, alltså 01000000 - 01111111"
Du markerar bit6?
Om så är fallet, så ligger "kanal" i de första 4 bitarna (x) i tecken 1. '0000xxxx'
Hela tecken 2 (byte2) är ju avsett för vilken controller jag ska styra i GCXen.
t.ex. controller #81 = '1010001'
Om men sen i tecken 3 (byte3) tar emot ett tal/värde mellan 0 och 63 så ska utgången bli satt låg resp. hög ifall man tar emot en byte som har decimala värdet mellan 64 och 127.
Ber om ursäkt om detta är solklart för dig och jag inte förstått hur du menar i ditt exempel.
Re: Funderingar kring USART och PIC16F887
OK, jag kanske hade blandat ihop "kanal" och "controller". Men det ser du nog.
Du skrev :
> Data Byte 1 = 0x50 - 0x57
Och att de tre lägsta bitarna h'00' - h'07' är "controller", OK ?
Därför markerade jag de 3 lägsta bitarna.
*Om* man även måste kolla att hela värdet ligger inom rätt
intervall (h'50' - h'57') så blir det ett par instruktioner till (en AND
och en XOR om jag tänker rätt).
Byte/tecken 3 verkar vi dock vara överens om. Fast jag skrev lite fel, det ska vara :
"- Bit 6 av tecken/byte 3 är på/av. -x------, alltså 01000000 - 01111111"
Om bit 6 är "1" så ska det stängas "av", om den är "0" så ska det sättas "på".
Eller om det är tvärtom, men det är ju inte viktigt för principen skull...
Bättre så ?
> i de första 4 bitarna
Används helst inte begreppen "första" resp "sista" om bitarna, det
är inte tydligt/självklart vad det betyder. Lägsta och högsta är bättre.
Du skrev :
> Data Byte 1 = 0x50 - 0x57
Och att de tre lägsta bitarna h'00' - h'07' är "controller", OK ?
Därför markerade jag de 3 lägsta bitarna.
*Om* man även måste kolla att hela värdet ligger inom rätt
intervall (h'50' - h'57') så blir det ett par instruktioner till (en AND
och en XOR om jag tänker rätt).
Byte/tecken 3 verkar vi dock vara överens om. Fast jag skrev lite fel, det ska vara :
"- Bit 6 av tecken/byte 3 är på/av. -x------, alltså 01000000 - 01111111"
Om bit 6 är "1" så ska det stängas "av", om den är "0" så ska det sättas "på".
Eller om det är tvärtom, men det är ju inte viktigt för principen skull...
Bättre så ?
> i de första 4 bitarna
Används helst inte begreppen "första" resp "sista" om bitarna, det
är inte tydligt/självklart vad det betyder. Lägsta och högsta är bättre.
Re: Funderingar kring USART och PIC16F887
OK, jag kanske hade blandat ihop "kanal" och "controller". Men det ser du nog.
Ok då är jag med.
Och att de tre lägsta bitarna h'00' - h'07' är "controller", OK ?
Nej jag tror inte att vi ska behöva kolla mer än de tre första bitarna.
Blir det enklare att lösa så, så kör vi på det.
Byte/tecken 3 verkar vi dock vara överens om.
Jag översatta hexadecimalerna till binära tal och då förstog jag hur du tänker.
Ser nu att 6e biten blir ju 0 så länge man får 0-63 och alltid hög mellan 64-127.
Det är ju perfekt.
Ground Controlen skickar ut 0x00 (0) för att slå av ett relä och 0x7F (127) för att slå på.
Genom att känna av bit 6 som du beskriver så funkar ju teoretiskt alla tal mellan 0-63 resp. 64-127.
Perfekt i fall nån bit skulle "bli fel" på vägen va?
Då är ju allt solklart.
Blev lite förvirrad först med förväxlingen av "kanal" och "kontroller".
Så vad säger du?
Tar du på dig jobbet?
Ok då är jag med.
Och att de tre lägsta bitarna h'00' - h'07' är "controller", OK ?
Nej jag tror inte att vi ska behöva kolla mer än de tre första bitarna.
Blir det enklare att lösa så, så kör vi på det.
Byte/tecken 3 verkar vi dock vara överens om.
Jag översatta hexadecimalerna till binära tal och då förstog jag hur du tänker.
Ser nu att 6e biten blir ju 0 så länge man får 0-63 och alltid hög mellan 64-127.
Det är ju perfekt.
Ground Controlen skickar ut 0x00 (0) för att slå av ett relä och 0x7F (127) för att slå på.
Genom att känna av bit 6 som du beskriver så funkar ju teoretiskt alla tal mellan 0-63 resp. 64-127.
Perfekt i fall nån bit skulle "bli fel" på vägen va?
Då är ju allt solklart.
Blev lite förvirrad först med förväxlingen av "kanal" och "kontroller".

Så vad säger du?
Tar du på dig jobbet?
Re: Funderingar kring USART och PIC16F887
> Ser nu att 6e biten blir ju 0 så länge man får 0-63 och alltid hög mellan 64-127.
> Det är ju perfekt.
Japp, med lite vana ser man det direkt oavsett om det är binärt, hex eller decimalt.
> Ground Controlen skickar ut 0x00 (0) för att slå av ett relä och 0x7F (127) för att slå på.
Right, du ser hur svårt det är. Så där beskrev du inte alls det förrut. *Om* det är
så som du beskriver det *nu*, så kan man naturligsvis även bara kolla om värdet
är lite med noll (eller inte). Bit-6-testen fungerar dock alltid om det är dom du beskrev
först (men även om det *bara* är värderna h'00' och h'7F' som kan förekomma).
> Tar du på dig jobbet?
Jag ? Jag hoppas att det inte verkade så. Nej, absolut inte.
> Det är ju perfekt.
Japp, med lite vana ser man det direkt oavsett om det är binärt, hex eller decimalt.

> Ground Controlen skickar ut 0x00 (0) för att slå av ett relä och 0x7F (127) för att slå på.
Right, du ser hur svårt det är. Så där beskrev du inte alls det förrut. *Om* det är
så som du beskriver det *nu*, så kan man naturligsvis även bara kolla om värdet
är lite med noll (eller inte). Bit-6-testen fungerar dock alltid om det är dom du beskrev
först (men även om det *bara* är värderna h'00' och h'7F' som kan förekomma).
> Tar du på dig jobbet?
Jag ? Jag hoppas att det inte verkade så. Nej, absolut inte.
Re: Funderingar kring USART och PIC16F887
Jag ? Jag hoppas att det inte verkade så.
Nej, jag ställde en enkel fråga om du vill skriva koden.
Fick svar. Tack ändå.
Någon annan?
PMa eller maila mig och kom med ett prisförslag.
Nej, jag ställde en enkel fråga om du vill skriva koden.
Fick svar. Tack ändå.
Någon annan?
PMa eller maila mig och kom med ett prisförslag.