Announcement: there is an English version of this forum on Benutze AVR und mcp2515, mcp2551 Warum bleibt die Kommunikation nach etwa 10 sek stehen?
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.
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....
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)
Angehängte Dateien:
-
fuses.jpg
150 KB
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.
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.
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!
@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
Christian schrieb:
> Habt Ihr immer noch das Problem
Wenn er nach 3,5 Jahren immer noch damit kämpft, dann sollte er wohl das
Tätigkeitsfeld wecheln.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.