Forum: Mikrocontroller und Digitale Elektronik CAN übertragung brich ca. nach 10 sek ab

Vermutlich, weil etwas nicht stimmt.
Ohne Details keine Hilfe möglich.

Stimmen denn alle Übetragungs-Parameter bei allen Knoten überein? Ich
sag mal so Sachen wie Quarz, Geschwindigkeit, Samplepoint,
Busterminierung, Normal-Mode oder Listen-Only-Mode.

Auf beiden Seiten ist die gleiche Hardware (16MHz Quarz). Gleiches
Bittiming natürlich auch. Bus ist mit 120 terminiert.

Ich hab noch was rausgefunden: Die Übertragung bis etwa 10 sek
funktioniert nur wenn der Sender auf One-Shot eingestellt ist. Wenn
nicht, sendet er garnichts.

Der Empfänger ist im Normal Mode.


Wer eine Idee hat, bin über jeden Tipp dankbar!!!

Details bitte! Welche SW, welche Daten??? Sollen wir hellsehen?

Im Anhang Schaltplan und Assembler Code.

Die Sache ist sehr einfach: Der Sender sendet ca. jede Sekunde das
PinA.

Der Empfänger soll sie (bei Interruptereignis) an den PC senden
(Rs232).

Das wars.

Habe jetzt mal eine LED beim Sender (wenn Byte rausgeht) und beim
Empfäger (wenn Interrupt auftritt, Low an INT0). Klappt alles am
Anfang, beide leuchten kurz synchron auf. So wie es sein muss. Danach
bleibt die Empfänger-LED aus (nach 10 sek). ALso muss irgendwo
dazwischen was faul sein.

Keiner eine Idee?

Kann sein dass die CAN Verbindung zu Kurz ist? Die beiden Tranceiver
sind nur testweise über 10cm-Draht verbunden... Terminiert mit 120 Ohm.

Empfängt der Sender seine eigene Meldung? Das muß er, denn
sonst weis er nicht ob die auf den Bus ging. Was sagen den die
Fehlerstati dazu (Error active und passive). Nach einer bestimmten
Anzahl
von Fehlsendungen schaltet der Sender ab, solange bis er Resettet
wird oder andere Meldungen auf dem Bus erkennt (je nach Status).

Gruß
 Martin

"Empfängt der Sender seine eigene Meldung?"

Ist das das mit dem Abfragen des TXREQ-Bits? Denn das hab ich gemacht:


wait_TX_empty:
    ; Verify that Message was send successfully:
    ; If TXB0CTRL.TXREQ clear, then success
    cbi PortB, 4      ; /CS pull down
    ldi temp, 0b00000011    ; READ-Instruction
    rcall spiout
    ldi temp, 0b00110000    ; TXB0CTRL
    rcall spiout
    ldi temp, 0b10011111    ; Dummy Byte
    rcall spiout
    sbi PortB, 4      ; release /CS


    ;temp2 has content of TXB0CTRL
    sbrc temp2, 3      ; Test on TXREQ
    rjmp wait_TX_empty

hi ... les mal den REC und TEC zählerstand aus

wenn der bus physikalisch ok is sind die zähler auf 0 oder nahe 0 ...
hab aber selbst noch nie was anderes als 0 gesehen wenn die verbindung
passt.

wenn die zähler hochzählen hast übertragungsfehler ... dann evtl am
slope widerstand drehen ... der kommt mir mit 200 ohm arg klein vor.
ich arbeite mit 10kOhm.

mfg

so ein scheissdreck

ich habe eine LED Leiste mal an freie Ports gehangen um damit das
Register für die Fehler (EFLG) auszulesen. Blieben jedoch alle aus.
Also keine Fehler....
Mit bleibt jetzt nur zu hoffen, dass irgendein Quarz oder Kondensator
spinnt. Werde alle möglichen Bauteile mal austauschen.

warum 200 ohm als slopewiderstand?

Hallo Markus

Im Datenblatt ist ja überhaupt kein Wert für Rs angegeben, also hab ich
willkürlich gewählt. Der Macher des Boards von www.kreatives-chaos.de
meinte dass er sogar nur eine Drahtbrücke verwendet...

Habs auch schon mit 1KOhm und deinen 10kOhm probiert... nichts
geholfen.

Ich probier grade das REC und TEC auszulesen. REC ist schonmal Null
(Empfängerseite)

Ich hab jetzt mal so programmiert, dass der Sender 3 Bytes sendet:
1. TEC
2. REC
3. EFLG

An der Empangsseite ist innerhalb 10 sekunden auch eine Ausgabe an
rs232 erfolgreich.
Darin sehe ich: TEC hat am Anfang den Wert 1111, REC 0, EFLG auch 0.

Beim nächsten Tripel hat TEC immer eins weniger, die anderen bleiben
0:

1110, 0, 0
1101, 0, 0
...
0000, 0, 0
hier stoppt die Übertragung dann auch

Was heißt das jetzt? Dass der Sender am Anfang viele Fehler aufweist,
und die bei jedem Senden um 1 verringern?
Wo ist die Logik? Sollte der nicht - wenn überhaupt - nur hochzählen?

Hallo hORST,

ich habe mir vor kurzem auch nen CAN-Bus aufgebaut und wie auch Du den
MCP2515 als CAN-Controller genutzt. Allerdings habe ich den Bustreiber
von Philips 82C250 eingesetzt. Habe mir gerade mal das Datenblatt vom
mcp2551 angesehen - kaum ein unterschied. Aus dem Philips Datenblatt
geht für den slopewiderstand an pin 8 folgendes hervor: 3 Verschiedene
modi's:
1.)For high-speed operation...connecting pin 8 to ground.
2.)For lower speeds or shorter bus length...can be programmed with a
   resistor connected from pin 8 to ground.
3.)If a HIGH level is applied to pin 8, the circuit enters a low
   current standby mode.

Zu testzwecken ist Mode 2 angebracht. Als slopewiderstand ist im
Datenblatt ein 50k Widerstand empfohlen, den ich bei mir auch verwendet
habe. Slopewiderstand und dein Bittiming sollten allerdings auch
zueinander passen! Und der Kondensator zwichen Vcc und GND am
Bustreiber sollte auch nicht fehlen.
Hast du deine Busleitung auch verdrillt? (glaube zwar nicht, dass es
daran liegt, aber man weiß ja nie.)

Zu deinem letzten Beitrag:
Dass TEC mit dem Dualwert 1111 beginnt kann auch daran liegen, dass du
ja dort den Empfänger ausliest, wenn ich das deinem Beitrag richtig
entnehme.

Probier das mit dem Slopewiderstand mal aus und schraub am besten noch
dein Bittiming etwas herrunter. Wenn es dann immer noch nicht
funktioniert einfach nochmal posten.

Hallo hORST,

ich hatte schon mal das Problem, dass die Kommunikation zum MCP durch
Interrupts unterbrochen wurde. Das Verhalten war dann ganz ähnlich wie
bei dir, nach ein paar Sekunden war keine Kommunikation mehr auf dem
Bus.

Ein anderes Problem hatte ich mit dem SS\ Pin. Auch wenn der als
Ausgang verwendet wird, sobald dort ein low Pegel anliegt schaltet die
SPI in den Slave Mode, egal was gerade sonst passiert (aber das scheint
bei Dir ja nicht der Fall zu sein).

Viele Grüsse

Volker

Wenn TEC um eins nach unten zählt, ist vermutlich ein Überlauf
aufgetreten, d.h.er hat um 15 oder 31 ... nach oben gezählt. Ich kenne
den Baustein nicht, aber hier musst Du die Suche ansetzen.

Was auf jeden Fall von Vorteil ist, wenn man einen CAN-Dongle am PC
hat, der mitprotokolliert, was los ist. Gibt es bei Eb** zuhauf für die
Autoschrauber. Z.b. Ixxat, Lawicel, Peak oder Selbstbau. z.B.
http://cgi1.ebay.de/ws/eBayISAPI.dll?ViewItem&item=8049051312

Ganz was feines sind die Profigeräte von Vector (CANscope: 3300 Eur)
und Gemac (CBT: 2400 Eur)
http://www.gemac-chemnitz.de/pages/d_html/produkte/bus-tester/new-de-can-bust.html

Oder das non-plus-ultra:
http://www.lecroy.com/tm/products/scopes/default.asp?mseries=26
http://www.yokogawa.com/tm/dl/serialbus/tm-serialbus_02.htm
von Agilent und Tek gibts entsprechendes.

Slope-R hatte ich auch genügend rumprobiert. Zuletzt war meine
Einstellung: 10kbps Can Speed und 53kOhm Slope-R.

Ergebnis dasselbe.

Hab auch mal das SJW um den Samplapoint auf +/- 2 TQ erhöht. Auch ohne
Erfolg.

Werd dann mal weiter rumprobieren und wieder nen ganzen Tag
verschwenden.

ich hab für nen 100 kbit bus und 10 k slopewiderstand folgende werte

CNF1 0x04
CNF2 0xB8
CNF3 0x05

der TEC sollt am anfang wenn ich mich net irre null sein und zählt bei
einem sendefehler hoch und bei einem erfolgreichen senden wieder runter

was ich bei nem kurzen blick in den code gesehen hab ... du gehst net in
den configuration mode um die CNF1 -3 zu schreiben. muss man zwar nach
einem power up und reset nicht aber da komischerweise auch der TEC
count am anfang nicht auf 0 ist könnte es sein das da was schief läuft

Also ich habe gerade nochmal im Datenblatt des MCP2515 nachgesehen. Bei
deinen oben angegebenen Werten der Error counter bleibt der Controller
auf jedenfall Error-aktiv, also kann es daran schonmal nicht liegen.
Ich sehe gerade, dass dein TEC, REC und EFLG ja doch vom Sender kommen.
Das bitte ich dann in meinem obigem Beitrag zu enschuldigen. Es ist gut
möglich, dass die CAN-Spezifikation den initialen TEC-Wert mit
16(dezimal) festlegt. Allerdings ist merkwürdig warum die Übertragung
genau bei TEC=0 abbricht....?

Geht man davon aus, dass TEC weiter runter zählen würde, so hätte TEC
im nächstn schritt einen Wert von 255 und dein Controller würde sich
folgerichtig in den Error-passive Zustand begeben. In diesem könnte er
allerdings noch Nachrichten senden womit das also auszuschließen ist.

Nehmen wir nun mal an, dass er die letzte Nachricht sendet und nach
erfolgreicher Übertragung TEC von 1 auf 0 inkrementiert. Da hier ja eh
alles falsch herum läuft könnte man ja annehmen das der Controller mit
TEC=0 die Bedingung für den Bus-off Zustand TEC>255 als erfüllt ansieht
und sich somit in diesen Zustand begibt.
Mein Vorschläg wäre: Schließ die RS-232 mal an deinen Sender an und
lies den Zustand des Transmitters nach dem sendeabbruch mal aus.

Und poste bitte deine Ergebnisse direkt, dass interessiert mich nämlich
brennend was mit deinem Controller da abgeht.

Ja, so ähnlich ging es mir am Anfang meiner CAN-Karriere (vor 3 Jahren)
auch, zuerst mit den Identifiern, kürzlich mit Teilnehmern, die nach
5-30 Stunden einfach nicht mehr sendeten, trotzdem alle 3 Sendepuffer
voll waren. Dann waren da noch Teilnehmer, die ab und zu unter anderer
ID Telegramme verschickten.
Dabei hatten wir CAN ausgewählt, weil das angeblich so sicher sei.

Ursache war, dass der µC eine PLL hat, und die jittert immer ein
bißchen, der CAN-core wurde direkt aus dem Quarz versorgt, welcher
felsenfest war. Die temporäre Nichtsynchronität hat den CAN-core etwas
durcheinandergebracht. Wer denkt denn an sowas?
Abhilfe: CAN auch von der PLL versorgen.

Hast Du die GND beider Schaltungen miteinander verbunden?

Vielleich kann mal einer der anderen Poster einen Code zur Verfügung
stellen, damit festgestellt werden kann, ob es an der HW oder an der SW
liegt. Denke mal eher an die SW.

Datenrate spielt bei der HW nur mit langen Leitungen eine Rolle (bei
der SW könnte es jedoch auch Timing-Probleme geben).

Kurze Leitung macht gar nichts aus, evtl. kannst Du die Bustreiber ganz
weglassen und wired-or-Betrieb machen
            +5V
            4k7 PullUp
CANrx--------+------------------+--------CANrx
             |                  |
CANtx---|<|--+                  +--|>|---CANtx

CANgnd-----------------------------------CANgnd

Hat das schonmal getestet? Ich nämlich noch nicht, sollte theoretisch
funktionieren.

So kannst Du die Treiber mal ausschließen.

Ich habe glaube ich gerade einen Fehler in deinem Programm entdeckt.
Da ich derzeit kein ATmega datenblatt zur Verfügung habe weis ich auch
nicht genau welchen SPI-Modus du Benutzt. Ich gehe jetzt einfach mal
von Mode 0,0 aus.
Der MCP2515 fordert es so:
Daten die via SPI zum MCP gesendet werden übernimmt der MCP mit der
Rising Edge von SCK.
Doch jetzt Achtung: Der MCP stellt Daten auf seinem SlaveOutput pin zur
falling edge von SCK zur Verfügung.
Der Sampling Point muss jeweils im Atmel umgeschaltet werden!
Bsp. Read-Instruction:
<Sampling on rising edge>...
Sende Read-Instruction
Sende Adresse
<nun Sampling on falling edge>
Sende Dummy Byte
<und wieder zurück auf Samling on rising edge>

Diese Umschaltung habe ich in deinem Programmcode nicht gefunden.
Könnte also daran liegen.

Obiges Bsp. nochmal als C code:

uint8_t spi_read(uint8_t address) {
  SPI_PORT &= ~(1<<N_SS);  // /SS auf low
  SPDR = 0x03;
  while(!(SPSR & (1<<SPIF))) {
    asm volatile ("nop"::);
  }
  SPDR = address;
  while(!(SPSR & (1<<SPIF))) {
    asm volatile ("nop"::);
  }
!  SPCR |= (1<<CPHA);  // Samling on falling edge
  // damit SCK 8 mal tacktet; don't care; und SPIF cleared
  SPDR = 0x00;
  while(!(SPSR & (1<<SPIF))) {
    asm volatile ("nop"::);
  }
!  SPCR &= ~(1<<CPHA);  // Sampling wieder on rising edge
  SPI_PORT |= (1<<N_SS);  // /SS wieder auf high
  return SPDR;
}

ich probier da sgleich mal, obwohl es im Datenblatt so aussieht, als
wenn bei SPI OUT auch auf rising Edge gewartet wird. Siehe Seite 68
(Figure 12-11).

Aber wenn ich mir das Bild darüber ansehe (INPUT TIMING) werden die
Daten ja garnicht bei rising reinheholt, sondern bei falling....

oder zählt der Zeitpunkt in der Mitte des Bits?

In der Tat sieht es bei Figur 11.11 (SPI Output Timing) beinahe so aus
als würde sich der Pegel auf SO zwichen Vorder- und Rückflanke von SCK
nicht ändern, davon kann aber nicht ausgegangen werden.

Auf Seite 61 unter Punkt 11.1 stehts aber auch nochmal Schwarz auf
Weiß:

....Commands and data are sent to the device via the SI
pin, with data being clocked in on the rising edge of
SCK. Data is driven out by the MCP2515, on the SO
line, on the falling edge of SCK.....

Zu deinem Beitrag von 17:24h:
Die Daten werden beim Input Timing mit der rising edge übernommen. Auf
meinem Datenblatt ist das beim Input Timig recht eindeutig zu erkennen.

Stimmt, hätte man immer an falling Edge anpassen müssen. Danke für den
Tipp. Das habe ich gemacht: jede READ-Instruction hat nun eine
Umschaltung. Im Anhang der Sende-Ablauf und die Ausgabe am seriellen
Port (jetzt am Sender angeschlossen).

Die Bytefolge ist: TEC, REC, EFLG
Das Muster 10101010 ist das Dummybyte und wird plötzlich auf der SPI
Rückbahn reingeholt, obwohl es nur rausgehen soll.

Was man sieht ist mir nicht so ganz klar..

Dann hängt er sich wieder auf, die LED geht nicht mehr aus (da wohl das
TXREQ-Flag immer high ist)

Sind die Fuses vielleicht falsch (Anhang)?
Ich habe einen externen 4MHz Quarz (HC18).

Ich habe jetzt mal die beiden Transceiver 2515 auf beiden Seiten
getauscht. Ein anderes Verhalten. Die Empfänger LED löst nicht mal mehr
innerhalb der ersten 10 sek. aus. Kann sein dass einer defekt ist??

klar kann das sein.
verbinde die beiden doch mal direkt, wie ich um 16:04 schrieb.

Liest Du eigentlich, was ich mir aus den Fingern sauge?
Antworten auf meine Fragen kommen nämlich eher spärlich.

Hi Profi

danke. nee ich hab das schon gelesen, war aber vorher noch beim
durchforsten meines Codes.

>> Abhilfe: CAN auch von der PLL versorgen.
Was meinst du damit? Die OSC-Eingänge mit dem Quarz des AVR verbinden?


>> Hast Du die GND beider Schaltungen miteinander verbunden?
Jap, ist alles auf einem Steckbrett.

Das mit dem direkten Verbinden hab ich noch nicht gemacht, weil ich
nicht weis wie dieser wired-or betrieb ist.
Was heißt |<| ?
Du verbindest die CanH und CanL Leitungen mitnander?

Das soll eine Diode sein, möglichst keine 1N4001, sondern eine
schnellere, z.B. 1N4148 o.ä.
Die bewirkt, dass low (dominant) Priorität vor high (rezessiv) hat.

Wenn ich mir das nochmal überlege, ist es eher wired-AND.
A B X
0 0 0
0 1 0
1 0 0
1 1 1
Aber der Plan stimmt schon so.
Wired or ist es, weil die Signale Negative Logik (low-active) haben.

mist, hab keine Dioden hier.

Aber wie meinst du das mit dem PLL?

Hi, eine andere Sache...

"Im Anhang Schaltplan und Assembler Code.
Die Sache ist sehr einfach: Der Sender sendet ca. jede Sekunde das
PinA.
Der Empfänger soll sie (bei Interruptereignis) an den PC senden
(Rs232).
Das wars."

Meinst du die RS232 ist schnell genug?!

Na wenn zwischen jeder Übertragung eine Sekunde Platz ist, sollte das
doch reichen?

@ britneypunter

Was meintest du eigentlich mit dem "8 mal taktet"??

Dein Code ist dieser:

!  SPCR |= (1<<CPHA);  // Samling on falling edge
  // damit SCK 8 mal tacktet; don't care; und SPIF cleared
  SPDR = 0x00;
  while(!(SPSR & (1<<SPIF))) {
    asm volatile ("nop"::);
  }

Und ich habe es so umgesetzt:
ldi temp, 0b01010101  ; CPHA = 1 (Sampling on falling edge)
out SPCR, temp
ldi temp, 0b10101010  ; Dummy Byte
rcall spiout
ldi temp, 0b01010001  ; CPHA = 0 (Sampling on rising edge)
out SPCR, temp

Der macht aber ziemlich mist beim Übertragen (ab einem spontanen
Zeitpunkt). Kann sein dass mein Code irgendwas auslässt?
Ich meine das "mittendrin umschalten" braucht ja einige Zyklen... ist
es das was du mit "8 mal taktet" meinst?

Bist du dir sicher dass es dort auf das Umschalten ankommt?
Der Code von kreatives-chaos:
// --------------------------------------------------------------
/*
 *
 */
uint8_t mcp2515_read_register(uint8_t adress)
{
  uint8_t data;

  /* CS low */
  PORTB &= ~(1<<SPI_CS);

  spi_putc(SPI_READ);

  spi_putc(adress);

  data = spi_putc(0xff);

  /* CS high */
  PORTB |= (1<<SPI_CS);

  return data;
}

// ----------------------------------------------------


Er machts auch nicht und behält die rising-edge auch beim Lesen.
Und funktionieren tuts ja.
Oder sehe ich den Schritt grad nicht?

Das "8 mal Tackten" ist einfach noch aus meinen ersten code Segmenten
bei denen ich auch den das SPI zum ersten mal benutzt habe. Es hat die
selbe Aussage wie bei dir "Dummy Byte".

Also in ASM sollte das umschalten nur 1 bis 2 Tackte dauern. Solange
/CS low gehalten wird kannst du dir eigentlich sogar soviel Zeit lassen
wie du möchtest.

Habe mir gerade mal deine Daten angesehen:
TEC startet jetzt nur noch bei 8 und beginnt dann wieder mit dem
runterzählen, kommt aber nicht wirklich bis zu 0. Bleibt bei 3 stehen
während REC plötzlich 255 haben. Schaut man aber mal auf EFLG, so zeigt
dies ja trotzdem 0 an => übertragungsfehler USART!?
Aber im nächsten zyklus wird's interressant: TEC=0 und REC=170 (dez)
sowie EFLG=170 (dez). Wieso REC, du sendest doch nur? Ich sitze gerade
in der DVZ und habe leider auch keinen Zugriff auf meine Sachen, aber
war 170 (dez) nicht der Wert, bei dem der Controller in Error-passive
geht? Und check mal was EFLG=AA (hex) bedeutet.

Hallo!

Ich habe die abgespeckte aktuelle Version im Anhang. Am PC kann ich
über HTerm sehen, dass die gesendeten 2 Bytes ankommen: 11001100 und
00110011
Danach ist Ruhe. Wenn empfangen wird leuchtet auch kurz die
Empfangs-LED (PortA, 0) synchron zur Sende-LED.

Sollte es doch ein SW Problem sein?

Habs eigentlich gut dokumentiert...

@ Profi:
>Ursache war, dass der µC eine PLL hat, und die jittert immer ein
>bißchen, der CAN-core wurde direkt aus dem Quarz versorgt, welcher
>felsenfest war. Die temporäre Nichtsynchronität hat den CAN-core
etwas
>durcheinandergebracht. Wer denkt denn an sowas?
>Abhilfe: CAN auch von der PLL versorgen.

Das würde ich gerne mal probieren, weis nur nicht wie du das meinst!
Kannst du kurz sagen wie ich was anschließen muss?

Dieses CAN-problem betrifft den DSP56F803: der CAN-Core hat verschiedene
programmierbare Clock-Quellen - besser man programmiert PLL mit
Vorteiler als Clock.

Ich riet Dir bereits, einen CAN-Dongle bei eb** zu kaufen, da siehst
Du, was auf dem Bus los ist, und kannst auch gezielt Telegramme
schicken. Dann weißt Du, ob es am Sender oder am Empfänger liegt.

Hast Du bereits den ASM-Code, den der Compiler generiert, mit Deinem
verglichen?

So, bin wieder da!

Erstmal: Respekt an die Optik deiner Quellcode-PDF's!

Habe mir gerade mal dein Bittiming angesehen.
CNF1:
TQ=10 hört sich gut an, habe ich auch (jedoch bei 4MHz).  SyncJumpWidth
hast du 1TQ, ich habe 3TQ. Sollte laut Datanblatt aber kein Problem
sein
CNF2:
PHSEG1 = 8TQ, ich hab 7TQ, jedoch ist dein Propagation Segment mit nur
einem TQ evtl. zu klein. Dieses Segment ist dazu da um nach der
Synchronistation die Buslaufzeit sowie eine kleine verarbeitungszeit
der Teilnehmer auszugleichen. Ich habe dort 2TQ.
CNF3:
PHSEG = 6TQ , habe ich auch.

Da bis zur abtastung PropSeg und PhSeg1 vergehen kommen wir somit auf
die selbe Anzahl TQ => sollte mit deinen einstellungen funktionieren.

Vieleicht liegt es an den 16MHz auf nem Steckbord. Nimm doch mal 4MHz,
brauchst bis auf die SPI config auch nichts zu ändern.

hey britneypunter, das hört sich an als wenn du auch mit mcp's
rumspielst. das wär ja cool wenn wir da gemeinsam den Fehler eingrenzen
könnten!!!!

Eine eeitere Diagnose von mir:
Fehlerregister auslesen (nur Sender). Wie Du, mit 4Mhz Quarz. Habe auch
folgende Komponenten getauscht gegen neue:
ATmega gegen AT90S
mcp2515 alle neu
Steckbrett neu
sowieso neu aufgebaut

Keine Panik vor dem langen Quellcode. Hier hab ich jetzt nur eine
kleine Sendeschleife aktiviert:
Schau doch mal zur Sprungmarke "send:"
Dort werden (per Unterprogramm) TEC, REC und EFLG ausgelesen und dn die
serielle Schnittstelle übergeben. Und das ganze mit 300ms Pause.

Mit HTerm habe ich die Ergebnisse vor mir:
Die etwa ersten 50 Bytes sind nur Nullen. Alles OK dachte ich, keine
Fehler in den 3 Registern!
Danach kamen etwa 20 Bytes nacheinander, die jedoch alle das gleiche
Muster hatten: 10101010. Das kann also unmöglich sein, dass es die
Fehlerregister sind.
Danach waren wieder nur Nullen zu empfangen.

Was ist da los? Ich denke dass einfach die falschen Daten gesendet
werden.
Irgendwas bringt vielleicht die SPI Übertragung durcheinander?


Kannst du das Programm bei dir testen?
Schreibst du auch in ASM?

Das muss man doch mal hinkriegen (sitze nun schon etwa 10 Tage an
diesem Problem!!)

Habe ich oben aber irgendwo mal geschrieben, dass ich auch den mcp
benutze. Ist auch mal gerade einen Monat her als ich meinen CAN
aufgebaut habe, von daher ist bei mir auch noch alles frisch abrufbar.

Mit meinem CAN Projekt habe ich dann auch von ASM auf C gewechselt. Mit
dem neuen AVR Studio ist der wechsel auch super leicht.

Leider habe ich meine Steckbords schon geräumt so das ich den Programm
nicht testen kann. Möchte mir schon seit ein paar Wochen ne Platine
anfertigen, bin aber bis jetzt noch nicht dazu gekommen.

Dein Fehler ist echt außergrwöhnlich und deshalb auch interressant.
Ich werde mir mal deinen Quellcode komplett vornehmen und auch mit
meinen Einstellungen vergleichen. Den Fehler finden wir schon!

Hi britneypunter

find ich genial dass du mir dort helfen willst! Wenn du das in C
gemacht hast, kannst du da ein List-FGIle erzeugen, dass den ASM Code
enthält? Vielleicht sollte man das mal mit meinem Code vergleichen?

hallo horst,

ich weiß nicht obs dir hilft, aber ich habe um das bit-timing zu
bestimmen die x-calculator software von warwick benutzt. benütze
allerdings einen µc mit integriertem controller. die software gibts bei
atmel unter:

http://www.atmel.com/dyn/products/product_card.asp?family_id=613&family_name=CAN+Networking&part_id=2501

ganz unten bei "software files".

viel glück!

Danke Ingo, hab aber grad rausgefunden dass es garnicht an der CAN
Übertragung liegt, sondern schon vorher. Ich habe mal mit dem
Loopback-Modus gespielt und dort sieht man schon Schwierigkeiten.

Das seltsamste ist, dass er sich immer mal anders verhält wenn man es
einschaltet. Mal so , mal so. Aber meistens hängt er dann bei der
TX0IF-Abfrage (Zeile 189). Vorher wird das gesendete Byte (11100111)
auch richtig per Loopback in den Empfangsbuffer geschoben und dort
wieder richtig gelesen (rcall getbyte).

Also ich habe den Loopback beim Sender eingeschaltet, das CAN-Kabel
sicherheitshalber entfernt.

Damit konnte der Fehler noch weiter eingegrenzt werden. WIe gesagt
hängt er sich bei beim TX0IF-Pollen auf. Ich habe schon gesucht aber
ich komm auf keine Lösung dort. Wahrscheinlich muss es immernoch am SPI
liegen.

Habe mir mal dein fehlerlesen.pdf vorgenommen und jede Menge zu
beanstanden:

1. SPI config: Im komentar schreibst du SPI clock Rate osc/128, stellst
aber osc/4 ein. Nimm auch osc/128, habe ich auch.

2. Bittiming: Warum hast du dort ein anderes genommen?

3. Du schreibst Loopback Mode, aktivierst aber den Normal Mode. In
meinem Programm habe ich den erst wesentlich später aktiviert.

4. Du schaltest für die RX-buffer Maskierung und Akzeptanzfilter aus,
beschreibst jedoch im nächsten schritt die Mask-Register und dies auch
ziemlich seltsam (nur SID1 und EID6)

5. Dein pdf beschreibt wenn überhaupt nur einen Receiver (im Dokument
steht unten sender.asm), denn

6. ab jetzt liest du nur noch TEC, REC und EFLG aus. Falls du etwas
empangen solltes mußt du dann aber auch die Receive Buffer auslesen,
sonst sendet dein Controller Overload Frames bei jedem weiteren
empfang. Der Overload Frame ist dominant und folglich kommt nichts mehr
an. Dann würden auch die Errorcounter hoch gezählt.

7. Am Bsp. der Subroutine "getbyte": 'rcall wait_10ms' ist nicht
notwendig, du wartes eh bis fertig gesendet ist. 'in temp,SPDR' ist
die ersten 2 mal völlig unnötig, was soll das bringen? Beim letzten mal
macht es sinn, denn du möchtest ja das gelesene byte haben.
Zudem vermisse ich die Umschaltung auf falling edge.

8. Weshalb nutzt du nicht die SPI-Instructions wie z.B Load TX Buffer?
Dann kannst du die Daten auch sequentiell übertragen ohne ständig
wieder die adresse vorzugeben. Deinen TX code-teil nutzt da aber ja in
diesem Programm garnicht, ist mir nur aufgefallen.

Stell mir mal deinen richtigen Code zur verfügung, bei dem du die
Datenbytes auch empfangen hast.

stimmt, 1.-4. sind Schreibfehler, ziemlich unhöflich von mir, sorry.

Ich werde mir das jetzt nochmal vornehmen, aber vorher noch was:

5.) Das ist der Code für den Sender (das USART ist hier nur mit drin um
die Fehlerregister auszulesen). Oder woran siehst du das ein Empfänger
sein muss?

6.) Das wusste ich noch garnicht, dass dann Overloads auftreten.

7.) Das "in temp,SPDR" ist meiner Meinung doch immer nötig um weitere
SPI-Befehle auszuführen. Dadurch, dass man SPDR ließt, wird SPIF auf
Null gesetzt und somit SPDR wieder verfügbar. Ist es nicht so? Oder
braucht es garnicht beachtet zu werden?
Das mit dem Flanken-Umschalten ist m.E. nicht nötig. Habe mehrere Leute
gefragt, die es auch nicht implementiert hatten. Ich habs aber auch
schon probiert. Leider kam ich auf noch mehr Müll als schon vorher.
Sicher dass das sein muss?

8.) Bei "Load TX Buffer" weis ich nicht wie weit der ließt. Ich habe
ihm ja schließlich nicht gesagt wieviele Bytes überhaupt
gesendet/empfangen werden müssen. Aber ginge natürlich trotzdem.
Wahrsch. wäre der Rest dann Nullen (?)

zu 5.)
send:
   rcall erroroutput
   rcall wait_100ms    ; das 3 mal
   rjmp  send
In erroroutput liest du TEC, REC und EFLG und gibst diese an die
USART.
Und dass dann periodisch, oder sehe ich das falsch?

zu 7.) Hast recht, ich erinnere mich noch schwach an sowas. Beim
Debuggen habe ich aber festgestellt, dass der atmel das SPIF beim
nächsten schreiben von SPDR selber löscht.

zu 5.) jepp, ist hie rnatürlich nur zum Debuggen eingebaut. Mit
"Sender" ist natürlich nur gemeint dass dieser CAN-Signale sendet und
nicht empfängt.

Aber er kommt doch garnicht zum senden, was willst du denn da Debuggen?
Poste oder schick mir doch mal dein 'normales' Programm (Sender und
Empfänger), dann kann ich dir bestimmt weiterhelfen.

damit wollte ich nur sehen, ob die SPI Übertragung funzt. Ich hätte
erwartet das die 3 Fehlerregister 0 sind, da ja auch keine Fehler
auftreten können. Da aber dann doch andere Werte drinstanden... muss
ein Fehler in der Kommunikation zum µC bestehen.

Ich werde das normale Programm schnellstens hier posten....

Hab mir gerade mal deinen schaltungsaufbau, den du am 27.03 20:40h
gepostet hast, angesehen. Entspricht dieser Aufbau der Realität? Wenn
ja: Du hast weder am Atmel noch am MCP einen Hardware Reset vorgesehen.
Das ist aber wichtig, damit alle Register Initialisiert werden.

Reset mit 15k Up pullen und mit ca. 100nF Reset auf Masse verbinden.
Damit erreichst du, dass /Reset nach dem einschalten noch kurz auf low
liegt => reset

Am Atmel ist doch der 10K Pull Up dran. Am MCP mache ich den Reset durch
einen SPI Befehl. Sollte laut Datenblatt das gleiche sein. Was meinst
du? Die 100nF hab ich nie so wirklich wichtig genommen...

Nur durch den Pull up am Atmel wird dieser aber nicht Resetet, da muss
schon noch ein Kondensator auf Masse um ein Verzögerungsglied zu
bekommen. Ich denke jedoch nicht dass das dein Problem ist,
funktioniert meistens auch ohne restet. Da ist aber kein verlass
drauf!

Nach dem ich mir deinen quellcode (fehlerlesen.pdf) mal angesehen habe
bin ich mir zu 99% sicher das es an deiner Programmlogik liegt.

Und wie gesagt, ich warte auf dein Programm.

Hallo subsonic

Hier endlich die Codes. Beim Programmtest kam wieder die alte
Erscheinung: Ca. 5 Mal kommt das Byte richtig beim Empfänger an und
wird dort zum PC gesendet. Danach ist Ruhe.

zum reset ...
der atmel und der mcp haben nen automatischen power on reset (wenn die
Betriebsspannung schnell genug ansteigt) ... RC glied am pin muss net
sein, aber 1nF schadet net um störeinstrahlung zu blocken.

Weshalb sicherst du SPCR immer?

hatte mal irgendwo gelesen dass evtl. das MSTR-Bit gelöscht wird.
Deswegen immer sichern,dacht ich mir.

Schaue mir gerade deinen Empfänger Quellcode an:

Du machst gar keine richtige Konfiguration deiner Empfangseinheit. Wenn
Register nicht beschrieben werden können wir ja davon ausgehen dass sie
nur Nullen enthalten.
Da du RXB0CTRL nicht beschreibst werden nur Messages mit Standart ID
oder Extendet ID akzeptiert die mit den Aczeptace-Filtern und der
zugehörigen Maskierung übereinstimmen! Extendet ID brauchst du erst mal
nicht, deshalb empfehle ich RXM = 01, d.h. selbe Bedingug wie oben
jedoch nur mit Standart ID
Du musst also für den Buffer 0 noch folgendes einstellen: Beispielhaft
konfigurieren wir nur einen der 7 Filter mit der ID der zu empfangenen
Nachricht:
RXFnSIDH  =  0x00   // Filter ID high
RXFnSIDL  =  0x00   // Filter ID low
RXMnSIDH  = 0xFF  // Alle bits des Filters verwenden
RXMnSIDL  =  0xFF  // Alle bits des Filters verwenden
Nimm diese Einstellungen noch vor der Aktivierung des Normal Mode vor.
Ich würde auch nicht unbedingt den ID $0000 wählen, nimm besser mal
$0001

Benutze doch um den receive buffer auszulesen die ‚READ RX BUFFER
INSTRUCTION’. Das geht nicht nur wesentlich schneller du sparst dir
sogar das lästige rücksetzen des Receive Flags. Das erledigt diese
Instruction für dich.

Ansonsten ist mir nichts schwerwiegendes aufgefallen

Fällt mir gerade noch ein: Da du RXbuffer 0 benutzt musst du dann auch
Filter 0 oder Filter 1 benutzen, die anderen sind für RXbuffer1.

Ha, habe gerade eine Theorie für dein Problem:
Buffer 0 hat die höchste Prio, d.h. falls dieser frei ist steht deine
Nachricht dort drin. Da du den CAN recht schnell laufen hast und dein
Empfänger bei der USART warten muss bis frei ist, kann es sein, dass
bereits die nächst Nachricht eingertoffen ist. Da du dich aber noch im
Interrupt befindest und den Interrut auch nur bei falling edge
generiertst, bekommt dein Atmel das garnicht mit => buffer 0 wird
überschrieben (oder die Nachricht kommt in buffer 1, welcher dann
sicher später überschrieben würde) und ein Overload wird fällig. Dass
passiert dann bestimmt so oft bis einer Bus-off geht.

Klingt doch gut, oder?

letzteres Problem wollte ich eigentlich aus dem Weg schaffen, dass ich
eine entsprechend lange Intervallzeit am Sender habe. Ca. 2 Sekunden.
Bis die vergehen, sollte der Empfänger doch schon hundert mal wieder
bereit sein was zu empfangen... oder?

Ja, da hast du wohl recht. Naja, dann liegt es daran schonmal nicht.
Da nach ca. 5s nichts mehr geht würden ja dann auch nur 2 Messages
empfangen. Das hört sich dann trotzdem schwer nach nem Overload an, da
genau 2 buffer zur verfügung stehen. Benutz mal die RX Buffer
Instruction, evtl. klapt das mit der Buffer freigabe nach dem lesen bei
dir nicht so wirklich.

Ok hab mal die Filter und Masken so eingestellt, wie du sagtest. Auch
den readrxbuffer-Befehl.

Leider immernoch das Problem.

Hab schon überlegt, ob bei der SPI-Übertragung was schiefläuft. Die 4
SPI Kabel (ca 8cm lang) sind direkt neben einem 4MHz Quarz langgeführt.
Dachte dort gibts evtl. EInflüsse von dem!? Jetzt hab ich die Kabel auf
20cm verlängert und einen weiten Bogen um den Quarz gemacht. Da kommt
dann nur noch ein Byte am Empfänger an. Irgendwie komisch oder?

So, also hardwareseitig kann ich wohl jede Defektität ausschließen. Habe
alles auf eine Platine gelötet mit minimalen SPI-Wegen. Immernoch
dasselbe Problem.... Nach einigen richtig übertragenden Bytes kommt ein
Byte was anders ist und danach ist Ruhe.

Hat jemand eine Idee was hier nicht passt? Ich würde das mal wirklich
gerne wissen!

Könnte jemand mal einen im C Compiler-generierten ASM Code posten? Ich
selbst kriege hier andauernd Fehlermeldungen im WinAVR dass die
include-Dateien nicht stimmen.
Möchte mal das maschinengenerierte mit meinem erstellten ASM testen!
Egal, was genau die CAN-Übertragung macht, ich such mich da schon
durch.

Bin wieder da!

Handelt es sich bei den paar richtig übertragennen Bytes bzw. Messages
immer um die selbe Anzahl bis der Fehler auftritt?
Hat das fehlerhafte Byte immer den selben Wert?

Hi Subsonic.. hatte schon fast Sehnsucht ;-)

Es ist immer anders wenn er was empfängt, man kann nicht vorhersagen
wieviele richtige Bytes ankomen werden und danach kommt auch jedesmal
ein anderes fehlerhaftes Byte.

Ganz schön seltsam.

Im Moment hab ich das aufgegeben, den Fehler zu suchen und mache das
ganze in C. Wenn das läuft, werd ich die ASM Codes vergleichen.

Also eine Overload PDU besteht aus 6 aufeinanderfolgenden dominanten
bits ("0") gefolgt von 8 rezessiven bits ("1"). Die 6 dominanten
bits würden bei einem Identifier von z.B. $001 anfangs dem Sender
granicht auffallen, er sendet also munter weiter, nur dein Empfänger
merkt, dass keine 8 rezessiven bits auf dem Bus sind. Ändere vieleicht
mal deinen Standart Identifier (du nutzt doch standart?!) auf z.B.
$3A5.
Somit würde auch der Sender direkt merken, dass nicht das auf dem Bus
ist, was er gesendet hat. Der Sender erkennt dann das entweder eine
Error-PDU oder Overload-PDU vom Empfänger ausgegeben wurde.
Wenn es etwas damit zu tun haben sollte müsstes du prinzipiell weniger
messages empfangen, bis ein Fehler auftritt, wenn er denn noch
auftritt.

Ist der CAN-Bus nicht was für Profi-Anwender?

Mit einfachen Hausmittelchen einen CAN-Bus betreiben erscheint mir doch
sehr utopisch. Beim UART geht das ja noch: Der nimmt nichts übel und ist
nicht von so vielen Spezifikationen und Eigenleben abhängig. Wir haben
CAN-Bus-Anwendungen  versucht, in kleinen Schritten, zuerst mit Punkt-
zu- Punkt- Kommunikation, aber man tappt doch ziemlich im dunkelen.

Um zu analysieren was auf dem Bus (mit 20 und mehr Knoten) passiert
(Bus Traffic, Identifier, Timings, Statistik, Arbitrierung, usw.),
kommt man um einen CAN Bus Analyzer für den PC schlecht herum. Man kann
ihn sich natürlich selbst programmieren. Ansonsten kostet der uns gerade
mal 5500 Euro.
Oder wer schreibt mir mal einen Low-Cost-CAN-Analyzer + Hardware?

Gruß

Dietmar

wenn man nen can bus controller wie den MCP 2515 nimmt ist eine can bus
anwendung im nicht kommerziellen hobby bereich überhaupt kein problem.

hab 10 stationen seit einiger zeit ohne probleme am laufen ... can
analyzer is da mit kanonen auf spatzen geschossen ;)

Wieviel Prozent Bus-Traffic (Durchschnitt und Peak) findet denn auf den
10 Stationen statt?

Guten Morgen,
hat bei mir auch einige Tage gedauert, bis was lief.
Wenn man den Dreh heraußen hat, ist alles recht einfach.

Sicher gibt es CAN-Analyzer, die braucht man erst dann, wenn der Bus
sehr lange ist, in HF-verseuchter Industrie-Umgebung, oder bei
Zeitkritischen Aufgaben bei hoher Buslast.
Es gibt inzwischen Oszis, die u.a. CAN decodieren können (schreibe
gleich was dazu ins Wiki).

Einfache CAN-USB-Umsetzer kosten neu ca. 200 Euro, für Autoschrauber
habe ich bei eb** schon wesentlich günstigere gesehen.
Im Lieferumfang befindet sich meist ein CAN-MiniMon, auf dem man Pakete
sieht und senden kann. Das reicht für's Erste locker.

http://www.mikrocontroller.net/articles/CAN

@Dietmar: im Link sind auch mehrere Selbstbauanleitungen für Dongles.

so, das C Gestell ist fertig und macht das selbe wie mein ASM Programm
von früher. Und das ist doch mal interessant: Es geschieht daselbe!
Nach ein paar übertragenen Bytes stoppt alles.
Mein Code ist also nicht falsch. Es muss einen anderen Grund geben. Ich
werde jetzt mal am Empfänger nicht nur immer Buffer0 auslesen, sondern
auch Buffer1. Würde mich zwar wundern, aber evtl. empfängt der ja
irgendwann auf dem anderen Buffer (welches nicht gelesen wurde) und
verstopft damit die gesamte Übertragung....

Ja klar, Industrieumgebung und hohe Buslast sind bei mir gegeben. Die
Bitrate wird nach Leitungslänge und Anzahl Busknoten bestimmt, das ist
voll ausgereizt. Der CAN Analyzer hat mir da bisher sehr geholfen. In
meiner Anwendung kann ich mich nicht auf gut Glück oder Zufall
verlassen, die muß bei Inbetriebnahme sauber spielen. Es gibt von
diesen Tools aber auch Low-Cost-Versionen, die möglicherweise
ausreichen, aber man ist ja immer erst hinterher schlauer. Man braucht
nicht alle Features, und ab 500 Euro ist man, glaube ich, auch schon
dabei.

Ich mache mit dem Analyzer Langzeitaufzeichnungen und sehe dann, wenn
eine von 1000000 Messages fehlt oder wann ein Error Frame oder ein
falscher Identifier kam. Bei falschem Identifier (ja, sowas passiert,
wenn sich in einer umfangreichen Software irgendwo Daten überschreiben,
wo man es nicht vermutet) kann man dann in der Software suchen. Ohne
Analyzer, erfährt man über die Softwarefehler so gut wie nichts, man
tappt wirklich etwas im Dunkeln.

Allein eine funktionierende CAN Software von Null an aus dem Boden zu
stampfen, ist ja schon ein Akt für sich. Glücklicherweise haben die
Controller- und Kompilerhersteller da heute Demosoftware, die man als
Ausgangsbasis verwenden kann, und ohne die man etwas aufgeschmissen
wäre.

Einen CAN-USB-Umsetzer verwenden wir im Testautomaten, wo eine
komplette CAN-BUS-Anlage über längere Zeit simuliert wird.

Den Preis 200 Euro haben wir für einen CAN-USB-Umsetzer auch
herausgefunden.

Unser Bus ist auch sehr lang, bis 1 km. Es werden unter anderem alte
Stromversorgungsleitungen aus den 60-er Jahren wiederverwendet, um
Neuverlegungsaufwand zu sparen, aber das dürfte kein Problem
darstellen, da sich auch die Bitrate per Software dynamisch umschalten
läßt.

Habe gerade eine Konstellation mit 15 Knoten am laufen, mit Buslänge 10
m, 250 kBit/s. Wenn ich da kurz einen der beiden
Busterminierungswiderstände öffne (um eine Störung zu simulieren),
gehen schon alle Knoten in den Bus Off Status. Laut ISO-Spezifikationen
kann man den CAN-Controller wieder einschalten und die Fehlerzähler RX
Error und TX Error herunterzählen lassen. Das klappt ein paar mal nach
einem Busfehler, irgendwann hängt aber der CAN-Controller fest und
startet nicht mehr. Dann hilft nur noch ein Reset, über Watchdog oder
wie auch immer. Hat mal jemand ne Ahnung, was das sein könnte? Der TX
Error Zähler steht in so einem Fall auf 0x88 (immer) und der RX Error
Zähler auf 0x00.

Wer Mikrocontroller aus der Philips LPC2000-Serie verwendet, mit 2 oder
4 CAN Controllern, findet dazu bei Keil, Hitex und Philips ausgezeichnet
funktionierende Demo-Software als C-Sourcecode.

Den Link schaue ich mir natürlich noch an. Aber, mit Selbstbau ist das
beim Miniaturisierungstrend so eine Sache. Eine Platine für den LPC2000
kann man vielleicht noch layouten, aber kann man die mit dem feinen
Pitch auch noch selbst löten? Leider bekommt man die Halbleiter
zunehmend nur noch in immer kleineren Abmessungen, die LPC2000 mit 64
Pins haben die Abmessungen einer 1 Cent Münze.

Jetzt ist dem Herrn (Horst), der den Thread startete, immer noch nicht
geholfen. Sieht aber so aus, als wenn der CAN-Controller nach ein paar
Fehlern in den Error Passive Status wechselt und schließlich Bus Off
geht. Vielleicht fängt man da mit der kleinsten Bitrate an, die der
Controller einstellen kann. Dann hat man auch noch mit dem Oszi eine
Chance.

Gruß

Dietmar

man das war ja nen langer Text...

zu dem Problem:
Der Empfänger sucht nun bei jedem Low-Am INT-Pin nach dem richtigen
Buffer für Daten. Ich konnte erkennen, dass jedoch immer Buffer0
benutzt wird. Alles andere wäre auch irgendwie unerklärlich.
Nun leider unterbricht das Ganze wieder an gewohnter Stelle.
Ich denke ich sollte die Fehlersuche am Sender fortsetzen... Am Slope
hab ich auch nochmal gedreht. Von 50k runter auf 10k. Aber kein
Einfluss.
Bin ich irgendwie mit einem CAN-Fluch belegt oder was geht hier vor?
Ich versteh die Welt nicht mehr. Alle erdenklichen Fehlerquellen konnte
ich ausschließen.
Ich mach mich nochmal an den Sender...

@Horst: check your mails
@Dietmar: welche Tools für 500Eur meinst Du?

1km Buslänge, womöglich noch ohne Abschirmung, oh nein, die reinsten
Langwellen-Antennen.

"Wenn ich da kurz einen der beiden
Busterminierungswiderstände öffne (um eine Störung zu simulieren),
gehen schon alle Knoten in den Bus Off Status"

Bei mir ganz anders (500kb/s, 12-100 Knoten, 6-60m): Wenn ich den
Abschlußwiderstand abziehe, passiert (zumindest bei <10m) gar nichts.
Erst wenn der zweite fehlt, geht gar nichts mehr.

Festhängende CAN kenne ich auch: welchen Controller meinst Du hier?

Welchen Pitch hat der LP2000? 0,5mm ist kein Problem beim Löten.

So was machen wir denn jetzt? Ich habe auf Sender und Empfängerseite die
C-Codes von [kreatives-chaos.de]. Und es funktioniert genau so wenig wie
mein ehemaliger ASM-Code. Jedesmal stoppt die Übertragung nach einigen
Sekunden. Ich bin echt am Ende - habe alles doppelt und dreifach
ersetzt um gebaut, auf Platine gelötet - nichts!
Im Anhang mein aktueller Stand mit dem C-Code.
Das einzige was ich von Anfang an nicht geändert habe ist die
Spannungsversorgung mit dem 7805 (genauer Typ:L7805CV GK193VW CHN452)
Kann vielleicht sein, dass er an der Grenze läuft und dann irgendwann
ein Bauteil schlappmacht? Ich speise den mit 7,5 VDC, wird leicht
handwarm im Betrieb. Kann eigentlich nicht daran liegen, meiner
Meinung.

Hast du schon versucht das untere vor der while(1) Schleife und nicht
darin zu machen ?

----------------------------------------------------------
typedef struct
{
    uint16_t  id;
    uint8_t   rtr;
    uint8_t   length;
    uint8_t   data[8];
} CANMessage;

// Neue Nachricht erzeugen
CANMessage message;

// Daten eintragen
message.id = 0x0123;
message.rtr = 0;
message.length = 2;
message.data[0] = 0x04;
message.data[1] = 0xf3;

>Das einzige was ich von Anfang an nicht geändert habe ist die
>Spannungsversorgung mit dem 7805 (genauer Typ:L7805CV GK193VW CHN452)
>Kann vielleicht sein, dass er an der Grenze läuft und dann irgendwann
>ein Bauteil schlappmacht? Ich speise den mit 7,5 VDC, wird leicht
>handwarm im Betrieb. Kann eigentlich nicht daran liegen, meiner
>Meinung.

Ich setze einen Kasten Bier das hier das Problem liegt. Ich würde mal
mindestens 8V am Eingang anlegen und !!!! mindestens mit 220
mikrofahrrad ;-) die Ausgangsseite des Reglers bestücken.....

Ich habe jetzt pro Sender und Empfänger einen 7805 inkl. 100µF + 100nF
(Eingangsseite) und 100nF + 10µF (Ausgangsseite).

Also je Sender und Empfänger mit eigener Versorgung.

Das Problem steht nach wie vor. Bin selbst überrascht. Die gesamte
Platine zieht über 600mA aus dem Netzteil, wie ich messen konnte.

Was kann man nun noch tun? kotz

600mA ??
Da ist doch was oberfaul!
60mA wäre ein passender Wert.
Was wird denn außer dem Spannungsregler noch warm?
Die 3 Watt müssen sich ja irgenwie bemerkbar machen.

Sorry, es sind 46mA die die Schaltung aufnimmt.

Es funzt !!!!!

Habe heute noch einen Fehler finden können: Der Reset-Pin am mcp2515
war nicht beschaltet. Hing also in der Luft. Das hab ich damals nicht
beachtet, da ich per SPI resettet habe. Hab nun einen 10k gegen Vcc.

Leider war danach aber irgendwie auch (nach ein paar mehr) Bytes
schluss. Schönes Gefühl wenn man nen richtig schweren Fehler aus dem
Weg räumt und danach immernoch keine Verbesserung kommt.

Naja als ich dann mal nicht HTerm als Empfangstool genommen habe,
sondern Hyperterminal, lief es... jedenfalls bis jetzt. Denke hab die
Sache endlich abgeschlossen. Frag mich nur wie das mit dem HTerm sein
kann. Ich denke der Puffer war voll (HTerm ließt wohl nur eine
bestimmte Anzahl Bytes ein?) und damit konnte die Platine nicht mehr
senden (Verstopfung?). Obwohl das ja wohl auch eigentlich nicht sein
darf....

Na wie auch immer..es funktioniert nun das Wichtigste: die Übertragung
selbst.

Resümee: 2 Wochen den mcp bis aufs innerste studiert.. auch nicht
schlecht.

Danke allen für die rege Hilfe hier!!!!!!

Werd mich demnächst wohl wieder mit neuen Problemen melden....

Na endlich, glückwunsch auch von meiner Seite.

Vielmehr Beiträge hätte das hier auch nicht mehr verkraftet. "Fremde"
bräuchten ja Stunden, bis die das hier alles durch hätten.

Aber das mit deinem HTerm finde ich ja echt schon hart. Wie soll man
denn darauf kommen??? Ab jetzt bin ich bei sowas auf jeden Fall auch
vorgrwahrnt! Dann wünsche ich dir noch viel Spass mit diesem genialen
Bussystem!

Glueckwunsch ;-)

@Profi:

Nein nein, durch den Wellenwiderstand des Kabels muß man keine
Langwellen-Antenne befürchten. Außerdem gibt es strenge
Abnahmemessungen durch alle nötigen Behörden (EMV, Funk,
Störstrahlung).

1 km Leitungslänge geht beim CAN-Bus mit 10 kbit/s.

Das ist bei uns getestet bei Buslast 80 Prozent und eben nur 10 kbit/s.
Bei 1 Mbit geht es eben nur max. 40 m weit bei Idealbedingung (Twisted
Pair, 60 Ohm, abgeschirmt).

CAN Analyzer muß nicht Maximalausbau sein, den gibt es von z.B. Vector
Informatik auch für 500 Euro zum Einstieg.

Pitch LPC2000: Schau dir das Datenblatt an, das du dir hier ziehen
kannst:

http://www.semiconductors.philips.com/pip/LPC2119FBD64.html

Bei 1 Mbit/s spielt der Bus mit über 7 Knoten gerade nicht mehr. Die
Bits nähern sich der Form einer Haifischflosse an. Ist vielleicht die
Kapazität der Suppressordioden an den Busleitungen jeder Baugruppe, die
müssen raus und zentral und in der Anzahl weniger (vielleicht auf der
Busplatine des Steuergerätes und an kritischen Punkten) untergebracht
werden.

Gruß

Dietmar

Habt Ihr immer noch das Problem ich denke du must die RX TX Leitung 
zwischen canbustreiber und interface vertauschen  2551 und 2515

Dann sollte es gehen.


Wie beim Netzwerk TX senden RX hören TX zu TX und RX zu RX geht nicht



MFG