Das Problem beim Senden von AT90CAN128

>Aber es kann der Grund sein, dass ich
>nur ein AT90CAN128 habe und der keine Rückmeldung vom anderen
>CAN-Controller bekommen kann, schickt der immer die Nachrichten aus.

Das dürfte der Grund sein. Kann der AT90CAN128 vielleicht den 
Loop-Back-Modus? Dann wäre es ihm egal, ob da ein anderer Controller am 
Bus vorhanden wäre.

Vor allem sollte auch ein R am Ausgang die rausgehenden Daten zurück zum 
Eingang bringen, sonst sendet der Controller seine ID und stellt bei der 
ersten 1 fest, dass am Eingang 0 ist, also ein Hochrangigerer Frame auf 
der Leitung ist, schaltet das senden ab und versucht die reinkommende 
Nachricht zu lesen.

Hi tex,

danke für deine Info. Die Widerstäde (je 120 Ohm) habe ich schon auf dem 
bread board gelegt, die als Terminal (parallele Schaltung) funktionieren 
sollten. CANL und CANH sind auch mit den Widerständen angeschlossen. 
(CANH auf einer Seite, CANL auf der anderen Seite). Ich weiss nicht, ob 
das von dir gemeint ist.
Der Eingang von dir gesagt habe, weiss ich nicht ganz genau. Im Programm 
habe ich nur eine Sendefunktion geschrieben, Empfangsfunktion habe ich 
noch nie eingetippt. Ich möchte nur mal schauen, ob das Senden 
funktioniert. Muss ich  noch die Empfangsfunktion schreiben, um das 
dauerhafte Senden zu vermeiden?

Viele Grüße
Juan

>Der Eingang von dir gesagt habe, weiss ich nicht ganz genau. Im Programm
>habe ich nur eine Sendefunktion geschrieben, Empfangsfunktion habe ich
>noch nie eingetippt.

Das ist eine Grundfunktion des CAN-Controllers und von der 
Programmierung erst einmal unabhängig. (siehe Beschreibung im Datenblatt 
AT90CAN128). Du brauchst einen Weg über den das gesendete Signal zum 
Sender zurückkehrt, damit selbiger merkt, das sein Signal nicht verloren 
ging. Am einfachsten geht das mit einem CAN-Teilnehmer, dann sieht man 
auch gleich was aus den Daten geworden ist, die man gesendet hat. 
Ausserdem musst Du die Anzahl der Wiederholungen in der Software 
begrenzen, sonst sendet Dein CAN die einmal abgesetzte Nachricht so 
lange, bis sie empfangen wurde.

>Die Widerstäde (je 120 Ohm) habe ich schon auf dem
>bread board gelegt, die als Terminal (parallele Schaltung) funktionieren
>sollten.

Damit verhinderst Du nur, dass die Daten am Leitungsende reflektiert 
werden. Was Du aber brauchst ist eine Kopplung die das Ausgangssignal 
(vor dem Bustreiber) an den Eingang leitet damit der Eingang keine 0 
sieht, wenn am Ausgang eine 1 anliegt.

Hi tex,

Im Moment habe ich eine Platine von OLIMEX, darauf stehen der MCU 
(AT90CAN128) , RS232 Interface (einschließlich MAX232, Pegelumsetzer) 
und CAN Interface (einschließlich CAN Transceive oder Treiber MCP2551). 
Die Kopplung, die du meinst, ist nicht mehr einsetzbar.
Die Anzahl der Widerholungen in dem Programm habe ich gar nicht gesetzt 
und ich machte sogar nicht mit der unendlichen Schleife (while (1)). 
Aber sendet  der immer wieder dasselbe Signal aus. Der Grund dafür 
wahrscheinlich ist, dass es keinen anderen Busteilnehmer (z.B. anderer 
AT90CAN128 als Empfänger) gibt, der ein Acknowledge Signal zurücksenden 
kann. Solang der AT90CAN128 keine Rückmeldung von anderem Busteilnehmer 
bekommt, sendet er Signal dauerhaft. Dank für deine Antwort im Voraus.

Viele Grüße
Juan

>icht mit der unendlichen Schleife

Vielleicht resetet sich der Atmel dadurch selbst und beginnt das prg von 
neuem? => periodisches senden
Poste doch mal den Code..

>amit selbiger merkt, das sein Signal nicht verloren
>ging.

Das müsste man am Oszi sehen: Atmel beginnt zu senden, während der 
Arbitrierung bricht er ab, und fängt (nach einer Zeit x) neu an zu 
senden.
Allerdings sollte dann nie das komplette CAN-Paket auf dem Oszi zu sehen 
sein...

Hallo lippy, tex :))

beigefügt hänge ich die Code und die Bilder vom Oszi an. Die Code ist 
einfach, dort gibt's keine unendliche Schleife, aber das Ergebnis sieht 
im Bild. Im Bild 1 stehen die periodischen Signale, die grüne Kurve ist 
CANH und die blaue Kurve CANL. Die Signale zwischen zwei Cursors kann 
man feststellen, dass das 8 Byte Data ist (s. im Programm, vordere 4 
Byte 0xAA, hintere 4 Byte 0xDD). Aber die ID Nr. kann gar nicht mit dem 
Programm übereinstimmen. Schau mal zuerst bitte an. Danke!

Viele Grüße

Juan

ohne ack von einem anderen wird das alles nichts, wie schon mehrfach 
angemerkt.
Das "intelligente" CAN erkennt, dass die Botschaft offensichtlich von 
niemandem erkannt wurde - und versucht es halt wieder. Irgendwann müsste 
er aber aufhören, den Bus vollzupusten und sich zurückziehen.

ändere mal deine main zum testen so ab:

1

int main ()

2

{  

3

  struct MOb msg;

4

5

  msg.ID = 0xCC;

6

  msg.data[0] = 0xAA;

7

  msg.data[1] = 0xAA;

8

  msg.data[2] = 0xAA;

9

  msg.data[3] = 0xAA;

10

  msg.data[4] = 0xDD;

11

  msg.data[5] = 0xDD;

12

  msg.data[6] = 0xDD;

13

  msg.data[7] = 0xDD;

14

15

  CAN_Init();

16

  sei();

17

  CAN_Transmit(msg);  

18

19

        while(1);           // das bitte dazuschreiben  

20

21

  return 0;

22

}

Hallo crazy horse,

du meinst das nicht von dem Programm abhängt, oder? Aber eine weiter 
Frage ist, wieso kann die ID Nr. nicht mit dem Programm miteinander 
übereinstimmen?
Hast du noch Ahnung davon? Vielen Dank.

Viele Grüße

Juan

Hi Lippy,

hab schon versucht, aber funktioniert das nicht. Trotzdem danke ich dir 
herzlich.

Viele Grüße

Hallo zusammen,

das Problem zur ID. Nr ist schon gelöst. Das Bild ist OK, ich habe 
vergessen, dass es im CAN Frame immer Bitstopfen gibt, d.h. nach 5 
gleichpoligen Bits wird ein Stopfbit eingesetzt. Dann sieht die ID. Nr 
im Bild ganz klar. Für ihre Hilfe danke ich euch.

Viele Grüße

Juan