Svenska ElektronikForumet

Då gör vi ett nytt försök idag.

Okej, då går vi tillbaka och kör all hantering av inkommande tecken i ISR´n.

En fråga är det möjligt att rensa hela rx_buffern på något enkelt sätt?

> En fråga är det möjligt att rensa hela rx_buffern på något enkelt sätt?

Vad menar du med "rensa" ?
Alla register måste alltid innehålla *något*. De kan aldrig innehålla "inget"...
Spelar det någon roll vad det är ?

"Nollställningen" sker ju annars av att pekaren (FSR) till bufferten
ställs tillbaka till början av bufferten.

När ett register är tomt innehåller väl det 00.

>"Nollställningen" sker ju annars av att pekaren (FSR) till bufferten ställs tillbaka till början av bufferten.

Sätts då alla positioner till 00 i buffern (rx_buffer 1-5).?

>Spelar det någon roll vad det är ?
Ja om man skall göra en koll om registret innehåller en ett specifikt tecken, så det inte ligger kvar efter en reset *Då spelar det någon roll*.

> När ett register är tomt innehåller väl det 00.

Nej. Det innehåller just h'00'. Ett register kan*ALDRIG* vara tomt !!!
Inte under några som helst omständigheter. Det innehåller alltid *något* !

Sen är det en annan sak att *DU* kan definiera h'00' = "Tomt",
men det är inget som processorn har en aning om, så att säga...

> Sätts då alla positioner till 00 i buffern (rx_buffer 1-5).?

Nej.

> Ja om man skall göra en koll om registret innehåller en ett specifikt tecken,

Visst, om du inte har andra sätt att kolla det på (och det har du ju, du har räknare
som håller reda på hur mycket av bufferten som innehåller "korrekt" data)
så kan man sätta alla positioner till h'00' (eller något annat som betyder
"tomt" för *dig*, det kan vara i princip vad som helst som inte kan förväxlas
med korrekt data...).

Att använda just h'00' är inte fel i sig, dels går det enkelt att sätta ("CLRF reg")
och att testa ("MOVF reg, F" följt av en test med BTFSS/BTFSC av Z-flaggan).

h'00' är ett värde precis som h'12' och alla de andra 254 möjliga kombinationer, exakt som sodjan skriver.

Men varför nolla rx-bufferten när du ju har visat att det inte håller? Det finns ju tydligen inget fast format annat än att en block börjar med ESC, nästa tecken visar vilken sort data som kommer och nästa igen är en positionsindex.

Alla data som kommer in efter dessa 3 bytes är textdata som ska läggas i den färdiga ASCII-värde buffer på 10 tecken och antalet tecken är valfritt... (inom vissa gränser).

Detta betyder att Rx_Buffer bara ska vara på 2 bytes och allt ut över detta ska placeras enl. indexen som räknas upp efter varje siffer.

Anledningen till att jag vill rensa Rx_buffer+1 är.

Om det som är på gång är 1B 21 2A 20 20.
Då kommer 1B som "nollställs räknaren för rx_buffern" den ställer sig på pos. 1. och går ur ISR. Om det inte var 1B, gå vidare.

Nästa tecken är då 21 och skall sparas i rx_buffer+1
Så här görs en check om 21, spara i Rx_buffer+1 och gå sen ur ISR.
Om det inte är 21, gå vidare

Nästa tecknet efter är 2A.
Om man då gör en check först om Rx_buffer=21.
Om rx_buffer+1 är = 21, gå vidare. Annars "nollställ räknaren för rx_buffern" den ställer sig på pos. 1. och går ur ISR.
Är 21 gör nu en check på tecknet som är 2A, om det är något mellan 30-37
ta reda på vilket och spara i rx_buffer+2. Men det var ju 2A så "nollställ räknaren för rx_buffern" den ställer sig på pos. 1. och går ur ISR.
Nu kommer ju 20 går förbi ESC checken och checken om 21.
Men på checken om rx_buffer+1 är 21 skall Rx_buffern+1 vara h'00' , därför behövs det att rx_buffer+1 är lika med 00 eller h'00' eller kanske 0x00.

Visst, inget problem.
Det beror helt på hur du vill hantera det...
Kom bara ihåg att alla register alltid innehåller *något*...

> Om man då gör en check först om Rx_buffer=21

Eller att man har något extra "flagga" (d.v.s ett register som man sätter till
något värde som talar om det) som talar om vad som är på gång.
Då behöver man inte använda bufferten i sig för att kolla det.

Men visst., båda metoderna fungerar...

> eller h'00' eller kanske 0x00.

Samma sak. Jag föredrar dock h'00' efter som det är samma skrivsätt som
för d'123', b'01010101' och a'A'...

Och att "rensa" är ju enkelt :

clrf rx_buffer
clrf rx_buffer + 1
clrf rx_buffer + 2
clrf rx_buffer + 3
clrf rx_buffer + 4
clrf rx_buffer + 5

eller hur lång rx_buffer nu är. På ett lämpligt ställe...

Så nu har jag gått igenom era senaste inlägg och kommit en bit med koden, men undrar om det stämmer.
rx_buffer+2 inehåller indexpekaren som är något mellan 20 och 2F.
så rx_buffer+2 skall subtraheras med ett värdet så om det blir 0, skall siffran som är i rx_data skickas till någan av Digit_0-7

Så är det 32 skall värdet i rx_data skickas till digit_7.

EDIT: Sedan ökas värdet i rx_buffer+2 med 1, så att index kan räkna ut var nästa tecken skall.
EDIT: Har även lagt upp hela koden på nätet.
http://rodel.se/resultat_display.asm

Så nu har jag fått det att fungera, men inte helt hundra.
För vissa paket händer det inget med när man skickar från pc´n till displayen.

EDIT: dom kommer inte med från tidtagningen heller.

Det som fungerar är:
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:
1B 21 32 31 32 12:_ _,_ _
1B 21 34 33 34 _ _:34,_ _
1B 21 37 35 _ _:_ _,_5

Har kört koden i MPLAB och kolla i Simulator Trace, så skickar man in 1B 21 34 32 då hamnar den på följande så det borde funka.
index_2
decfsz Ind_check, f ; Index pekare =34 ?
goto index_3 ; Nej, gå till Index_3
movf rx_data, w
movwf digit_4
incf rx_buffer+1
goto done

Någon som har något tips på vad det kan vara?

Hela koden ligger finns att ladda ner.
http://rodel.se/resultat_display.asm

En liten fråga bara...

De där tecknen som du har markerat med "underscore", de är inte
med i datat, eller hur ?

Och när du skriver "1B 21 34 33 34 _ _:34,_ _ ", så är det första "34" ett
HEX värde medans det andra "34" är "trea-fyra" skickat som, ja vadå ?

Eller hur menar du igentligen ? Kanske att det som står efter bara är en
kommentasr till HEX värderna som kommer först ???

Förtydliga.

1B 21 34 33 34 = Hex 1B 21 sen kommer index pekaren som här är 34 där efter kommer ASCII datat i Hex och blir som det nedan på displayen.
_ _:34,_ _ =ASCII
Det ovan skall alltså föreställa dom 8 tecken på displayen.

Men det kommer inte upp på displayen som jag skrev innan.

OK, alltså : Är det korrekt uppfattat ?

Om jag också har fattat det rätt, så är det inte givet att de olika
paketen måsta ha just de längerna ovan, eller är det det ?
D.v.s att t.ex ett "1B 21 32" paket alltid har två siffror som data ?
Eller kan det vara fler siffror t.ex så här Som jag ser det *nu*, så anger den *andra* byten efter <ESC> i vilken position
som de följande siffrorna startar. Det skulle kunna användas för att redan
från början initiera pakeren till bufferten så att tecknen direkt kommer in
på rätt plats (rellativt displayen). Det borde förenkla rutinen som sedan
ska "översätta" RX_Buffer till data till displayerna.

>Är det korrekt uppfattat ?
Helt riktigt, skulle varit lite tydligare där.

>Eller kan det vara fler siffror t.ex så här
Nej det är inte givet för hur långt ett paket är, eller iallafall delvis.
Som standard skickar klockan ut 5 st. hex tecken, som tidigare beskrivits ex. 1B 21 34 39 38.
Hur det upprepade datat ser kan ses i protokoll PDF´n.
Det sänds ut hela tiden *oavsett* om det finns något att skicka, då skickar den ut två *SPACE* (h'20') där normalt ASCII datat är ex. 1B 21 34 20 20, 1B 21 36 20 20 o.s.v.
Men mitt i sändningen av standard datat, kan det komma en större eller mindre uppdatering.
En mindre som när tiondelen skall uppdateras när klockan rullar, 1b 21 36 31, 1B 21 36 32 o.s.v.
En större kan vara när klockan rullar och skall hoppa över från 59 sek till 1 minut, då ser det ut så här ex. 1B 21 33 31 30 30 30

>Eller kan det vara fler siffror t.ex så här
1B 21 32 31 32 33 34 12:34,__
Svar, Ja det kan det vara vid en uppdatering av standard datat.

>Som jag ser det *nu*, så anger den *andra* byten efter <ESC>
> i vilken position som de följande siffrorna startar.
Du menar alltså 21 det är vilken typ av data, om det är åkarenstid h'21' eller bästa tid h'22'

Vet inte om det är samma grej du menar, som jag var inne på.
1b *21* har ju 16 st index pekare, gäller även för h'22' och h'23'.
Jag är inne på att man går igenom allt data som har med 1b *21* att göra, alltså när första paketet 1B 21 20 20 20 kommer så börjar index pekaren räkna där. Alltså den ökar värdet i rx_buffer+2 med 1 och går ur nästa kommer 1B 21 22 20 20 den ökar värdet i rx_buffer+2 med 1 och går ur o.s.v.
Man skulle även kunna spara allt från *21* i respektive minnes plats för Digit, som ex. Digit_0 - Digit_15.
Då nästa projekt är att koppla upp och köra med LCD-displayen, då finns alla 16 byte sparde för att skicka till den. Men det är ett senare projekt.

Detta gör att man skulle kuna 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 är vad jag var inne på att testa.

> > Som jag ser det *nu*, så anger den *andra* byten efter <ESC>
> > i vilken position som de följande siffrorna startar.

> Du menar alltså 21 det är vilken typ av data, om det är åkarenstid
> h'21' eller bästa tid h'22'

Nej, (som jag skrev) den *andra* byten *efter* <ESC> !!

D.v.s 32-37. Det ser ut som om det anger var i displayen själva datat ska ligga.

> Detta gör att man skulle kuna skicka ett paket

Vem är "man" ?
Skickas inte datat från en färdig utrustning ?