www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SPI-Probleme (Mega64)


Autor: Felix Opatz (zotteljedi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Felix Opatz (zotteljedi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Felix Opatz (zotteljedi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Woche hat 7 Tage und ein Tag 24 Stunden...

Viel Erfolg!

Autor: Felix Opatz (zotteljedi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Felix Opatz (zotteljedi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Felix Opatz (zotteljedi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.