Resultat display

sodjan · Inlägg av **sodjan** » 5 februari 2008, 12:54:24

> Var inne på det om man inte kan lägga in den 8 data biten,

Jag förstår inte ur du menar. Om du kör 7 bit + paritet så *ÄR* bit
8 paritetsbiten. Bit 9 är bara aktuell ifall du kör 8 bit + paritet.

> Så kabeln är färdig och fungerar och data tas emot från klockan och skickas vidare till pc´n.

Perfekt !

> Men den åttonde databiten kommer inte med utan, det är 7 bitars data som skickas från PIC´n till PC´n.

Det är väl 8 databiter med 8'de biten alltid = "0" ???
Eller kör du faktiskt 7 bitar från PIC till PC's ??
Notera att detta är inget som sker lite hur som helst, utan det sker
med det protokoll så som du har konfigurerat det.

Dessutom så sa du ju tidigare att det bara var 7 databitar från den
utrustning du lyssnar på, så vad är problemet ? Var skulle den 8'de
databiter komma från ??

Stewal · Inlägg av **Stewal** » 5 februari 2008, 13:30:20

Jag förstår inte ur du menar. Om du kör 7 bit + paritet så *ÄR* bit
8 paritetsbiten.
Bit 9 är bara aktuell ifall du kör 8 bit + paritet.
Så sant nu när du säger det.

Det är väl 8 databiter med 8'de biten alltid = "0" ???
Eller kör du faktiskt 7 bitar från PIC till PC's ??
Notera att detta är inget som sker lite hur som helst, utan det sker
med det protokoll så som du har konfigurerat det.

Om jag kopplar KLOCKAN -> PC´n direkt coh analyserar datat, så spelar det ingen roll om programmet är inställt på att ta emot med parity eller utan.
Datat ser likadant ut.

Det samma gäller om det är kopplat KLOCKAN -> PIC -> PC
Datat ser likadant ut, oavsett parity.

Dessutom så sa du ju tidigare att det bara var 7 databitar från den
utrustning du lyssnar på, så vad är problemet ?
Var skulle den 8'den databiter komma från ??
Jag var inne på att det behövde vara 8 bitars data för att PIC´n skulle läsa datat rätt. Därför vill jag lägga till den åttonde databiten.
Men det behövs alltså inte, då kan jag tabort den koden jag skrev.

sodjan · Inlägg av **sodjan** » 5 februari 2008, 16:10:14

> Datat ser likadant ut.

Paritet eller inte (d.v.s hos mottagaren) handlar om *tolkning* av datat.
D.v.s i själva överföringen är det ingen skillnad på "7 bit med paritetsbit"
och "8 bit utan paritetsbit".

> Jag var inne på att det behövde vara 8 bitars data

"7 bit, even/odd parity" är samma sak som "8 bit, no parity",
det handlar bara om hur mottagaren *tolkar* den 8'de biten.
För USART'en är även paritetsbiten "data"...

I ditt fall kan du välja själv att skicka med paritetsbiten till PC'n eller inte.
Du kan mycket väl skicka 8 bitar med 8'de biten = "0".
PC'n kan vara inställt på "8 bit, no parity", det är helt OK.

Sen är det ju en helt annan fråga om man *vill* ha paritetskontroll eller inte...

Stewal · Inlägg av **Stewal** » 5 februari 2008, 17:12:54

Eftersom det kommer samma data ut från PIC´n som man skickar in. Kan man anse att det fungerar.

Nu till min nästa fråga i C kan man programmer med IF satser, lästa att det fanns liknade för ASM vilket skulle vara med CMP, JNE, JMP och Label.

Men fick felmeddelande på dom komandona, så hur gör man bäst för att programmera nästa del.

Har tänkt mig på följande sätt, sen om det är rätt.

IF "RX_DATA" är h'1B' goto TID, annars läs in RX_data igen.

TID
IF "RX_DATA" är h'21' goto POS, annars läs in RX_data igen.

POS
IF "RX_DATA" är h'30' goto TIM, annars läs in RX_data igen.
o.s.v

sodjan · Inlägg av **sodjan** » 5 februari 2008, 18:18:02

> lästa att det fanns liknade för ASM vilket skulle vara ...

De du räknar upp är för någon annan assembler, inte för PIC-assembler.

> Men fick felmeddelande på dom komandona,

Självklart, om de inte finns i listan med instruktioner (kapitel 15, sidan
225 och framåt) så *ska* du få ett felmeddelande.

> IF "RX_DATA" är h'1B' goto TID, annars läs in RX_data igen.

Det blir (ungefär) :

Kod: Markera allt

   movf   RX_DATA, w
   sublw  h'1B'          ; Om RX_DATA = 1B, så blir Z nu = 0
   btfsc  STATUS, Z      ; D.v.s skippa nästa inst om Z = 0
   goto   TID            ; Z=1, hoppa till TID.

   movf   RX_DATA, w
   sublw  h'21'          ; Om RX_DATA = 21, så blir Z nu = 0
   btfsc  STATUS, Z      ; D.v.s skippa nästa inst om Z = 0
   goto   POS            ; Z=1, hoppa till POS.

   movf   RX_DATA, w
   sublw  h'30'          ; Om RX_DATA = 30, så blir Z nu = 0
   btfsc  STATUS, Z      ; D.v.s skippa nästa inst om Z = 0
   goto   TIM           ; Z=1, hoppa till TIM.


   goto   read_again     ; Fel tecken, läs igen...

TID                      ; Vi har fått in h'1B', så fortsätt här...

Om det nu var så du ville att det skulle fungera...

Stewal · Inlägg av **Stewal** » 5 februari 2008, 19:03:35

Självklart, om de inte finns i listan med instruktioner (kapitel 15, sidan
225 och framåt) så *ska* du få ett felmeddelande.
Gick igenom databladet och hittade inget, misstänkte det.

Det ex. du gjort är som jag hade tänkt mig, så nu är det bara till att koda vidare.

Hur får man in slut resultatet, som skall skickas till displayen sen?

Kod: Markera allt

dlr3416_out 8, a'2' ;pos (timme)

Har provat med följande men det funka inte.
Får bara upp samma bokstav ovasett ASCII kod som skickats som HEX.

Kod: Markera allt

dlr3416_out 8, RX_DATA ;pos (timme)

sodjan · Inlägg av **sodjan** » 5 februari 2008, 19:42:11

Vad är "dlr3416_out" ?

Stewal · Inlägg av **Stewal** » 5 februari 2008, 19:50:33

Om du tittar på din kod för DLR3416 så förstår du.

sodjan · Inlägg av **sodjan** » 5 februari 2008, 20:00:07

OK, jag såg inte att du hade något sådant macro.
Mitt macro fungerar inte med två displayer...

Stewal · Inlägg av **Stewal** » 5 februari 2008, 20:07:17

Fick det att funka, med att lägga till RA2 som ändrar vilken display som det skall skrivas till.

Kod: Markera allt

not_pos_7
        decfsz      dlr3416_pos, f    ; pos = 7 ?
        bsf         dlr3416_a0          ;JA, sätt A0=1, A1=1, A2=1
        nop						
        bsf         dlr3416_a1
        nop
        bsf         dlr3416_a2
        nop  
        goto        toggle_wr

Stewal · Inlägg av **Stewal** » 5 februari 2008, 23:45:43

Har nu provat fram och tillbaka men kod är inte riktigt som det var tänkt.

Tar och förklarar hur datat ser ut.

Datat som klockan skickar ser ut på följande sätt, ett ex. kl. 21:48:19 blir som nedan.
1B 21 30 32 311B 21 32 34 38 1B 21 34 31 39
1B=ESC
21=Tid 22=Bästa tid 23=inget
30=timmar, 32=minuter, 34=sekunder
32=2
31=1

Så här är det tänkt att koden blir
För timtal.
tim
Om RX_DATA = 1B gå vidare, annars gå till "datain" (loopar tills rätt)
Om RX_DATA = 21 gå vidare, annars gå till "datain" (loopar tills rätt)
Om RX_DATA = 30 gå vidare, annara gå till "min"
Sänd RX_DATA (2) till display
Call datain för att hämta (1)
Sänd RX_DATA (1) till display
goto datain (börja om)

min
Om RX_DATA = 32 gå vidare, annara gå till "sek"
Sänd RX_DATA (4) till display
Call datain för att hämta (1)
Sänd RX_DATA (8) till display
goto datain (börja om)

o.s.v

sodjan · Inlägg av **sodjan** » 6 februari 2008, 00:06:05

En sak, du kan inte ha både "goto datain" och "call datain".

"Datain" måste antingen vara en subrutin eller *inte* vara en subrutin.

En CALL måste alltid avslutas med en RETURN, men en GOTO kan aldrig
avslutas med RETURN (om det inte var en CALL före GOTO, så klart...).

Om jag förstår rätt så kommer datat alltid i "paket" om 5 tecken :

1: <ESC> (h'1B')
2: Typ av paket (21=Tid 22=Bästa tid 23=inget)
3: Typ av värde (30=timmar, 32=minuter, 34=sekunder)
4-5: Själva värdet som två tecken.

Om det är så så skulle jag vänta med all analys av datat tills du har
ett komplett paket om fem tecken. D.v.s läs in tecken i en buffert (5 tecken lång).
Räkna efter ett <ESC> till totalt fem tecken och anropa då en rutin
som tittar igenom paketet och gör det som ska göras. Koden blir
lite renare med bättre separation mellan själva mottagandet av ett "paket"
och den följande analysen av datat.

Med lite smart programmering behöver du inte "veta" om det är
timmer, minuter eller sekunder. Du kan använda de 3 lägsta bitarna
i h'30', h'32' resp h'34' för addressering av rätt position i displayerna.
D.v.s det kan ske med samma kod, ingen separat kod för h/m/s...

D.v.s :

h'30' : b'00110000' : använd b'000' och b'001' för adress.
h'32' : b'00110010' : använd b'010' och b'011' för adress.
h'34' : b'00110100' : använd b'100' och b'101' för adress.

Man måste inte göra så, det var bara en liten optimering som jag såg...

Däremot tror jag stark på att läsa in ett helt data-paket *först* och
analysera innehållet när det är klart.

Stewal · Inlägg av **Stewal** » 6 februari 2008, 00:59:25

>En sak, du kan inte ha både "goto datain" och "call datain".
Kan man ha flera call efter varandra innan return?

>Om jag förstår rätt så kommer datat alltid i "paket" om 5 tecken :
Stämmer bra, du kan se det i pdf´n nedan.
http://rodel.se/protokoll.pdf

Som du ser så är det 3 paket, innehållande 16 st värden. som innhåller 2 st. tecken.

Klockan loopar ut dom här tre paketen hela tid, fast med uppdaterat data.
Det gör att det är mycket data som skickas hela tiden.

Det du skriver om att hämta in datat och sen analysera det innan skrivning till display låter som en bra lösning.
Nu är jag bara en nybörjare och har ingen aning om hur man löser det, så du som är expert får nog ge mig ett kod ex. om jag skall klara av det.

Det är bättre att göra en bra lösning från början än att göra om det sen till det bättre.

sodjan · Inlägg av **sodjan** » 6 februari 2008, 01:18:54

Jo. men med 9600 baud så har du mycket tid på dig
mellan varje tecken att göra annat. Med 9600 baud (d.v.s ca
1000 tecken per sekund) och 4 Mhz så har du ca 1000 instruktioner
på dig mellan varje tecken. Att kolla ett packet och uppdatera
displayerna borde gå på ca 100 instruktioner, eller en tiondel av
tillgänglig tid mellan två tecken.

Om inte den tiden räcker till, kan du använda 2 buffrar som skrivs
omvarandra, då har du 5 gånger så lång tid på dig att kolla datat (d.v.s
innan den andra bufferten också har blivit full).

Du kan även väldigt enkelt köra 8 Mhz istället och ha dubbelt
så många instruktioner tillgängliga (på samma tid). Justera
bara SPBGR enligt databladet, så att du fortfarande får 9600 baud...

> Kan man ha flera call efter varandra innan return?

Jo, man varje CALL hör ihop med ett RETURN. Det är alltid
lika många CALL som RETURN (d.v.s *exekverade*, det kan
naturligtsvis vara olika antal i själva koden).

Och om du gör CALL DATAIN så måste DATAIN avslutas med RETURN.
D.v.s att DATAIN är en subrutin. Och då kan du inte göra GOTO DATAIN
(*OM* du inte redan befinner dig "inne" i DATAIN !!).

Jag skulle göra så här (schematiskt) :

Skapa en buffert ("RES rx_buffer 5", eller något sådant).
Låta USART trigga ett interrupt via RXIF.
I interruptrutinen, "fylla på" bufferten, när den är full, sätt en flagga.
(Bufferten hanteras enklast med registret för "indexerad adressering".)

Main-koden gör ingenting innan flaggan är satt, då görs ett call
till en "data_check" rutin som kollar paketet (och uppdaterar displayerna
om det behövs). D.v.s main-koden ligger bara i en loop coh kollar
flaggan.

Om inte data_check hinner med, kan man ha två 5-teckens buffrar och
switcha mellan dom (den kan USART ISR'en ta hand om). Då kan
mottagningen av nästa paket pågå samtidigt som data_check analyser
föregående paket. Men jag tror inte att det behövs...

Stewal · Inlägg av **Stewal** » 6 februari 2008, 01:37:01

Okej låter avancerat.

Får nog leta efter något exempel, då det för mig är lättare att gå igenom ett ex. och lära sig ut ifrån det.