Atmega162, SJA1000, Zeitverzögerung\Verschlucken von Nachrichten

[Meiner (Gast)]

Hi,

ich hab momentan folgendes Problem: Ich habe grade eine Platine vor mir 
liegen, bei der acht SJA1000 Can-Controller über einen Atmega162 (16 
Mhz) betrieben werden. Zur Programmierung wird die Can-Lib von 
"kreatives-chaos". Das Board ist nicht von mir und wurde wohl schon für 
einige Projekte erfolgreich eingesetzt.

Momentan soll das Board dazu genutzt werden, einfach einen Can-Bus zu 
spiegeln, sprich CAN1 -> CAN2 (100k Baud). Das Problem liegt darin, dass 
bei der zu erwartenden Sequenz von 5-6 Messages (aufgezeichet per Canoe) 
manche Nachrichten mit extremer Zeitverzögerung (oder auch mal gar 
nicht) gespiegelt werden. Mit Canoe kann außerdem beobachtet werden, 
dass die Bus-Auslastung auf CAN2 deutlich kleiner ist als auf CAN1. 
Filtere ich hier nach und nach Nachrichten raus, normalisieren sich die 
Buslasten.

Das Verhalten lässt sich auch über Canoe mit nur einer Nachricht 
erzwingen, indem die Zykluszeit auf geringe Werte (z.B. 10-20ms) gesetzt 
wird.

Der Programmcode besteht dank CAN-Lib eigentlich nur aus der 
Intialisierung der Baudrate, sowie der Abfrage in einer 'while' 
Schleife, ob eine Nachricht auf CAN1 empfangen wurde. Wenn ja, wird die 
Nachricht auf CAN2 gesendet.

Ich komme an dieser Stelle nun nicht so recht weiter. Worin könnte hier 
das Problem liegen? Ist der µC bzw. der Controller irgendwie überlastet? 
Schafft der solche Zykluszeiten nicht? Falls jemand mir helfen kann, 
wäre ich sehr dankbar.

[Peter D. (peda)]

Meiner schrieb:
> Zur Programmierung wird die Can-Lib von
> "kreatives-chaos".

Du erwartest hoffentlich nicht, daß jemand sich die Lib erst selber 
suchen muß.

Meiner schrieb:
> Worin könnte hier
> das Problem liegen?

Ohne kompletten Source, nicht zu sagen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Meiner schrieb:
> Das Problem liegt darin, dass bei der zu erwartenden Sequenz von 5-6
> Messages (aufgezeichet per Canoe) manche Nachrichten mit extremer
> Zeitverzögerung (oder auch mal gar nicht) gespiegelt werden.
Ich tippe auf Software...

> Ist der µC bzw. der Controller irgendwie überlastet?
Kann sein.

> Schafft der solche Zykluszeiten nicht?
Wenn er ungünstig programmiert ist....

> sowie der Abfrage in einer 'while' Schleife, ob eine Nachricht auf CAN1
> empfangen wurde. Wenn ja, wird die Nachricht auf CAN2 gesendet.
Du solltest die Nachrichten in einem Fifo/Ringpuffer puffern. Was, wenn 
der CAN2 mal einen Fehler hat und das 3. von 16 Telegrammen /wiederholt 
wiederholen/ muss?

[Meiner (Gast)]

Peter Dannegger schrieb:
> Meiner schrieb:
>> Zur Programmierung wird die Can-Lib von
>> "kreatives-chaos".
>
> Du erwartest hoffentlich nicht, daß jemand sich die Lib erst selber
> suchen muß.
>
> Meiner schrieb:
>> Worin könnte hier
>> das Problem liegen?
>
> Ohne kompletten Source, nicht zu sagen.

Hier der Link: 
http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek . 
Hatte ich vergessen, weil ich bei meiner Recherche hier im Forum auch 
schon öfter drüber gestolpert bin. Hatte angenommen, dass die evtl. 
bekannt ist.


Der Programmcode sieht so aus:

#define UCU_CAN CAN1
#define HDSG_CAN CAN2

int main(void) {
  can_t sReceivedMessageOnUcuCAN;
  can_t sReceivedMessageOnHdsgCAN;
  io_init();
  cs_init(BITRATE_100_KBPS, UCU_CAN);
  cs_init(BITRATE_100_KBPS, HDSG_CAN);
  _delay_ms(0); /* no delay after system start*/
    
  while (1) {
    /*------------------------------------------------------------------
     *Mirror UCU-CAN on HDSG-CAN
     *----------------------------------------------------------------*/
    if (cs_get_message(&sReceivedMessageOnUcuCAN, UCU_CAN)) {
      if (cs_send_message(&sReceivedMessageOnUcuCAN, HDSG_CAN)) {
        // LED an oder sonstiges
      }
    }
  }
}

Lothar Miller schrieb:
> Meiner schrieb:
>> Das Problem liegt darin, dass bei der zu erwartenden Sequenz von 5-6
>> Messages (aufgezeichet per Canoe) manche Nachrichten mit extremer
>> Zeitverzögerung (oder auch mal gar nicht) gespiegelt werden.
> Ich tippe auf Software...
>
>> Ist der µC bzw. der Controller irgendwie überlastet?
> Kann sein.
>
>> Schafft der solche Zykluszeiten nicht?
> Wenn er ungünstig programmiert ist....
>
>> sowie der Abfrage in einer 'while' Schleife, ob eine Nachricht auf CAN1
>> empfangen wurde. Wenn ja, wird die Nachricht auf CAN2 gesendet.
> Du solltest die Nachrichten in einem Fifo/Ringpuffer puffern. Was, wenn
> der CAN2 mal einen Fehler hat und das 3. von 16 Telegrammen /wiederholt
> wiederholen/ muss?

Das wird intern (in einem kleinem Wrapper um die CAN-LIB) bereit getan. 
Ein Auszug:

/*=============================================================================
 * transmit-buffer-array : one buffer for each channel
 *============================================================================*/
struct Buffer {
  can_t data[BUFFER_SIZE]; /*array of can messages*/
  uint8_t read; /* link to the oldest message*/
  uint8_t write; /* link to an empty field*/
} buffer_array[NUMBER_OF_CHANNELS];

und gesendet wird über

uint8_t cs_send_message(const can_t *msg, can_controller_id_t controller_id) {
    chip_select(controller_id);
    if (!can_check_free_buffer()) // TX buffer full
    {
      if (msg == NULL)
        return TRUE; // nothing to send
      if (BufferIn(msg, controller_id))
        return TRUE; // buffer not full
      else
        return FALSE;
    } else // TX buffer not full
    {
      can_t *msg_to_send = NULL;

      if (BufferOut(&msg_to_send, controller_id)) // buffer not empty
      {
        can_send_message(msg_to_send); // send oldest buffered message
        if (msg != NULL)
          BufferIn(msg, controller_id); // store new message for later
      } else // buffer empty
      if (msg != NULL)
        can_send_message(msg); // send new message

      return TRUE;
    }
}

"BufferIn" schreibt neue Nachrichten in den Buffer, "BufferOut" liefert 
die Älteste und die "chip_select" Funktion schaltet die entsprechenden 
Can-Controller.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Meiner schrieb:
> "BufferIn" schreibt neue Nachrichten in den Buffer
Du schienst da irgendwie die Rückgabewerte gar nicht zu verwenden oder 
auszuwerten:

    if (!can_check_free_buffer()) // TX buffer full
    {
        return TRUE; // nothing to send
        :
        :
        return FALSE;
    } else // TX buffer not full

> Der Programmcode besteht dank CAN-Lib eigentlich nur aus der
> Intialisierung der Baudrate, sowie der Abfrage in einer 'while'
> Schleife, ob eine Nachricht auf CAN1 empfangen wurde.
Und der config.h, in der wesentliche Einstellungen vorgenommen werden...

> manche Nachrichten mit extremer Zeitverzögerung (oder auch mal gar
> nicht) gespiegelt werden.
Hast du den Thread dort auch gelesen? Da taucht immer wieder so ein 
Problem mit "verlorenen" Nachrichten auf, z.B. auch am 20. Juli 2011