Hallo Leute, ich versuche gerade, mit einem ATmega64 einen MCP2515 und einen ENC28J60 zum Laufen zu bringen. Bisher ist erst der MCP2515 auf dem Board, aber ich merke bereits, daß das ein Schuß in den Ofen war. Ist es tatsächlich so, daß man nur EIN Gerät an den Hardware-SPI anschließen kann? Ich möchte auf dem CAN-Projekt von Fabian Greif (www.kreatives-chaos.com) aufbauen, und hatte auch mal was ähnliches mit dem Mega8 gebaut. In der Software heißt es, daß der /CS des MCP2515 am SS des AVR angeschlossen werden muß, damit das Hardware-SPI genutzt werden kann. Das heißt für mich, daß nur Geräte, die am SS hängen, verwendet werden können, ergo genau eins. Stimmt das so? Kann ich über die Portpins einen Multiplexer ansteuern, und SS gaten, um mehr Geräte dranzuhängen? Das nächste und größere Problem: nachdem ich jetzt den Fehler mit dem SS (bei mir hängt /CS derzeit an PB5) erkannt habe, habe ich /CS an SS gehängt (zusätzlich, aber wenn PB5 als Eingang konfiguriert ist, müsste das doch gehen, oder? Mag nicht auf Verdacht hin Leiterbahnen durchkratzen), aber ich sehe auf allen Leitungen im Wesentlichen nichts, nichtmal Clock, wobei das mit einem Analog-Scope bis 10 MHz auch keinen Spaß macht, kaum ist was da, ist es auch wieder weg (außerdem ist das eigentliche Kabel irgendwie kaputt, und das jetzige fängt Mist ohne Ende ein, ich sehe ständig die AM unseres hiesigen Radiosenders) Ich merke gerade, daß das hier ziemlich wirr wird, also nochmal ein paar klare Fragen: - Wie kann man mehrere Geräte an einen SPI hängen? - Ist beim Mega64 am SPI irgendwas so dramatisch anders als beim Mega8, daß übernommene Software gerade mal gar nicht geht? - Ist ein zusätzlich an einer Leitung hängender und als Eingang geschalteter Portpin ein Problem? - Sendet das SPI Daten immer raus, auch wenn kein Gerät dran hängt (also wie z.B. das USART es tut)? Vorhin beim Testen blockierte die SPI-Funktion nämlich beim Senden des zweiten Byte, dann habe ich an der Hardware was geändert, dann ging's, dann habe ich es zurückgeändert, und jetzt geht's immer noch (also es blockiert nicht mehr, ob er was sendet weiß ich nicht, bin ja quasi blind). Leider habe ich schon viel zu viel Zeit mit dem Projekt verplempert (ist ein Teilstück meiner Diplomarbeit; ich hätte mich als Softwerker doch auf PC-Software beschränken sollen, da kann man wenigstens funktionierende Hardware voraussetzen :-/), und wenn ich es nicht in 1-2 Wochen laufen habe, muß ich diesen Teil als gescheitert betrachten und die Hardware simulieren, was reichlich dämlich wäre. Die Ethernet-Schnittstelle habe ich bereits innerlich abgeschrieben, aber CAN ist ein Muß für dieses Projekt. Gruß, Felix
zum SS: im Datenblatt zum Mega64 heißt es, daß die SS-Leitung nicht vom SPI kontrolliert wird, wenn man Master ist (und so soll es ja sein), deshalb müsste IMHO jeder Portpin gehen, wenn ich ihn doch eh selber hoch- und runterziehen muß. Mit anderen Worten: SS ist nur "besonders", wenn der Controller ein Slave sein soll, in allen anderen Fällen verhält es sich wie ein normaler Portpin, und kann auch durch jeden normalen Portpin ersetzt werden. Korrekt?
>Ist es tatsächlich so, daß man nur EIN Gerät an den Hardware-SPI >anschließen kann? Nö, man muß nur jedem Gerät seinen eigenen /SS-Pin spendieren. Und der wird eh vom Master "manuell" bedient. >- Wie kann man mehrere Geräte an einen SPI hängen? Jedem seinen eigenen /SS-Ausgang am Master spendieren >- Ist beim Mega64 am SPI irgendwas so dramatisch anders als beim >Mega8, daß übernommene Software gerade mal gar nicht geht? AFIAK: Nö >- Sendet das SPI Daten immer raus, auch wenn kein Gerät dran hängt ja, sofern der Master etwas senden soll... >Leider habe ich schon viel zu viel Zeit mit dem Projekt verplempert >(ist ein Teilstück meiner Diplomarbeit; ich hätte mich als Softwerker >doch auf PC-Software beschränken sollen, da kann man wenigstens >funktionierende Hardware voraussetzen :-/), und wenn ich es nicht in >1-2 Wochen laufen habe, muß ich diesen Teil als gescheitert >betrachten und die Hardware simulieren, was reichlich dämlich wäre. >Die Ethernet-Schnittstelle habe ich bereits innerlich abgeschrieben, >aber CAN ist ein Muß für dieses Projekt. Du sitzt doch wohl nicht seit einem halben Jahr am Problem mit dem SPI, oder? Verlängern stellt kein Problem dar (musste ich damals auch machen, weil Teile nicht lieferbar waren. Da war die Diplomarbeit erst in 4 statt 3 Semestern fertig). Was willst du denn werden? Dipl(-Ing) oder Heulsuse?
Nein, am SPI sitze ich erst seit zwo Tagen, die zwei Monate (von vorhandenen fünf bzw. mit Verlängerung sechs) sind für das ganze andere Gerödel (Planungsphase, Definitionsphase, Entwurfsphase usw., API-Design, Spezifikation usf., zwei entworfene Protokolle für die Kommunikation der einzelnen Einheiten, ...) draufgegangen. Studiengang ist übrigens Informatik mit Schwerpunkt Software-Engineering (also UML und den ganzen Blödsinn). Die verbleibenden 3 Monate hatte ich so angedacht: - 1 Woche für die Funktionsbibliothek (um aus hin- und hergeschobenem ASCII ein paar anfassbare Funktionen zu machen) - 2 Wochen für die Klickibunti-GUI mit grafischer Auswertung der Meßergebnisse usw. - 4 Wochen für das Zusammensetzen der Dokumentationsbrocken zu einer lesbaren Arbeit - 4 Wochen Pufferzone für unvorhersehbare Probleme Das heißt die Firmware sollte planmäßig in 1 Woche passen (waren ja, soweit ich bisher dachte, nur fertige Brocken zusammenzusetzen), weil ich die 4 Wochen Pufferzone garantiert brauche, um den verreckenden Drucker im Copyshop, oder die verschmierte Farbe auf Seite 153, die das erneute Ausdrucken notwendig machen würde, kompensieren zu können. Gruß, Felix
Oder um es nochmal in andere Worte zu fassen: der SPI macht ca. 0,5% der Sache aus, die gesamte Hardware vielleicht 10-15%, und es ist alles andere als mein Fachgebiet, weswegen ich da reichlich am Schwimmen bin, wie man unschwer merkt.
Schon klar, die Zeit würde sicher reichen, wenn ich wüsste, wonach ich suche. Der Haken ist der, daß genau das gleiche Ding mit dem Mega8 tut, aber mit dem Mega64 nicht.
Ich denke ich habe das Problem gefunden: Schrott auf SCK. Es ist doch immer das Einfachste (Ockham hatte irgendwie recht, aber immerhin war mein Schaltplan und die Software in Ordnung). Ich habe da ein periodisches, aber nicht ununterbrochenes Signal, das von Spitze zu Spitze ca. 60 mV misst (spi.jpg). Es war recht schwierig, das zu erwischen, weil sich der Controller aufhängt (bzw. ich schätze er kommt nur nicht aus der Sende-Funktion des SPI zurück), wenn ich mit dem Scope dranfasse. Aber nicht immer, und nicht an jedem Punkt von SCK, sondern am liebsten neben dem ISP-Adapter. Wenn ich in der Nähe des MCP2515 ein Stück Fädeldraht anlöte, dann geht gar nichts mehr. Ich erwähnte bereits das beschissene Kabel das ich am Scope habe, das stört vermutlich recht kräftig in die Schaltung rein, daher das Aufhängen bei Berührung. Ich habe nun die SPI-Clock auf f_osc/128 gestellt (war vorher ganz mutig auf f_osc/4...), und nun sehe ich zum einen die Clock, und zum anderen bekommt der MCP2515 etwas mit, und sendet auch brav. Allerdings sieht das am PCA82C250 (der CAN-Driver für die hübschen Pegel) irgendwie traurig aus (can_h.jpg, can_l.jpg, natürlich anderer Maßstab, IIRC 0,5 V/DIV). Ist das gut genug, um was zu senden, oder ist das zu schlecht? Die Signalführung auf dem Board ist sicherlich mies, aber IMHO dürfte das CAN-Signal nur von der "letzten Meile" abhängen, also was vom MCP zum PCA und vom PCA zum SubD-Connector kommt. Fazit: ich probier's damit, und wenn die anderen Busteilnehmer mich auslachen, dann wird das ganze recht düster, weil für HF-Voodoo habe ich weder das Know-How noch das Equipment. Gruß, Felix
Bitte 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.