PIC RS232 Interrupt C18

code??? ja hier ...

Der Code ist in den USB Framework eingebettet... Ich kopiere nur die 
Wichtigen stellen rein, sonst wird es unübersichtlich.

HIER der LOW INT CODE

1

#pragma interruptlow YourLowPriorityISRCode

2

  void YourLowPriorityISRCode()

3

  {

4

5

        // PIC hardware USART Rx interrupt?

6

    if (PIR1bits.RCIF)

7

    {

8

      PIE1bits.RCIE = 0;// DISABLE INTERUPPT

9

10

      buffer_rx = RCREG;

11

12

      if (RCSTAbits.FERR)

13

      {

14

15

      }

16

      else if (RCSTAbits.OERR)

17

      {

18

19

          RCSTAbits.CREN = 0;  

20

          RCSTAbits.CREN = 1;  

21

      }

22

        else // valid byte 

23

        {

24

        write_ringbuffer(buffer_rx);

25

      }

26

      PIE1bits.RCIE = 1;//ENABLE INTERUPPT

27

    }

hier meine USER INIT

1

void UserInit(void)

2

{

3

4

5

  PIE1bits.RCIE = 1;    

6

  IPR1bits.RCIP = 0;

7

  INTCON = 0b11000000;

8

  RCONbits.IPEN = 0;

9

}

Und hier meine USART init.

1

void InitializeUSART(void)

2

{

3

  TRISCbits.TRISC7  =  1;    // RX

4

  TRISCbits.TRISC6  =  0;    // TX

5

  SPBRG             = 0xe2;

6

  SPBRGH             = 0x04;  // 2400 Baud.      0x1386 =2400; 0x04e2 = 9600

7

  TXSTA             = 0x24;  // TX enable BRGH=1

8

  RCSTA              = 0x90;  // continuous RX

9

  BAUDCON            = 0x08;  // BRG16 = 1

10

11

12

13

  //***  PERIPHERAL INTERRUPT PRIORITY REGISTER 1 ***

14

  //  RCIP: EUSART Receive Interrupt Priority bit

15

  //  1 = High priority

16

  //  0 = Low priority

17

  IPR1bits.RCIP = 0; 

18

  //  TXIP: EUSART Transmit

19

  //  1 = High priority

20

  //  0 = Low priority

21

22

}//end InitializeUSART

Peter Haas wrote:
> Vielleicht hat ja jemand ein Laufendes Beispeilprojekt für mich unter C18.

Im Application Maestro kannst Du ein fertiges Modul (inkl. Ringbuffer) 
konfigurieren und den Sourcecode studieren.

@ Severino R.
Danke für den Tipp.

Ich bin gerade dabei das Teil zu Verstehen.
Mein Problem liegt mehr im Handling der Interrupts, was an diesem 
Beispiel sehr gut deutlich wird... Außer des der Interrupt Vektor nur 
für 0x08 da ist. Naja, vielleicht verstehe ich es ja trotzdem ;-).

@  Allgemein: Wiso wird der Maestro nicht mehr weitergepflegt? Ist ein 
schönes Tool.

@Zwirbeljupp: Er wird definitiv nicht ausgelöst. Habe allen Müll beim 
Kopieren rausgeschmissen. Ich Nibble beim empfangen einen Ausgange mit 
LED.
Außerdem hängt dort auch mein Ossi dran. Der Triggert aber ums verrecken 
nicht. Ergo --> kein Interrupt

Irgendetwas habe ich noch nicht beachtet....

Peter Haas wrote:
> Ausßer des der Interrupt Vektor nur
> für 0x08 da ist. Naja, vielleicht verstehe ich es ja trotzdem.

PIC18 haben nur zwei Interrupt-Vektoren: einen für den High-Priority 
Interrupt und einen für den Low-Priority-Interrupt. Die Prioritäten 
kannst du konfigurieren. Im wesentlichen ist der Unterschied, dass der 
Low-Priority durch den High-Priority Interrupt unterbrochen werden kann 
(umgekehrt nicht).
Was den Interrupt ausgelöst hat, musst Du selber anhand der xxIF-Bits 
herausfinden.

> Wiso wird der Maestro nicht mehr weitergepflegt?

Diese Frage solltest Du an support@microchip.com stellen.

Was gäbe es Deiner Meinung nach zu pflegen?

Peter Haas wrote:

> Ich Nibble beim empfangen einen Ausgange mit LED.

Du nibbelst einen Ausgang? Wie machst Du denn das? Mag der das 
überhaupt?

Severino R. wrote:
> Peter Haas wrote:


> PIC18 haben nur zwei Interrupt-Vektoren: einen für den High-Priority
> Interrupt und einen für den Low-Priority-Interrupt. Die Prioritäten
> kannst du konfigurieren. Im wesentlichen ist der Unterschied, dass der
> Low-Priority durch den High-Priority Interrupt unterbrochen werden kann
> (umgekehrt nicht).
> Was den Interrupt ausgelöst hat, musst Du selber anhand der xxIF-Bits
> herausfinden.

Ja, ich dachte soweit hätte ich auch verstanden.

>>Peter Haas wrote:

>> Ich Nibble beim empfangen einen Ausgange mit LED.

>Du nibbelst einen Ausgang? Wie machst Du denn das? Mag der das
>überhaupt?

Nein, ich nibble den Ausgang nicht!!! Mein Fehler, ich Toggle ihn und 
das Mag er. Zu debuggen benutzt ich Macros mit verschiedenen bitmustern. 
Mein Tolles Ozzi (http://www.lecroy.de) WAVERUNNER 104 Xi unterstüzt 
Erkennung auf bitmustern, die werden dann schön Bunt angezeigt. 
Teileweise einfacher als mit dem ICD. Zumal wenn man das USB Framework 
nutzt.

Zwirbeljupp wrote:
> Okay, dann mal Stück für Stück (Achtung, Pseudocode!):
>
>
>
> So, wenn es damit immer noch nicht funktioniert, dann solltest Du Deine
> Hardware mal überprüfen.
> Hast Du denn überhaupt schonmal versucht, das RCIF-bit zu pollen? Das
> Bit wird nämlich auch gesetzt, wenn die Interrupts eigentlich garnicht
> aktiviert sind.
> Sollte das Bit auch beim Pollen nicht gesetzt werden, stimmt was mit
> Deiner Hardware nicht.
>
> gruß
> zwirbelJ

Danke, werde gleich mal schauen, ob ich es zum laufen bekomme.

Hi,

Es läuft jetzt... ABER: ich muss zwirbeljupp mal was erklären... ;-)

Zwirbeljupp wrote:
> Okay, dann mal Stück für Stück (Achtung, Pseudocode!):
>
>

1

> RCIE = 1;   // USART Rx-Interrupt enable bit

2

> RCIP = 0;   // USART Rx-Int. auf low priority konfigurieren

3

> IPEN = 1;   // Die Interrupt-Priority-Levels must Du schon aktivieren,

4

> wenn Du sie auch benutzen willst

5

> RCIF = 0;   // RX-Interrupt-Flag erstmal löschen

6

> 

7

> GIEH = 0;   // high-prio ints hast Du nicht, also abschalten

8

> GIEL = 1;   // low-prio ints aktivieren

9

>

>

Deine Aussage "high-prio ints hast Du nicht" stimmt. Aber "abschalten" 
NEIN.

Es lag nur an diesen einem Verdammten bit. Aus dem Datenblatt-Text ist 
es so nicht sofort ersichtlich aber wenn man sich das Bild anschaut, 
dann ist es eindeutig. Ich habe mal ein Bild mit angehängt.

ALSO GIEH auch =1 ....

CU