>Detta gör att *man* skulle kunna skicka ett paket som ser ut enligt följande för att fylla hela displayen med 23:45,56
>1B 21 20 20 20 20 20 20 20 20 20 20 20 20 32 33 34 35 36, notera då att den första byten efter 21 är index pekare 20 nästa 21, 22 ,23
>o.s.v.
Det jag menar är att man kan skicka från pc´n följande datastäng
1B 21 20 20 20 20 20 20 20 20 20 20 20 20 32 33 34 35 36 för att fylla displayen.
Som sagt klockan skickar inte ut en så lång datasträng, den skickar det jag skrivit tidigare.
Resultat display
Okej vi tar det från början.
Klockan skickar ut 2 olika sorters data det är åkarens tid 1B (21) och bästa tid 1B (22) och1B (23) som inte innehåller något, så långt ok.
Varje sådan grupp 21, 22 eller 23 innehåller en pekare 16 st för varje paket, paket ex. "1B 21 *32* 20 20" där *32* är pekaren.
Pekaren är då från h'20'- h'3F' alltså börjar 1B 21 med 20 som första pekare sen 22,24,26 28,2A,2C,2E,30,32,34,36,38,3A,3C,3E sen börjar ju nästa grupp som är 1B 22.
Nu innehåller ju varje paket "1B 21 32 20 20" två ASCII tecken, så jag hade räknat fel det är 32 byte per grupp(21,22 & 23).
I det här projektet är det som sagt bara datat i grupp 21 och pekarna 30-3F eller ännu exaktare 32-37.
För att förstå bättre refererar jag till protokoll pdf´n.
http://www.rodel.se/protokoll.pdf
>UJag är inte helt med på var "20" kommer ifrån i "1B 21 20...."
i dina exempel står dt 32-37 där.
1B 21 20 31 32
1B 21 22 33 20
Är start nr. för åkaren, men det har inget med detta projekt att göra men i nästa.
Vi kan glömma det där med att skicka 1B 21 20 20 20 20 20 20 20 20 20 20 20 20 32 33 34 35 36, för jag har testat att skicka datat så till den elektromekaniska displayen och då händer inget. Så vi håller oss till datat inom 30-3F.
Klockan skickar ut 2 olika sorters data det är åkarens tid 1B (21) och bästa tid 1B (22) och1B (23) som inte innehåller något, så långt ok.
Varje sådan grupp 21, 22 eller 23 innehåller en pekare 16 st för varje paket, paket ex. "1B 21 *32* 20 20" där *32* är pekaren.
Pekaren är då från h'20'- h'3F' alltså börjar 1B 21 med 20 som första pekare sen 22,24,26 28,2A,2C,2E,30,32,34,36,38,3A,3C,3E sen börjar ju nästa grupp som är 1B 22.
Nu innehåller ju varje paket "1B 21 32 20 20" två ASCII tecken, så jag hade räknat fel det är 32 byte per grupp(21,22 & 23).
I det här projektet är det som sagt bara datat i grupp 21 och pekarna 30-3F eller ännu exaktare 32-37.
För att förstå bättre refererar jag till protokoll pdf´n.
http://www.rodel.se/protokoll.pdf
>UJag är inte helt med på var "20" kommer ifrån i "1B 21 20...."
i dina exempel står dt 32-37 där.
1B 21 20 31 32
1B 21 22 33 20
Är start nr. för åkaren, men det har inget med detta projekt att göra men i nästa.
Vi kan glömma det där med att skicka 1B 21 20 20 20 20 20 20 20 20 20 20 20 20 32 33 34 35 36, för jag har testat att skicka datat så till den elektromekaniska displayen och då händer inget. Så vi håller oss till datat inom 30-3F.
>Den stämmer inte. Kollar man i den blir det bara förvirrat.
>T.ex "Efter positions talet (ex.32) kommer datat i två delar" är fel, eller hur ?
Varför är det fel, klockan skickar ut datat hela tiden.
Det vill säga den loopar ut grupperna 21, 22, 23 hela tiden även när inget finns att skicka. Då är det två *SPACE* där ASCII-tecknen skall vara.
Alltså 1B 21 32 20 20 och det som skickats är 32 och 33 i ett paket, nästa blir 1B 21 34 20 20 och är 34 och 35.
Sen när det kommer en ändring, så kan det vara längre eller kortare.
Den kan komma var som helst i loopen.
Jag kan göra en skärm dump på comports programmet så du får se vad som skickas ut från klockan.
>T.ex "Efter positions talet (ex.32) kommer datat i två delar" är fel, eller hur ?
Varför är det fel, klockan skickar ut datat hela tiden.
Det vill säga den loopar ut grupperna 21, 22, 23 hela tiden även när inget finns att skicka. Då är det två *SPACE* där ASCII-tecknen skall vara.
Alltså 1B 21 32 20 20 och det som skickats är 32 och 33 i ett paket, nästa blir 1B 21 34 20 20 och är 34 och 35.
Sen när det kommer en ändring, så kan det vara längre eller kortare.
Den kan komma var som helst i loopen.
Jag kan göra en skärm dump på comports programmet så du får se vad som skickas ut från klockan.
>Intressant är att jag just påpekade detta med positionerna och indexen i mitt förra svar...
Nä jag säger inget annat, försöker bara förklara så att alla förstår hur det hänger ihop.
>Jag angav även en metod för att lösa detta på enklaste sätt.
Ja och det är det som allt är uppbyggt på och det fungerar till viss del om du läst tidigare inlägg.
--------------------------------------------------------------------------------
Nä jag säger inget annat, försöker bara förklara så att alla förstår hur det hänger ihop.
>Jag angav även en metod för att lösa detta på enklaste sätt.
Ja och det är det som allt är uppbyggt på och det fungerar till viss del om du läst tidigare inlägg.
Kod: Markera allt
Det som fungerar är:
HEX Display
----------------------- -----------
1B 21 33 31 32 33 34 35 _1:23,45
1B 21 35 33 34 34 __:_3,45
1B 21 36 34 35 __:__,45
Men det fungerar inte att skicka:
HEX Display
----------------------- -----------
1B 21 32 31 32 12:__,__
1B 21 34 33 34 __:34,__
1B 21 37 35 __:__,_5Fungerar det att skicka "12:__:__" till det mekaniska displayen?
Som jag ser det måste sista siffern ALLTID uppdateras oavsett vad som är uppdaterat innan eller hur?
Skickas en uppdaterat tid lär det inte bara vara minuterna som är räknat upp, även 1/100'del bör vara ändrat då eller har jag fel?
Hur som helst, det är fint möjligt att mottagningsrutinen sparar talen på index-sättet och sedan har du en likadan buffer som innehåller vilka tal som visas och då i main kontinuerligt jämföra och skriva ut vid olika. Självklart sparas tecknet man skriver ut i rätt plats så att den uppdateras vid varje tecken som skrivs ut.
På detta vis kommer senaste data alltid att uppdateras i displayen direkt de kommer in oavsett i vilken ordning de kommer.
Som jag ser det måste sista siffern ALLTID uppdateras oavsett vad som är uppdaterat innan eller hur?
Skickas en uppdaterat tid lär det inte bara vara minuterna som är räknat upp, även 1/100'del bör vara ändrat då eller har jag fel?
Hur som helst, det är fint möjligt att mottagningsrutinen sparar talen på index-sättet och sedan har du en likadan buffer som innehåller vilka tal som visas och då i main kontinuerligt jämföra och skriva ut vid olika. Självklart sparas tecknet man skriver ut i rätt plats så att den uppdateras vid varje tecken som skrivs ut.
På detta vis kommer senaste data alltid att uppdateras i displayen direkt de kommer in oavsett i vilken ordning de kommer.
>Fungerar det att skicka "12:__:__" till det mekaniska displayen?
Svar ja!
>Som jag ser det måste sista siffern ALLTID uppdateras oavsett vad som är uppdaterat innan eller hur?
Svar nej, det går att uppdatera bara en siffra.
Följande siffror går att uppdatera en och en:
1B 21 36 31
1B 21 35 32
1B 21 33 34
På displayen
_ 4:_ 2,1_
Men hela dena sekvens fungerar.
1B 21 33 34 35 36 37 38
Vilket på blir displayen: _4:56:78
>Hur som helst, det är fint möjligt att mottagningsrutinen sparar talen på
>index-sättet och sedan har du en likadan buffer som innehåller vilka tal
>som visas och då i main kontinuerligt jämföra och skriva ut vid olika.
>Självklart sparas tecknet man skriver ut i rätt plats så att den uppdateras
>vid varje tecken som skrivs ut.
>På detta vis kommer senaste data alltid att uppdateras i displayen direkt
>de kommer in oavsett i vilken ordning de kommer.
Är inte riktigt med på hur du menar, föresten har du kikat på på koden som delvis fungerar.
Svar ja!
>Som jag ser det måste sista siffern ALLTID uppdateras oavsett vad som är uppdaterat innan eller hur?
Svar nej, det går att uppdatera bara en siffra.
Följande siffror går att uppdatera en och en:
1B 21 36 31
1B 21 35 32
1B 21 33 34
På displayen
_ 4:_ 2,1_
Men hela dena sekvens fungerar.
1B 21 33 34 35 36 37 38
Vilket på blir displayen: _4:56:78
>Hur som helst, det är fint möjligt att mottagningsrutinen sparar talen på
>index-sättet och sedan har du en likadan buffer som innehåller vilka tal
>som visas och då i main kontinuerligt jämföra och skriva ut vid olika.
>Självklart sparas tecknet man skriver ut i rätt plats så att den uppdateras
>vid varje tecken som skrivs ut.
>På detta vis kommer senaste data alltid att uppdateras i displayen direkt
>de kommer in oavsett i vilken ordning de kommer.
Är inte riktigt med på hur du menar, föresten har du kikat på på koden som delvis fungerar.
Kod som <nästan> fungerar är alldeles ointressant faktisk.
Jag utgår ifrån att indexeringen fungerar och data petas i allt eftersom de kommer.
Då har du alltså en buffert som uppdateras kontinuerligt i formatet:
hhmmssxxyy
Om du då gör en likadan buffer som visar vad som visas på displayen kan di bara jämföra siffer för siffer och skiljer de kopierar du det tecken från inkommande-buffern till visas-buffern och skriver ut det tecken på rätt plats.
En annan lösning kan även vara att bara skriva ut vad som står i inkommande-buffern hela tiden, detta görs i main-loop, ISR'n ser då till att ta emot tecken och peta in i rätt placering.
Jag utgår ifrån att indexeringen fungerar och data petas i allt eftersom de kommer.
Då har du alltså en buffert som uppdateras kontinuerligt i formatet:
hhmmssxxyy
Om du då gör en likadan buffer som visar vad som visas på displayen kan di bara jämföra siffer för siffer och skiljer de kopierar du det tecken från inkommande-buffern till visas-buffern och skriver ut det tecken på rätt plats.
En annan lösning kan även vara att bara skriva ut vad som står i inkommande-buffern hela tiden, detta görs i main-loop, ISR'n ser då till att ta emot tecken och peta in i rätt placering.
>Kod som <nästan> fungerar är alldeles ointressant faktisk.
Om den är ointressant är det väl lika bra att börja om?
>Jag utgår ifrån att indexeringen fungerar och data petas i allt eftersom de kommer.
Ja indexeringen fungerar och datat petas in på sina minnesplatser, har testat det i MPLAB. Så långt ok.
>Då har du alltså en buffert som uppdateras kontinuerligt i formatet:
hhmmssxxyy
Det är en minnes plats för varje siffra
och formatet hhmmssxx
>Om du då gör en likadan buffer som visar vad som visas på displayen
>kan di bara jämföra siffer för siffer och skiljer de kopierar du det tecken
>från inkommande-buffern till visas-buffern och skriver ut det tecken på rätt plats.
Likadan hur menar du? Att det som kommer in på den första kopieras till den andra eller? Förstår inte riktigt meningen med det.
>En annan lösning kan även vara att bara skriva ut vad som står i inkommande-buffern hela tiden,
>detta görs i main-loop, ISR'n ser då till att ta emot tecken och peta in i rätt placering.
Om jag inte är helt vilse i pannkakan, så är det så koden är skriven nu.
Om den är ointressant är det väl lika bra att börja om?
>Jag utgår ifrån att indexeringen fungerar och data petas i allt eftersom de kommer.
Ja indexeringen fungerar och datat petas in på sina minnesplatser, har testat det i MPLAB. Så långt ok.
>Då har du alltså en buffert som uppdateras kontinuerligt i formatet:
hhmmssxxyy
Det är en minnes plats för varje siffra
Kod: Markera allt
digit_0 res 1
digit_1 res 1
digit_2 res 1
o.s.v>Om du då gör en likadan buffer som visar vad som visas på displayen
>kan di bara jämföra siffer för siffer och skiljer de kopierar du det tecken
>från inkommande-buffern till visas-buffern och skriver ut det tecken på rätt plats.
Likadan hur menar du? Att det som kommer in på den första kopieras till den andra eller? Förstår inte riktigt meningen med det.
>En annan lösning kan även vara att bara skriva ut vad som står i inkommande-buffern hela tiden,
>detta görs i main-loop, ISR'n ser då till att ta emot tecken och peta in i rätt placering.
Om jag inte är helt vilse i pannkakan, så är det så koden är skriven nu.
Så nu har jag testat att göra en till buffer, som kollar om det uppdaterats i inkommande och i så fall kopierar över det till vissa buffern.
Men det är precis samma som innan.
Har även att skicka inkommande data direkt till displayen men det är samma.
Så felet måste ligga i koden i ISR.
Men koden i ISR har jag test kört i MPLAB och där fungerar det.
Allså 1B 21 34 20 20 lägger upp 20 20 på rätt platser i minnet.
Så då är frågan vad kan vara fel?
Men det är precis samma som innan.
Har även att skicka inkommande data direkt till displayen men det är samma.
Så felet måste ligga i koden i ISR.
Men koden i ISR har jag test kört i MPLAB och där fungerar det.
Allså 1B 21 34 20 20 lägger upp 20 20 på rätt platser i minnet.
Så då är frågan vad kan vara fel?
Så efter en grundlig felsökning har jag tillslut hittat felet och det har med avläsningen av serialdatat.
Displayen fungerar klockrent, om man har följande inställningar.
2400B, 7bit, Parity Space
2400B, 8bit, Parity No
Man alltså *inte* 2400B, 7bit, Parity Even som tidtagningen skickar datat.
Det är felet till att den inte fungerar på vissa tecken.
Displayen fungerar klockrent, om man har följande inställningar.
2400B, 7bit, Parity Space
2400B, 8bit, Parity No
Man alltså *inte* 2400B, 7bit, Parity Even som tidtagningen skickar datat.
Det är felet till att den inte fungerar på vissa tecken.
