Uart försök med 12F1840

[Icecap]

Nja... jag läste lite fel.

Finns det plats i buffern till tecknen som kommer?
Vad står '255' i UART1_Read_Text(uart_rd,"\n",255) för?

[Mr Andersson]

https://download.mikroe.com/documents/c ... _read_text

void UARTx_Read_Text(char *Output, char *Delimiter, char Attempts);

Reads characters received via UART until the delimiter sequence is detected. The read sequence is stored in the parameter output; delimiter sequence is stored in the parameter delimiter.

This is a blocking call: the delimiter sequence is expected, otherwise the procedure exits (if the delimiter is not found).

Parameters :
Output: received text
Delimiter: sequence of characters that identifies the end of a received string
Attempts: defines number of received characters in which Delimiter sequence is expected. If Attempts is set to 255, this routine will continuously try to detect the Delimiter sequence.

Du har skräp på linan.

[newbadboy]

Aj fan det har definitivt med den att göra. Satte den till 5 istället för 255. Nu är det lite mer sporadiskt beteende. Efter en skickad sträng är CS ibland hög Ibland låg.

[Icecap]

Vilket nivå finns det på Rx-linan när radion är i stand-by?

Om den är '0' kommer UART'en att uppfatta det som et problem och sannolikt en byte.

[newbadboy]

Den är faktiskt hög när CS är noll.

[lillahuset]

Läs varje tecken för sig och skriv ut hexadecimalt så behöver du inte spekulera i vad du tar emot.

[Icecap]

Lite kommentarer om generell funktion:
Just detta är problemet med att använda dessa "bra" färdiga rutiner: om inget går fel kan de fungera skapligt men blir det fel är det plötsligt svårt eller mycket svårt.

Min lösning hade varit interruptbaserat och med ett datapaket med checksum osv.

Med en Timer-interrupt kunde man styra tiderna där radion skulle slå på mycket exakt och konstant.

Med en UART-interrupt kunde man ta emot och buffra data när de kom och ha kontroll på vad som, buffer-overflow osv.

Samtidig är det möjligt att ha en time-out på data så att om ett halvt paket data kom pga. störningar kommer det att kastas bort när det har gått en viss tid och det har blivit "gammalt"

Kommunikationspaketet hade även varit med en STX och ETX där STX ville nollställa pekaren i buffern och ETX ville betyda "OK, det finns ett datapaket i buffern, jobba på det!"

I detta fall kan STX och ETX vara tecken man enkelt kan skriva på t-bordet och "sniffa" utan en massa hex-konvertering, t.ex. '<' och '>'.

STX = Start TeXt.
ETX = End TeXt.

Allt detta betyder ju också att alla "delayms()" försvinner (förutom möjligen den första) och tas över av Timer-interrupten där man skapar en "state mashine" - vilket i grunden bara betyder att man ställer någon flagga och sedan gör ISR'n "sin grej", steg för steg.

Då radion (mottagaren) i detta projekt (och helt säkert andra också) ska spara ström och därför bara kör ibland måste en sändare ju synkroniseras till detta, alltså måste gate-ningen vara stabil vilket betyder att den INTE får ändras oavsett vilka kommandon som tas emot.

Jag gör "alltid" detta, har faktisk en rimligt enkel rutin för att kunde skriva kommandosträngar bestående av flera ord och värden, ETX är då '\r'. Till kommunikation mellan µC och µC är detta sätt med ord-igenkänning dock spill av tid och på tok för besvärligt.

Jag har numera färdiga "standard-rutiner" för de seriella portar (annan µC men har kört samma system på PIC) så att jag enkelt kan starta ett projekt, de innehåller interrupt-rutiner och allt, kanske lite väl ambitiöst men jag kan starta ett projekt och få fysisk kommunikation med det på ca: 30 minuter inkl. tolkningen av kommandon.

Det har dock varit ett hästarbete att komma dit.

[newbadboy]

Jag hör vad ni säger. Då vet jag iaf lite mer om detta och var problemet troligen ligger. Ja trist när fördiga funktioner inte räcker hela vägen fram ... ska labba runt lite och se om jag kan på ngt sätt komma runt problemet..

[newbadboy]

Fick faktiskt det till att funka helt ok med koden nedan. Finns säkert 1000 sätt att göra det bättre på men allt är relativt till tiden.

Kod: Markera allt

#define Solenoid LATA.F2
#define Buzzer LATA.F4
#define CS LATA.F5

char uart_rd[20];
int k=0;



void Recieve(){
 if(UART1_Data_Ready()==1){
    if(CS==1){
       UART1_Read_Text(uart_rd,"\n",255);
       CS=0;
       if(uart_rd[0]=='K')
         if(uart_rd[1]=='a')
            if(uart_rd[2]=='r')
               if(uart_rd[3]=='o')
                  if(uart_rd[4]=='l')
                     if(uart_rd[5]=='y')
                        if(uart_rd[6]=='S')
                           if(uart_rd[7]=='i')
                              if(uart_rd[8]=='m')
                                 if(uart_rd[9]=='o')
                                    if(uart_rd[10]=='n'){
                                       Solenoid=1;
                                       delay_ms(500);
                                       }
       }
    }
 }

void main(){
  OSCCON=0b01101000;       //4Mhz klocka
  TRISA=0b00000010;
  ANSELA=0b000000000;
  C1ON_bit=0;
  SRLEN_bit=0;
  UART1_Init(9600);
  CS=0;
  delay_ms(100);


while(1){
      asm CLRWDT;
      Solenoid=0;
      if(k==400)
        CS=1;
      Recieve();
      if(k>=800){
        CS=0;
        k=0;
        }
        k++;
      }
}

[Shimonu]

Är det bara jag som tycker de nästlade if-satserna sticker i ögonen?

[newbadboy]

Det är nog bara du

[Icecap]

De är definitivt besvärliga!!!

[lillahuset]

Instämmer, det ser ut som skit.
Ett tips är att alltid använda {}. Två skäl. Om du stoppar in en rad efter if () ändras logiken. Om du gör det efter if () { ändras inte logiken. Det andra skälet är att om du använder en vettig editor får du snygg indentering av } och det blir lättare att hitta fel.

[Jan Almqvist]

Lite varning för denna konstruktion:

Kod: Markera allt

char uart_rd[20];
int k=0;

...

       UART1_Read_Text(uart_rd,"\n",255);

Om det kommer fler än 20 tecken innan CR/LF kommer du att "skriva sönder" minnet.

[newbadboy]

Tar mig till förslagen och gör det mer rätt/snyggt