Moin Moin CAN Wissende :-) Ich habe ein MCP2515 an einem ATMEGA 1284 via SPI mit 2Mhz. Der MCP und die MCU laufen mit 16Mhz. Die Problematik ist, dass ich auf eine CAN Nachricht innerhalb von < 80µs antworten möchte ( Request <-- Response ). Mit oben beschriebenen Setup benötigt der MCP2515 schon ganze 26,6 µs um nach dem Empfang der CAN Nachricht einen INTerrupt auszulösen. Das Auslesen des Buffers via SPI dauert dann 69,8 µs. Bis die Daten also im Programm sichtbar sind, dauert es schon 96,4 µs. Das erhöhen der SPI Geschwindigkeit wird im Grunde das Problem nicht lösen, denn ich muss ja auch noch die Daten verarbeiten und wieder per SPI an den MCP2515 senden. Ist es überhaupt realistisch mit "C" und einem anderen Controller, z.B. SJA1000 oder AT90CAN128 solche Antwortzeiten zu erreichen? Beste Grüße Karsten
Karsten K. schrieb: > Ist es überhaupt realistisch mit "C" und einem anderen Controller, z.B. > SJA1000 oder AT90CAN128 solche Antwortzeiten zu erreichen? Nun ja, bei einem ARM z.B. LPC2000 mit CAN müssen nur intern Register gelesen und geschrieben werden, das erspart den Bus. Ich fand das schon komfortabler zu programmieren, weil man nicht erst auf einen Bus zugreifen muß. EIne andere Frage ist der Bus-Traffic auf dem CAN-Bus, ob man den restlos zupacken möchte.
Karsten K. schrieb: > Ist es überhaupt realistisch mit "C" und einem anderen Controller, z.B. > SJA1000 oder AT90CAN128 solche Antwortzeiten zu erreichen? Definitiv. Am C soll es ohnehin nicht scheitern, solange man sauber programmiert und der Compiler keinen Murks macht. Bei Controllern mit CAN-Interface sind die Daten ja quasi direkt im Zugriff, d.h. der Controller kann auch direkt anfanzen zu werkeln. In deinem Fall werden ja allein schon fast 30µs verbraten bis du die Daten überhaupt auslesen kannst. Das Verarbeiten der Daten auf dem Controller dürfte hier das geringste problem sein, in deinem Fall ist einfach das Interface zu langsam. 80µs sind ja eigentlich schon eine ganze Menge, kommt natürlich darauf an, was für Operationen der Controller durchführen muss, aber bei 16 MHz sind das immerhin schon 1280 Takte. Wenn man die vollständig nutzen kann, weil der Controller die Daten direkt lesen kann, dann sollte das also kein Thema sein.
:
Bearbeitet durch User
Bei 16 MHz kann die SPI mit 8 MHz laufen, das ist schonmal Faktor VIER schneller!
die 26µS bis zum Interrupt hat er aber trotzdem, dann Daten verarbeiten usw. wird trotzdem knapp..
Falk Brunner schrieb: > Bei 16 MHz kann die SPI mit 8 MHz laufen, das ist schonmal Faktor VIER > schneller! Wenn es linear skaliert und lesen und schreiben gleich lange brauchen dann benötigt er aber immer noch mindestens 26,6µs + (2 * 69,8µs/4) = 61,5µs (vorausgesetzt der MCP hat keine weitere Vorzögerung um die Daten auf den CAN-Bus auszugeben). Damit bleiben auf dem Controller weniger als 18,5µs um zu reagieren. Könnte aber je nach Anforderung reichen.
Humm, 8 Mhz SPI: lesen würde bei linearem Verhalten dann 14,6µ dauern. Schreiben von 8Byte + CAN Header dauern dann 21,68 µs. Plus MCP Interrupt auslösen von 26µs und 5µ für das aufbereiten zum senden sind alles zusammen 67,28µs. Das wäre mir ehrlich gesagt zu knapp, denn die MCU wird ja auch noch einige Zeit benötigen. Wenn es stimmt, das ein AT90CAN128 wirklich viel schneller ist werde ich das in Angriff nehmen. Ein SJA1000 ist zwar auch nett, aber nur in SMD und kostet eine "Unmenge" an Pins. Der CAN Bus ist im Übrigen leer. Es sind nur maximal drei teilnehmer am Bus. Ach, und die Übertragung läuft mit 250K Baud. Es ist zumindest beruhigend, das es keine utopischen zeiten sind und ich nicht unbedingt in Assembler schreiben muss. Das wäre für mich nicht wirklich realisierbar :-) Gruß Karsten
Karsten K. schrieb: > Die Problematik ist, dass ich auf eine CAN Nachricht innerhalb von < > 80µs antworten möchte ( Request <-- Response ). Mit oben beschriebenen > Setup benötigt der MCP2515 schon ganze 26,6 µs um nach dem Empfang der > CAN Nachricht einen INTerrupt auszulösen. Ist das wirklich so ? Wenn ich die decodierten CAN Daten vom Logicanalyzer anschaue (2.Bild), werden die End of Frame Daten + IFS nicht berücksichtigt. Wenn ich das mal grob interpoliere antwortet der MCP2515 nahezu sofort ... Gruß Gerd
Hallo Gerd, Danke für deine Aufmerksamkeit. Ich war mir sicher, aber Kontrolle ist besser. Der Analyser zeigt nicht nur die Netto-Daten sondern das gesammte CAN-Paket. Ein etwas besserer Ausschnit zeigt, das nach dem CRC noch ein paar Impulse ( hier ein ACK ) kommen. Dann dauert es tatsächlich 26,6 µs bis der MCP2515 einen INTerrupt auslöst. gruß Karsten
Wenn ich mich nicht irre ist das letze, vom Logic Analyzer dekodierte Bit das ACK-Bit. Die IFS Bits gehören aber IMHO zu einem kompletten Frame dazu ... Mit welcher CAN-Rate arbeitest Du denn ? Standard oder Extended Frame ? Gruß Gerd
Karsten K. schrieb: > Wenn es stimmt, das ein AT90CAN128 wirklich viel schneller ist werde ich > das in Angriff nehmen. Ein SJA1000 ist zwar auch nett, aber nur in SMD > und kostet eine "Unmenge" an Pins. Du könntest auch einen dsPIC33EP512MC502 in Betracht ziehen. Gibts auch bastelfreundlich in DIL28, 70MHz, 48k RAM, 512k Flash (es gibt auch welche mit weniger), ECAN im Chip drin (quasi eine deutlich verbesserte Version dessen, was Du im 2515 hast, mehr Buffer, etc etc). fchk
Gerd B. schrieb: > Wenn ich mich nicht irre ist das letze, vom Logic Analyzer dekodierte > Bit das ACK-Bit. Die IFS Bits gehören aber IMHO zu einem kompletten > Frame dazu ... sed s/IFS Bits/EOF Bits/
:
Bearbeitet durch User
Gerd B. schrieb: > sed s/IFS Bits/EOF Bits/ Hei freu: jemand der sed kennt :-) Gerd du hast Recht. Wenn die EOF bits alle 1 sind, wird man die so nicht sehen. Baudrate ist 250K; ein Bit ist dann 4µs lang. es passen also noch ganze 6 EOF bit in den Frame und es bleiben dann nur 2,625µs als Verzögerung vom MCP2515 übrig. Ich habe hier ein AT90CAN128 auf einem development board von Olimex. Ich werde mich dann an die Arbeit machen das ganze interrupt gesteuert mit dem eingebauten CAN-Controller zu realisieren. Wir eine heiden Arbeit; Aber wir wollen ja Herausforderungen haben. Herzlichen Dank an alle für eure sehr nützlichen Tips! Eine Runde V-Bier bitte. ( In Paderborn konnte man vor vielen Jahren auch ein Byte oder gar ein Long in einer Kneipe bestellen und wurde nich schräg angesehen. Bit heisst da ja das Bier :-) Gruß Karsten
@ Karsten K. (karsten42) >Ich habe hier ein AT90CAN128 auf einem development board von Olimex. Ich >werde mich dann an die Arbeit machen das ganze interrupt gesteuert mit >dem eingebauten CAN-Controller zu realisieren. Wir eine heiden Arbeit; >Aber wir wollen ja Herausforderungen haben. Oder einfach bewährte Systeme nachnutzen. Das Rad immer wieder neu zu erfinden ist nicht sonderlich clever. http://www.kreatives-chaos.com/artikel/universelle-can-bibliothek Siehe auch CAN.
Bitte 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.