EUSART baudrate fråga till en PIC16F690

[Magnus_K]

Hej hej,

Sitter och läser databladet till en PIC16F690 och blir inte riktigt klok på baud rate generatorn.

Jag har en master (PIC:en) som snurrar med intern 8 MHz Fosc, och en slav (skift-register), och tänkte då använda synkron överföring. Data och klock-snöret har inga termineringsmotstånd så någon MHz-överföring lär det inte bli tal om...
Det jag inte blir riktigt klok på är om jag kan använda mig av registervärden från tabell 12-5 (sid 164), fastän det står att det är för asynkron överföring?
Om så är fallet, räknar man verkligen med samma "baud rate error" när man överför synkront?

Vill jag ha 0% fel vid överföring så ska jag välja 10417 i baudrate men skulle verkligen vilka öka på det lite. Med den här baudrate:en så överför jag 8 bitar på ~770µs men det vore kanon att i alla fall få ner det till hälften. Tips mottages tacksamt!

[Klas-Kenny]

Hm, du pratar data/clock och du pratar EUSART. Har de något med varandra att göra?

Mig veterligen så är baud rate generatorn och allt annat som har med EUSART att göra enbart för serieport/uart, och där får du ingen klocka. SPI borde vara det som är intressant här..

För övrigt vad gäller felet, det de listar är ju standard baud rates. Och i de flesta fall så landar inte den genererade baud raten exakt på det man vill utan någon procent därifrån vilket ju kan ställa till det just eftersom att den andre parten lyssnar och skickar med en viss hastighet utan klocka. Därför vill man ju vara så nära "rätt" som möjligt. Men det fungerar fint även om man ligger någon procent ifrån, kommer inte ihåg exakt var gränsen för problem går men det är inte extremt kritiskt.

Det är alltså inte så många procent av data kommer att bli fel vid sändning.
Men nu spelar det ju som sagt ingen roll eftersom att det inte är Uart som är aktuellt. Och skickar man med en klocka så finns inte den problematiken.

[H.O]

Hmmm, min spontana tanke är att om du ska kommunicera med ett "vanligt" shift-register så är det inte (E)USART'en du ska använda utan (M)SSP modulen.

Vad är det för enhet, mer specifikt, du ska prata med och varför är baudraten så kritisk när det ändå är synkron kommunikation, både master och slav använder ju då SAMMA klocka så om det skiljer lite, eller en hel del, spelar ju ingen roll.

Med detta sagt så har inte en enda gång användt (E)USARTen i synkront mode så....

EDIT: "Kopia" på Klas-Kennys inlägg....

[Magnus_K]

Kanske helt har missförstått det här men om jag istället kallar data och klocka för DT och CK, och ställer in PIC:en som synkron master.
Genom att sen lägga till en "latch-klocka" manuellt så kan jag låta hårdvaran göra jobbet med dataöverföringen mellan PIC:en och skiftregistret?

Nej men då är det kanske som jag misstänkte. Baud rate error är alltså när det blir timingmissar mellan klocka och dataöverföring men eftersom jag här skickar data enkel väg, och att det är synkront, så kommer det uppstå några timingfel. Eller

[H.O]

Vid asynkron överföring så genererar ju respektive enhet sin egen "klocka" och en startbit används för att "synkronisera" mottagaren till sändaren, efter att mottagaren har detekterat startbiten klockas databitarna in i helt baserat på mottagarens egen "klocka". Om den skiljer sig "avsevärt" från sändarens "klocka" så kommer sändare och mottagare att komma "ur synk" innan alla 8/9 bitar är överförda.

Olika baudrates går olika bra att generera från en specifik oscillatorfrekvens. Frekvensen på respektive enhets oscillator kan också avvika från det optimala pga av temperaturvariationer eller toleranser på komponenter etc varför den faktiska baudraten i respektive enhet skiljer sig från den teoretiska. T.ex kan sändarens baudgenerator generera 57450 baud istället för 57600 medans mottagaren genererar 57750 istället för 57600, ett totalt fel på 300baud eller 0.5% - inga problem.

Baudrate error-siffran som anges i databladet är alltså inte hur "många" överföringsfel du får utan mycket den faktiska baudraten avviker från den teoretiska - förutsatt att oscillatorn är korrekt.

Men jag vill fortfarande hävda att för att prata med shift-register så är det (M)SSP modulen som är hårdvaran i PIC'en som skall göra jobbet.

[Magnus_K]

Mycket bra förklaring. Tack för det H.O

Du har rätt om att SSP:n bör göra jobbet men jag ska berätta för dig varför det blev som det blev. Sen om det skiter sig pga okunskap eller om jag för en gång skull kan få något rätt, det kanske ni kan berätta. Så här ligger det till:

Jag satt och CAD:ade kortet till min klocka och jag hade redan bestämt mig för en 690 pga att jag programmerat dom innan och känner igen databladet ganska bra.
När designen led mot sitt slut så insåg jag att jag saknade en I/O... Shit pommesfrites. Hur skulle jag kunna fixa det då?

I det stadiet hade jag SSP-modulen för kommunikationen till shift-registret.
Då det står SDI is automatically controlled by the SPI module i databladet så hade jag lämnat denna I/O oansluten eftersom det endast är envägskommunikation mellan 595:an och PIC:en.
Efter lite grottande så insåg jag att här "använder" jag 3 I/O:s till kommunikationen men använder jag mig istället av EUSART:en och som synkron master så behöver jag bara 2 I/O:s, RX-pinnen kan jag göra vad jag vill med.

Så blev det till slut och om det har gått åt h-vete vet jag inte än. Vad tycker ni?

[H.O]

Som sagt, jag har aldrig använt (E)USART'en i synkront mode och vet ärligt talat inte om den kan fungera på det sättet du vill. Men OK, när du aktiverar (M)SSP modulen så tar den över både MISO och MOSI-pinnen och du är inte intresserad av MISO så du "slösar" bort den. Men i samma stycke som du citerar så står det:

Any serial port function that is not desired may be
overridden by programming the corresponding data
direction (TRISB and TRISC) registers to the opposite
value.

Så om du vill använda SDI-pinnen som en utgång sätter du bara TRIS-biten till 0 och kör på som vanligt. Vill du använda den som ingång behöver du inte göra nånting, bara att läsa porten som vanligt. I alla fall är det så jag tolkar det hela, förhoppningsvis hoppar någon in och rättar mig om det är fel eller så provar du helt enkelt.

[Magnus_K]

Du har nog helt rätt i vad du skriver H.O. Jag tror jag blev osäker på just "to the opposite value" eller något. Återkommer med resultat!

Måste passa på att fråga en sak som semi-berör ämnet:
Stämmer det att en sk hårdvarumodul, tex Timers, SSP, EUSART med mera inte belastar processor något? Eller hmm, hur ska jag formulera mig... Om tex en timer snurrar och sätter flaggor vid overflow, en SSP klockar iväg data som hamnar i buffern, berör det mig på något sätt när det kommer till instruktions-cykler etc?

Hoppas någon förstår vad jag menar...

[H.O]

Det går ju åt ett par instruktioner för att konfigurera och starta timern men när den väl snurrar så konsumerar den inga instruktioncyckler, det är ren hårdvara. Men om du vill att nått faktiskt ska hända när den "rullar over" (t.ex räkna upp en variabel eller flippa en I/O-pinne) så måste du ju såklart hantera den interrupt som då genereras. Vissa PICar kan automatiskt "trigga" andra moduler (t.ex starta en AD-omvandling) helt automatiskt men generellt sett så måste du såklart skriva kod för att tala om vad som ska hända och den koden konsumerar självklart instruktionscykler.

Samma sak med SSP-modulen, du konfigurerar den med kod, skriver en byte till bufferten med kod, sen gör den jobbet själv utan att belasta processorn varefter en interrupt (kan) genereras som du hanterar med kod.

[Magnus_K]

Jäkligt häftigt alltså. Tänk vad mycket pulver jag aldrig brytt mig om att använda, utan gjort det i mjukvaran i stället.
Nu ska jag försöka få något gjort men tack så mycket hjälpen så här långt!

[Magnus_K]

Första problemet upptäckt med att använda "min metod":

När jag laddar TXREG med data så finns det bara en interruptflagga som talar om när processorn fört över bitarna från TXREG till TSR (buffern som skickar iväg datan). Ingen flagga som säger till när buffern är tom.
Enda sättet att veta när buffern blivit tömd är att polla TRMT-biten för att se om sändning pågår eller inte.

Sitter och funderar på om man kan göra tex while(TRMT) {} och vänta ut sändningen men snacka om vansinne. Ideér?

[H.O]

Du skriver en byte till TXREG, den överförs direkt och automagiskt till TSR eftersom TSR är tomt och börjar shiftas ut därifrån, när det sker (direkt) är ju TXREG på nytt tomt och du kan ladda nästa byte dit - SEN aktiverar du din interrupt och gör lite annat medans den första och lite på den andra byten shiftas ut.

[Magnus_K]

Ska visa senare hur det ser ut men jag använder en timerinterrupt för att uppdatera min display med ett fast intervall.
Det är här det blir lite tokigt för att jag måste invänta att shift-registret får all sin segmentdata innan jag klockar ut den på sina utgångar och går vidare med programmet.
Hade jag använt SSP:n så hade det ju bara varit att invänta SSPIF och ha en interrupt med högre prio.

Jag löser inte det här själv så jag tänkte sätta mig ikväll och se om jag kan få ihop något begripligt och be er om tips.

[Magnus_K]

Nej, får inte ihop det här... Får inte PIC:en att skicka en enda bit, serieklockan är också stendöd.
Är det någon som ser att jag missat något uppenbart i nedan kod?
(Har rensat så mycket som möjligt som inte rör den här funktionen med D1-4 har fått "dummyvärden" i felsökningssyfte)


Initierar EUSART-modulen så här:

Kod: Markera allt

void EUSART_init() {

      SPBRG = 0b00000000;             // Try baud rate SPBRG 0 for highest speed
      PIE1.TXIE = 0;                  // Interrupt is PIE1.TXIE, INTCON.GIE and INTCON.PEIE
      TXSTA.SYNC = 1;                 // SYNC bit (1) in TXSTA = sync operation
      TXSTA.CSRC = 1;                 // CSRC bit (1) in TXSTA = PIC master
      RCSTA.SREN = 0;
      RCSTA.CREN = 0;                 // SREN & CREN bit (0) in RCSTA = transmit mode
      RCSTA.SPEN = 1;                 // SPEN bit (1) in RCSTA = Enable EUSART
      BAUDCTL.SCKP = 0;               // Clock polarity - BAUDCTL.SCKP (0) is clock idle low, data trf on rising edge
}

Försöker skicka data så här:

Kod: Markera allt

void main() {

     EUSART_init();

     while(1) { 

        newTRANSFER = 1;

        if(newTRANSFER) {

           short i;
           i = digitCounter;
           i++;
           if(i >= 5) {
              i = 0;
           }
           TXSTA.TXEN = 1;
           switch (i) {
           case 0:
             TXREG = D1;
             break;
           case 1:
             TXREG = D2;
             break;
           case 2:
             TXREG = DP;
             break;
           case 3:
             TXREG = D3;
             break;
           case 4:
             TXREG = D4;
             break;
           default:
             TXREG = 0;
             break;
           }
           while(TXSTA.TRMT) {}
           newTRANSFER = 0;
        }     
     }
}

[Klas-Kenny]

Ptja, är I/O'n initierad till utgång?