...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....
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. ;)
