...also, ich bin zu dem Entschluss gekommen, das der MCP-2515 einfach ein verbuggter (drecks-) Controller ist. Wenn ihr bessere Erfahrungen habt, dann bin ich ganz Ohr und würde mich echt freuen!! Wer sich den Spaß machen möchte, der darf gern: -den Empfangsmode RXM auf extended-ID stellen (RXM = 10) -die Masken vollständig setzen(0xFFFFFFFF) -Akzeptanz-Filter 0 auf die extended-ID 0x00000030 einstellen -Akzeptanz-Filter 1 auf die standard-ID 0x030 einstellen Ergebnis: Alle extended-ID's werden abgewiesen, bis auf die im Filter eingestellte, also alles bestens! Alle standard-ID's werden abgewiesen (auch die 0x030), da ja Extended-Mode eingeschalten ist,also auch alles bestens? ...dann schickt mal eine Standard-ID 0x030 wo das erste und zweite Datenbyte (DB0,DB1) =0x00 ist. Upps, wie so kommt diese Standard-ID durch den Akzeptanz-Filter 1 ????? Dies dürfte nur bei dem MCP2515 im gemischten Mode (RXM = 00) passieren, da dort die Datenbytes DB0+DB1 mit zur Filterung herangezogen werden. Dies ist nützlich, wenn man gewisse Protokolle mit Index nutzen möchte, allerdings sind dann nur 6 Filter lächerlich....also nach meinem Empfinden eine Funktion die keine Sau braucht, aber den Controller einer wichtigen Eigenschaft beraubt, nämlich gemischt standard und extended-ID unabhängig vom Empfangspuffer zu verwenden! Schlussendlich ist irgendwie der Mode RXM (10) = RXM (00), was nicht sein sollte... Beim MCP2510 gibt es die Protokollsache laut Datenblatt nicht, werde ihn mir mal spassenshalber bestellen und testen...
...Es scheint, als wäre ich der einzige Depp der diesen Controller nutzt, oder dieses Problem mit den verkorksten Filtereinstellungen hat. Was noch so ein toller Designer-Gag ist: Man kann über RXM die Modis für für die Akzeptanzfilter des jeweiligen Empfangspuffer auf extended,standard,beides,oder disable stellen, super Sache oder? Man hat aber auch in der Maske des jeweiligen Empfangspuffers das Exide-Bit, welches man entsprechend in der Maske setzen könnte um den gleichen Effekt zu erzeugen....zumal man die Maske eh setzen muss! Aber das ist nur Theorie, denn man hat dieses Bit für den User in der Maske unzugänglich gemacht, damit man den Modus eben in einem extra Register einstellt. warum einfach, wenn es auch umständlich geht....
Sieht so aus als ob du dich eher über dich aufregst als über den Controller. Augen zu und durch.
Ich versteh dich. Manchmal fühlt man sich, wie der einzige auf der Welt, dem das passiert. Wir hatten von FTI einen Drucksensor am SPI und einen Beschl.sensor. Immer, wenn man dem Drucksensor Informationen abforderte, blieb der SPI "manchmal" hängen. Wenn die Antwort "gerade" war, zog der Barometerchip MISO auf LOW( letztes, gesendetes Byte eben) und BLIEB dort so. Workaround hier, nach jedem Schawatz mit dem Teil haben wir seine Vendor-ID abgefragt. die war "ungerade" :) Naja - so änlich, schon ne Weile her... Machmal ists verrückt. Allein am Bus fiel das nicht auf
Hallo Axel und Herbert, erst mal Danke fürs lesen! Auch wenn mich das bei dem Problem nicht weiter bringt, so ist es irgendwie tröstlich zu sehen wie andere mit sowas umgehen :) @Herbert da magst Du Recht haben...vielleicht ärgert mich einfach nur den Fehler auch nach gefühlt 100 mal Datenblatt lesen nicht verifizieren zu können und nicht akzeptieren will die ganze schöne Zeit verplempert zu haben, da es auf Grund eines Bugs hierfür keine Lösung gibt :) @Axel danke für Deinen Zuspruch :) LG und ein schönes WE
Hi, die Seite kannst Du ja: http://www.microchip.com/wwwproducts/en/MCP2515 Ich habe den Chip vor zig Jahren das letzte Mal eingesetzt, kein Kunde hat diese Probleme gemeldet. Das Errata-Sheet ist von 2007 - wer weiß, vielleicht bist Du wirklich der Erste, der in dem uralt-Silizium einen neuen Bug gefunden hat. Also tu der Entwicklerwelt einen Gefallen und schreib Deinen dokumentierten Fehler an Microchip. Danke Dir und schönen Sonntag, marcus
Hallo Marcus, wollte gern die Erfahrung von anderen Usern abtasten, vielleicht liege ich ja einfach nur daneben. Can-Bus hatte mich am Rand tangiert und für die ersten schnellen Versuche fand ich den MCP 2515 gut verfügbar und preislich natürlich attraktiv. Du schreibst von "uralt-Silizium"... was nimmt man heutzutage denn so, wenn man einen MC ohne implementierte Can-Schnittstelle hat? Hab da irgendwie nur schlecht verfügbare Typen gefunden...vielleicht hast Du einen guten Tip für mich? Marcus H. schrieb: > Danke Dir und schönen Sonntag ...ich hab zu danken, Dir einen schönen Abend :)
Hi Frank, "Uralt-Silizium" - nichts gegen bewährte Technik, ehrlich gesagt würde ich mich wundern, wenn Du einen neuen Bug gefunden hättest. Schreib doch wirklich mal Microchip an. Hätte ich Deine Aufgabe, so würde ich wahrscheinlich auf einen modernen Controller mit CAN-Interface setzen. Selbst wenn da dann ein Siliziumbug hochpoppt, hast man mehr Möglichkeiten für ein Firmware-Workaround. In meinem Fall wäre das dann ein STM32, aber das ist meine ganz persönliche Vorliebe. Auf jeden Fall bei der Auswahl sowohl die Datenblätter, die Errata-Sheets und das Internet befragen. Grüße, Marcus
Hallo Marcus, Marcus H. schrieb: > Hätte ich Deine Aufgabe, so würde ich wahrscheinlich auf einen modernen > Controller mit CAN-Interface setzen. Selbst wenn da dann ein > Siliziumbug hochpoppt, hast man mehr Möglichkeiten für ein > Firmware-Workaround. ...das sehe ich mittlerweile auch so, wenn z.B. die Filtermöglichkeiten des implementierten Can-Controller nicht ausreichen, dann löst man das eben in Software....flink genug und dazu auch noch preislich attraktiv sind die STM32 ja wirklich, wobei wir beim nächsten Punkt sind --> Marcus H. schrieb: > In meinem Fall wäre das dann ein STM32, aber das ist meine ganz > persönliche Vorliebe. ...so sieht auch meine Vorstellung aus, ich hab bisher alles in Assembler auf AVR programmiert und deshalb auch jedes Bit in der Peripherie gern angefasst. Über die Sinnigkeit schweigen ich mal, aber es machte eben Spass die Hardware auch in ihren dunkelsten Ecken zu beleuchten :) Zu den STM32 schiele ich schon eine ganze Weile und versuche gerade den Einstieg in C, denn mit Assembler würde ich da höchstens mal eine kleine Bibliothek für exotische Peripherie schreiben. Bin schon gespannt wie das wird ;)
Bestromer schrieb: > Assembler das geht einfach darum, was am Effizientesten ist. Für die STM32 bekommst Du Startup-Code in C und in Assembler - mir gefällt der Assemblercode fast besser. ARM-Assembler ist schon "etwas" mächtiger als bei AVR/PIC, jedoch nicht so ein Schmerz wie bei 808x. Gelegentlich findet sich eine Entschuldigung für ein paar Zeilen Maschinencode. Spätestens wenn Du Dinge tun willst, die augenscheinlich nicht durch die Standardbibliotheken abbildbar sind. Wieder Kosten sparen, z.B. hier http://www.harerod.de/applications_ger.html#ASi-Xceiver 2€ Bauteile ersetzen in dieser Anwendung ein 10€ ASIC. Ich habe verkaufe gerade wieder die Entwicklung einer Miniplatine im Format 21x18 nach England - sollten nicht mehr als 150 Zeilen AVR Assembler werden. Hier geht es mal wieder im Stromverbrauch, Platz und Kosten. Jahresmenge 5k Oder letztes Jahr die direkte LCD-Glas-Ansteuerung mit einem PIC - 8kHz Befehlstakt (yep, kilo!), 500 Maschinenbefehle, 20µA im Betrieb aus einer Knopfzelle: http://www.harerod.de/applications_ger.html#allTimer Jahresmenge 50k, da darf man als Entwickler schon mal ein paar Stunden Kosten optimieren. Und ja - ich portiere lieber lwIP auf einen neuen Controller, als TCP/IP in Maschinencode aufzusetzen. Dafür bin ich dann doch nicht h4ck3r genug. ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.