Ich habe hier einen SJA1000 CAN-Controller, der an eine CPU der
8051er-Klasse soll. Nein, genaugenommen h=E4ngt er schon dort, und ebendort macht er mir auch Probleme. Irgendwie krieg ich aus den Timingwerten von CPU und dem Baustein einfach nicht raus, wo es eckt.
Zumindest geben Philips und Atmel die Timings so unterschiedlich an, dass man sie nicht ineinander =FCberf=FChren kann.
Wenn ich die CPU in den "Takt halbe" Mode schalte, funzt alles. Nur dann verbrate ich f=FCr den Rest der App halt auch jede Menge wertvolle "Rechenzeit".
Hat jemand Erfahrung, wie schnell so ein SJA1000 betrieben werden kann bzw. an welcher Timing-Ecke er zum ersten mal anst=F6=DFt?
hab jetzt leider keine Zeit um mir die Timings genau anzuschauen, aber ich hab schonmal nen SJA1000 an nem ATmega128 betrieben der mit 12 MHz arbeitet. Für das ext. Memory Interface hatte ich Waitstates an weiß aber nimmer ob wegen dem RAM oder dem SJA. Probiers doch erstmal mit
12 MHz und ldi TEMP,0xC0 out MCUCR,TEMP damit hats bei mir funktioniert. Wenn nicht, dann gibts ja vielleicht auch nen Verdrahtungsfehler.
Warum nicht? Der SJA1000 hat ein eigentlich recht simples Businterface.
Du solltest ein paar mehr und genauere Informationen liefern, damit man sich auch ein Bild machen kann (welcher Controller, welche Taktfrequenz am SJA, welcher CPU-Takt wird angestrebt, wo kommt der CPU-Takt her, wie und in welchem Busmode ist der SJA1000 angeschaltet, was /genau/ gibt es für Probleme, welche Meßmittel stehen Dir zur Verfügung, was hast Du schon nachgemessen, etc. pp.).
CPU ist ein AT89C51ID2 von Atmel, Quarz mit 24MHz. Der SJA h=E4ngt mit =FCber 74LVX3245 an der CPU; einer richtungsfixiert, der zweite richtungsgesteuert =FCber /RD und /OE=3D/CS (vom 1aus8 Decoder).
Die CPU unterst=FCtzt zwei Speed-Modi: mit 6 oder 12 Clocks/machine cycle. Um eben die Rechenleistung der CPU auszunutzen h=E4tte ich nat=FCrlich gerne den X2-Mode mit 6Clocks/Cycle verwendet. Und eben dabei "verschluckt" sich der Baustein.
Ein Register wird mit einem Wert geschrieben und anschlie=DFend wieder zur=FCckgelesen und verglichen. So bin ich zumindest mal dahinter gekommen, dass etwas nicht ganz stimmen kann. Denn der r=FCckgelesene Wert ist nicht der zuvor geschriebene :-s Im "normal mode" der CPU mit 12clocks/cycle bin ich langsam genug, da passt's. Also die beiden Timing-Diagramme hergenommen und versucht rauszufinden, wo es hapert. Und genau dabei festgestellt, dass die beiden praktisch nicht ineinander =FCberzuf=FChren sind. Wobei ich die Angaben des SJA f=FCr durchaus OK finde, bloss die von Atmel wollen da nicht so richtig ins Schema passen :-((
Nein, nicht unbedingt - aber natürlich muß man die vollständige Schaltung kennen, um überhaupt etwas dazu sagen zu können.
Fangen wir mal vorne an... Ich zitiere nochmal aus Deiner ersten etwas genaueren Beschreibung:
Dir ist bekannt, Daß Du bei 3.3V VCC das Teil im X2 Modus nur bis 20 MHz betreiben solltest?
Grundsätzlich dürfte der 74HC138 bei 3.3V viel zu lahm für diese Anwendung sein. Ich habe zwar keine Spezifikation für 3.3V, aber schon bei 4.5V wird es sehr eng: dort ist der Decoder mit einer max. Verzögerung von 45 ns spezifiziert.
Jetzt sieh Dir mal das Timing-Diagramm vom Controller an. Bei 24 MHz im X2 Modus (unterstellen wir den mal, obwohl das ja eigentlich nicht gemacht werden soll) bleiben Dir vom Anlegen des Adreß-MSB bis zum /RD oder /WR Signal 54 ns (worst case). ALE verschwindet (worst case) 33 ns vor /RD bzw. /WR. Das Adreß-LSB auf den Datenleitungen verschwindet definitiv früher, also bevor /RD bzw. /WR kommen. Vermutlich schaltest Du mit dem Decoder den Datenbustreiber also erst an, wenn dort die Adresse schon längst wieder weg und ALE längst vorbei ist. Die Reaktionszeit des Bustreibers und die (wenn auch kurze) Hold Time des SJA müssen natürlich noch zusätzlich berücksichtigt werden. Demnach bekommt der SJA nicht die Adresse, die er haben sollte. (Es mag im Timing noch weitere Klumpfüße geben, aber der hier fällt zuerst auf.)
Und nun sieh Dir mal an, wohin die Reise bei niedrigeren Betriebsspannungen geht: bei 2V ist der HC138 mit max. 225 ns angegeben...
Du solltest also, wenn Du tatsächlich so ein schnelles Interface haben möchtest, auch geeignete Bauteile dafür verwenden. Und den Controller innerhalb seiner Spezifikation betreiben, also den Takt etwas reduzieren. Außerdem solltest Du nochmal prüfen, ob im Gesamtzusammenhang eine Versorgung von 3.3V für den Controller wirklich sinnvoll ist - bei 5V träte das Problem wegen der direkten Datenbusverbindung wohl nicht auf.
Stehen Dir eigentlich vernünftige Meßgeräte zur Verfügung, um das Timing einmal zu überprüfen?
Aehm. Autsch. Hab die Taktrate jetzt auf 20MHz geändert, um auf Nummer sicher zu gehen. Hatte allerdings nach meiner Modifikation sauber funktioniert. Nur soll das ja nicht nur bei einem Prototypen arbeiten sondern auch in einem gewissen Arbeitsbereich (Temp, ...).
Vielleicht wird man ja betriebsblind, wenn man zu lange auf einen Schaltplan starrt (oder ihn sogar selber gezeichnet hat).
Aber der Tipp war Gold wert. Die Adressdecodierung war das wirkliche Problem. Hab das Datenblatt aufmerksam durchgearbeitet und dabei grosse Augen bekommen. Irgendwie ist der 'HC einfach aus Gewohnheit und ohne sehr grosse Überlegungen dort hin gekommen.
Jetzt versieht ein 74AC138 seinen Dienst, der mit ca 10ns deutlich schneller ist.
Das und sicherheitshalber noch die reduzierte Taktfrequenz haben das Problem gelöst - auch im Klimaschrank.
sag ich ja, betriebsblind...
hab dazugelernt - Datenblätter immer GANZ lesen. :-)
Genaugenommen sind es 3.6V, da auch ein GSM-Modul mit drauf ist. Und das macht mir bei diesen Spannungen schlapp.
Wenn ein LeCroy (Wavepro?) vernünftig ist, dann ja ;-)
Vielen Dank für Deinen fundierten Input. Das ist genau der Grund, warum ich das Usenet so schätze...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.