2 Stk. MCP2515 an einem z.B. ATMega32

Hallo,
daran hatte ich auch gedacht !!! es gibt ja welche mit 2 bis z.B. 5 (und 
mehr) internen Can Controllern nur sind die nur in SMD zubekommen und 
das könnte ich mit der Dip Varinate vom MCP2515, Mega32 und dem 
Treiberbaustein 82C250 umgehen. Mir macht die Programmierung in C schon 
deutlich zuschaffen.

Gruß
Peter C.

Hallo,
ja super, genau sowas suche ich.
Wäre es unverschämt nach der Lösung (Schaltplan und Code) zufragen. Ich 
würde sogar nur 100KBit benötigen. Eine Lösung für Maske/Filter findet 
sich bestimmt auch.

Gruß
Peter C.

Hallo,
mich würde die Schaltung von Autor: H.joachim Seifert (crazyhorse) schon 
mehr interessieren. Ich hoffe er meldet sich noch einmal.

Gruß
Peter C.

Hallo,
klasse, sind ja garnicht soviele Bauteile. Programmierst du in C ??????, 
Ist der Schaltplan mit Eagle oder Target gezeichnet worden ???
Kann ich irgend wie an den Quellcode kommen, muß ja nicht umsonst sein 
!!??

Welche Funktion übernimmt die Schaltung zwischen Motor und Steuergerät ?

mfg.
Peter

Hallo,
ich dachte mir schon das mehr hinter der Schaltung steckt. Auf den Teil 
wo die Frames umgearbeitet oder geschlüsselt werden verzichte ich sehr 
gerne. Auf www.kreatives-chaos.com ist der Umgang mit dem MCP und der 
lip schon beschrieben nur als "noch " nicht C User ist es allemal schwer 
die 2. Steuerleitung irgendwie herein zubekommen und da die Sprache von 
Basic schon deutlich abweicht schwer zum Quadrat. Wenn es sich bei den 
Grundfunktionen um das bidirektionale senden und empfangen geht kann ich 
dir garnicht genug danken. Wenn ich das richtig verstehe müßte man den 
mittleren Teil der deine Anpassung Auto zu Steuergerät macht für meine 
Zwecke "nur" herausnehmen und schon sollte es laufen. Ja ich glaube ich 
fantasiere, so leicht ist es sicher nicht.

Zur Aufklärung, ich entwerfe kleine Platinen mit Target (Version 400 
Pins), vom Enwurf bis zur Fertigung meiner Schaltung habe ich bis heute 
immer geschafft. Deshalb bevorzuge ich liebend gerne die DIP/DIL 
Varianten.

Also wenn ich die Grundfunktionen nutzen düfte, wäre das ein großer 
Schritt vorwärts für mich.

Gruß
Peter

Hallo,
das heißt alle Routinen von www.kreatives-chaos.com  des MCP2515 
Beispieles ?????
Ich lese also von 1. MCP ein, speicher ID, DLC und die Datenbytes/RTR in 
Variablen und gebe sie dann von den Variablen wieder an den SPI des 2. 
MCP

Wenn ich das so sehe ist der Syntax der Sprache C das große Problem. Ob 
ich das allerdings so hinbekomme !!!!!!!

Gruß
Peter

Hallo,
das für mich schlimme ist, ich kann dir so in etwa folgen und weiß was 
die Controller tun sollen. Ich bekomme nur sprichwörtlich die Kraft, die 
Information nicht auf den Boden - soll heißen der C Dialekt in 
Verbindung mit altem Schulenglisch ist für mich das Problem.
So suche ich Beispiel/e, die funktionieren und an dehnen ich mich weiter 
hangeln kann um so auch mehr von C zu verstehen.

Deshalb ja meine Frage nach dem Code. Ich habe mehr als nur Verständis 
das wenn etwas funktioniert man die "Geheimsache" nicht veröffentlicht. 
Wir kennen uns nicht und so muß man immer mit Spionage, blödes Wort, 
rechnen.

Ich denke ich werde deinen Schaltplan zugrunde legen (ich habe nur kein 
Jtag) und mal versuchen die Routinen mit einenm MCP und mega8 zum Laufen 
zubekommen. Wenn das geht, gehen sollte, mit dem zweiten paralell und 
wenn das auch geht CAN0 und CAN1 mit einander zuverknüpfen. Sollte ich 
das auch noch hinbekommen müßte der letzte Schritt mit Maske und Filter 
auch zuschaffen sein.

Ich habe auch einen Seite gefunden die mehr zum Thema C zeigt.
http://www.c-programme.de/

Gruß
Peter

Hallo,
Da geb ich dir recht, je mehr ich drüber nachdenke. Der Umgang mit dem 
CAN ist zwar nicht so neu, sitz aber nicht so tief. Mit einem At90CAN 
habe ich mit Basic schon "etwas" Erfahrung, nur erscheint mir das 
Schreiben etwas langsam - lesen geht super fix. Ich denke es sollte 
schneller gehen als nur alle 15-20ms einen Frames senden zu können und 
da fällt mir ein alter Spruch ein. Nimm C und alle Sorgen sind passe.
Wahrscheinlich nur wenn man C drauf hat. Das Schulenglsich kommt auch 
nur bedingt mit dem technischen Englisch der Datenblätter mit. Ich muß 
mal schauen. Zunächst werde ich die fehlende Bauteile bei Reichelt 
bestellen und in der Zwischenzeit kann ich mir die Routinen und den 
AT90CAn nochmal zu Gemüte führen.

Okay

Gruß
Peter

Hallo crazyhorse,
ja ich weiß der Beitrag ist jetzt 14 Monate alt und ich habe mir deinen 
Rat zu Herzen genommen und wohlt mal kurz Rückmeldung geben. Ich habe 
mich voll in die CAN Nummer und Basic gehängt.
Ich hatte mir eine Lochrasterplatine mit zwei MCP2515 nehmst MCP2551 und 
da gleicher Sockel wie ein ATMega8 einen ATMega328P aufgebaut. Der hat 
den Vorteil das er pinkompatibel ist und mehr Ram und Flash hat und 
zudem ein Freq Ausgang und im max Fall bis 20MHz betrieben werden kann.
Der ATMega8 wäre schon für die kleine Bascom Lösung zu klein  (flash und 
Ram) gewesen und so war der ATMega328 schon eine gute Wahl - fand ich. 
Das Bascom Proggi läuft auch auf beiden CAN mit 100KBit in beide 
Richtungen. Leider konnte ich für mich die Buffer/Speicheung der Frames 
nichts lösen und habe aus Geschwindiglkeitsgründen vor 4 Monaten 
tatsächlich auf C umgestellt.
Aus den ehemals böhmischen Dörfern ist mitlerweile eine Nachbargemeinde 
geworden und so hangel ich mich anhand des Beispieles von kreatives 
Chaos durch.
Nach Umstellung des Programmes auf den ATMega328P hatte ich dann wohl 
einen Fehler der es erforderte die iom328p zuerweitern. Nach der 
Anpassung der Bus Frequenz konnte ich dann auch schon was empfangen und 
am Bildschirm darstellen. Der 328P hat andere Registernamen und so war 
der Umstieg mit meinem 20 Jahre alten Schulenglsich schon eine 
Herausforderung. Da in dem Testprogramm ja nicht im Interrupt empfangen 
wird sondern nach nach Auswertung des Pins im der Main 
stelle....versuche ich gerade den Empfang in den Interrupt zuverlegen.
Nach Einstellung und Angleich an den MCP versuche ichs gerade - da so 
wie ich vermutet anhand des C-Code du Codevision verwendest sieht das 
bei AVR Studio ja etwas anders aus.

//Interrupt INT1 und INT0 einschalten
EIMSK|=(1<<INT1)|(1<<INT0); // INT1 und INT0 einschalten im General 
Interrupt Control Register

// Einstellen auf fallenden Flanke
EICRA|=(1<<ISC11)|(0<<ISC10)|(1<<ISC01)|(0<<ISC00); //fallende Flanke 
löst aus

ISR (INT0_vect)
{

tCAN message;             //erzeugt ein Variable nach dem tCan struct
mcp2515_get_message(&message);    //liest einen Frame vom MCP2515

print_can_message(&message);    // ausgabe nur für kurzen Test
PRINT("Interrupt ausgelöst\n");    // ausgabe nur für kurzen Test
}


Ob es funktioniert weiß ich noch nicht es läßt sich zumindest jetzt 
compelieren. Mein Frage ...warum ich eigentlich den Betrag aufwärme - 
sollte ich nochmal ein Frage haben ob ich dann nochmal um Rat fragen 
kann.??
Okay das wars schon.........

Gruß
Peter

Hallo,
gute Info, das die Uart in der ISR nicht geht wuste ich jetzt nicht.

Ich bleib am Ball

Schöne Weihanchten

Der UART funktioniert in der ISR schon, nur mit an sicherheit grenzender 
Wahrscheinlichkeit nicht interruptgesteuert (was ja sonst aus 
Geschwindigkeits- und Effektivitätsgründen der Fall ist). Das liegt 
daran, daß in einer ISR aus der AVR-libc als erste Aktion die Interrupts 
gesperrt werden. Also kann der FIFO-Interrupt im UART zwar schön sein 
Interruptflag setzen, aber ohne global interrupt enabled passiert da 
nichts weiter (welches erst als letzte Aktion bei Verlassen der ISR 
wieder eingeschaltet wird). Erst dann wird der UART-interrupt 
abgearbeitet. Du kannst natürlich mit sogenannten nested interrupts 
arbeiten, das wird aber heftigst und sollte wegen der Interruptstruktur 
beim AVR vermieden werden. Beim Cortex M3 sieht das aber schon anders 
aus.

Peter C. schrieb:
> Da in dem Testprogramm ja nicht im Interrupt empfangen
> wird sondern nach nach Auswertung des Pins im der Main
> stelle....versuche ich gerade den Empfang in den Interrupt zuverlegen.

Das vergiß mal am besten ganz schnell wieder. Die ISR soll/muß aus o.g. 
Grund so kurz wie nur irgend möglich sein, damit keine Überschneidungen 
passieren. Sowas würde sich dann z.B. in gelegentlich fehlenden Zeichen 
usw. äußern; auf jeden Fall meist nicht reproduzierbar, da von der 
aktuellen Belastung des µC abhängig.
Selbst wenn es jetzt klappen sollte: Es gibt keine Garantie und 
spätestens bei Reduzierung der timingresourcen hast du dann irgendwann 
und irgendwie ein Problem. Und dann wieder die ganze Softwarestruktur 
ummodeln motiviert nicht gerade.
Die Softwarearchitektur muß vor dem ersten Programmfetzen schon ziemlich 
konkret und logisch feststehen. Und "ISR so kurz wie möglich" ist beim 
AVR eine unumstößliche Regel. Wie gesagt, spätestens bei Erweiterungen 
(oder auch späterer simpler Taktreduzierung wegen Stromsparen oder so) 
holt einen das ein.

Hallo,
ich denke das aufgrund der Funktionen und Interpretationen sowie 
Umsetzung in Bascom der Bascom Code schon größer ist. Es kann auch 
durchaus sein das bei mir nicht alles super kompakt programmiert ist 
(learning by dooing usw.....). Vielleicht vermittelt deshalb Bascom 
einen Hauch von Geschwindigkeitsverlust/nachteil - ohne jetzt den Bascom 
Nutzer zusehr auf die Füsse zutreten - denn bis vor 4 Monaten habe ich 
auch damit gearbeitet.

Das die ISR möglichst kurz sein soll ist ja klar..Da ich möglichst viel 
durch den ATMega und die 2 MCPS2515 durchschleusen möchte dacht ich das 
aufgrund der Darstellung von H.joachim Seifert das ein begehbarer Weg 
sein kann. Seinen Ausführungen entnahm ich das in seiner Anwendung ein 
Haufen Frames durchgehen und es super läuft und sogar noch eine 
Sortierung und weitere Bearbeitung stattfindet.
Ich habe rund 15 Frames die in einer Sekunden von CAN 0 zu CAN 1 sollen 
und zurück sind es ca. 5 Frames. Die kleinste Widerholungszeit sind 
100ms - so dachte ich das es funktionieren kann selbst wenn ich mit, 
vorher Bascom und jetzt C selbst was proboiere. Ich bin kein 
Hardwarprofi und kein Programmierer und studiert habe ich das auch 
nicht. An hand meiner Forschungen ist sicher ein 32Bit MC mit min 2 
internen Can Controllern und 40MHz die beste Wahl sogar noch mit 
deutlichen Reserven - nur sind da keine Informationen zu bekommen 
zumindest nicht für für mich. Ich möchte noch selbst Hand anlegen und 
was lernen. Selbst wenn ich auch bei der Lösung feststellen muß - es 
reicht nicht - gehts vielleicht weiter mit einem LPC2129 oder wie auch 
immer.
Erst mal der AVR und die 2  x MCP2515, händelbar als DIL Varianten und 
dann sehen wir weiter.

Gruß
Peter

PS: Ich bin für jede Hilfe dankbar.

Hallo,
ja ich weiß was die Schaltung tun soll und kann das auch beschreiben.
Nur ist halt die Umsetzung meist nicht so einfach. Ich befasse mich 
jetzt seit 4 Monaten mit C und kann nicht unbedingt sagen das ich ein 
Profi bin ich würde eher so den Status kurz nach Anfänger nehmen. Aber 
ich kann in einem gewissen Umfang den C Code deuten was da passiert oder 
passieren soll. So habe ich in meiner Schaltung auch schon Fehler in der 
Software beseitigt die vom org Atmel Studio (io328p) verursacht wurde. 
Hat zwar gedauert aber mit meinem Schulenlisch habe ichs dann doch 
gefunden.

Also rein beim Empfang und der Darstellung der Frames die ich aus dem 
Notebook über einen MHS USB CAN Adapter an den MCP2515 schicke ist schon 
enorm. Selbst wenn ich mit dem MCP2515 empfange und das Eingelesene mit 
einer um 10 erhöhten ID wieder versende ist der Zeitverzug erst ab ca 8 
Frames deutlich zusehen. Bei der Bascom Variante schon ab dem 4. Frame.

So bin ich zur Zeit guter Dinge das da noch was geht und ich zur 
Verbesserung noch einen Puffer irgendiwe dazwischen bekomme.

Aber Schritt für Schritt lernen und begreifen, mir hilft es wenn ich 
erst mal selber schaue und mir das Hirn zermatere.
Klappt nicht immer !!!!!

Gruß
Peter

Du hast dabei auf jeden Fall die richtige Grundeinstellung => verstehen 
und lernen wollen, nicht blind und doof copy&paste.

Auch bei den DIL-Geschichten zu bleiben finde ich hier absolut richtig, 
da du schnell und problemlos von der Theorie zur Praxis wechseln kannst.

Auf Grund der jetzigen "Probleme" wie Treffsicherheit oder Handhabung 
das Luftgewehr AVR gegen eine Panzerfaust Cortex M3 zu tauschen, wäre 
der größte Fehler, um die Scheibe in 3 m Entfernung treffen zu wollen 
...
Die Einarbeitung und Änderung nur wegen des Chips und der Toolchain 
würde dich vollends demotivieren und du hast dort erstmal ganz andere 
Probleme, die mit deinen Jetzigen nichts zu tun haben.

Wie schon von mehreren Seiten kam: Strukturiertes Arbeiten ist die Basis 
einer jeden effektiven Tätigkeit. Das schließt das (vorherige) Planen 
natürlich mit ein.

Um eventuell noch ein Mißverständnis auszuräumen: Interrupts sind dazu 
erfunden worden, um die vorhandenen Resourcen effektiver zu nutzen; 
dienen quasi der Verteilung von Resourcen, wo sie gerade benötigt 
werden. So sollte man (spätestens) bei der kleinsten Leistungsanhebung, 
wie z.B. Nutzung einer zweiten Peripherieeinheit, von z.B. Polling auf 
Interrupts umsteigen. Innerhalb der ISR sollten aber wirklich nur die 
absolut zeitkritischen Sachen gemacht werden; die evtl. weitere (weniger 
zeitkritische) Verarbeitung muß dann an anderer geeigneter Stelle 
erfolgen. Nur so ist sicherzustellen, daß ein anderer, ebenfalls 
zeitkritischer Prozeß, seine absolut notwendigste Aufgabe ebenfalls in 
der erforderlichen Zeit abarbeiten kann.
Im übertragenen Sinne bedeutet das, daß beim Receive-Interrupt der 
Inhalt innerhalb der ISR in z.B. irgendeinen Buffer ausgelesen und der 
Receive-Buffer danach sofort wieder für den nächsten Frame freigegeben 
wird (inkl. Rücksetzen von Interrupts/Flags sowie Flags zur 
Weiterverarbeitung etc.). Ende der ISR.
Die Verarbeitung der gerade ausgelesenen Message findet dann also 
außerhalb der ISR statt; z.B. durch Auswerten des in der ISR gesetzten 
Weiterverarbeitungs-Flags in der main-loop.

Hallo Lutz,
ich danke dir für deine Meinung und ermutigenden Worte.
Einen Plan habe ich selbstverständlich:
- 2 x MCP2515 an einem ATMega328P
- bidiretionaler Datenstrom
- Richtung 0 zu 1 = alles durch
- Richtung 1 zu 0 = 2 IDs herausfiltern (ID 0x261 und ID 0x263)
- Empfangs- Sendebuffer mit einbeziehen
- bei freien MC-Resourcen soll bei einer bestimmten ID die Schaltung 
abgeschaltet werden.

Mein Plan und Vorgehensweise
- zuvor habe ich mit einem CAN USB Adapter den kompletten Datenstrom mit 
geschnitten. Ich weiß also das der CAN 100KBit hat, Frames in 
verschiedenen Längen sowie RTRs dazwischen sind. Es sind insgesamt ca 
15-20 Frames die mit unterchiedlichen Zeiten wiederholt werden. Ein paar 
werden mit 100msec, 200msec, 500msec und ein kleiner Teil mit 800msec / 
1000msec versendet. Die Ids konnte ich zu 95 Prozent identifizieren und 
weiß was für Daten die Frames enthalten. Bauteilanmeldung am CAN Ring 
usw usw.......

In der Testschaltung arbeitet auf einer Seite ein CAN USB mit dem ich 
per Notebook senden/empfangen kann und die andere Seite bildet ebenfalls 
ein AT90CAN128 der auch senden/empfangen kann.
Meine Schaltung sitzt dann dazwischen und hat eine Verbindung zu einem 
Standrechner der per RS232 angebunden ist - nur um zusehen was passiert. 
das Notbook zeigt alle CAN Daten mit Zeitstempel.
Ich habe auf einer Lochrasterplatine sowohl 2 x MCP2515 mit ATMega328 
sowie auch einen AT90CAN128 mit MCP2515 gebaut. Beides habe ich auf 
Bascom zum Laufen gebracht mit mäßigem Gechwindigkeitsgewinn.

Um C zuerlernen habe ich im Internet nach was brauchbaren erklärten 
gesucht und die Seite von Kreatives Chaos war der Treffer schlecht hin.
So habe ich zunächst das Beispiel auf dem AVR Studio 4 geladen und auf 
den ATMega328P umgestellt. (das hat schon einige Zeit gedauert da ich 
auch das Datenblatt einmal umkrempeln mußte und nach der Nadel im 
Heuhaufen gesucht habe und den Fehler in der Studio eigenen Datei 
gefunden habe)
Nach dem das Beispiel dann fehlerfrei im AVR Studio compelierbar war, 
war es auch einfacher Teile des Codes zuverstehen. So war der 1. MCP und 
der ATMega328P schon mal online und als Knoten am CAN instaliert.

Da in dem Code der Int0 nicht als Interrupt sondern als PIN in der Main 
abgefragt wurde - die Main also nur darauf wartet das der PIN gesetzt 
wird arbeite ich an der Umstellung auf den Interrupt - zur Zeit.

Weiter möchte ich dann die Initialsierung des 2. MCP2515 einbauen und 
den Empfang gleichzeit über beide Seiten darstellen.
Dann die empfangen Frames von CAN 0 und CAN 1 in einem Buffer 
zwischenspeichern und bis dahin wirds sicher noch Monate dauern, 
überkreuz aus dem Buffer versenden.
Wenn das klappt ...........wird sicher noch das Filtern vor dem Buffer 
erfolgen müssen. Macht ja keinen Sinn was zu speichern was man nicht 
braucht.

so ....das wäre mein Plan.
Anregungen oder Tipps nehme ich gerne entgegen.....

Gruß
Peter

Peter C. schrieb:
> Da in dem Code der Int0 nicht als Interrupt sondern als PIN in der Main
> abgefragt wurde - die Main also nur darauf wartet das der PIN gesetzt
> wird arbeite ich an der Umstellung auf den Interrupt - zur Zeit.

Die main läuft also immer durch und schaut gerade in dem Moment, ob der 
Pin gesetzt ist. Wenn ja, wird die message weiterverarbeitet.
=> Das wäre schlecht, denn alles was nach der Pinabfrage kommt, geht 
erst weiter, wenn die vorherige messageverarbeitung zu Ende ist. In der 
Zeit kann evtl. schon eine weitere message (auch in einem anderen 
Empfangsregister) überschrieben werden/verloren gehen.

Als Lösung "einfach" wie beschrieben den INT aktivieren und in der ISR 
den buffer auslesen, ein Flag in der main setzen, den INT zurücksetzen 
und weiter geht das Programm. Insgesamt ist der Code für alles ja schon 
da; du mußt ihn nur entsprechend auf die ISR und die main aufteilen.

Geht es dabei zufällig um das anzeigen von eigenen Daten im FIS? ID 
0x261 und 0x263 würde da passen.

Hallo Lutz,
wenn ich den Demo-Code richtig deute läuft die Main sogar nicht mal 
durch sondern wartet in dieser Endlosschleife auf den Empfang.

  while (1) {
    // warten bis wir eine Nachricht empfangen
    if (mcp2515_check_message()) {
      PRINT("Nachricht empfangen!\n");

      // Lese die Nachricht aus dem Puffern des MCP2515
      if (mcp2515_get_message(&message)) {
        print_can_message(&message);
        PRINT("\n\n");

      //schickt direkt Message + 1 zurück
  //     message.id = message.id +1;
  //    mcp2515_send_message(&message);
      }
      else {
        PRINT("Kann die Nachricht nicht auslesen\n\n");
      }
    }
  }

  return 0;
}

Okay..........also den ISR int0 auf "low Level" damit auch der zweite 
schnell nachfolgende Interrupt mitbekommen wird und doch besser in der 
ISR den MCP-Buffer auslesen in Framebuffer speichern und mit flag in der 
Main weiterverarbeiten.

Im Moment stecke ich am Interrupt, nachdem die ISR ausgelöst wurde 
vermutet ich gehts nicht weiter denn der Interrupt im MCP wird nicht 
gelöscht. Nach EInschalten liegen am Int0 5V nach Empfang 0V un dkeine 
Änderung mehr........

//aktivieren des int0 im ATMega328P
EIMSK|=(1<<INT0);
//fallende Flanke
EICRA|=(1<<ISC01);
der muß dann wohl auf low Level gem. Datenblatt ATMega328P Seite 73 !!??
schreibt man das so EICRA|=(0<<ISC01); oder so EICRA &= ~(1<<ISC01);
In der ISR komme ich mit

ISR (INT0_vect)
{

tCAN message;                      // def struct variable
mcp2515_get_message(&message);     // hol den Frame aus dem MCP Buffer 
noch ohne weiter speichern und flag
print_can_message(&message);      //nur zum zeigen

}

da ist auch noch was falsch.

Gruß
Peter

Ist leider ziemlich schwierig bzw. unmöglich, aus den Codefetzen auf das 
gewünschte Verhalten bzw. Gesamtverhalten des Programms zu schließen.

Zumindest die o.g. while-Schleife macht anscheinend schon etwas 
sinnvolles (wobei wieder uneingeschränkt Satz 1 zum Tragen kommt). Das

1

return 0; 

2

}

gehört aber schon nicht mehr zur while-Schleife und wird vermutlich das 
Ende von main sein.

Die Schleife prüft (anscheinend) ständig, ob eine Nachricht empfangen 
wurde. Wenn nicht wieder zum Schleifenanfang.
Wenn ja, wird das (anscheinend) mit PRINT ausgegeben.
Dann wird (anscheinend) versucht, die message in eine (vermutliche) 
struct zu schreiben.
Wenn das erfolgreich war, wird die message (anscheinend) ausgegeben und 
anschließend noch 2 Zeilenumbrüche angefügt.
Wenn das nicht erfolgreich war, wird das (anscheinend) mit PRINT 
ausgegeben.

Du mußt beide Chips getrennt sehen:
MCP2515:
Erstmal mußst du dem MCP2515 "beibringen", welche messages er überhaupt 
annehmen soll. Das macht er ausschließlich über die Identifier. Dazu 
gehört auch, in welchem Empfangsbuffer die message landen soll. Und du 
mußt ihm sagen, wie er eine empfangenen Nachricht nach außen 
signalisieren soll. Ich glaube, man konnte beim MCP2515 einmal zwischen 
der Methode "Sammelinterrupt" wählen. Egal was er hat hat, er 
signalisiert das nur an einem Pin nach außen. Dann müßtest du den 
MCP2515 durch auslesen von Registern (über die SPI-Schnittstelle) 
gezielt befragen, was er denn hat. Oder man konfiguriert ihn so, daß er 
pro Empfangsbuffer einen bestimmten Pin signalisiert. Damit wäre dann 
nach außen schon klar, welcher Empfangsbuffer ausgelesen werden muß. Das 
reduziert die erforderliche Kommunikation mit dem MCP2515.

ATMegaxx:
Hier schließt du die oder den o.g. Pin "Signalpin" des MCP2515 an (je 
nach dem, ob Sammelinterrupt oder nicht). Den Pin des ATMega mußt du als 
externen Interrupt einrichten. In der ISR muß dann, je nach gewählter 
Methode ("Sammelinterrupt oder nicht"), die Befragung des MCP2515 
angeschoben werden.

***
Hier kommt dann das vorher diskutierte Thema zum Tragen, was in die ISR 
kommt und was in die while-Schleife gepackt wird.
***

Zum Ende der ISR muß auf jeden Fall der Interrupt des ATMega wieder 
zurückgesetzt werden.
Wann der Interrupt des MCP2515 zurückgesetzt wird, hängt wiederum von 
der gewählten Methode "Sammelinterrupt" ab. Eventuell werden die 
Interrupts auch durch Auslesen des Empfangsbuffers oder Ausführen der 
ISR automatisch zurückgesetzt; weiß ich aber nicht mehr, Steht aber 
natürlich im Datenblatt des MCP2515 und des ATMega.

Peter C. schrieb:
> schreibt man das so EICRA|=(0<<ISC01); oder so EICRA &= ~(1<<ISC01);

Letzteres. Mal dir am besten binär mal beide Schreibweisen auf, dann 
verstehst du, was da eigentlich gemacht wird.
Im ersten Fall verODERst du die Zahl Null, welche vorher um ISC01 
Stellen nach links geschoben wurde (ISC01 wird irgendwo, wahrscheinlich 
in der atmega328io.h so stehen: #define ISC01 1). Wenn an der Stelle 
vorher eine Eins stand, bleibt sie da auch stehen. Wohl nicht das, was 
gewünscht ist.

Im zweiten Fall verUNDest eine Bitmaske, bei der das gewünschte Bit in 
der Maske Null ist. Das ergibt auf jeden Fall als Ergebnis Null, egal 
was vorher da stand. Wohl das, was gewünscht ist.
Wie gesagt, am besten mal binar aufschreiben.

Jetzt ist aber der Entenbraten fällig!

Hallo Lutz,
so anbei der komplette C Code mit allem aus diesem Verzeichnis auch mit 
der geänderten io328p

Der MCP ist so eingestellt das jede empfangener Frames einen Interrupt 
an dem Sammel-PIN des MCP auslöst und damit am int0/PD.2 des Atmega 
anliegt. Im Demo Programm wir der PD.2 als PIN genutzt und in der 
mcp2515_check_message() abgefragt und dann mit 
mcp2515_get_message(&message) erst der Frame vom MCP geholt. In der 
While schleife wird bei jeden Durchlauf geprüft ob ein Frame da ist - 
und so können schon welche verloren gehen oder gegangen sein - speziell 
gesehen auf das was später mal raus werden soll - hatte ich schon 
beschrieben.

Ich habe die ISR zum int0 angelegt und in der main eingestellt. Um zu 
sehen ob die ISR tatsächlich auch auslöst mit einem Todesstrafen Print 
versehen.
Dann versucht dort ein Flag zusetzen um diese dann in der Main 
auzuwerten und das auslesen des MCP anzustoßen. geht aber so nicht,da 
sind die C  Lücken wohl doch noch zugroß.

bin für jeden Tipp dankbar

Gruß
Peter

Nur ganz kurz durch die main geflogen:

Laut 7.0 Datasheet MCP2515:
When an interrupt occurs, the INT pin is driven low by the MCP2515 and 
will remain low until the interrupt is cleared by the MCU.
=> Der MCP setzt den entsprechenden Interruptpin auf low. Du mußt also 
den ATMega-Interrupt auf einen Flankenwechsel von high nach low 
einstellen. Gemäß Table 13-2 Datasheet ATMega328P: (1<<ISC01). Der ISC00 
muß Null bleiben. Da du erstmal nur mit INT0 testen 
solltest/kannst/willst, kannst du also einfach erstmal
EICRA = (1<<ISC01);
schreiben.

Hallo Lutz,
ja diese Einstellung funktioniert auch, der Interrupt wird ausgelöst. In 
der ISR schreibe ich dann einfach eine 1 in meine Flag Variable die ich 
dann in der Main per Print anzeigen lasse bzw wieder mit 0 überschreibe 
um zu sehen ob in der nächsten ISR Auslösung wieder eine 1 
hereingeschrieben wurde.
Da der Int vom MCP ja zwingend per SPI bzw. Bitmodify vom ATMega 
zurückgesetzt werden muß ist die high -> low Flanke erstmal kein Problem 
da zu den Tests die Frames nur langsam mit 800mSec wiederholt werden und 
so Zeit zur Reaktion bleibt.
Wenn später deutlich mehr Frames folgen, kann es da nicht passieren, das 
wenn der Int vom MCP durch den ATMega abgearbeitet / der Frame 
ausgelesen wird, das dann bereits ein zweiter Frame im MCP angekommen 
ist und den Int-MCP auf low hält der ATMega dies aber nicht erkennt weil 
der Int0 "nur" auf den Flankenwechsel High->low reagiert und so ein 
Frame, vom Atmega unbemerkt, im MCP bleibt. Der ATMega setzt ja auch nur 
das Register im MCP zurück welches zuvor als meldendes und ausgelesendes 
identifizerit wurde - oder ????????????
Wurde deshalb weiteroben die "Low Level" Einstellung bevorzugt ???? und 
so der ATMega immer nach einem angekommenden Frame in den 2 Buffern 
sucht (Statusabfrage) solange der Int-MCP auf Low bleibt ??????

Ich habe versucht in der main mein ISR Flag abzufragen und so das 
auslesen des MCP anzustossen - da geht aber noch was in die Hose. Aus 
Basic kenne ich die Do  -  Loop Schleife die sich immer wiederholt, 
stellt die  While () ähnliches da ???? Diese Frage traue ich mich als 
Anfänger garnicht zustellen.

Gruß
Peter

Hallo Lutz,
also so funktioniert es jetzt mit dem setzen des Flag in der ISR und 
Auswertung in der Main. Direkt nach dem Einlesen schicke ich dén Frames 
wieder mit ID+10 zurück auf den CAN (sicher nicht schön aber der test 
heiligt die Mittel - damit es keine Kollisionen und Fehler gibt).
So schafft der MCP 50 Frames einzulesen und 50 Frames zuversenden und 
das in einer Sekunde. Da die Frames mit wie schon geschrieben mit 100 
msec, 200 msec usw bis 1000 msec eingehen und auch wieder direkt 
versendet werden haben die Einzelframes nur eine Verzögerung von 1-2 
mSec.
Das übersteigt meine künsten Erwartungen - ich bin begeistert.

Dann werde ich mich mal an den Buffer wagen...........
Achja damit auch der zweite Empfangsbuffer im MCP den Rollover mitspielt 
habe ich noch das BUKT Bit gesetzt (MCP Seite 27)

// turn off filters => receive any message
mcp2515_write_register(RXB0CTRL, (1<<RXM1)|(1<<RXM0)|(1<<BUKT));
mcp2515_write_register(RXB1CTRL, (1<<RXM1)|(1<<RXM0));

volatile uint8_t flag;

ISR (INT0_vect)
{
flag = 1;
}

while (1) {

   if (flag == 1) {

   // Lese die Nachricht aus dem Puffern des MCP2515
         mcp2515_get_message(&message);
   //      PRINT(" ID : 0x%3x\n", message.id);  //nur Test

        //schickt direkt Message + 1 zurück
          message.id = message.id +10; //  ID + 10 senden auf gleichen 
CAN
          mcp2515_send_message(&message);

        flag = 0;    //  zurücksetzen des ISR flag
      }
    }


  return 0;
}

Peter C. schrieb:
> Wenn später deutlich mehr Frames folgen, kann es da nicht passieren, das
> wenn der Int vom MCP durch den ATMega abgearbeitet / der Frame
> ausgelesen wird, das dann bereits ein zweiter Frame im MCP angekommen
> ist und den Int-MCP auf low hält der ATMega dies aber nicht erkennt weil
> der Int0 "nur" auf den Flankenwechsel High->low reagiert und so ein
> Frame, vom Atmega unbemerkt, im MCP bleibt. Der ATMega setzt ja auch nur
> das Register im MCP zurück welches zuvor als meldendes und ausgelesendes
> identifizerit wurde - oder ????????????
> Wurde deshalb weiteroben die "Low Level" Einstellung bevorzugt ???? und
> so der ATMega immer nach einem angekommenden Frame in den 2 Buffern
> sucht (Statusabfrage) solange der Int-MCP auf Low bleibt ??????

Na ja, der MCP2515 läßt sich ja schon den Geschwindigkeitsanforderungen 
entsprechend nutzen. Grundsätzlich erfüllt er die Spezifikation mit 1 
MBit/s, ist aber noch verhältnismäßigig simpel (jede Funktion für sich 
alleine; das Gesamtzusammenspiel des Chips ist schon deutlich doller. 
Aber bei wenig Bitrate kommt halt jeder einfach und schnell zu seinem 
Ziel).
Man kann an den Schrauben drehen:
- SPI-Takt. Geht bis 10 MHz. Da kann man schon abschätzen, wieviel Bit/s 
theoretisch gehen. Kommt dann aber auch auf den Overhead an. Wie komme 
ich schnellstmöglich an meine Informationen? Lese ich dieses oder jenes 
Register erstmal pauschal aus? Hangel ich mich Schritt für Schritt mit 
Abfragen an meine Information? Auch unterstützt da das automatische 
address-increment; man braucht nur weiter die Schnittstelle takten.
- Interrupt-Pins. Man kann einen Sammelinterrupt nehmen und o.g. 
Abfrageorgie praktizieren. Man kann aber auch jeden Empfangsbuffer 
einzeln per Pin signaliseren lassen. Dann ist schon mal klar, welchen 
Buffer man auslesen muß und man muß weniger per SPI kommunizieren.
- Man kann Rollover als letztes Mittel nutzen.
- Generell haben die meisten CAN-Chips mehr Sende- als Empfangsbuffer. 
Warum nur?
- Man kann übelst Takte zählen und schauen, ob es nicht kürzer geht, 
wenn man den Empfangsbuffer schon in der ISR ausliest. Während der 
Inhalt per SPI rüber geht, puffert im Zweifelsfalle das MAB, bis der 
nächste Frame evtl. gültig wird und dann erst in den Empfangsbuffer 
kopiert wird.

Da geht bestimmt noch mehr.

Hallo, Peter

So, jetzt schreib ich auch meinen Senf dazu.. :)
Ich habe was ähnliches wie Du auch schon mit einem Mega8 gemacht, sogar 
mit bis zu 4 x 2515. Bei meinen recht nidrigen Bitraten gab's nie 
Probleme.

Wenn ich etwas daraus gelernt habe dann: Lass wenns irgendwie möglich 
ist die Finger weg von Interrupts (im AVR, die Interrupt-Leitungen von 
den Controllern machen ggf. schon Sinn.

Dein letztes Beispiel klappt genauso gut wenn Du auf den ISR (INT0_vect) 
komplett verzichtest und in main() statt if (flag == 1) einfach den 
Portpin abfragst an dem der Interrupt anliegt.
Damit vermeidest Du insbesondere die Fehlerquelle (die in Deinem Code 
noch da ist), dass ein zweiter IRQ kommt noch bevor Du flag = 0 setzt.
Wenn Du das unbedingt so machen willst, mach' es jedenfalls in der Zeile 
unmittelbar nach der Abfrage des flag.

Auf KEINEN Fall solltest Du in irgend einem Interrupt eine SPI 
Kommunikation machen. Die Probleme die Du bekommst wenn ein Interrupt in 
eine laufende Kommunikation, vielleicht sogar mit einem anderen 2515 
hineinkracht, kannst Du damit wirksam vermeiden.

Ich verzichte übrigens komplett auf die Interrupt-Leitungen und frage 
den Buffer-Status nur über SPI ab. Mit einer schnellen SPI und wenn Du 
beide Empfangsbuffer der 2515 (Rollover Buffer 0 -> Buffer 1) nutzen 
kannst funktioniert das nach meiner Erfahrung ausgezeichnet ohne das was 
verloren geht.

Ich hoffe ich konnte was konstruktives zu Deinem Projekt beitragen...
lg
Luigi

Nun ja, das ist in der Tat ein freies Land und da darf natürlich ein 
Jeder sagen und denken, wie es ihm behagt.

Bei sachlichen Themen helfen Fakten da allerdings extrem weiter.

Luigi schrieb:
> Auf KEINEN Fall solltest Du in irgend einem Interrupt eine SPI
> Kommunikation machen. Die Probleme die Du bekommst wenn ein Interrupt in
> eine laufende Kommunikation, vielleicht sogar mit einem anderen 2515
> hineinkracht, kannst Du damit wirksam vermeiden.

Du kennst die zu Grunde liegende avr-libc schon, ja?

#define ISR (vector,
      attributes
      )
Introduces an interrupt handler function (interrupt service routine) 
that runs with global interrupts initially disabled by default with no 
attributes specified.

Jede ISR aus der avr-libc sichert als erstes mal das SREG, dann cli(); 
und restored als letztes das SREG beim Verlassen wieder. Zumindest war 
es mal so.
Wie kann da jetzt in einer ISR ein Interrupt dazwischenhauen und das von 
dir beschriebene Verhalten verursachen???

u.A.w.g.

P.S.: Bitte zerstöre wegen deiner (wegen Zensur habe ich den Inhalt der 
Klammer schon selber gelöscht) Erfahrungen einem ernsthaft Lernenden 
nicht den Lehrweg. Echt nicht persönlich gemeint, aber nur weil du die 
Interrupts nicht verstanden hast, müssen andere nichts falsches lernen. 
Und das zuerst gelernte bleibt nun mal am besten hängen ...

Aber sollen bitte noch andere ihre Meinung dazu sagen; es kann ja 
schließlich auch sein, daß ich mich irre.

Hallo zusammen,
ich wollte eigentlich nur mitteilen das ich die nächste Stufe in meinem 
Plan geschafft habe.(mit euren Tipps).... Im Vorfeld habe ich einwenig 
geforscht um Informationen zum Datendurchsatz und dem Händling 
zubekommen, auf viel bin ich nicht gestossen mit dem ich zum damaligen 
Zeitpunkt was hätte anfangen können und ohne Ahnung .....wonach hätte 
ich fragen sollen. Wie der Anfang des Beitrages ja zeigt bin ich dann 
vor 14 Monaten dem Tipp von  H.joachim Seifert nachgekommen und hatte es 
zuerst mit Bascom propiert. Mit Bascom habe ich einwenig Erfahrung aber 
das war gestern....

Sicher bin ich auch auf Ergebnisse gestossen die auf 16/32Bitter MCs 
basierten oder auch Kauflösungen.
Aber ich wollte selbst ran und verstehen was da so abgeht. Vor 4 Monaten 
habe ich die Bascomlösung geschmiessen und habe mit C begonnen - kein 
leichter Schritt. Ich habe viel gelesen und habe aufgrund der Dil 
Varinaten genau diese Chips gewählt. Ich kann die Platine selbst 
herstellen, ich kann eine Testschaltung selbst aufbauen und so ist auch 
der Weg ein Teil des Zieles.
Meine Elektronikerausbildung ist 25 Jahre her und da spieleten diese 
Dinge(MCs) noch garkeine Rolle ganz zu schweigen vom Schulenglisch und 
den Schwierigkeiten mit den Datenblättern und dem technischem Englisch. 
So bleiben mir sicher Dinge verborgen die andere mit einem Handstreich 
begreifen und umsetzen können.

Ich ich finde es toll, das diese Eure Meinungen hier zusammen kommen und 
viele Wege aufzeigen wie es gehen kann oder welche Erfahrung jeder 
Einzelne gemacht hat. Alles geäußerte ist es wert uberdacht und beachtet 
zu werden.

Wie schon gesagt.....geschrieben ich bin für jeden Tipp dankbar.

Gruß
Peter

Hallo crazyhorse,
okay arbeitet dann deine Schaltung von der Hand in den Mund ???? soll 
heißen der empfangene Frame wird per Int vom MCP-0 dem Mega auf dem int0 
(für Can0) mitgeteilt und der sperrt nur den Int0 (für Can0) holt den 
Frame aus dem MCP-0 noch in der ISR und überträgt den Frame in den 2. 
MCP (CAN1) und gibt dann den int0 wieder frei. In der Zeit kommen schon 
wieder weitere Frames an die dank des low Level ISR auch nicht vergessen 
werden können ???????

Arbeitest du mit einem Zwischenpuffer der die Framerichtung im Auge 
behält oder hat deine Variable CAN_sw=1; CAN_sw=0; eine direkte 
Abarbeitungsrichtung zur Folge ?????? hast du die Umschaltvariable 
direkt mit in den CAN struct mit eingebaut ???? oder separiert.

Wenn ein Zwischenspeicher voller wird und die Versendung nicht so 
schnell hinterher kommt könnte natürlich auch ein Speicherüberlauf 
vorkommen !!!!!!?????

Wie gesagt vor 14 Monaten habe ich noch nicht gecheckt was da so 
geht....heute nach 4 Monaten ("C") bin ich deutlich weiter wenn auch 
noch lange lange nicht auf dem Level.

Auf meinem CAN sind es 2 x 100KBit mit Datenframes mit unterschiedlicher 
Länge und das reicht von 8byte und einer Wiederholungsrate von 1000msec 
bis hin zu einem Datenbyte mit 100msec. Eine Wiederholungsrate die 
kürzer als 100msec ist, ist nicht dabei.

Würde ein Mitschnitt des Datentransfer für die fachliche Beurteilung 
helfen können ???

Gruß
Peter

Hallo nochmal Peter!
Hallo, Lutz!

Scheinbar habe ich mich da etwas unglücklich ausgedrückt, jedenfalls 
schlecht genug um von Lutz gleich in die Spinner-Ecke gestellt zu 
werden... (:

Ich hoffe dass ich die Interrupts ganz gut verstehe, danke dennoch für 
die Belehrung.

Der Punkt auf den ich hinauswollte ist der, dass es Probleme geben kann, 
wenn Du sowohl aus einer ISR als auch aus dem main() Kontext die SPI 
Schnittstelle ansteuerst.
Nimm an Du startest eine SPI Kommunikation aus main() und diese wird von 
einer ISR unterbrochen.
Wenn Du in der ISR ebenfalls SPI machst, wird die ursprüngliche 
Kommunikation gestört, das passiert natürlich auch dann wenn 2 
unterschiedliche Geräte angesteuert werden, da ja CS von der 
Original-Kommunikation noch gesetzt ist.
Das Ergebnis ist dann leider ziemlich unvorhersehbar.
Natürlich kann man das über Flags synchronisieren, aber was macht man in 
der ISR wenn man draufkommt dass man grad kein SPI machen kann..?

Noch ein kurzes Wort zu H.joachims "Interrupt ist auf jeden Fall der 
richtige Weg":
Jetzt fange ich auch ein bisschen rechnen an...
Du hast also 260µs pro Frame. Mit einem hohen Anteil an Remote-Frames 
kommt man etwas tiefer, vielleicht 200µs.
Das Abfragen des Empfangs-Register-Status über SPI dauert ungefähr 2 µs 
also 1/100tel davon.
Bei 2 x 2515 also ca. 4 µs.

Wenn Du laufend, während nichts anderes zu tun ist, die Statusregister 
der 2515 abfragst, kannst Du also innerhalb von 4 µs auf einen 
eingegangenen Frame reagieren.
Wenn man dasselbe mit Interrupts macht, kann man das vielleicht auf 1 µs 
drücken.
Keinesfalls kann es passieren, dass deswegen ein Frame verloren geht.
Außerdem hat man eine laufende Prüfung (die ich gerne verwende) ob der 
2515 noch korrekt ansprechbar ist.

Bitte beachte dass ich nicht sagen möchte dass die Verwendung der 
Interrupts jedenfalls sinnlos ist, es geht nur i.A. auch ohne, so dass 
man sich in vielen Fällen die zusätzlichen Leitungen sowie die Port-Pins 
sparen kann.

So, jetzt will ich Euch Experten nicht länger davon abhalten, andere 
Poster zu zerreissen und wechsle wieder in die englischsprachlichen 
Foren.
Irgendwie scheint es dort eine positivere Grundstimmung gegenüber Laien 
die Interrupts nicht verstehen zu geben...

lg
Luigi

Hallo,
also mein ursprüngliches Problem vor 14 Monaten war das ich einen CAN zu 
CAN Router bauen wollte und das ohne Plan mit wenig CAN Kenntnissen und 
mehr Bascom Erfahrung...................Nach 10 Monaten also vor 4 
Monaten habe ich zwar einen CAN zu CAN Router mit Bascom und 2 x MCP2515 
und Atmega328P sowie mit AT90CAN128 und einem MCP2515 realisiert aber 
das war nicht mit dem Datendurchsatz zu vergleichen was jetzt mit C und 
dem MCP und dem ATMega328P schon geht.
4 Monate intensives lernen und probieren haben mich einen deutlichen 
Schritt an den CAN und große Schritte näher an C gebracht.

Hardware:
Notebook mit CAN USB von MHS, Lochrasterplatine (SPI Leitungen noch 
nicht optimal) mit 2 x MCP2515 und ATMega328P und noch einen AT90CAN128 
(langsames lesen/schreiben= Bascom) sowie RS232 Anzeigemöglichkeit auf 
dem Stand PC auf dem auch AVR Studio ist.
Von der Seite her kann ich 2 CAN Strecken ausbauen wo sich in der Mitte 
die Platine mit den 2 x MCP und der ATMega befindet - so kann ich den 
Durchsatz ansatzweise testen.

Um beide MCP mit dem Atmega zu nutzen muß ich dann aber noch die 
Initialisierung auf beide bringen, ich muß mir noch mal dein Beispiel 
ansehen wie ich die CS Pins in die Grundfunktionen einbringen muß - ohne 
dem gehen ja nicht beide.

Ich schau aber erstmal ob ichs selbst hinbekommen - dann bleibt es 
besser kleben

Danke.....

Gruß
Peter

Luigi schrieb:
> Scheinbar habe ich mich da etwas unglücklich ausgedrückt,

hat ja jetzt aber gut geklappt.

> jedenfalls schlecht genug um von Lutz gleich in die
> Spinner-Ecke gestellt zu werden... (:

Ach was! Nich gleich Pippi in die Augen kriegen.

Luigi schrieb:
> Der Punkt auf den ich hinauswollte ist der, dass es Probleme geben kann,
> wenn Du sowohl aus einer ISR als auch aus dem main() Kontext die SPI
> Schnittstelle ansteuerst.
> Nimm an Du startest eine SPI Kommunikation aus main() und diese wird von
> einer ISR unterbrochen.

Das Grundproblem bzw. die Grundlösung ist aber die Gleiche wie beim 
vorherigen Mißverständnis: Wenn ich etwas im Programm habe, was nicht 
unterbrochen werden darf, muß ich diese Unterbrechung eben verhindern! 
In der ISR macht die avr-libc das schon von alleine (weil eine ISR hier 
niemals unterbrochen werden sollte), an anderen Stellen muß es der 
Programmierer halt selber machen (da er ja als einziger diese Stellen 
kennt). In diesem Falle z.B. in jeder SPI-Funktion als erstes SREG 
sichern, cli(), machen, was zu machen ist und als letztes wieder das 
SREG restoren. Wobei hier beim MCP2515 wohl außer der Initialisierung am 
Anfang eigentlich nur noch Interrupts als "SPI-Trigger" in Frage kommen 
dürften. Kann aber allgemein in anderen Fällen ganz anders sein; hast du 
recht.

Rumgerechnet habe ich nun nicht ...

Luigi schrieb:
> Bitte beachte dass ich nicht sagen möchte dass die Verwendung der
> Interrupts jedenfalls sinnlos ist, es geht nur i.A. auch ohne, so dass
> man sich in vielen Fällen die zusätzlichen Leitungen sowie die Port-Pins
> sparen kann.

Steht außer Frage. Zumal der Interrupt sicher nicht das Erste auf der 
Welt war.
Nur hatte ich weiter oben schon argumentiert, daß
1.) ein Anfänger als erstes lernen sollte, wie es "richtig" ist. Wenn er 
später Erfahrung hat, kann er selber Abschätzen und daraufhin 
entscheiden, wie er es im konkreten Einzelfall macht.
2.) bei Programmerweiterungen aus Performancegründen sehr schnell ein 
komplettes Redesign der Softwarestruktur erforderlich werden kann, was 
man sich dann hätte sparen können. Klar kann man auch erst Bascom
lernen ...
War jetzt fies, ich weiß. Aber bestimmt verständlich (was ich inhaltlich 
meine).

Hallo H.joachim Seifert,
die ISR mit der MCP-Abfrage drin läuft, den Teil der CAN Routinen aus 
der Demo habe ich schon zum Teil angepasst hier muß ich aber mehr tun da 
hier auch der/die CSs sowie die SPI Initialisierung drin ist.
Aber auch in der Funktion sieht es etwas anders aus
Da muß ich mal sehen ob ich da *rec_can0 über eine Variable 
einschleusen/übergeben kann so das auch *rec_can1 übergeben werden 
kann(siehe unten...), man könnte natürlich die Funktion doppelt 
schreiben und dann anpassen aber das finde ich jetzt schon 
Mist..........und ich möchte auch keinen ünötigen Flashspeicher 
verschwenden.

Achja die CS liegen beide auf PortB einmal PB1 und PB2

Die CAN_Sw macht mit noch zuschaffen da ich nochmal nach der "globalen 
Variable" schauen muß wie die angelegt wird, so meckert das AVR Studio 
noch - da will ich aber erst selbst ran. So ist auch die schreibweise 
Codevision zum AVR Studio für mich schon unterschiedlich.

Aber ich sehe Licht am Ende des Tunnels und es ist nicht die 
Eisenbahn......Spaß beiseite - ich will damit sagen das ich begeistert 
bei der Sache bin..

@Lutz,
>Klar kann man auch erst Bascom lernen ...
>War jetzt fies, ich weiß. Aber bestimmt verständlich (was ich inhaltlich
> meine).

Nee..... ist nicht fies wenn man weiß wie man da hingekommen ist.
Vor Jahr und Tag habe ich mit den C-Control Dingern von Conrad 
angefangen, die waren recht schnell am Ende den die Ansprüche stiegen. 
Dann kam die open C-Control, da ging schon etwas mehr und die waren 
günstiger. Aber auch von den Preisen wurde man ruckzuck von den Beinen 
geholt und so war der dritte Schritt Atmel AVR und als Basic 
geschädigter war Bascom das nahliegenste. Nur mit CAN anlein wäre mit 
Bascom nicht Schluß gewesen doch wo es jetzt um hardwarenahe 
Programmierung geht und daraus resultierend um Geschwindigkeit ist C für 
mich "die" Wahl. Wenn mir das einer vor Jahren gesagt hätte, hätte ich 
den noch ausgelacht. Allerdings muß ich heute sagen - gut das ich 
umgestiegen bin.


uint8_t mcp2515_get_message(CANMessage *rec_can0)
{
  // read status
  uint8_t status = mcp2515_read_status(SPI_RX_STATUS);
  uint8_t addr;

  if (bit_is_set(status,6)) {
    // message in buffer 0
    addr = SPI_READ_RX;
  }
  else if (bit_is_set(status,7)) {
    // message in buffer 1
    addr = SPI_READ_RX | 0x04;
  }
  else {
    // Error: no message available
    return 0;
  }

  RESET(MCP2515_CS_0);
  spi_putc(addr);

  // read id
  rec_can0->id  = (uint16_t) spi_putc(0xff) << 3;
  rec_can0->id |=            spi_putc(0xff) >> 5;

  spi_putc(0xff);
  spi_putc(0xff);

  // read DLC
  uint8_t length = spi_putc(0xff) & 0x0f;

  rec_can0->header.length = length;
  rec_can0->header.rtr = (bit_is_set(status, 3)) ? 1 : 0;

  // read data
  for (uint8_t i=0;i<length;i++) {
    rec_can0->data[i] = spi_putc(0xff);
  }
  SET(MCP2515_CS_0);

  // clear interrupt flag
  if (bit_is_set(status, 6)) {
    mcp2515_bit_modify(CANINTF, (1<<RX0IF), 0);
  }
  else {
    mcp2515_bit_modify(CANINTF, (1<<RX1IF), 0);
  }

  return (status & 0x07) + 1;
}

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

Hallo zusammen,
zunächst wünsche ich allen ein glückliches und gesundes neues Jahr 2012.
Direkt an dieser Stelle möchte ich mich für die kompetente 
Hilfsbereitschaft speziell bei
- H.joachim Seifert
- Lutz
- Peter Dannegger
bedanken.
Ohne die richtigen Initialzündungen eurerseits hätte ich das als "C 
Anfänger" nicht hinbekommen. Die Schaltung empfängt nun bidirektional 
die CAN-Frames zwischen der o.g. Demohardware und versendet auch 
entsprechend der eingestellten CAN_SW Variable. Damit habe ich mit eurer 
Hilfe schon einen großen Teil meines Planes erreichen können.
Die Bearbeitungsgeschwindigkeit ist schon klasse.

>Einen Plan habe ich selbstverständlich:
>- 2 x MCP2515 an einem ATMega328P
>- bidiretionaler Datenstrom
>- Richtung 0 zu 1 = alles durch
>- Richtung 1 zu 0 = 2 IDs herausfiltern (ID 0x261 und ID 0x263)
>- Empfangs- Sendebuffer mit einbeziehen
>- bei freien MC-Resourcen soll bei einer bestimmten ID die Schaltung
>abgeschaltet werden.

Die Einstellung der Empfangs Masken und Filter im MCP sollte ich auch 
noch hinbekommen obwohl mich die Datenfilterung im AVR direkt brennender 
interessiert da ich nur einzelne IDs herausfiltern will und nicht den 
Rest um die 0x261 und 0x263 herum definieren will.

DANKE !!!!!

Gruß
Peter

Hallo H.joachim
vielen dank für die Blumen. Sicher gibt es Lösungen die man per copy und 
paste übernehmen kann, allerdings stellt sich dies meinst als Griff ins 
Klo dar sobald man einen Fehler hat der entweder beim portieren oder 
sogar an der Hardware selbst liegt - also in der Regel eigene Schuld 
ist.
Mir lag und liegt immer noch viel daran zu verstehen was da passiert und 
auch passieren soll. Nur so bin ich in der Lage auch als Anfänger Fehler 
zu finden und zu beseitigen oder wenn das nicht klappt die Fehler 
zubeschreiben und mit Tipps dem Fehler auf die Pelle rücken zukönnen.
Was ich auf jeden Fall gelernt habe das es für die Umsetzung immer 
verschieden Ansätze gibt und man auch seinen Weg finden muß.

Die Case select Lösung werde ich mal für mich beleuchten und mal sehen 
ob so für mich lösbar ist. Bei der Schaltung bzw dem Durchschleusen habe 
ich einige wenige RTRs drin...... ich muß mal sehen.
Sobald ich die Demo- in die Probehardwareplatine umgesetzt habe werde 
ich einen Probelauf in der Zielhardware starten.

Tausend Dank

Gruß
Peter

Hallo erstmal,

ich würde gerne ein ähnliches System aufbauen und dabei aber mehr 
MCP2515 an einen AVR anbinden, als es INT-Pins gibt. Das heißt am 
Beispiel ATmega16, gleich 3 MCP2515 oder mehr.
Gibt es da eine Möglichkeit, das zu realisieren oder bin ich nur am 
träumen. Ich hab im Tutorial etwas über ein SPI Kommando gelesen als 
Alternative zur Interruptleitung, stimmt das?

Allgemein zum MCP2515 steht im Datenblatt ein Puffer von 2 oder 3 
Nachrichten. Kann ich diesen als abrufbaren Zwischenspeicher von 
Nachrichten nutzen, die noch nich zum AVR weitergeleitet wurden?

Der Experte liest sich gleich raus, das ich meine ersten wackligen 
Schritte auf der CAN-Bus Leitung mache, und deshalb kann ich jede Hilfe 
brauchen.

Gruß Tobi

Hi, nochmal ich,

ist ein Interrupt Controller eine Möglichkeit? Könnte man mit dem 
Interrupt Controller die verschiedenen MCP2515 Interrupts koordinieren?

Hallo,

sorry dass ich das hier nochmal nach oben ziehe, aber aus welchen Grund 
sind denn die Ausgänge von IC6 und IC2 auf der Zeichnung von H.Joachim 
Seifert negiert?

Ist es außerdem denkbar, statt zwei MCP2551 nur einen MCP2551 und 
zusätzlich noch einen TJA1055 (Lowspeed CAN) zu verwenden? Kann dieser 
Analog zum MCP2551 angeschlossen werden, oder wird zusätzliches 
benötigt? Der TJA1055 hat ja noch einige Pins mehr...

VG!

Florian schrieb:
> aber aus welchen Grund
> sind denn die Ausgänge von IC6 und IC2 auf der Zeichnung von H.Joachim
> Seifert negiert?

/INT und /CS? Das sind einfach nur low-aktive Eingänge und meiner 
Meinung nach so etwas seltsam gezeichnet.

Florian schrieb:
> Ist es außerdem denkbar, statt zwei MCP2551 nur einen MCP2551 und
> zusätzlich noch einen TJA1055 (Lowspeed CAN) zu verwenden?

Klar geht das, nur wird der TJA1055 eben anders verschaltet was Du ja 
auch schon erkannt hast.
Die zusätzlichen Pins kann man auch nicht einfach weglassen.

Etwas hässlich habe ich das gerade aus einem EAGLE Design gezogen mit 
dem TJA1054, die drei Pins 4,5 und 6 gehen dabei an I/O Pins vom 
Controller.

Der wichtigste Unterschied ist die Wakeup-Funktionalität die ich in dem 
Design aber nicht benutzt habe.

Vielen Dank Rudolph!