Svenska ElektronikForumet

Det ser väl ut som att du får kolla lite noggrannare på paketet som
kommer. Och bara uppdatera den del som det gäller.

D.v.s lite extra kod som tittar på tecknet efter <esc>.
Är det fasta format för 33,35,36 paketen ?

Hmmmm... nu blir det ju lite mer knepigt faktisk när paketen inte har fasta storleker, nu måste du ju tänka till lite.

Mitt förslag:
Som tidigare tar du emot ESC som nollpunkt. Du sparar nästa byte som anger vilken sort data som kommer samt den byte som anger vilken siffer som kommer härnäst.

Om vi låtsas att det kommer följande paket: 1B 21 33 '1' '2' '3' '4'
Du sparar alltså 0x21 i din variabel "denna sorts data nu" och 0x33 i variablen "denna plats nu", detta ger en Recieve-buffer på 2 platser. Om det kommer in en ESC ska dessa 2 platser nollas!

Du har ytterligare sparat ett antal platser till 'talbuffer' såhär:
hh(:)mm(:)ss(,)xxyy (tecken med parantes finns inte i den buffert, bara för synbarhet)

Sedan, när NÄSTA tecken kommer ('1':an) kollar du först att båda platser i recieve-buffern är "icke-noll" samt att plats 1 i recieve-buffern är 0x21.

Om dessa förhållanden finns är det bra, kolla då att plats 2 i recieve-buffern inte är högre än 0x.

Allt fortfarande OK? BRA! då är det ett tecken som kommer ju! Och värdet i plats 2 i recieve-buffern innehåller ju en tips om var det ska! Det är alltså en index-variabel!

Alltså tar du det värde, drar av 0x31 så att du får 0-9 (känns det bekant, det är 10 värden och hur stor är din 'talbuffer'?). Om värdet blir högre än 9 slutar du göra mer i ISR'n.

Annars adderar du adressen till din 'talbuffer' och i den adress du då får petar du in den mottagna byte (INDF & FSR du vet). Därnäst ökar du på index-variablen med 1 och om den kommer upp på det värde som anger bästa tidupplösningen är det en ny readout så det flaggar du för.

På detta vis kollar du upp inkommande tal och fördelar dom direkt i rätt lokation.

Jag tycker att det är lite vanskligt att göra en så detaljerad algoritm som
Icecap har gjort utan att ha en verifierad och kontrollerad specifikation
över dataformatet. Det har ju redan ändrats en gång.

När jag pratade med tillverkaren förra året, berättade han att när det händer en stor för ändring så skickar klockan ut det i ett paket.
Paketen kan skilja i storlek (antal tecken) beronde på förändring.
Därefter upprepar klockan datat, genom att skicka det som jag beskrev från börja i projektet.
Ex. 1:15,98 = 1 min, 15 sek, 98 hundradelar
ex. 1B 21 32 20 31, 1B 21 34 31 35, 1B 21 36 39 38

Säg att åkaren går i mål, då blir det inte så stor förändring eftersom tiden rullar och då skickas tiondelen, sekunder och sist minuten till displayen.
Det som tillkommer vid målgång är 100-delen.
Men när tiden slutar att visas, så kommer en stor förändring displayen skall nollas.
Först ser det upprepade datat ut så här 1:15,98
1B 21 32 20 31, 1B 21 34 31 35, 1B 21 36 39 38

Sen kommer den stora förändringen som klockan skickar ut.
1B 21 33 20 20 20 20 20
Vilket är släck 1:15,98 och tittar man lite närmare på första packet (1B 21 32 20 31) så ser man att 32 = 20 släckt och sen kommer 33=31

33=1-tal på minuter.
34=10-tal på sekunder
35=1-tal på sekunder
36=10 dels sekund
37=100 dels sekund.

För att släcka dom skickar man alltså 1B 21 33 20 20 20 20 20

Eller nästa exempel när klockan rullar och man går från 1 min 59 sek. till 2 minuter 00 sek.
Då skickar klockan först tiondel sekunden 9 sen den större förändringen 2:00,0
1B 21 36 39, 1B 21 33 32 30 30 30

När klockan rullar skickas alltå hela tiden tiondelen ut som kan sen nedan.
1B 21 36 37, 1B 21 36 38, 1B 21 36 39 sen 1B 21 35 31 30 för en minut.


Man behör ju inte säga att det börjar med en ESC, den kan ju sluta med en ESC.
21 36 37 1B, 21 36 38 1B, 21 36 39 1B, 21 35 31 30 1B

OK, whatever...

Nyckeln till att få det att fungera är hur som helst att ha en 100% exakt
definition av hur datat ser ut. Annars blir det en massa gissande.
Definitionen kan vara via befintlig dokumentstion eller att man loggar
kommunikationen tills allt finns med.

Som standard skickar klockan ut följande:
Ett paket innehållande 5 tecken.
ex. 1B 21 34 31 32
som kan ses i PDF´n nedan.
http://www.rodel.se/protokoll.pdf
1B
21-23
20-3F
ASCII-data
ASCII-data

När klockan rullar kan det mitt i sändningen av standard data kommer det en uppdatering av ASCII datat och det kan se ut enligt följande.
1B 21 36 31
1B 21 33 31 30 30 30
Eller om man skickar ut realtids klockan till displayen, kan en uppdatering ASCII datat se ut så här.
1B 21 30 31 30 30 30 30 30 för kl. 10:00:00

Någon dokumentation har aldrig funnits och det är knappt att konstruktören kommer ihåg, så det här är vad jag har kommit fram till med det kostruktören har sagt och vad jag har loggat och fått fram.

Så nu är frågan hur man på bästa sätt får detta att fungera, om man ut går ifrån 1B, 21 och 32,33,34,35,36 och 37

EDIT: Glömde lägga med PDF´n

> i PDF´n nedan.

"nedan" ?
Menar du det tidigare PDF dokumentet ?
Eller någon nytt som du glömde länka till ?

> om man ut går ifrån 1B, 21 och 32,33,34,35,36 och 37

*Om* jag förstår rätt så ser datat alltid likadant ut efter 32,33,34,35,36 och 37 !?
Så du får kanske göra en liten rutin för varje "paket typ".
Alltså, "main" anropar naturligtsvis *en* rutin, men i den får du sedan
kolla på pakettypen och göra vad som måste göras...

Nu är länken där som jag glömde lägga ut.

>*Om* jag förstår rätt så ser datat alltid likadant ut efter 32,33,34,35,36 och 37 !?
Stämmer bra som standard datat skickar den ut 32, 34 och 36 med 2 tecken vardera.
Alltså tecken för 32 och33, 34 och 35, 36 och 37.

Så man kan säga att 1B 21 32 39 38 är tecken "32"=9 och "33"=8

>Så du får kanske göra en liten rutin för varje "paket typ".
Menar du subrutiner?

Problem innan var att det kom in ASCI data i första positionen i buffern, där skulle bara vara 21, 22 och 23
Samma var för andra positionen där 20-3e hamna, det var här problemet började.
Eftersom här skulle man selektera på om det var 32, 24 eller 36.
Men kom det in ASCII data här, som klockan skickar ut 30-39
Så kunde den ju välja att skicka annat data till displayen och allt hamnade i ofas.

Om man gör buffern större så den rymmer så många tecken som klockan max skickar ut och sen när nästa ESC kommer sätte man Buffer _full.
så borde det inte spela någon roll om det är 3 - 6 tecken i buffern.
Bara första position innehåller 21, 22, 23 och den andra 20-3e.
Då i den andra får man selektera på
33=1-tal på minuter.
34=10-tal på sekunder
35=1-tal på sekunder
36=10 dels sekund
37=100 dels sekund.
och skicka det till respektive siffra på displayen.

Nu fick jag inte den koden att funka helt ut sist, även om jag skickade data från pc´n i rätt antal tecken.

Hur kan man få till det med fler rutiner, förklara.

Och jag förklarade hur man kan ta emot valfri längd data men OK, skit i det, det var bara lösningen på ditt problem.

Edit: 10-timmar har som index 0x30, 1-timmer har 0x31, 10-minuter har 0x32, 1-minuter har 0x33 osv. så vad är problemet?

Det kommer alltså en ESC som starttecken.
Sedan kommer det en indikator som måste vara 0x21.
Då kommer indexen, '0' = första tecken i talremsan, '1' = nästa osv.
Och sist kommer det valfritt antal tecken med tiden i klartext.

Alltså kan man:
ESC nollar "allt" det nödvändiga.
0x21 på förstaplats = kanon, den tar vi.
Nästa är index, den subtraherar man '0' ifrån och sparar.
Vad som kommer härnäst (fram till ESC eller för många tecken) placeras i tidbufferten på 10 bytes och för varje tecken räknas indexet upp ett steg.

När index har nått ett värde som pekar på den högsta upplösning som används + 1 är en full uppdatering klar och det ska petas ut till displayen.

Klart.

Ni får ursäkta för jag har visst missat 2 inlägg vid 14 tiden.

> Hur kan man få till det med fler rutiner, förklara.

Hur du praktiskt disponerar koden spelar ingen roll, bara den "vet om"
att hantera de olika pakaten korrekt.

I princip ska din kod göra exakt samma sak som du själv
skulla göra med papper och penna för att "dekoda" paketen.

Icecap har nu läst dina inlägg och det låter som en bra lösning, men det är en grej.
Om det kommer ett packet ovasett längd är det inte bäst att sända det direkt? Annars blir datat liggande tills buffern är full.

Jag kan bara referera till den elektromekaniska display som vi har, om jag skickar en sekvens ovasett längd så publiceras den på displayen.
Det genom att bara skicka *ett* packet som detta ex. 1B 21 32 20 31 32 33 34 35
_1:23:45

Frågan är bara hur man gör det, eftersom det inte kommer någon ESC i slutet. Kan man sätta en timeout som skickar ut det, eller kan man gå på att RCIF inte är satt?

Ni får ursäka att jag lite vart efter kommer med information, men nu när jag börjar förstå mer om programmering. Så märker man ju hur viktigt det är att allt underlag finns.

Jo, det blir lite mer komplicerat om paketen har okänd längd !

Och om det dessutom kan vara en pause efter sista "siffran", d.v.s
att det inte direkt kommer ett nytt paket med <ESC> i början (för i sp fall
kan ju det användas som "stopp" på föregående paket). D.v.s att den
inledande <ESC> på *nästa* paket helt ersätter räknaren som signalerar
när bufferten är "full".

Om det är så som beskrivs ovan, så kanske det är bättre att först invänta
de första tecknen i paketet (<ESC> plus de som specar innehållet) och
sedan processera själva "datat" eller "siffrorna" on-the-fly i takt med att de
kommer infarande. Då blir man inte beroende av att veta när paketet
tar slut, man bara hanterar datat så längde det kommer.

Alltså en lite annorlunda design av ISR'en utan buffer t.ex. Den får ersättas
av ett antal flaggor som håller reda på vad det är som pågår hela tiden.

Det är det jag säger, man måste veta *EXAKT* hur data kan se ut.

Svar kommer imorgon, hade suttit och skrivit i mer en 40 min. och klickade på skicka och kom till logga in gjode det och upp kommer ett tomt svara dokument.

Jaja, det är inte alltid lätt.