USART PIC18 XC8

[sodjan]

Jo, det syns säkert. Speciellt om man vänder på det så att
lysdioden är släckt vid vila och tänds vid sändning.

[Lullen]

Många bra tips! Tyvärr så är jag förbannad pga att jag tappade hojen på mobilen så har inte orkat testa något än. Tar det imorgon istället.
Jag hann dock försöka kolla lite hur det fungerar med putsUsart och den fungerar typ såhär iaf. Vet inte om jag kollade på rätt ställe men jag såg inget om hur det fungerar med interrupts iaf.

Kod: Markera allt

void putsUSART( char *data)
{
  do
  {  // Transmit a byte
    while(BusyUSART());
    TXREG = *data;
  } while( *data++ );
}
char BusyUSART(void)
{
  if(!TXSTAbits.TRMT)  // Is the transmit shift register empty
    return 1;          // No, return FALSE
  return 0;            // Return TRUE
}

Vad ska hända om jag öppnar min usart och sen skiter i och läser? Ska något krascha? Ska bokstaven som ligger där bytas ut mot den nästkommande? Hittade något om nån overflow (något kallat OERR) men har inte hittat det heller när jag sökte vidare.

Kom på att jag testade att skicka kommandona (jag kommer endast skicka saker vid start för att sätta upp gpsen) direkt efter UsartOpen() och då var jag tvungen att starta om usart för att den skulle fungera igen, dvs att jag iaf skulle få hela strängar (kom inte ihåg om jag fick interrupts). Efter omstarten så fungerade det men gpsen tolkade iaf inte dessa kommandon då jag fortfarande fick alla updates

[sodjan]

OK, då borde inte putsUSART blockera interrupten vid mottagande.
Det borde kunna köras parallellt.

Det finns ju två oklara punkter här, och det är aldrig enkelt eller bra
att ha de obekanta i en ekvation.

*Först* måste det verifieras om du över huvudtaget skickar något till GPS'en.
*Sen* är det en annan fråga hurvida GPS'en faktiskt förstår det den får.

Hur är det, kör du 9600 vid dessa tester? Jag tror att det är olyckligt att
blanda in en tradje variabel (hastighetsändring) när vi redan har 2 st.

Ja, det kan vara så att om man inte läser så sätts en "overflow" (kallas
även "overrun" ibland) flagga om man inte läser det som mottas. Du kan
ju ändå ha din ISR fungerade men bara "kasta" det mottagna innan allt
är klart för att börja bearbete paketen.

Normalt ska man aldrig få overrun eller "framing error". "18.1.2.2 Receiving Data"
i databladet beskriver när detta inträffar och vad man måste göra, se även
"18.1.2.5 Receive Framing Error" och "18.1.2.6 Receive Overrun Error". Det
verkar tydligt nog.

[sodjan]

Ett annat tips...

Ofta när man håller på med kommunikation mot en utrustning som man
inte är helt "100" på hur den fungerar, så kan det vara enklare att
simulera det hela med ett lämpligt program på en PC. Antingen (om
all kommunikation sker i ASCII) kan man köra PuTTY eller annan valfi
terminalemulator, eller något speciellt program för tester där man kan
skicka data som hex. Man kan ju även simulera strängarna från GPS'en.

D.v.s ersätt din GPS med en PC med lämpligt program och kör där tills
du *tror* att allt fungerar, då är det dags att hänga på GPS'en och
köra live hela vägen.

[Swech]

Alternativt är att hänga på en sladd och lyssna på "konversationen" mellan
PIC och GPS på en PC samtidigt (med lämpligt terminalprogram). Man lyssnar av RX/TX linjerna

Swech

[Icecap]

Swech: jag gör ofta så - men TS har ju ingen COM-port eller nivåomvandlare...

[Lullen]

Jag märkte en rolig grej.
Jag testade att kolla om jag ens får en ACK från gpsen och det får jag inte.
Acken är av meddelandetypen $PTMK så kollade bara det men jag fick en annan $PTMK i min indata. Nämligen mitt egna kommando som jag skickar ut.
Vad kan detta bero på? Jag har kollat och putsUsart lägger till saker i TXREG och ReadUsart läser från RXREG

[Icecap]

Vad det beror på?
Sannolikt att du inte har koll på huruvida data faktisk sänds rätt och tas emot rätt. Det börjar bli dags att skaffa en level-converter (t.ex. MAX232 eller ST232) och en USB-dongel.

[sodjan]

> Det börjar bli dags att skaffa en level-converter...

Ja, det är min egen auktion, men i alla fall...

http://www.tradera.com/1-st-ttl-cmos-rs ... _208546776

[Lullen]

Nu har jag snart suttit i sex timmar idag och med många motgångar som fick mig att börja tänka på vad jag håller på med så har jag nu lyckats kunna visa på vad som händer!

Jag kopplade in TX till RX och försökte läsa av datan men fick hela tiden OERR = 1. Testade sedan att bara skicka ett tecken '$' och det fungerade så jag tog två då jag läste att FIFOn har 2 tecken. Och när jag väl drog på 3 tecken så fick jag mitt OEER fel igen. Så då vet vi att OERR är problemet, har försökt hitta något som kan vägleda mig om vad jag kan göra för att förhinda detta men utan lycka. Men jag är glad iaf och tack alla att ni orkar med mig!

Då jag inte bryr mig om vad som kommer in egentligen när jag försöker skicka mina kommondon så har jag en tanke på hur jag kan fullösa detta. Jag har testkört och jag fick ingen tråkig OEER men kan det fungera dvs min sändning ser ok ut iaf? Finns det någon finare lösning?

Kod: Markera allt

while(BusyUSART());
    WriteUSART('$');
    while(BusyUSART());
    ReadUSART();
    WriteUSART('P');
    while(BusyUSART());
    ReadUSART();
    WriteUSART('M');
    while(BusyUSART());
    ReadUSART();
    WriteUSART('T');
    while(BusyUSART());
    ReadUSART();
    WriteUSART('K');
    while(BusyUSART());
    ReadUSART();
    WriteUSART('\n');
    return;

[sodjan]

> har försökt hitta något som kan vägleda mig om vad jag kan göra för att förhinda detta men utan lycka.

För några inlägg sedan skrev jag:

> Normalt ska man aldrig få overrun eller "framing error". "18.1.2.2 Receiving Data"
> i databladet beskriver när detta inträffar och vad man måste göra, se även
> "18.1.2.5 Receive Framing Error" och "18.1.2.6 Receive Overrun Error". Det
> verkar tydligt nog.

Där beskrivs just det som du nu har "upptäckt"...
3 tecken är OK, sedan blir det "overrun".

> Finns det någon finare lösning?

Den snyggare lösningen är att låta en interruptrutin ta hand om de
mottagna tecknen (och "kasta" dom om du inte behöver tecknen).
Då kan du skriva hur mycket du vill WriteUSART()...

[Lullen]

Jo det var där jag läste och det är ju att FIFOn blir full, det stod att den rymde 2 bokstäver där. Om jag inte accessar FIFOn innan tredje byten kommer in så får jag OERR. Jag var så säker innan på att det inte hände så testade inte det då du skrev att det normalt aldrig ska hända . Jag har min RX i en interrupt. Jag har skrivit om den lite nu sen första inlägget. Det finns två platser i den som tar lite mer tid som jag har kommenterat i koden. Kanske klarar inte PICen dessa när jag samtidigt skriver. Framför allt då när jag nullar hela received data vid start-bokstaven. Ska testa lite olika saker under dagen men är det något som ser galet ut så hojta till

Kod: Markera allt

//Interrupten anropar denna om RCIF == 1
void handleUsartRx(){
    if (RCSTA1bits.OERR){
        RCSTA1bits.CREN = 0;
        Nop();
        RCSTA1bits.CREN = 1;
    }
    getPosition();
    PIR1bits.RCIF = 0; // clear rx flag
}

void getPosition(){
    struct Position position;
    position.fixed = -1;
    rx = ReadUSART(); //read the byte from rx register
    
    if(rx == '$'){
        //We got a start char!
        rxIndex = 0;
        for(int i = 0; i < 100; i++){ //Kan denna vara för långsam?
            receivedData[i] = '\0';     //Kanske är det bättre att sätta receivedData[i+1] = '\0' vid varje mottagen char?
        }
    }
    if(rxIndex < 100){
        receivedData[rxIndex] = rx;
        rxIndex++;
    }else{
        rxIndex = 0;
    }
    if(rx == '\n'){
            strcpy(ReadyData,receivedData); // Kan denna vara för långsam?
    }
    return;
}

[sodjan]

> då du skrev att det normalt aldrig ska hända...

...eftersom man alltid ska ta hand om det som kommer, ja.
Gör man inte det, så får man overrun.

Ja, jag reagerade på att du körde saker i ISR'en som i alla fall jag
inte kunde bedöma på rak arm hur lång tid det tog. Normalt så läser
man från USART'en och sparar undan det mottagna, och om ett helt
paket är mottaget, signaera till main() så att det kan bearbetas.

> Framför allt då när jag nullar hela received data vid start-bokstaven.

Det borde väl räcka att köra den då du har ett komplett packet att bearbeta?
Det förutsätter att "slut på paket" går att identifera säkert.