Resultat display

[Stewal]

>Skapa en buffert ("RES rx_buffer 5", eller något sådant).
>Låta USART trigga ett interrupt via RXIF.

USART receive är en inbyggd buffert om jag förstår det rätt 255 byte och den buferten som skall skapas (rx_buffer 5) blir 5 byte stor?
Försöker bara sätta mig in lite bättre hur det skall byggas upp.

>I interruptrutinen, "fylla på" bufferten, när den är full, sätt en flagga.
>(Bufferten hanteras enklast med registret för "indexerad adressering".)

Till en början behöver adresserna för Bank0 - 4 sättas, eller är dom redan satta default i RAM?
Anledningen till fundering är att i Thomas McGahee picuart beskrivning, så är adresserna för bankerna satta i samband med användning av intruptrutiner.

[Icecap]

Såhär tar jag emot kommunikationen i mitt nuvarande projekt, jag har "putsat lite" för att anpassa till detta.

Kod: Markera allt

typedef unsigned char byte;

byte Timmar[2], Minuter[2], Sekunder[2], Sek100[2], Sek10k[2];

#define ESC 0x1B
#define HOUR_TAG    0x30
#define MINUTE_TAG  0x32
#define SECOND_TAG 0x34
#define SEC100_TAG  0x36
#define SEC10K_TAG  0x38

#define CURRENT_TIME 0x21

byte Rx_Buffer[5];
byte Rx_Input; // Räknare för antalet tecken
byte Updatera;

_interrupt void Rx0_ISR(void)
  {
  byte Recieved;
  Recieved = u0rb; // Hämta från UART'en, kan bara läsas 1 gg!
  if(Recieved == ESC) Rx_Input = 0;
  else  
    {
    if(Rx_Input > sizeof(Rx_Buffer)) // Tillåt bara om det finns plats
      {
      Rx_Buffer[Rx_Input++] = Recieved; // Lägg in i buffer
      if((Rx_Input >= 4) && (Rx_Buffer[0] == CURRENT_TIME)) // Första ESC försvinner ju...
        {
        switch(Rx_Buffer[1])
          {
          case HOUR_TAG:
            Timmar[0] = Rx_Buffer[3];
            Timmar[1] = Rx_Buffer[2];
          break;
          case MINUTE_TAG:
            Minuter[0] = Rx_Buffer[3];
            Minuter[1] = Rx_Buffer[2];
          break;
          case SECOND_TAG:
            Sekunder[0] = Rx_Buffer[3];
            Sekunder[1] = Rx_Buffer[2];
          break;
          case SEC100_TAG:
            Sek100[0] = Rx_Buffer[3];
            Sek100[1] = Rx_Buffer[2];
          break;
          case SEC10K_TAG:
            Sek10k[0] = Rx_Buffer[3];
            Timmar[1] = Rx_Buffer[2];
            Updatera = 1;
          break;
          }
        }
      }
    }
  }

Då ligger alla data rätt: Hög adress är hög siffer och "Updatera" sätt till 1 ('sant') när alla data har kommit in, när du har startat en uppdatering nollar du den flagga igen.

Då kan ditt program ligga i main-loop och bara kolla efter "Updatera".

[sodjan]

> USART receive är en inbyggd buffert om jag förstår det rätt 255 byte

Vet inte vad du syftar på. USART'en har en buffert på ett tecken/byte.
Andra buffertar måste du skapa och hantera i koden.

> Till en början behöver adresserna för Bank0 - 4 sättas, eller är dom redan satta default i RAM?

Jag är inte heller här riktigt med på vad du menar. Det finns inga
"adresserna för Bank0 - 4". Det finns två st bitar i ett register (STATUS)
som används som två extra adress-bitar för att välja rätt bank. De sätts
inte "till en början", utan i koden där det behövs. I just detta fall har du inte
fler variabler än att de rymms i de första 96 GPR'en i Bank0, så blir det
lite mindre bank-switching.

> Anledningen till fundering är att i Thomas McGahee picuart beskrivning,

OK, jag är inte till 100% påläst på hur han har löst det. Ta gärna ideer
därifrån, men hans lösningar kanske inte är optimla för sig. T.ex om det
är där som det finns en 256 tecken buffert, så kan du skippa den delen.

[Stewal]

Tackar Icecap.

Som du säker sett så kommer efter ESC 3 st. paket 21, 22, 23 och där är 21 som är intressant i det här projektet vilket inte var med i ditt ex.
Varje packet innehåller ju 16 adresser , innehållande 5 byte ex. 1B 21 30 32 31

Men man ser hur ditt ex. jobbar sig genom koden, tyvärr är min kod i ASM inte C.
Men får försöka över sätta koden.

[Stewal]

>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.

Har tittat lite på det här förslaget och om man tittar på koden som klockan skickar.
Så är det enligt ditt ex. ovan på följande sätt och kl. 21:48:19 .
1B 21 30 32 31
1B 21 32 34 38
1B 21 34 31 39

Det är då enligt följande:
h'30'=32 :2
h'31'=31 :1
h'32'=34 :4
h'33'=38 :8
h'34'=31 :1
h'35'=39 :9

Vi har en elektromekanisk display som nämts tidigare och den kan man skicka 1B 21 33 38 till för att sätta siffra 8 på ex. pos 3 från höger _ _ _ 8 _ _

[Stewal]

Har börjat skriva lite kod för att skapa rx_buffer på 5 byte, men hur får man buffern att sätta en flagga när den är full?

[sodjan]

> men hur får man buffern att sätta en flagga när den är full?

Bufferten gör inte det, du (eller din kod) gör det när du (d.v.s din kod)
har skrivit det femte tecknet i bufferten.

"Bufferten" är ingenting annat en 5 minnespositioner ("byte") som
ligger efter varandra. Den kan inte göra något av sig självt, den har
inget eget liv, så att säga...

För att jämföra med Icecap's C kod :

"byte Rx_Buffer[5];" ==>> "RES Rx-Buffer 5 ; buffer med 5 pos"

"byte Rx_Input;" ==>> "RES Rx_Input 1 ; pekare till Rx_Buffer"

Resten är i princip bara att översätta från C till motsvarande asemmbler.

I din main-kod ligger det bara en loop och väntar på att Updatera ska bli = 1.
Då anropas rutinen som överför siffrorna til rätt display.

Notera att Icecap's kod väntar in både timmer. minuter och sekunder
innan det skrivs till displayerna. Det är väl mest en smaksak om man vill göra
så eller om man vill skriva till h/m/s så snart de har kommit in, så att säga.

Sen har Icecap helt rätt i att du naturligtsvis inte behöver lagra även <ESC>
i bufferten, den finns ju alltid där...

[Stewal]

>För att jämföra med Icecap's C kod :
>"byte Rx_Buffer[5];" ==>> "RES Rx-Buffer 5 ; buffer med 5 pos"
>"byte Rx_Input;" ==>> "RES Rx_Input 1 ; pekare till Rx_Buffer"

var inne på skriva så här men det är alltså fel.
RS232_VAR UDATA_SHR
Rx-Buffer res 5 ;Rx_buffer på 5 byte


>Resten är i princip bara att översätta från C till motsvarande asemmbler.

Får försöka.

>I din main-kod ligger det bara en loop och väntar på att Updatera ska bli = 1.
>Då anropas rutinen som överför siffrorna til rätt display.

Ja tanken från början var att bearbeta en byte i taget.

>Notera att Icecap's kod väntar in både timmer. minuter och sekunder innan det skrivs till displayerna.
>Det är väl mest en smaksak om man vill göra så eller om man vill skriva till
>h/m/s så snart de har kommit in, så att säga.

Om man går på att skicka allt T/M/S data samtidigt till displayen måste del spara in en till buffer.
Det slipper man om man skickar datat direkt och då till påståndet nedan.

>Sen har Icecap helt rätt i att du naturligtsvis inte behöver lagra även ><ESC> i bufferten, den finns ju alltid där...

Det gäller även för paketet <21> och Tim <30>, <32>, <34>

[sodjan]

Äh, jag vände nog bara på det.
Skriv som manualen säger, inte som jag skriver...

> Om man går på att skicka allt T/M/S data samtidigt till displayen måste del spara in en till buffer.

Nej, snarare tvärtom. Du måste ha extra lagring för timmar och minuter
i väntan på att sekunder ska komma. Skrivs det direkt så kan de dela
samma minne.

> Det gäller även för paketet <21> och Tim <30>, <32>, <34>

Mja, de beror på hur mycket man läser in innan det analyseras.
D.v.s det beror på hur koden skrivs...

> Ja tanken från början var att bearbeta en byte i taget.

Det är viktigt att hålla reda på vad man talar om.
*interrupt-rutinen* kommer naturligtsvis *alltid* att hantera
ett tecken/byte i taget. De andra delarna kanske inte gör det.
De kanske hanterar ett 5-bytes paket i taget. Eller hela h/m/s
paketet på en gång. Som sagt, det beror på hur man vill
strukturera sin kod. Inget är mer rätt än något annat.

[Stewal]

>Mja, de beror på hur mycket man läser in innan det analyseras.
>D.v.s det beror på hur koden skrivs...
Om man läser ex. 21:48:19 så skulle det se ut följande i bufferten.
30 32 31 32 34 38 34 31 39
Om man då tittar på Icecap´s kod så kan jag inte se hur den skulle kunna gå igenom bufferten och välja rätt data.
Visst 30 (Hour_tag) ligger ju först och då skulle den ta byte 1 & 2 och sen alltså ta 32 (Minute_tag)?

[Icecap]

Om paketen kommer i den följd som det anges i den PDF-fil som det länkas till anges det att timmarna/minuterna/sekunderna (osv.) kommer i en block som börjar med ESC som "nollpunkt".

Sedan verkar det komma ett löpnummer, antagligen för att man inte ska blanda ihop olika tider med varandra, då detta program inte ska vara för trögt struntar vi i löpnumret.

Sedan kommer det en TAG som anger vilket värde som detta block innehåller,
0x30 för timmar, 0x32 för minuter osv. (missade i min exempelkod att det var hex).

Därefter kommer de 2 tal i ASCII som innehåller själva värdet, om minuterna är t.ex. 23 kommer det alltså en '2' och en '3' och dessa ska sparas i lämplig lokation, i ISR'n som läser inkomna data finns inte tiden att skicka till displayen också, alltså gäller det att spara tiden i minnet och signalera att den ska skrivas ut.

Så min kod är ganska enkel och skaplig snabb också:
* Om det kommer en ESC ska input-pekaren nollas då det kommer en ny block.
* Är det inte ESC ska den inkomna byte läggas in i buffern och input-pekaren räknas upp ett steg.
* Om input-pekaren är så pass stor att det har kommit ett block:
- Om det är ett timme-block ska datan överföras till timmarna.
- Om det är ett minut-block ska datan överföras till minuterna.
- osv.
- När sista blocket har kommit signaleras det att en uppdatering har skett.

Kom ihåg att det kommer block efter block utan uppehåll men enl. PDF-filen kommer det bara ETT värde per block och varje block börjar med ESC. Kommer det alltså ett sånt block man vill ha tar rutinen ut de data som är aktuella och sedan är blocket "dött", det har inget värde längre, datan är ju redan lästa.

För att läsa en komplett tid behövs alltså alla 5 block (fastän du verkar skippa timmarna) innan en tid är läst och att då signalera att tiden ska uppdateras innan alla block är inkomna vore ju fel.

Men jag märkte en sak: det värde jag antog var löpnummer är i själva verket en betydelsefull indikator, jag har därför ändrat koden enl. detta.

[Stewal]

>Sedan verkar det komma ett löpnummer, antagligen för att man inte ska blanda ihop olika tider med varandra,
>då detta program inte ska vara för trögt struntar vi i löpnumret.

Tror inte man kan strunta i det, det är 3 paket eller löpnummer eller vad man vill kalla det.
0x21=åkarens tid
0x22=bästatid
0x23= används inte
om man inte väljer just 0x21, skulle man först läsa in åkarenstid och lägga på displayen.
Sedan bästatiden 0x22 och lägga ut på displayen och sen 0x23 som skulle blanka displayen och sedan börja om med 0x21 igen.
Eller är det fel?

>Men jag märkte en sak: det värde jag antog var löpnummer är i själva verket en betydelsefull indikator,
>jag har därför ändrat koden enl. detta.

Är det det jag menar ovan?

>I ISR'b som läser inkomna data finns inte tiden att skicka till displayen också,
>alltså gäller det att spara tiden i minnet och signalera att den ska skrivas ut.

Om man då sparar allt innan sändning skulle det se ut så här i minnet.
ex. kl. 21:48:19 [32 31 34 38 31 39]
Efter datat sparat skull det skickas till displayen och då skickas som följande. eller?
Hämta från Rx_Buffer lägg i w (32) lägg ut på data pinnarna.
sätt adr. position. 8 skriv till display.
Hämta från Rx_Buffer lägg i w (31) lägg ut på data pinnarna.
sätt adr. position. 7 skriv till display.
o.s.v.

>(fastän du verkar skippa timmarna)
Det stämmer har gjort ex. ovan med klockan istället för att det skall bli lättare att förstå.
Det som är intresant för dispalyen som skall byggas är 1:27.691 om man tittar i PDF´n, som är 1 min, 27 sek, 691 tusendelar.
Men låt oss köra på klockan istället så blir det enklare att förstå.

[sodjan]

> Sedan bästatiden 0x22 ..... och sen 0x23 som skulle blanka displayen...Eller är det fel?

Är det en fråga ? Svaret vet väl bara du ??
Personligen antog jag att det bara var 21-blocken som du ville se.
Eftersom du skrev det...
Skit samma, du får hantera vilka data du vill.

> Men låt oss köra på klockan istället så blir det enklare att förstå.

Det är ju exakt samma sak, bara att välja andra fält. D.v.s 32,34,36,38
istället för 30,32,34. Det ena är inte speciellt mycket enklare än det andra.

[Stewal]

Kan inte säga annat än helt riktigt.

[Stewal]

Har nu börjat översätta C koden till ASM är det är rätt vad gäller Define?

Kod: Markera allt

#define ESC, h'1B'
#define CURRENT_TIME, h'21'
#define HOUR_TAG, h'30'
#define MINUTE_TAG, h'32'
#define SECOND_TAG, h'34'
#define SEC100_TAG, h'36'
#define SEC10K_TAG, h'38'