PIC18F2585 uart send complete

Hallo,
ich beschäftige mich eigentlich auch mehr mit Atmel oder Freescale, es 
stellt sich mir aber auch so dar, wie du es geschildert hast. Einen 
Interrupt äquivalent zum "TXC - USART Transmit Complete" habe ich beim 
PIC 18F2585 nicht gefunden. Dort gibt es anscheinend nur ein "TXIF: 
EUSART Transmit Interrupt Flag bit".

Ich vermute du möchtest RS485 im Halbduplex betreiben und dann immer 
Driver/Receiver umschalten?

Ich fürchte, dann musst du das zeitbasiert machen (musste ich letztens 
auch machen).

PicNeuling schrieb:
> Wie wird der Sende Pin für Rs485 bei Pics gesteuert?

Meinst du damit einen Pin, der den Bus-Transceiver umschaltet zwischen 
Receive/Transmit?

Ich habe einen gewöhnlichen GPIO benutzt und kurz vor dem Senden 
umgeschaltet und - zeitbasiert - nach dem Senden abgeschaltet.

Gegenfrage: Gibt es bei Atmels eine Möglichkeit das automatisch zu 
machen (außer mit einem GPIO)?

Gruß,
Alex

Ich kenne mich mit den Atmels nicht so aus, aber da scheint es so zu 
sein, dass es einen Interrupt gibt, nachdem das TX Register gesendet 
wurde.

Beim PIC gibt es Interrupts über das TXIF solange das Register frei ist. 
Also nach dem Senden wie bei Atmel, aber auch schon vorher, wenn gar 
nichts gesendet werden soll und auch nachher fortdauernd solange das 
TXREG frei ist.
Das kann man als Hinweis auffassen, dass ein neues Byte gesendet werden 
kann. -> Man muss den Interrupt abschalten, wenn man nichts zu senden 
hat.

RS485 habe ich selber noch nie verwendet aber vielleicht hilft die 
folgende Application Note etwas weiter:

AN774 Asynchronous Communications with the PICmicro USART

Das ist mir beim PIC18F26K80 auch aufgefallen und ich denke das wird 
wohl bei allen PIC18 ähnlich sein. Das TXIF Flag kann man so nicht zur 
Auswertung heran ziehen. Sobald das Sendregister leer ist, geht TXIF auf 
H und läßt sich auch nicht löschen. Fragt man in der Interruptroutine 
also nur TXIF ab, wird der Code (Wenn das Senderegister zufällig leer 
ist. Und das ist es ja fast immer :) auch bei einem Timerinterrupt 
ausgeführt. Aber jetzt kommt das Erfreuliche. Ein TX Complete Interrupt 
wird trotzdem korrekt ausgelöst. Ob das ein Bug ist oder so gewollt ist? 
keine Ahnung. Die Erratas schweigen sich dazu leider aus. Ich habe das 
für mich so gelöst, das ich TXIF an letzter Stelle im der 
Interruptroutine abfrage und bei den vorherigen Int's mit einem goto 
hinter TXIF springe. Wenn das Programm also bei TXIF ankommt, kann es 
nur noch der TX Int sein. Ist zwar nicht die sauberste Methode, aber 
funktioniert.

1

void InterruptServiceLow(void)

2

{

3

  // Timer0 Interrupt

4

  if (INTCONbits.TMR0IF) {

5

    TMR0L = T0_FREQ;

6

    INTCONbits.TMR0IF = 0;  // Clear T0 Int Flag

7

8

    ...

9

    goto LOW_ISR_END;

10

  }

11

12

  // CAN Receive Buffer 0 Interrupt Flag 

13

  if (PIR5bits.RXB0IF) {

14

    if (RXB0CONbits.RXFUL) {

15

      CAN_ReceiveMessage ();

16

      RXB0CONbits.RXFUL = 0;

17

    }

18

    PIR5bits.RXB0IF = 0;  // Clear the received flag.

19

    goto LOW_ISR_END;

20

  }

21

22

    /** USART TX Interrupt ********************************************************

23

    *** Wichtig: Das TX Int Flag wird nicht gelöscht. Es zeigt nach einem

24

    *** Interrupt eigentlich nur an, das das TX Senderegister wieder beschrieben werden

25

    *** kann. Deswegen steht dieser Interrupthandler an letzter Stelle.  Wenn wir

26

    *** hier ankommen, kann es nur noch der TX Int sein. In jedem anderen Handler

27

    *** wird nach Abarbeitung mit Goto ISR_Ende: diese Routine übersprungen

28

    ******************************************************************************/

29

    if (PIR1bits.TX1IF) {

30

      if (PIE1bits.TX1IE)

31

        UART_TX_ISR ();

32

    }

33

34

  LOW_ISR_END:;

35

}

Gruß, Steffen

Steffen N. schrieb:
> Fragt man in der Interruptroutine
> also nur TXIF ab,

Frag einfach immer auch das IR-Enable mit ab!
(Ist halt so bei IR auf einen Vektor ...)

1

void high_isr(void)

2

{

3

    if(INTCONbits.TMR0IE && INTCONbits.TMR0IF){ // if timer 0 overflow

4

        mTOG_LED_3(); // then toggle LED

5

        INTCONbits.TMR0IF = 0; // and clear flag

6

        return;

7

    }

8

//    if (interrupt_2_enabled && interupt_2_flagged){

9

//      ...

10

//      return;

11

//    }

12

13

    while(1){;} // Endloschleife → finde unvorhergesehene interrupts

14

}

Volker S. schrieb:
> Frag einfach immer auch das IR-Enable mit ab!
> (Ist halt so bei IR auf einen Vektor ...)

Da hats Du natürlich vollkommen recht, nur löst diese Vorgensweise das 
Problem mit TXIF nicht. Ist beim PIC18 eben so und betrifft auch nur das 
TXIF Flag.