# Christoph meinte am 21. März 2008, 20:03 dazu:

Ich bin begeistert!

Da ich in naher Zukunft Prozessstraßen für die Industrie entwickeln (und verkaufen) werde, die als Baukastensysteme über CAN vernetzt sind, wird mir diese Bibliothek viel Arbeit abnehmen. Wenn ich Verbesserungen habe, werde ich mich auf jeden Fall melden.

Und selbstverständlich gibt es bei den ersten verkauften Geräten eine entsprechende Spende an den Roboterclub der RWTH. Wenn ich nicht schon mehr als genug Arbeit hätte - autonome Roboter wären ein tolles Betätigungsfeld.

Nochmal ein herzliches Dankeschön für die Bibliothek und vielen Grüße aus der Eifel,
Christoph

# Simon meinte am 18. August 2008, 21:31 dazu:

Hi Fabian,

ich habe im Grunde den gleichen Aufbau wie beim CAN-Testboard, nur hängt noch ein Display am Controller mit dem ich die Debug-Ausgaben mache.

Sobald ich aber can_init() aufrufe (im Beispielprogramm oben) stürzt der controller ab. Alles was nach can_init() kommt wird nicht ausgeführt.

Fällt dir da auf die schnelle ein möglicher Grund ein der die can_init() evtl. in eine endlosschleife o.ä. laufen lassen könnte??

dank!

# Simon meinte am 19. August 2008, 12:33 dazu:

Danke für die schnelle Antwort! Ich habe gerade die can-lib.zip von oben runtergeladen und neu kompiliert. Am Verhalten hat sich aber nichts geändert: Er bleibt immer noch in der can_init() hängen.

Oder gibts vll. ein svn-rep von dem ich nix weiß?

# Otmar Schmid meinte am 23. August 2008, 09:14 dazu:

Hallo Fabian
Zuerst einmal ein grosses Lob und vielen Dank für diese can-lib. Ich will den CAN-Bus als Hausbus einsetzen. Zwei kleine Punkte:
- Der Filenamen at90can_disable_dynamic_filter.c ist zu lang (> 32 Zeichen) und erzeugt bei meinem Makefile einen Fehler.
- Das Label SUPPORT_FOR_MC2515__ in mcp2515_error_register.c in Zeile 33 ist falsch geschrieben.
Nun zu meinem eigentlichen Problem:
Ich habe zwei identische Testboards mit ATmega168 und MCP2515 nachgebaut. Auf beiden läuft bis auf die Identifier das gleiche Programm. Wenn ich die Programme nacheinander starte, funktioniert alles einwandfrei. Nur wenn ich beide geichzeitig starte (simultanes Power on bei beiden), dann zeigt sich der Fehler. Der eine MCP2515 sendet fälschlicherweise Daten die er vorher empfangen hat, oder die zufällig in den Registern stehen. Natürlich wird es auf dem CAN-Bus zu kollisionen kommen. Doch damit sollte der MCP2515 umgehen können. Gibt es eine Erklärung dazu? Das ganze Projekt ist unter (...) zu finden. Ich verwende Debian testing.
Vielen Dank für die Hilfe und schöne Grüsse Otmar

# Marcus meinte am 20. Oktober 2008, 18:00 dazu:

Hallo,

mir ist aufgefallen, dass wenn ich den mcp2515 mit BITRATE_250_KBPS initialisiere, dann kann ich Daten mit meinem USB PEAK Adapter nur mit einer Baudrate von 125kBit/s empfangen oder senden. Stelle ich BITRATE_500_KBPS ein, dann kann ich mit dem PEAK Adapter die Daten mit 250kBit/s empfangen oder senden. usw?
Ich habe mir natürlich die can.h entsprechend angepasst.

Aber mich würde generell interessieren warum das so ist. Der Peak Adapter ist in Ordnung und funktioniert in anderen Anwendungen ohne Probleme?

# Fabian Greif meinte am 20. November 2008, 11:17 dazu:

Ganz genau steht sie unter der “2-Klausel-BSD” oder auch FreeBSD-Lizenz.

Der genaue Text steht aber auch in Quelltext.

# Alex meinte am 16. Dezember 2008, 09:59 dazu:

Hallo,

ich hab eine kleine Frage zu deiner Lib. Ich bin dabei mit 2 AT90CAN128 CAN Nachrichten zu versenden. Der eine sendet, wie im Beispiel beschrieben. Allerdings nur 15 mal. Ich nehme an dass dann der Buffer voll ist. Der zweite CAN Knoten sollte eigentlich empfangen tut er aber nicht. Ich hab hier mal mein Codeausschnitt:

if (can_check_message())
{		
can_t msg;
// Try to read the message

  if (can_get_message(&msg))
  {
				   
    uart_putc(msg.data[0]);
  }
}

Vielleicht hast du ja ein Beispiel dass Senden und Empfangen zeit.

Gruß Alex

# Alex meinte am 16. Dezember 2008, 20:58 dazu:

Nein hab leider kein Filter gesetzt gehabt. Werds aber mal austesten.

# Fabian Greif meinte am 11. Februar 2009, 00:28 dazu:

Es hört sich an als würde der AT90CAN128 nicht das Acknowledge vom Bus empfangen. Überprüfe doch mal mal die RX-Leitung vom CAN Transceiver zum AT90CAN.

Grüße
Fabian

# Frédéric meinte am 11. Februar 2009, 19:53 dazu:

Thanks you Fabien for your library, it’s the best thing since sliced bread :)

With the library (and an ATMEGA168 and a small LCD) I made an onboard gauge for CAN enabled cars that display fuel consumption, trip data, engine info, etc.

# Fabian Greif meinte am 24. Februar 2009, 18:51 dazu:

Mein Quarz hat 12Mhz. Habe ich jetzt ein Problem,

Problem hast du keines, außer das du die Werte selbst anpassen musst.

oder kann ich im File at90can.c auf Zeile 171 einfach den Teiler (jetzt 199) ändern?

Das wäre das Eine. Viel wichtiger sind aber die Werte ab Zeile 39 in der ‘at90can.c’. Die Werte werden in die Register CNF1..3 geschrieben und bestimmten die Bitrate für den CAN Bus.

Grüße Fabian

# Bernhard Ibertsberger meinte am 26. März 2009, 17:42 dazu:

Hallo Fabian,
die CANlib verrichtet ganz wunderbar ihren Dienst. Jetzt habe ich aber das Problem eine CAN verbindung mit einem Programm in der bootloader section aufzubauen. µC ist at90can128

Ein kleines Demo (verschickt jede Sekunde ein CAN message und toggled eine LED) funktioniert in der application section.
Wenn ich aber das Programm in die bootloader section verschiebe blinkt nur mehr die LED, es kommen aber keine CAN Telegramme an.
can_send_message liefert keinen Error.

Hast du eine Idee woran das liegen könnte? Ich bin schon ein wenig Ratlos.

lg Bernhard

# Uwe Dierolf meinte am 22. Mai 2009, 12:36 dazu:

Hallo Florian, ich versuche gerade dein Testpogramm, das beim “CAN-Lib” download dabei war zu compailieren. Die “libcan.a” hab ich mit WIN-AVR erstellt und wie im Tutorium beschrieben in den Projektordner eingefügt. Jetzt versuch ich, da ich eigentlich nicht mit WIN-AVR Arbeite, mit AVR-Studio das Testprogramm zu compeilieren.

Er erkennt die Lib, da er wenn ich sie rausnehme meldet dass er die Funktionen nicht finden. aber wenn ich sie drin hab bekomme ich folgene Fehlermeldung. ” avr-gcc -mmcu=atmega32 -Wl,-Map=CAN_DEMO2.map CAN_DEMO2.o -lcan -o CAN_DEMO2.elf c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: cannot find -lcan make: *** [CAN_DEMO2.elf] Error 1 Build failed with 1 errors and 0 warnings… ” Leider weiss ich nicht was er mit “cannot find -lcan”
meint, da ich mit, aus mehreren Files zusammengestellten libs keine Erfahrungen hab.

Vielen Dank schon mal im Voraus MFG Uwe

# Uwe meinte am 28. Mai 2009, 21:51 dazu:

Hallo,
ja sie ist im selben wie im Makefile. Ich hab jetzt meine "main" in main umbenannt, was in AVR-Studio ja nicht von Haus aus so ist. Er bringt aber immer noch einen Fehler beim erstellen der Debugg-Datei was glaube ich mit "CAN_DEBUG_LEVEL" in can_private.h zusammenhängt. Code läuft jetzt, SPI und LCD, nur CAN, kann noch nicht so ;-)
Ich hab jetzt mal Alles gedruckt und kau es übers Wochenende durch, dann sehe ich villeicht klarer.

MFG
Uwe

# Uwe meinte am 30. Mai 2009, 16:09 dazu:

Jetzt hab ich meine Startprobleme überwunden, und wie immer ist es nichts Weltbewegendes,sonder was das man mit etwas ruhigem Nachdenken lösen kann. Wenn ich nur immer ruhig bleiben könnte :-(

1. Er hat die Lib. nicht gefunden, da ich im "library Search Path" nichts eingegeben hab, es muss aber immer was drin stehen, wenn auch nur ein "./"

2. Das mit der Debugg Datei war ein Namensfehler, da ich Deine Datei in Meinem anders benannten Projekt hatte.

Ich hätte AVR-Sudio villeicht erst updaten sollen, wenn die Lib. gelaufen wär. Zuviel Neues auf einmal geht meistens einfach schief.

Besten Dank noch mal für Alles.

jetzt mach ich mich an die Lösung des Eigentlichen Problems. MFG Uwe

# Fabian Greif meinte am 21. Juni 2009, 12:57 dazu:

Stimmt, das hatte ich mal geändert. Vielen Dank für den Hinweis, ist korrigiert.

Grüße Fabian

# Fabian Greif meinte am 22. Juni 2009, 18:18 dazu:

Irgendeine Idee warum das genau in der Schleife passiert? Die Beschaltung habe ich schon hundertmal überprüft.

Nein, so spontan nicht. Es scheint so als würde die SPI Übertragung nicht richtig gestartet.

Kannst du mal versuchen ohne die canlib Daten per SPI zu übertragen und schauen ob er da auch beim zweiten Aufruf hängen bleibt?

Grüße Fabian

# Fabian Greif meinte am 28. Juni 2009, 09:47 dazu:

Sooo. Ich habe (mal wieder) das Problem dass er bei can_init() hängen bleibt^^

Ich habe mir das nochmal genauer angeschaut, das Problem tritt eigentlich nur auf wenn man die Bibliothek für einen AVR kompiliert und dann einen anderen verwendet. Zwischen den verschieden AVRs verschieben sich nämlich auch die Registeradressen, dann wird dann darauf gewartet das sich ein Bit in einem vollkommen falschen Register setzt.

Schau mal nach nach ob die Einstellungen für dein Projekt und die für das Erzeugen der Bibliothek übereinstimmen.

Grüße Fabian

# CTruller meinte am 11. Juli 2009, 14:16 dazu:

Hallo Fabian,

ich möchte mich Deinen ersten Schreiber anschliessen und ein großes Lob aussprechen, einfach tolles Lib. Ich setze sie schon mehrfach mit großen Erfolg auf dem AT90CAN128 ein. Meine selbst kreierte Routine zum CAN-Bus hatte Macken, desshalb bin ich froh ein so gut funktionierende Lib gefunden zu haben.

Leider kommt jetzt doch ein ABER, ich wollte die Libcan.a auch im Bootloader einsetzen, weil meine Routine eben Macken hat, das ging solange gut wie mein Bootloader nicht im Flashspeicher ab 0x1E000 (bzw. im AVR-Studio 0xF000) laufen sollte, der Fehler ist reproduzierbar. Es kommen nur Fehlerdatentelegramme raus, beim Flashspeicher ab 0x0000 läuft das Programm wunderbar, richtige Datentelegramme. Ich habe schon gedebuggt, aber nichts aufälliges gefunden die Register vom CAN-Kontroller sind (so weit der Debugger (mit Eclipse) nicht lügt und ich das Richtige sehe) mit gleichen Daten gefüllt und ich habe alle Register mir direkt anzeigen lassen. Ich mach jetzt schon 3 Tage damit rum.

Es währe wirklich Super wenn Du einen Tip geben könntest.

Gruß CTruller

# Fabian Greif meinte am 20. Juli 2009, 18:46 dazu:

Das funktioniert, ist nicht schön aber vielleicht hast Du noch einen besseren Vorschlag.

Nicht so wirklich. Die einzige andere Möglichkeit die mir noch einfällt wäre die Tabelle zu deaktivieren und die Registerwerte direkt zu setzen. Wenn ich wieder Zeit habe werde ich das mal einbauen.

Grüße Fabian

# Fabian Greif meinte am 27. Juli 2009, 16:44 dazu:

Hast du die Interrupts aktiviert?

Setzt mal ein sei() nach die Initialisierung des CAN Controllers.

Grüße Fabian

# Fabian Greif meinte am 4. August 2009, 10:17 dazu:

spi.h:74: warning: ‘gnu_inline’ attribute directive ignored

Scheinbar kennt diese Version des GCCs __attribute__((gnu_inline)) noch nicht. Du solltest es durch static inline ersetzen können.

Die dortige Syntax ist mir leider auch völlig unbekannt. Was bedeutet uint8_t rtr : 2;

Das legt ein Bitfeld an, wobei rtr zwei Bit groß ist. Versuch mal das uint8_t durch int zu ersetzen.

Sag Bescheid ob es damit klappt.

Grüße Fabian

# Fabian Greif meinte am 4. August 2009, 10:35 dazu:

Was bedeutet hier mask?

mask gibt an welche Bits von id zur Filterung der Nachricht herangezogen werden.

Mit mask = 0 werden alle Nachrichten empfangen, unabhängig von id. Mit mask = 1 werden alle Nachrichten empfangen bei denen das niederwertigste Bit mit dem Bit aus id übereinstimmt. Mit mask = 0x7ff werden bei Standard-Frames alle Bits von id überprüft usw.

Siehe auch Filter bei MCP2515.

# maxf meinte am 17. August 2009, 17:44 dazu:

Hallo Fabian,

ich habe ein kleines Problem mit der Library. Ich benutze den MCP2515 an einem ATMega8. Aus irgendeinem Grund kann ich im normalen Modus (mit oder ohne Busteilnehmer) nur genau 3 Nachrichten verschicken. Im Loopback-Modus tritt dieses Problem nicht auf. Hast du eine Idee, wie das kommt? Wenn das Senden fehlschlägt, gibt die Methode can_send_message () 0 zurück, und auch die CAN_INDICATE_TX_TRAFFIC_FUNCTION wird nicht mehr ausgeführt…

# Nik meinte am 20. August 2009, 10:40 dazu:

Ich verwende den AT90CAN128, das Demo-Programm sendet, aber scheint nichts zu empfangen, zu mindest anwortet es nicht durch zurücksenden der Message mit anderer ID. WOran kann das liegen ?

# CTruller meinte am 24. September 2009, 11:47 dazu:

Hallo Fabian,

sorry, das ich die Frage über den RCA direkt an Dich schon mal gemailt habe. Wie schon am 11. und 13. Juli 2009 geschrieben setzen wir Deine Lib erfolgreich ein. Ich vermute mal das die nachfolgende Anfrage kein Fehler der Lib ist aber vielleicht hast Du oder jemand anderes einen Tip wie man ihn beheben kann. Beim verwenden der Funktion can_set_filter und can_disable_filter kommt es zu Errorframes auf dem CAN-Bus (Baudrate 250), wenn der CAN-Kontroller bereits gearbeitet hat, also anders gesagt, es kommt nicht dazu wenn can_set_filter gleich nach can_init aufgerufen wird. Auslöse Zeile ist in der Datei at90can_private.h in der Funktion _enter_standby_mode die Zeile 113 ?CANGCON=(1 kleinerals kleinerals ABRQ)?. Ab dieser Zeile kommtes bis zur Zeile in gleicher Datei bei der Funktion _leave_standby_mode Zeile 147 ?CANGCON=(1 kleinerals kleinerals ENASTB);? entsprechend der Durchlaufzeit von einem bis im Debughalt zu was weiß ich wie viele. Ich tippe mal auf ein Hardwareproblem, den wieso sendet der CAN-Kontroller weiter im Debughalt (ermittelt mit dem Canalyzer von Vector). Ich währe für jeden Tip dankbar, denn momentan kann ich die Funktion can_disable_filter nicht verwenden.

Danke schon mal im Voraus CTruller

# Fabian Greif meinte am 7. Oktober 2009, 15:35 dazu:

Hallo Marcel,

Es muss -lcan heißen, unabhängig davon wo die Bibliothek liegt. Das gibt man über die Option -Lpfad/zur/bibliothek/ an. Wie man das genau im AVR Studio einstellen muss kann ich dir leider nicht sagen, da ich es selbst nicht verwende.

Grüße Fabian

# Fabian Greif meinte am 27. Oktober 2009, 11:49 dazu:

can_send_message liefert drei mal true und danach false

Das bedeutet das die beiden Boards nicht miteinander kommunizieren können. Überprüf noch mal sämtliche Leitungen und die CAN Transceiver.

Wenn du die Fehlerregister ausliest solltest du auch sehen können das keine Kommunikation zustande kommt.

Ist irgendwo verständlich dokumentiert, wie das mit den Filtern läuft?

Im Datenblatt des MCP2515 findet sich einiges.

Kann das der Grund sein, warum die Kommunikation nicht klappt?

Nein. Auch ohne Filter sollten sich Nachrichten verschicken lassen.

Bekommt nicht jeder Busteilnehmer seine eigene ID? Wo setzt man die?

Nein, dafür ist der Programmierer verantwortlich. CAN kennt nur Nachrichten mit Identifiern, wie diese belegt werden ist nicht festgelegt. Das spezifizieren dann weitere Protokoll die auf CAN aufsetzen. Da kannst du dir ein schönes aussuchen oder dir selbst was ausdenken.

Grüße Fabian

# Fabian Greif meinte am 9. November 2009, 12:10 dazu:

Hallo Jens,

Was mache ich falsch, wenn ich nur 8 Bytes als Antwort geliefert bekomme, die Antwort CAN Message aber mehr enthält?

Du hast eine wichtige Einschränkung des CAN Protokolls nicht beachtet, nämlich das eine Nachricht maximal 8 Bytes an Nutzdaten enthalten kann.

Daher ist es vollkommen egal was du in der Software einstellst, der CAN Controller wird dir nicht erlauben mehr als 8 Bytes in einer Nachricht zu übertragen.

Grüße Fabian

# Georg meinte am 16. November 2009, 13:58 dazu:

Hallo Fabian, ich habe ein Problem und zwar habe ich ein CAN-Netzwerk mit insgesamt 8 Teilnehmern, davon 7 mit den mcp2515 und 1 atcan128. Jetzt habe ich aber das Problem, dass mir der MCP die Daten, die vom atcan128 gesendet werden, zwar empfängt, jedoch nicht löscht. Da muss ich danach die Daten wieder senden, damit ich überhaupt neue Daten empfangen kann. Meine Routine zum Empfangen: can_get_message;

v= (msg.data[0]-34)/3;

vor= msg.data[1];

zur= msg.data[2];

can_send_message(&msg);

Ich habe die ID in einem Empfangspuffer genau so konfiguriert, dass nur dieser 1 die Daten empfängt. Dieser Puffer soll aber jede neue Datei die mit dieser IP gesendet wird empfangen und die alte löschen. Gibt es eine bessere Möglichkeit um die Daten aus dem Empfangspuffer zu löschen als die Datei einfach wieder zu senden?

Schon mal vielen Dank!

# Jens meinte am 18. November 2009, 08:43 dazu:

Leider hatte ich bei http://www.mikrocontroller.net/topic/157019#1484234 keine Antwort bekommen, also doch noch mal hier.

Ich nutze die CAN Bibliothek

Alle Nachrichten empfangen klappt auch.

Was ich irgendwie gar nicht kapiere ist, wie ich nur Nachrichten mit bestimmten IDs empfangen kann. Kann mir jemand ein Beispiel für zwei zugelassene IDs erstellen? Ggf. einmal für 11 und einmal für 29 Bit?

Danke.

# Jens meinte am 19. November 2009, 09:14 dazu:

Ich arbeite mir dem MCP2515

# Fabian Greif meinte am 20. November 2009, 13:10 dazu:

Hallo Jens,

Oder muß ich beim compilieren der library was einstellen?

Nein, nichts was mit den Filtern zu tun.

Angenommen du willst nur Standard-Nachrichten mit den Identifiern 0x123 und 0x456 empfangen. Dann kann man die Filter zum Beispiel folgendermaßen einstellen:

prog_uint8_t can_filter[] = 
{
    // Group 0
    MCP2515_FILTER(0x123),  // Filter 0
    MCP2515_FILTER(0x123),  // Filter 1

    // Group 1
    MCP2515_FILTER(0x456),  // Filter 2
    MCP2515_FILTER(0x456),  // Filter 3
    MCP2515_FILTER(0x456),  // Filter 4
    MCP2515_FILTER(0x456),  // Filter 5

    MCP2515_FILTER(0x7FF),  // Mask 0 (for group 0)
    MCP2515_FILTER(0x7FF),  // Mask 1 (for group 1)
};
...
can_static_filter(can_filter);

Jetzt empfängt das erste Register nur die Identifier 0x123 und das zweite nur 0x456. Will man mit beiden Registern beide Identifier empfangen muss es folgendermaßen aussehen:

prog_uint8_t can_filter[] = 
{
    // Group 0
    MCP2515_FILTER(0x123),  // Filter 0
    MCP2515_FILTER(0x456),  // Filter 1

    // Group 1
    MCP2515_FILTER(0x123),  // Filter 2
    MCP2515_FILTER(0x123),  // Filter 3
    MCP2515_FILTER(0x456),  // Filter 4
    MCP2515_FILTER(0x456),  // Filter 5

    MCP2515_FILTER(0x7FF),  // Mask 0 (for group 0)
    MCP2515_FILTER(0x7FF),  // Mask 1 (for group 1)
};
...
can_static_filter(can_filter);

Beide Varianten sollten aber wirklich nur die beiden Identifier durchlassen und keine anderen.

Für Extended-Nachrichten musst du einfach MCP2515_FILTER durch MCP2515_FILTER_EXTENDED ersetzten und die Werte entsprechend anpassen.

Grüße Fabian

# Frank meinte am 15. Januar 2010, 23:13 dazu:

Hallo, ich versuche gerade die Lib auf einen ATmega644 20PU zum laufen zu bringen. Nur leider bekomme ich folgende Fehlermeldung: spi.h: In function ‘spi_start’: spi.h:75: error: ‘SPDR’ undeclared (first use in this function) spi.h:75: error: (Each undeclared identifier is reported only once spi.h:75: error: for each function it appears in.) spi.h: At top level: spi.h:78: warning: ‘gnu_inline’ attribute directive ignored spi.h: In function ‘spi_wait’: spi.h:80: error: ‘SPSR’ undeclared (first use in this function) spi.h:80: error: ‘SPIF’ undeclared (first use in this function) spi.h:83: error: ‘SPDR’ undeclared (first use in this function) In file included from mcp2515.c:50: mcp2515_private.h: At top level: mcp2515_private.h:144: warning: ‘gnu_inline’ attribute directive ignored make.exe: *** [build/mcp2515.o] Error 1

Woran kann das liegen? Gruss Frank

# Frank meinte am 17. Januar 2010, 17:35 dazu:

Hallo Fabian,

danke!!! Daran hat es gelegen! Gruss Frank

# Carsten Komnik meinte am 10. Februar 2010, 14:59 dazu:

Hallo Fabian.
Nachdem ich es schon fast aufgegeben hatte, klappt der Empfang von CAN-Nachrichten mit deiner lib nun auch auf meinem AT90CAN128.
Problem war die fehlende Initialisierung des Filters wie unter deiner Antwort vom 16.12.2008 beschrieben.
Vielen Dank!
Nun muss ich nur noch den Hänger nach 15x Nachrichten senden lösen :-)

# Martin meinte am 8. März 2010, 16:27 dazu:

Hallo Fabian, Vielen dank für diese tolle Lib. Alles funktioniert einwandfrei, ob AT90CAN oder mit der spi Variante. SUPER!!! Nur schade, dass du das es keinen CAN-Bootloader für den AT90CAN gibt.

# Fabian Greif meinte am 16. Mai 2010, 15:43 dazu:

Hallo Wolfram.

Zwei CAN Controller parallel ist mit der Bibliothek in der jetzigen Form noch nicht vorgesehen. Du müssest also wirklich die MCP-Funktionen kopieren, neu benennen und dann für den zweiten CAN Controller verwenden. Anders geht es im Moment leider nicht.

Erst mit der nächsten Version der Bibliothek (die dann in C++ geschrieben sein wird) wird das funktionieren. Allerdings ist diese noch nicht wirklich fertig und daher noch nicht öffentlich verfügbar.

Grüße Fabian

# Thorsten Krell meinte am 7. Juni 2010, 15:18 dazu:

Was muss ich eigentlich für eine Frequenz im Makefile einstellen, wenn ich den MCP2515 mit 8MHz betreibe und meinen ATMega128 mit 16MHz?

# Smon meinte am 20. Juni 2010, 17:59 dazu:

Grüße Fabian. Ich nutze derzeit deine Biliothek für ein kleines Hausbussystem an unserer Uni und ich bin auch schon recht weit gekommen. Bislang habe ich den Atmega8 verwendet aber nun stoße ich speichertechnisch an seine Grenzen und will deswegen auf den Atmege644 umsteigen und genau da liegt das Problem.

Die Initialisierung des CAN-Busses funktioniert nicht. Er liefert nicht nur ein “False” zurück, der Controller hängt sich komplett auf. Ich habe im Makefile für die MCU den Atemag644 angegeben. Das Aufspielen der Software ist kein Problem und auch andere Programme gehen tadellos. Ich habe auch das SPI-Interface selbst initialisiert (war beim Atmega8 nicht nötig), ohne Erfolg. Gibt es noch irgendwelche Einstellungen die ich vergessen/übersehen habe? Grüße, Simon

PS: Meine Schaltung ist richtig aufgebaut, habs auf dem Steckboard nun bestimmt schon 20 mal überprüft ;)

# Benjamin meinte am 12. August 2010, 09:08 dazu:

Hallo,

ich habe Deine Lib bei meiner Diplomarbeit in Verbindung mit einem SJA1000-Soft-IP-Core auf einem FPGA verwenden können und sage dafür einfach mal Danke :) Einen Fehler habe ich allerdings gefunden, in der sja1000_get_message.c liest Du die Register 17 und 18 in der falschen Reihenfolge aus (Zeile 81+82). Also einfach die 17 und 18 vertauschen, und dann kann man auch die ID der empfangenen Nachricht korrekt weiterverarbeiten ;)

Gruß Benjamin

# Fabian Greif meinte am 19. August 2010, 22:06 dazu:

@Stefan
Freut mich das es jetzt funktioniert. So was ist natürlich ein hinterhältiger Fehler.

@Benjamin
Da merkt man das ich den SJA1000 noch nicht wirklich viel eingesetzt habe ;-) Über einen Test auf meinem Testboard ist er nicht hinausgekommen.

Der Fehler ist jetzt korrigiert und ein aktualisiertes Archiv online. Danke für den Fehlerbericht ;-)

Grüße Fabian

# Fabian Greif meinte am 2. September 2010, 15:07 dazu:

Hallo Sascha,

du kannst einfach die SPI-Funktionen der canlib verwenden. Das ist nur eine Funktion nämlich spi_putc(). Leg einfach eine entsprechende Deklaration oberhalb der Stelle an der du die Funktion verwenden willst an:

uint8_t spi_putc(uint8_t data);

Grüße Fabian

# Fabian Greif meinte am 17. September 2010, 16:05 dazu:

Hallo JJ,

Die Implementierung in der can-lib war richtig! Deshalb würde ich empfehlen wieder auf die vorletzte Release-Version umzusteigen.

danke für den Hinweis. Ich habe mir gerade nochmal genau das Datenblatt des SJA1000 genauer zu Gemüte geführt. Du hast vollkommen recht, die bisherige Implementierung war korrekt und entspricht dem Datenblatt. Ich habe das Archiv mal wieder auf die vorherige Version “aktualisiert”.

Grüße Fabian

# Benjamin meinte am 27. September 2010, 15:56 dazu:

Hallo zusammen, es tut mir leid um die Verwirrung, die ich hier verursacht habe :). Dann muss bei mir was Anderes falsch gewesen sein (z.B. die Verilog-Beschreibung des SJA1000).

Gruß Benjamin

# Andrey meinte am 7. November 2010, 16:05 dazu:

Hi Fabian,

Sorry I don’t know German. I’ll try to include a Google Translate translation of this. Thanks for the library, I would like to use it with ATmega324p and mcp2515. mcp2515_private.h says 324p is not supported but ATmega32 and ATmega644 are supported. Can I use the library with ATmega324p and modify mcp2515_private.h or do I need to use ATmega644 in my design to make it work?

Thank you again. Andrey

Hallo Fabian,

Leider weiß ich nicht Deutsch. Ich werde versuchen, eine Google Translate Übersetzung dieses aufzunehmen. Vielen Dank für die Bibliothek, würde Ich mag es mit ATmega324p und MCP2515 verwenden. mcp2515_private.h sagt 324p wird nicht unterstützt, sondern ATmega32 und ATmega644 unterstützt. Kann ich die Bibliothek mit ATmega324p und ändern mcp2515_private.h oder muss ich in meinem ATmega644 Design zu verwenden, damit es funktioniert?

Nochmals vielen Dank. Andrey

# Andrey meinte am 10. November 2010, 00:53 dazu:

Thanks a lot Fabian for your help and such a quick response. :)

Andrey

# Klaus meinte am 17. November 2010, 17:59 dazu:

Moin,

ich bin gerade dabei, die canlib für den ATtiny44 unter Benutzung der Hardware-USI zu portieren (wenn ich fertig bin, werde ich den Patch hier reinstellen). Da ich Euren Code sinnvoll erweitern will, ohne Eure Struktur durcheinanderzubringen, eine Frage dazu: Gibt es einen besonderen Grund, weshalb spi_start() und spi_wait() zweimal definiert sind, einmal als Inline-Funktion in spi.h und einmal als statische Funktion in mcp2515_write_id.c? Weshalb wird in spi_putc() nicht auf spi_start() und spi_wait() zurückgegriffen?

Herzlichen Gruß, Klaus

# Andi meinte am 14. Dezember 2010, 21:49 dazu:

Die Funktion mcp2515_get_message enthält einen Fehler beim Ermitteln ob es sich um einen Standard Remote Frame handelt und zwar beim Auswerten über SPI_RX_STATUS. Sollte man gerade dabei sein den RXB1 Buffer auszulesen, so darf nicht SPI_RX_STATUS für die RTR Auswertung verwendet werden, da im Status Byte die Bits 0:4 nur für RXB0 gelten … zumindest laut Datenblatt ;-)

# Jo meinte am 20. Januar 2011, 16:25 dazu:

Hi, ist es eigentlich möglich, mit der Lib zwei MCP2515 an einem µC zu betreiben? Für ein Gateway …

Gruß Jo

# André meinte am 6. Februar 2011, 23:15 dazu:

Where´s the MCP2515 can_check_message function gone? Checked all *.h and *.cpp files … cant find a reference to this function? Where is it gone?

thx André

# André meinte am 7. Februar 2011, 17:16 dazu:

Ah, really great! :o) One more question, how do i compile it? I´ve never done this before. I want to use it with arduino (have an older compiled version from skpang.co.uk).

thx! André :o)

# Rainer meinte am 9. Februar 2011, 23:18 dazu:

Hallo Fabian,

mühsam nährt sich das Eichhörnchen, doch ich komme voran. Habe deine CAN-Demo erweitert, damit ich an einem Display ein bisschen debuggen kann. Aber soweit ich das feststellen kann hängt sich das Programm schon beim can_init auf. Ich bekomme nicht mal eine Ausgabe. Hast du eine Ahnung woran das liegen könnte?

Grüße

Rainer

# Rainer meinte am 10. Februar 2011, 18:56 dazu:

Hallo Fabian,

habs gestern hingekriegt. Das Ding schickt und empfängt. Deine Vermutung war zudem richtig. Sollte nächstes Mal einfach später schreiben, dann nerv ich dich nicht.

Du hast in deiner Demo für den ATMEGA32 kompiliert. Ich hab die Lib für den ATMEGA644 nochmal erstellt und jetzt gehts. Wieder was gelernt. Tja und wer lesen kann ist natürlich klar im Vorteil…

Vielen Dank für die Unterstützung. War ne lange Nacht gestern. ;-)

Rainer

# Niko meinte am 2. Mai 2011, 19:00 dazu:

Hallo,

ich bin gerade dabei die Can-Lib auf einem AT90CAN128 (auf dem Olimex AVR-CAN-Board) zu testen.

Mein Problem ist folgendes: Obwohl ich den Controller (meiner Meinung nach) richtig initialisiere kann ich im nicht mal im Loopback-Modus Nachrichten empfangen…

Im großen und ganzen schaut mein Programm so aus:

uart_init(UART_BAUD_SELECT(9600, F_CPU));
can_init(BITRATE_125_KBPS);

can_filter_t filter = {
    .id = 0,
    .mask = 0,
    .flags = {
        .rtr = 0,
        .extended = 0
    }
};

can_set_filter(0, &filter);
can_set_mode(LOOPBACK_MODE);
can_t message;

message.id = 0x123;
message.length = 2;
message.data[0] = 0xab;
message.data[1] = 0xcd;

print_can_message(&message);

while(1) {
    can_send_message(&message)) {

        delay(300);

        if (can_check_message()) {
            if (can_get_message(&message)) {
                print_can_message(&message);
            } else {
                PRINT("Fehler\n\r");
            }
        } else {
            PRINT("Fehler\n\r");
        }
        delay(1000);
    }

return 0;

Der AT90CAN sendet 15x, dann kommen Errors und empfangen wird gar nichts :-(

Vor längerer Zeit hab ich die Library auch schon mit einem MCP2515 verwendet (da hat alles einwandfrei funktioniert).

Ist meine Software falsch, oder liegts eher am Olimex-Board?

Liebe Grüße und Vielen Dank für die Mühe und die tolle Library :-)

Niko

# Niko meinte am 3. Mai 2011, 09:13 dazu:

Oh Mann, jetzt seh ich erst was für einen Blödsinn ich da gepostet habe (das kommt davon, wenn man den Code im Comment-Fenster editiert…).

Ich hab jetzt ein Testprogramm geschrieben und auf pastebin gepostet: PasteBin - Main.c

In der config.h ist nur der AT90CAN aktiviert und timestamps sowie extended-can-ids sind deaktiviert.

Im Library-Makefile habe ich auch den at90can128 eingestellt.

Das Makefile ist sicher richtig, da es das gleiche ist wie bei meinem letzten (erfolgreichen) Versuch mit dem MCP2515.

In dem Testprogramm mache ich folgendes:

• CAN & UART-Init

• Interrupts aktivieren

• Filter setzen (Alles auf 0)

• Loopback-Mode setzen

Und dann endlos:

• Message senden

• Message empfangen (Naja, eigentlich nur checken ob eine da ist)

Init etc. klappt, senden klappt 15x (bis die buffer voll sind), empfangen wird nichts…

Ich bitte um Entschuldigung für die vielen Comments (und vor allem für den uncompilierbaren Code).

# Niko meinte am 4. Mai 2011, 19:15 dazu:

So, kurz vorm aufgeben hab ich den AVR jetzt mal an die OBD Schnittstelle von meinem Auto gehängt und siehe da -> Er empfängt :-)

Ich vermute also, dass der Loopback-Modus nicht geht, oder ich falsch sende.

So, jetzt muss ich nur noch sinnvolle Daten vom Auto bekommen, dann bin ich glücklich :-)

Liebe Grüße

# Alex meinte am 28. Mai 2011, 23:03 dazu:

Hallo Fabian,

Danke für die tolle lib!! Ich habe sie testweise hier auf 5 CAN Boards laufen. Soweit geht alles, senden, empfangen, filtern. Nun habe ich aber ein Problem: Wenn mehrere Units gleichzeitig senden (natürlich mit anderer CAN ID), dann gehen mir Nachrichten verloren. Es sind immer andere die da fehlen, scheint zufällig zu sein. Einen ERROR Zustand auf dem Bus bekomme ich aber nicht. Was übersehen ich da?

Wenn der Empfänger immer wieder can_check & can_get_message aufrift, kann es sein daß er da einige “übersieht” wenn er zwischen den Checks beschäftigt ist mit Nachrichten verarbeiten?

Gruß, Alexandra

# Eugen meinte am 11. Juli 2011, 10:49 dazu:

Hallo Alex! Falls es sich noch nicht erledigt hat, hier ein Paar Überlegungen zum Thema: Kann es sein, dass die Empfangspuffer des MCP2515 volllaufen (er hat ja nur 2), also, dass praktisch die Nachrichten nicht schnell genug abgeholt werden? Auf dem Bus würde man in dem Fall keine Error-Frames sehen, denn die ACK-Flags werden weiterhin gesendet. Ich habe dieses Problem noch nie gehabt (weil ich gerade nur zwei Busteilnehmer habe), habe aber dafür gesorgt dass so was nicht passiert: die Nachrichten werden in der ISR erstmal aus dem MCP2515 ausgelesen (somit sind die interne Puffer des MCP2515 sofort wieder frei), in einen Zwischenpuffer geschrieben und anschließend vom Hauptprogramm aus dem Puffer geholt und verarbeitet. Gruß Eugen

# Jakob meinte am 20. Juli 2011, 21:09 dazu:

Hallo, inzwischen läuft die Lib. Es lag wie schon weiter oben an den Filtern und an sei.

Nun ist es so, das ich alle 100 ms 3 CAN-Botschaften an den AT90CAN schicken, er aber immer nur eine empfängt und verarbeitet (meinstens die erste der versendeten). Kann es sein, das in der Lib nicht alle Empfangspuffer verwendet oder abfragt?

Gruß Jakob

# Christian meinte am 24. Juli 2011, 13:37 dazu:

Hallo, ich bin Neuling in dieser Materie und möchte eigentlich nur das test program erstmal zu laufen bekommen. Dieses Habe ich in MYAVR ein gefügt die dateien can.h , config.h und libcan.a in den Programm ordner geladen. Desweiteren habe ich #include “can.h” und #include “config.h” gemacht. doch leider kennt MyAVR can_init() und can_send_message() immer noch nicht. kann mir jemadn einen Tip geben was ich falsch mache. Ich verwende Atmega32, MCP2515, MCP2551, CANUSB Adapter (Lawicel)

Gruß Christian

# Jakob meinte am 27. Juli 2011, 21:33 dazu:

Es werden nur die verwendet die du vorher darauf konfiguriert hast. Wenn jetzt eine Nachricht empfangen wird, dann ist der Puffer so lange gesperrt bis die Nachricht ausgelesen wurde (per can_get_message). Kommt in der Zwischenzeit eine weitere Nachricht an, so wird diese verworfen (falls nicht ein zweiter Puffer entsprechend konfiguriert ist und sie aufnehmen kann). Wenn die Nachrichten direkt hintereinander kommen, dann sollte man mindestens zwei Puffer zum Empfangen vorsehen.

Hallo Fabian,

danke für die Antwort.

Wie folgt habe ich die MOBs als Empfänger initalisiert:

# Fabian Greif meinte am 28. Juli 2011, 10:58 dazu:

Ist dass so I.O.?

Nein.

Wenn du die Bibliothek verwenden willst musst du sie auch verwenden:

can_filter_t filter = {
    .id = 0,
    .mask = 0,
    .flags = {
        .rtr = 0,
        .extended = 0
    }
};

for (uint8_t i = 0; i < 15; i++) {
    can_set_filter(i, &filter);
}

Damit kannst du allerdings nichts mehr senden weil alle MObs mit empfangen beschäftigt sind. Mindestens ein MOb sollte also frei gelassen werden.

Grüße Fabian

# Fabian Greif meinte am 29. Juli 2011, 11:42 dazu:

Wie konfiguriere ich eigentlich ein MOB als Sender mit deiner LIB?

Gar nicht. Du lässt es einfach “frei” bzw. konfigurierst es nicht als Empfänger, dann wird es zum Senden verwendet.

Grüße Fabian

# Jakob meinte am 29. Juli 2011, 20:07 dazu:

Hallo Fabian,

ist die Funktion can_set_filter() aus der Datei at90can_set_dyn_filter.c ?

Gruß

# Stefan meinte am 1. August 2011, 13:52 dazu:

Hallo Fabian, Hallo Gemeinde,

Ich möchte mich hiermit zunächst in die Reihe der Danksagungen einreihen! Ohne die Bibliothek wäre mein Projekt wohl zum Scheitern verurteilt. Trotzdem habe ich als MCU-Anfänger einige Probleme.

Frage: Ich möchte meinen AT90CAN auf einen Remote-Request-Frame antworten lassen. Dabei soll, nach Theorie, der Empfänger der empfangenen CAN-Botschaft mit gesetzten RTR-Bit, nur die Daten anhängen. Mir ist erstmal generell noch etwas unklar, wie ich auf empfange Botschaften reagiere bzw. diese verarbeiten kann. Aber ich habe mir gedacht, dass ich das rtr-bit von msg auswerten müsste und damit an das rtr-Bit der can_t-Stuktur gelangen müsste.

 int main(void) {
   can_init(BITRATE_125_KBPS);
   can_filter_t filter = {
         .id = 0x555,   //erwatet Frame mit ID:0x555?!
         .mask = 0,     //Maskierung "egal" 
         .flags = {     
         .rtr = 1,              
         .extended = 0  }       
        };
   can_set_filter(0, &filter);

   while (1) {
       if (can_check_message()) {
          can_t msg2;
          can_get_message(&msg2);   
          if (msg2.flags.rtr == 1){
            msg2.data[0] = 0xde;
            msg2.data[1] = 0xad;
            can_send_message(&msg2);
   }
  } 
 }
}

Ist natürlich aber irgendwie falsch. Ich versende über einen PCAN-Tester die Remote-Frames, aber die MCU antwortet nicht. Die Abfrage nach dem Eingangspuffer muss doch in die while-Schleife, damit die MCU ständig nach neuen Daten prüft!? Oder es ist mal wieder irgendwo ein typischer Anfängerfehler vorhanden?

Danke und VG

# Klaus meinte am 6. August 2011, 21:19 dazu:

Habe die Bibliothek nun mit Hardware-SPI auf dem ATtiny44 laufen. Das Posting von SP zu diesem Baustein ist irreführend, da er MOSI und MISO vertauscht hat. Dies kommt durch eine Besonderheit des ATtiny44-Bausteins: Data out ist immer Data out, egal ob man ihn als Master oder als Slave konfiguriert, weshalb das MISO-Pin nur für Slave-Betrieb MISO ist, im Master-Betrieb jedoch Data Out. Man muss das Datenblatt aber schon etwas genauer anschauen, um das zu finden. Den Patch habe ich Dir bereits per Email geschickt.

# Fabian Greif meinte am 25. August 2011, 14:23 dazu:

Hallo Johannes,

versuch mal in der Datei spi.h die Zeile

extern __attribute__ ((gnu_inline)) inline void spi_start(uint8_t data)

durch

static inline void spi_start(uint8_t data)

zu ersetzen. Gleiches bei spi_wait().

Wenn das noch nichts hilft, dann schreib mir am besten nochmal eine E-Mail.

Grüße Fabian

# Dennis meinte am 25. September 2011, 17:41 dazu:

Vielen Dank für die Lib. Leider bekomme ich sie nicht zum laufen. Ich habe deine Demo um ein par UART Debug prints erweitert, und festgestellt das er gar nichts Empfängt. Das ganze läuft aus deinen Testboards mit ATMEGA644.

Gibt es fertigen Code mit UART Kommandos der Garantiert funktioniert, damit ich Hardwarefehler ausschließen kann? Oder kann ich irgendwie per Uart die Kommunikation zwischen AVR und MCP debuggen? ich habe kein gescheites Oszi, somit kann ich die Signale nicht beobachten.

Danke

# Sebastian meinte am 29. November 2011, 12:09 dazu:

Hallo Fabian,

wir würden deine Bibliothek gerne für einen ATxmega128A1 nutzen, da dies Teil unseres Projektseminars ist. Kannst du uns sagen welche Anpassungen wir vornehmen müssen um deinen Code übernehmen zu können? Eine Library konnten wir mit WINAVR leider nicht erstellen da wir immer die Fehlermeldung erhalten, dass die MCU nicht nicht untertützt wird.

Wir nutzen die aktuellste Version von WINAVR (2010). Den passenden MCU identifier haben wir auch schon eingetragen (MCU = atxmega128a1).

Hast du eine Idee was wir vergessen haben?

Viele Grüße, Thorsten und Sebastian

# Chris meinte am 6. Dezember 2011, 12:02 dazu:

Hi, hatte auch Probleme die Library bei mir zum laufen zu bekommen (can_init blockiert). Bei mir lag es daran, dass ich nicht den SS-Pin für slave select benutzt habe. Dann kann es passieren, dass sich der Atmel in den slave-mode verabschiedet. Lösung ist entweder den SS-Pin als Output zu konfigurieren oder die Pull-ups zu aktivieren. (Siehe Datasheet SPI -> SS Pin Functionality)

# Fabian Greif meinte am 22. Dezember 2011, 16:42 dazu:

Can this library be used on the atmega32C1 processor?

Basically yes, but not without changes. At a first glance the registers for the AT90CAN and the ATmega32C1 look very similar. So it should be easy the perform the necessary changes (e.g. only 6 MObs instead of 15, a few defines etc.).

Best regards,
Fabian

# Fabian Greif meinte am 28. Dezember 2011, 15:41 dazu:

Hallo, ich benutze das AVRStudio da ich den ATMega8515 einsetze. Können sie mir einen Tip geben, wie ich die Library dort kompiliere und einbinde?

Nein, vom AVR Studio habe ich leider gar keine Ahnung. Ich entwickle sämtliche Software mit Hilfe von Eclipse und Make/SCons.

Das compilieren der Bibliothek kann ja auch außerhalb von AVR Studio passieren da es ja pro Projekt nur einmal erfolgen muss. Zum Einbinden der Bibliothek sollte dann bei “Linkereinstellungen” oder so ähnlich im AVR Studio möglich sein.

Grüße Fabian

# Fabian Greif meinte am 29. Dezember 2011, 14:20 dazu:

Ich kann auch 3 Nachrichten senden (Normal oder Loopback-Mode) aber dann bleibt das Programm hängen.

Dann sind vermutlich danach die drei Sendepuffer voll. Was hängt denn außer dem MCP2515 noch an deinem CAN Bus? Du brauchst immer einen zweiten Teilnehmer, ansonsten bekommt der MCP2515 kein Acknowledge vom Bus und schaltet sich in den Bus-Off-Modus.
Wenn du die Fehlerzähler ausließt solltest du das dort direkt erkennen können.

Grüße Fabian

# Sebastian meinte am 30. Dezember 2011, 16:46 dazu:

Hallo Fabian,

ich habe gefunden, woran es lag. Ich muss nur den PIN SS als Output definieren, bevor das SPI initialisiert wird. Sonst läuft dies nämlich im Slave-Modus und bleibt dann hängen. Warum ich trotzdem mehr als drei Nachrichten senden konnte bleibt mir aber ein Rätsel! Trotzdem danke für deine Mühe!

# Fabian Greif meinte am 5. Januar 2012, 17:55 dazu:

Hallo Schorsch,

Grundsätzlich geht das, aber im Moment besteht das Problem das #defines für den MCP2515 und den AT90CAN gleich benannt sind. Die entsprechenden Defines müsstest du umbenennen, dann sollte das klappen.

Kann man die Funktionen auch ohne Lip direkt einbinden sofern man genug Flaskspeicher hat

Natürlich kann man das auch. Es sind aber vermutlich einige kleinere Anpassungen nötig.

Grüße Fabian

# Fabian Greif meinte am 19. Januar 2012, 13:01 dazu:

Ist das sehr viel, was man da abändern müßte? Und WAS genau müsste man denn ändern?

Das müsste man ausprobieren. Wenn du alles in den gleichen Ordner wie deine Anwendung schmeißt (was ich nicht empfehlen würde) dann könnte es so direkt funktionieren. Ansonsten musst du vermutlich Pfade anpassen.

Spricht eigentlich etwas dagegen, dass ich die einzelnen Files dazu gleich ‘zusammenfasse’?

Nein. Wenn du das gerne tun möchtest kannst du das gerne tun.

Grüße Fabian

# Fabian Greif meinte am 9. Februar 2012, 16:17 dazu:

Hallo Hugo,

Ich möchte z.B. nur IDs mit 0xX00 und 0xX11 empfangen. Ich hätte das dann so umgesetzt: (…)

das ist genau richtig so.

Was ich nicht verstehe ist Group 0/1!? Was bedeuten sie?

Es gibt mehrere Filter die die gleiche Maske benutzen. Ich habe einfach mal alle Filter mit gleicher Maske zu Gruppen zusammengefasst, nämlich Group 0 und Group 1. Diese Gruppen entsprechenden dann auch in beiden Empfangspuffern. Das steckt dahinter.

(…) Wenn ich jetzt z.B. 4 IDs filtern will geht das dann so?

Jein. Der zweite Empfangspuffern (Group 1) macht genau das was du willst, allerdings empfängt du mit dem ersten Puffer alle Nachrichten (da Mask = 0).

Und warum hat Group 1 vier Filter und Gourp 0 nur zwei?

Das musst du Microchip fragen. Keine Ahnung warum sie es so gelegt haben.

Grüße Fabian

# Marcel meinte am 15. Februar 2012, 12:27 dazu:

Der Rest hatte leider nicht mehr reingepasst:

Die While…

while(1)
{
// Check if a new messag was received
if (can_check_message())
{
can_t msg;

// Try to read the message
if (can_get_message(&msg))
{
// If we received a message resend it with a different id
OCR1A = 100;
}
}

"wenn Button gedrückt"(die Formatierung lässt leider keinen
   Shift-Operator zu und schneidet immer den Text ab, 
   desshalb auf diese Weise^^)
{
can_t msg;

msg.id = 0x123456;
msg.flags.rtr = 0;
msg.flags.extended = 1;

msg.length = 4;
msg.data[0] = 0xde;
msg.data[1] = 0xad;
msg.data[2] = 0xbe;
msg.data[3] = 0xef;

// Send the message
can_send_message(&msg);
}
}

WAS mache ich denn nur falsch? Etwas vergessen?

Liebe Grüße

# Frank meinte am 25. Februar 2012, 16:39 dazu:

Hallo,

habe ein wenig rumprobiert: Es geht alles einwandfrei, wenn ich die RX-Objekte nacht den TX-Objekten palziere. Also in meinem Fall 0..5 TX-Nachrichten und mit:

can_set_filter(6, &filter);

das 6te Objet zum empfangen nehme. Habe ich da was übersehen ? Ich finde irgendwie nicht den Grund dafür …

Gruss Frank

# Steffen meinte am 26. Februar 2012, 22:06 dazu:

Hallo,

ich spiele seit kurzem mit einem AT90CAn128 herum, geneuer gesagt mit dem CAN-Controller usw. Ich habe dazu einmal die Lib in Betrieb genommen. Das funktionierte eigentlich auch grundsätzlich auf anhieb.

Senden geht wunderbar, am laufenden Band in einer Schleife ohne Probleme. Das Empfangen funktioniert aber nicht 100%ig. Generell kann der Controller empfangen und sendet eben die empfangene CAN Message auch zur Kontrolle wieder an den PC zurück, aber irgendwo steckt noch der Wurm drin.

Im Codeausschnitt unten sieht man in der while-Schleife ein Delay von xy ms. Wenn dies drin ist, wird jede empfangene Message beantwortet. Aufgrund des Delays können die Nachrichten natürlich nicht unendlich schnell empfangen werden. Wenn zu schnell an den 90Can gesendet wird, fallen einige empfangene Nachrichten unter den Tisch und es wird eben nur auf jede X-te geantwortet. Wenn ich die Schleife ohne Delay laufen lasse, werden gar keine Nachrichten empfangen. Ich kann dann so viele Nachrichten an den Controller senden wie ich will, es kommt keine an.

Ich habe im Moment in der while-Schleife noch Tasterabfragen und ein paar weitere kleine Dinge, aber egal, ob nur die CAN Geschichte in der While-Schleife steht oder auch die anderen Sachen. Ohne das Delay werden keine Nachrichten empfangen. Mit dem Dealy geht es dann, aber eben recht langsam. Die

CAN-Nachrichten, die empfangen werden sollen, brauchen eben einen entsprechenden Abstand, um empfangen zu werden.

Allgemein, wenn dann mal eine Message empfangen wird, wird sie auch ordnungsgemäß zurück an den PC gesendet.

Ich habe schon versucht CAN_RX_BUFFER_SIZE zu nutzen, aber das ändert an der ganzen Sache nix. Scheinbar ist auch die Bitrate egal. Habe es von 125K bis 1M probiert, immer das Gleiche.

Gibt es da irgendwo noch eine Schraube in der Lib, an der man da drehen kann?

Beste Grüße Steffen

` int main { cli; initPorts; initInterupt;

can_init(BITRATE_125_KBPS);         
can_filter_t filter = {
        .id = 0,
        .mask = 0,
        .flags = {
                .rtr = 0
             }
              };

    for (uint8_t i = 0; i < 7; i++) 
{
    can_set_filter(i, &filter);
}

can_set_mode(NORMAL_MODE);
    sei();                              
msg.id= 0x1234567;                  
msg.flags.rtr= 0;
msg.flags.extended= 1;              
msg.length= 4;                      
msg.data[0]= 0x89;                  
msg.data[1]= 0xAB;
msg.data[2]= 0xCD;
msg.data[3]= 0xEF;
can_send_message(&msg);             

while(1)
    {

    _delay_ms(13);
    if(can_check_message())
    {
        can_t msg;

        if(can_get_message(&msg))
        {
        msg.id += 10;  
        can_send_message(&msg);

        }
    }


}

}`

# Fabian Greif meinte am 1. März 2012, 14:18 dazu:

Meine Frage wäre nun, ob Fehler z.B. beim senden direkt erkannt und ausgewertet werden

Nein, die Fehler werden nicht automatisch behandelt. Das müsstest du selbst tun.

Grüße Fabian

# yankee meinte am 10. März 2012, 03:03 dazu:

Ist die Information “Die Bibliothek braucht ca. 1500 Byte Flash mit allen Funktionen. Verwendet man keine dynamischen Filter sind es 370 Byte weniger.” noch aktuell? Mein kleines Testprogramm hat ohne dynamische Filter hat ca. 4000 Bytes was bei 2kb Speicher auf dem ATtiny2313 garnicht mal so gut ist…

# Sven meinte am 17. März 2012, 12:03 dazu:

Hallo,

ich habe ein Problem mit der Einstellung

define SUPPORT_EXTENDED_CANID 1

Steht das eben auf 1 ist alles OK, wenn ich das nicht definiere oder auf Null setze, bekomme ich eine fehlermeldung:

'_messages_waiting' undeclared (first use in this function'

Das ist dann in der Datei:

at90can_get_message.c

Zeile 83.

_messages_waiting--;

Woran könnte das liegen? Beste Grüße

Sven

# Fabian Greif meinte am 17. April 2012, 23:10 dazu:

Hallo Christoph, ich vermute das dein zweiter Knoten kein korrektes Acknowledge sendet. Überprüf mal die Leitungen vom und zum CAN Transceiver. Was auch gerne zu seltsamen Fehlern führt, ist wenn man den Reset offen lässt.

Grüße Fabian

# Fabian Greif meinte am 18. April 2012, 13:11 dazu:

Sollte der CAN Trasceiver nicht automatisch abschalten wenn er merkt das dauernd Fehler auftreten?

Das CAN Transceiver nicht, der ist ja nur ein Pegelwandler. Aber der CAN Controller sollte das nach einer Zeit tun. Du könntest mal die Fehlerregister auslesen und schauen ob dort etwas drinnen steht.

(…) So geht es, ist aber dirty :-(

In der Tat, das ist nicht schön. Mir ist so ein Verhalten bisher noch nicht begegnet, von daher kann ich leider nicht so viel dazu sagen. Kannst du weitere CAN Konten an das Netzwerk hängen von denen du weißt, dass sie sicher funktionieren?

Grüße Fabian

# Fabian Greif meinte am 19. April 2012, 02:36 dazu:

im can_error_register_t.tx ist das MSB gesetzt. Leider weiß ich net wo ich schauen kann was das heißt, im Datenblatt hab ich net genau gefunden welches register das sein kann.

Das ist TEC Register. MSB gesetzt = 128 hieße der Controller ist im Error-passive Mode (siehe Seite 45 im Datenblatt). Das bedeutet irgendwas klappt bei deiner Kommunikation nicht. Das erklärt auch die sich wiederholenden Nachrichten, die werden nämlich so lange versendet bis sie von mindestens einem Empfänger fehlerfrei empfangen wurden.

Grüße Fabian

# Stefan meinte am 7. Mai 2012, 21:45 dazu:

Hallo,

ich benutze die CAN Lib mit einen AT90can128. In der heruntergeladenen CAN Lib habe ich folgendes geändert: makefile:

Makefile: MCU = at90can128 config.h:

define SUPPORT_EXTENDED_CANID 0

define SUPPORT_TIMESTAMPS 0

define SUPPORT_AT90CAN 1

define CAN_FORCE_TX_ORDER 0

define CAN_TX_BUFFER_SIZE 20

define CAN_RX_BUFFER_SIZE 20

Fehler bei bauen der Lib: at90can_send_message.c: In function ‘at90can_send_message’: at90can_send_message.c:114: error: ‘_transmission_in_progress’ undeclared (first use in this function) at90can_send_message.c:114: error: (Each undeclared identifier is reported only once at90can_send_message.c:114: error: for each function it appears in.) make: *** [build/at90can_send_message.o] Error 1

Was mache ich falsch? Kann mir jemand helfen?

Gruß Stefan

# Bernhard meinte am 20. Juli 2012, 09:25 dazu:

Hallo Jay,

ich kenn mich mit der Lib nicht so gut aus aber vielleicht hilfts ja….

1. Ist das GlobalInterruptflag gesetzt (sei();)?
2. Hast Du einen Filter gesetzt und wenn auch nur einen für alle Nachrichten? (Wenn Du keinen Filter setzt, dann ist kein Mob für den Empfang der Nachrichten eingerichtet)

Nach dem Du schreibst, das das Senden ohne Probleme funktioniert (ich vermute Du erhälst auch ein ACK von den anderne Teilnehmern) wird es wohl nicht an der Hardware liegen aber vielleicht kontrollierts Du die auch noch mal

mfg. Bernhard

# Hermann meinte am 29. August 2012, 09:51 dazu:

Hallo, gleiches Problem hatte ich auch. Für mich brachte folgenden Änderung Abhilfe (Orginal oben, abgeänderte Zeile unten):

in der can.h

//can_static_filter(const prog_uint8_t *filter_array);

can_static_filter(const uint8_t PROGMEM *filter_array);

in der at90can.h:

//prog_char _at90can_cnf[8][3] = {

const char PROGMEM _at90can_cnf[8][3] = {

viele Grüße, Hermann

# Faisal Alam meinte am 5. Oktober 2012, 12:32 dazu:

Hallo Fabian. Super Library erstmal. Ich möchte diese auf meinen AtMega328 anwenden und habe deshalb in der config.h CS auf den Pin 10 gelegt. Welche Daten muss ich noch in der Makefile anpassen?

Vielen Dank im voraus.

# Fabian Greif meinte am 9. Oktober 2012, 08:52 dazu:

Und muss ich dazu nur mcp2515_private.h abändern, die Defines bei den IO-Pins anpassen und spi.c abändern?

Ja, mehr sollte nicht nötig sein. Der Rest ist ja dann prozessorunabhängig.

Grüße Fabian

# Alexander meinte am 11. November 2012, 17:33 dazu:

Hallo Fabian, versuche gerade Deine Library auf dem Atmel Studio 6 zu übersetzten. Dafür habe ich diesen typedef gesetzt: typedef uint8_t prog_uint8_t; Ausserdem will ich einen ATmega162 an dem mcp2515 ankoppeln. Dazu habe ich folgende Zeile (mcp2515_private.h)

if defined || defined || defined || \

defined(__AVR_ATmega162__) Habe ich noch etwas vergessen? Kompilierung läuft. Test werde ich noch machen. Danke

# Fabian Greif meinte am 14. November 2012, 11:10 dazu:

is there a public repository for this library? i have uploaded the current state to github anyway: (…)

As there is obviously a demand I did the same thing and created a “official” github repository:

https://github.com/dergraaf/avr-can-lib

# Jürgen meinte am 25. November 2012, 14:34 dazu:

Hallo, ich habe massiv Probleme beim Übersetzen der lib unter Atmel Studio 6. - Problem prog_uint8_t: den Typ kennt Studio nicht mehr. Der Tipp von fckw (“__flash”) scheitert: kennt er auch nicht. Tipp von Hermann (uint8_t PROGMEM) führt zu:

can.h:393:1: warning: ‘progmem’ attribute ignored [-Wattributes] mcp2515.c:130:17: error: variable ‘_mcp2515_cnf’ must be const in order to be put into read-only section by means of ‘attribute((progmem))’

Testweise mal PROGMEM weggelassen (was zu ner falschen lib führt, ich weiß). Dann käme als nächster Fehler:

mcp2515.c:268:1: fatal error: opening dependency file .dep/mcp2515.o.d: No such file or directory

Das alles in der Kommandozeile, die ich aus Atmel Studio aufrufen kann. Bin mit meinem Latein am Ende. Kannst du bitte weiterhelfen? Oder wenigstens ein paar Tipps? Danke, Jürgen

# Jürgen meinte am 16. Dezember 2012, 14:25 dazu:

Hallo Mebus, kann in der github-Version keinen Unterschied zum Original feststellen. Dort wird nach wie vor “const prog_uint8_t *filter_array” definiert, und das Problem bleibt, dass prog_uint8_t in Atmel Studio 6 nicht definiert ist… siehe oben: die Workarounds der beiden anderen Kommentatoren fruchten nicht. Es muss doch möglich sein, hierfür einen Ersatz zu definieren… Ich kann zwar C, aber im Bereich der Atmel-Programmierung bin ich Anfänger. Eine Idee?

# bhaskar meinte am 19. Dezember 2012, 11:42 dazu:

I a new to CAN shield, I use CAN hield from sparkfun and arduino mega 2560 , volks wagen ECU ,PCAN-TJA1054 between can shield and ecu,when I send some mesaage I am unable to get any reply from the ecu, can somebody help me in this regard…..

# Toni meinte am 11. Januar 2013, 18:02 dazu:

Hi, ich habe das gleiche Problem wie Jay. Ich nutze einen MCP2515 und einen ATMega88. Nachrichten senden funktioniert, empfangen leider nicht. sei verwende ich und eine Filter setze ich auch. Wie bekommt denn der ATMega mit ob eine Nachricht im MCP2515 liegt? Läuft das über ein Interrupt? Und ja welcher Pin wird dafür genutzt?

# Fabian Greif meinte am 11. Januar 2013, 18:17 dazu:

@JayB

Ich hab mal da deine frage zu can_check_message, bleibt das solange True bis alle Puffer ausgelesen worden sind oder wie kann ich wenn ich mehrere eingangspuffer definiere alle Auslesen ?

Das bleibt TRUE bis keine Nachricht mehr in den Puffern vorhanden ist.

Da hier ja anscheint nur ein Puffer ausgelesen wird,

Ja, aber der Code steht meist in einer Schleife. Beim nächsten Durchlauf würde dann der zweite Puffer ausgelesen werden.

Grüße Fabian

# clemens meinte am 21. Februar 2013, 15:10 dazu:

Ich bin gerade dabei die lib auf die xmegas zu portieren. bis jetzt komme ich gut zurecht, habe aber bei folgendem makro noch keine idee: SET würde ich gerne zu PORTC.Set=MCP2515_CS konvertieren wobei PORTC als “#”define MCP2515_Xmega_CS_Port PORTC in der config.h liegt hat jemand eine idee, wie sowohl für atmega und xmega eine konvertierugn möglich ist? sonst werde ich es über ein #ifdef abfangen, wobei ich das weniger schön fände

# Fabian Greif meinte am 25. Februar 2013, 17:15 dazu:

Hallo Bernd, ohne eine Fehlermeldung/Beschreibung kann ich dir da leider nicht weiterhelfen.

Versuche es mal mit der Version von GitHub, wenn es das Problem mit den prog_char Typen ist, dann ist das dort behoben: https://github.com/dergraaf/avr-can-lib

Grüße Fabian

# Sebastian meinte am 26. Februar 2013, 21:29 dazu:

Hallo Fabian,

nochmal danke für deine tolle Library! Sie hat mir echt geholfen und meine Faszination für uCs erneut geweckt! Großes Lob!

Eine kleine Frage hätte ich noch. Ich benutze den dynamischen Filter, da ich die ID aus dem EEPROM lese. Für den Puffer 1 setze ich Mask auf 0xFFFF und ID auf meine ID, für Püffer 2 ebenso. Mein Ziel ist es nur die Nachrichten für meine ID zu bekommen.

 can_set_filter( 0, &mycanfilter)
 can_set_filter( 2, &mycanfilter)

Das klappt soweit auch, wenn ich jedoch im Standby bin wacht der uC jedes mal auf. Dann fragt er mit

 can_get_message(&msg_in)

die Nachricht ab und gibt als Rückgabewert 0x00 zurück - sprich das Lesen der Nachricht ist fehlgeschlagen. Ist ja auch logisch, da gar keine Nachricht da ist. Ist der uC nicht im Standby bekommt er komischerweise keinen Interrupt und er fragt auch nicht nach.

Gibt es eine Möglichkeit wie man verhindert, dass der uC im Standby einen Interrupt vom MCP bekommt? Ich hätte jetzt erwartet, dass der dauerhaft im Standby bleibt da ja keine Nachricht für ihn da ist … . Habe ich noch etwas übersehen?

Danke für deine Rückmeldung!

# Sebastian meinte am 4. März 2013, 13:54 dazu:

Hallo Fabian,

du hast natürlich recht. Ich habe den INT-Pin des MCP2515 direkt an den INT0 meines ATMega8 gehängt. Dieser ist dann als Interrupt auf LowLevel definiert.

Wenn der MCP2515 eine Nachricht bekommt, die er eigentlich filtern müsste legt er einen Low-Pegel an seinem INT-Pin an und mein ATMega8 wacht daraufhin aus dem Standby auf. Ich hoffe ich habe mein Problem verständlich geschildert.

# Karsten meinte am 14. März 2013, 11:58 dazu:

Moin Moin Fabian und Wissende,

Vielleicht eine dumme Frage: Die can.id ist mir uint32_t definiert. Bei extended möchte ich nun die 29bit ID übergeben. Dazu schreibe ich die Bits in ein unit32_t. Es bleiben dann ja 3 bit unbenutzt. Sind das die msb (most significant BIT) oder muss ich alles um 3 nach “links” shiften ?? Daaanke für eure hilfe

# Sebastian meinte am 18. März 2013, 12:05 dazu:

Hallo Fabian,

ich benutzte die Lib das erste Mal in einem AT90CAN128. Senden, sowie empfangen laufen prima. Ich hab eine Frage zu den Filtern. Wenn ich den folgenden Filter auf eine ID z.B. 0x80 setze, funktioniert das auch.

can_filter_t filter = {
  .id = 0x80,
  .mask = 0x7FF,  // nur die ID wird enpfangen
  .flags = {
      .rtr = 0,
  }
};
can_set_filter(0, &filter);

Kann ich mehrere Filter auf verschiedene ID´s setzen? Ich kann doch eigentlich lt. Datenblatt jedes von den 15 Mob einzeln mit einem Filter versehen. Ich möchte 6 verschieden ID´s beim Empfang filtern. Danke für die Unterstützung!

# Sebastian meinte am 18. März 2013, 16:13 dazu:

Hallo Fabian,

danke für Deine Antwort. Das Einrichten mehrerer Filter hat tadellos funktioniert. Eine Kleinigkeit hätte ich noch. Ich nutze den Timer1 für eine ISR und bekomme seitdem die Lib eingebunden ist 3 Warnings beim übersetzen. Wird durch die Lib der Timer1 benutzt oder blockiert?

ISR (TIMER1_COMPA_vect) { … }

warning: return type defaults to ‘int’ warning: type of ‘__vector_12’ defaults to ‘int’ warning: control reaches end of non-void function

Nochmals vielen Dank für deine Hilfe!

# Chris meinte am 30. März 2013, 00:14 dazu:

Absolut großartig! Die Library hat auf Anhieb auf meinem AtMega8 funktioniert. Vielen Dank dafür, die Lib bietet einen tollen Einstieg in das Thema CAN.

Das Demoboard habe ich allerdings als SMD-Variante gelayoutet, mit einem FT232RL, also USB Anschluss. Soll ich dir das Layout für deine Seite schicken? Ist aber nicht perfekt…

# Fabian Greif meinte am 29. April 2013, 10:15 dazu:

Hello Steeve,

Hello Fabian, and congratulation for your work that’s very impressive !

Thanks!

I’ve seen that you put hfuse 0xDC and lfuse 0x94 into your board (…). Does it mean that my board can’t work with your bootloader ?

No, it just means that you have to change these values according to your AVR. These values are only valid for an ATMega32 without the u4.

When you use the internal 8 MHz oscillator than lfuse=0xd2, hfuse=0xdc and efuse=0xf3 should work.

Regards, Fabian

# Dennis W: meinte am 25. August 2013, 11:31 dazu:

Hallo Fabian,

erst einmal vielen Dank für diese Bibliothek, sie funktioniet auf meinem AT90CAN128 ohne Probleme. Ich verwende den AVR-CAN von der Firma Olimex.

Aus Kostengründen der “Slave”-Knoten würde ich gerne auf ein Gespann von ATMega 8x, MCP2515 CAN Controller, MCP2551 Treiber aufsatteln. Da bietet sich das CAN Testboard an.

Frage: Um die Last auf den µC zureduzieren, wollte ich fragen, warum die Interruptleitung des MCP2515 nicht auch zu einem Interrupt im AVR führt? Auch im AT90CAN128 muss ich “pollen”, ob Nachrichten vorhanden sind. Was sind die Gründe für diese Handlungsweise? Gibt es Ansätze in der Bibliothekt, Interrupthandling zu verwenden?

Viele Grüße aus Bremen, Dennis

# Viktor meinte am 26. September 2013, 11:39 dazu:

Hallo Fabian! Vielen Dank für deine tolle Arbeit. Wie du dir sicherlich denken kannst, könnte auch ich deine Hilfe gebrauchen. Ich habe hier einen ATmega32 @8MHz mit einem MCP2515 @8MHz und versuche Daten mit einem CAN-fähigen Datenlogger zu senden und zu empfangen. Das Senden funktioniert nur bedingt, da der MCP nach ca. 10 bis 25 Nachrichten in den Fehlermodus geht (Sendepuffer wird nicht geleert bzw. überschrieben). Empfangen kann ich auch nur 3 Nachrichten. Was mich allerdings wundert, ist es wenn ich den MCP mit 100kBps initialisiere, funktioniert die Kommunikation mit 500kBps. Ich sitze bereits seit einer Woche daran und finde den Fehler einfach nicht. Hättest du evtl. einen Tipp für mich?

Viele Grüße Viktor

# Marco meinte am 3. November 2013, 15:58 dazu:

Hallo, ich möchte mich gern meinen Vorgängern anschließen und mich für die tolle Lib bedanken, die Einbindung ging relativ schnell und ohne Probleme.

nun habe ich aber doch ein kleines Problemchen und hoffe das ich hier hilfe finde. Einige haben das Problem schon geschildert, jedoch habe ich keine Lösung finden können, welche das Problem behebt. Ich benutze ein At90Can128 Board. und möchte gern eine Kommunikation mit einem PeakCan zum PC herstellen.

Das senden funktioniert sehr gut, jedoch das empfangen nicht.

ich habe den Code relativ einfach gehalten und möchte nur auf den Status überprüfen und anschließend eine LED blinken lassen. jedoch funktioniert dies schon nicht.

    // Initialize LED
       LED_INIT;

    // LED Blinken
       LED_Welcome(); 

    // CAN initialisieren 
       can_init(BITRATE_125_KBPS);

    // anfangszustand alle Filter off
   can_disable_filter(0xff);

   // Modus festlegen  
   can_set_mode(NORMAL_MODE);

    // Filter festlegen
       can_filter_t filter = {
      .id = 0x1FFFFFFF,
      .mask = 0x7ff,
      .flags = {
      .rtr = 0,
      .extended = 1
    }
     };

   // Filter setzen 
   can_set_filter(0, &filter);  

   // Int. einschalten
   sei();

   // Nachricht erzeugen    
   can_t msg;
msg.id = 0x12345678;
msg.flags.rtr = 0;
msg.flags.extended = 1;
msg.length = 1;
msg.data[0] = 0xff;

// Nachricht verschicken
can_send_message(&msg);
LED_Off;        _delay_ms(1000);


while (1){

    if (can_check_message())
    {
        LED_Welcome();  // blinken
    }
}

return 0; }

Die Terminierung wurde auf dem Board vorgenommen. Der USB CanAdapter steckt direckt am Board.

vielleicht kann mir jemand von euch weiter helfen

Danke

Danke

# Marco meinte am 15. November 2013, 19:54 dazu:

Hallo,

deine Lib funktioniert nun auch bei mir. Nach einigen Anfangsproblemen, welche aber immer durch den Anwender verursacht werden.

Nun möchte ich gern dir Lib mit einem Interrupt benutzen.

Hat jemand ein Beispiel? Ich möchte gern auf eine Empfangen Nachricht ein Interrupt auslösen, welche die Nachricht verarbeitet und wieder eine Nachricht zurücksendet.

in der restlichen Zeit will ich den µC in den Standby setzen um Strom zu sparen. Ich höre auch noch auf andere Interrupts (Taster usw)

In der Doku konnte ich leider kein Beispiel für einen Interrupt finden, Stelle mich bestimmt wieder total blöd an,

aber erst einmal vielen Dank für die Hilfe

Marco

# jacyju meinte am 1. Januar 2014, 20:48 dazu:

Auch von meiner Seite ein herzliches Dankeschön für die echt nützliche CAN-Bibliothek. Ich habe allerdings lange mit einem Problem kämpfen müssen bei dem ich dachte, es hängt mit meinem Code zusammen: Wenn mehrere Nachrichten schnell hintereinander (ohne delay_ms) gesendet wurden ist es vorgekommen, dass die Nachrichten in der Reihenfolge vertauscht waren. Das mag zwar bei einfachen Steueraufgaben nicht stören, wohl aber z.B. bei einem Bootloader, bei dem die Daten genau in der Reihenfolge ankommen müssen, wie sie gesendet wurden.

Das Problem liegt in der Datei “mcp2515_send_message.c”. Hier werden die Sendepuffer in der falschen Reihenfolge gefüllt. Nach einem Blick ins Datenblatt habe ich hier den Fehler verortet. Mein verbesserter und funktionierender Code sieht so aus:

uint8_t mcp2515_send_message(const can_t *msg)
{
    // Status des MCP2515 auslesen
    uint8_t status = mcp2515_read_status(SPI_READ_STATUS);

/* Statusbyte:
 *
 * Bit  Funktion
 *  2   TXB0CNTRL.TXREQ
 *  4   TXB1CNTRL.TXREQ
 *  6   TXB2CNTRL.TXREQ
 */
uint8_t address;
/*
ORIGINAL GEÄNDERT, SONST WAREN NACHRICHTEN BEI SCHNELLEM SENDEN HINTEREINANDER IN FALSCHER REIHENFOLGE,
DA PUFFER VON HOCH NACH NIEDRIG ABGEARBEITET WERDEN (s. Datenblatt MCP2515 Transmit Priority, S. 15:
"If two buffers have the same priority setting, the buffer with the highest buffer number will be sent first.")

In den ersten der 3 Puffer darf erst geschrieben werden, wenn alle anderen leer sind.
Sonst könnte es sein dass die Nachricht im ersten Puffer gerade weg ist, aber noch 2 ältere
in den anderen Puffern sind. Dann würde die jetzige neue Nachricht vor den älteren weggeschickt werden,
da sie ja dann ganz vorne im Puffer steht.
Man könnte das umgehen, indem man die anderen Nachrichten im Puffer "umschichtet", das heißt
alle anderen Nachrichten um einen Pufferplatz vorrückt. Oder man könnte die Priorität
der Puffer ändern. Beides ist aber kompliziert und braucht im Endeffekt sowieso
die gleiche Zeit, die es auch braucht bis die Nachrichten verschickt sind.
*/
if ((_bit_is_clear(status, 6)) && (_bit_is_clear(status, 4)) && (_bit_is_clear(status, 2))) {
    address = 0x04;
}
else if ((_bit_is_clear(status, 4)) && (_bit_is_clear(status, 2))) {
    address = 0x02;
} 
else if (_bit_is_clear(status, 2)) {
    address = 0x00;
}
else {
    // Alle Puffer sind belegt,
    // Nachricht kann nicht verschickt werden
    return 0;
}

RESET(MCP2515_CS);
spi_putc(SPI_WRITE_TX | address);
#if SUPPORT_EXTENDED_CANID
    mcp2515_write_id(&msg->id, msg->flags.extended);
#else
    mcp2515_write_id(&msg->id);
#endif
uint8_t length = msg->length & 0x0f;

// Ist die Nachricht ein "Remote Transmit Request" ?
if (msg->flags.rtr)
{
[…]

# Key Music meinte am 10. April 2014, 23:41 dazu:

Hallo zusammen, hallo Fabian,

habe gerade mal in die Library geschaut. Sehr gepflegt alles. Zu der Interrupt Service Routine ISR hätte ich mal eine Frage: Was passiert denn, wenn der TransmitOK- und ReceiveOK-Interrupt-Request gleichzeitig auftreten?! Könnte dann nicht der Receive-Part verloren gehen?

Wäre statt

if (CANSTMOB & _BV(TXOK))
{ ... }
else
{ ... }

nicht folgendes besser?

if (CANSTMOB & _BV(TXOK))
{ ... }
if (CANSTMOB & _BV(RXOK))
{ ... }

Gruß Key Music

# René meinte am 14. Mai 2014, 10:42 dazu:

Hallo,

deine Biblothek wurde mir empfohlen, bloss ist diese auch möglihch mit dem Xmega von Atmel zu betreiben?

Danke im voraus.