Forum: Mikrocontroller und Digitale Elektronik ISP zur Kommunikation zwischen einem ATmega und einem RPi


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von Marvin K. (m_marvin)


Lesenswert?

Ich versuche gerade einen Schrittmotortreiber mit einem ATmega328P zu 
realisieren.
Ich kann auch schon Impulse erzeugen, die die Schrittmotortreiber 
verstehen.

Jetzt brauchte ich noch eine Schnittstelle mit der ich den ATmega 
ansteuern kann.
Erst wollte ich I2C verwenden, aber dann hab ich im Datenblatt gelesen 
das das die Schnittstellen UART I2C und SPI gleichsetzt sind (Alle 
können Programmieren und auch Daten senden/empfangen).

Ich hatte nun die Idee das ich SPI zur Kommunikation nutze.
Ich habe dazu nun 2 Fragen auf die ich bisher keine Antwort gefunden 
habe:

1. Ich nutze ein STK500 zur Programmierung des ATmega, gibt es eine 
Möglichkeit, mit diesem auch andere daten über ISP zu senden, um die 
Funktionsweise meines Codes zu testen?
Am besten währe es wenn das direkt in Atmel-Studio ginge.
So müsste ich den ATmega nicht jedes mal Umstecken und keinen 
improvisierten Master für Testzwecke bauen.

2. Kann ich die SPI Schnittstelle am RPi direkt mit dem ATmega 
verbinden?
Ich habe gelesen das man bei I2C erst noch einen Level Shifter braucht, 
um aus den 5V des AVR die 3.3V des RPi zu machen.

Da ich generell noch nicht mit SPI gearbeitet habe (außer zum 
Programmieren der AVRs), würde ich auch gerne wissen, ob ich da noch 
irgendetwas zu beachten habe.

von Wolfgang (Gast)


Lesenswert?

Marvin K. schrieb:
> Ich habe gelesen das man bei I2C erst noch einen Level Shifter braucht,
> um aus den 5V des AVR die 3.3V des RPi zu machen.

Betreibe den ATmega328P nicht mit 5V. Dann hast du das Problem nicht.

Aber richtig, wenn du ihn mit 5V betreibst, brauchst du einen 
Level-Shifter, der allerdings für SPI nicht bidirektional zu sein 
braucht.

von Marvin K. (m_marvin)


Lesenswert?

Wolfgang schrieb:
> Betreibe den ATmega328P nicht mit 5V. Dann hast du das Problem nicht.

Ich brauche 5V, sonst erreiche ich die 16MHz nicht, die für meinen Code 
erforderlich sind, bzw. laut Datenblatt währe ich in einer Grauzone, zu 
der da nichts steht:

ATmega328P:
0 - 4 MHz @ 1.8 - 5.5V
0 - 10 MHz @ 2.7 - 5.5V
0 - 20 MHz @ 4.5 - 5.5V

von Marvin K. (m_marvin)


Lesenswert?

Außerdem arbeiten die Schrittmotortreiber mit 5V, dann bräuchte ich 
Levelschifter für die 16 Ausgänge des ATmegas.

von Hmmm (Gast)


Lesenswert?

Marvin K. schrieb:
> Ich nutze ein STK500 zur Programmierung des ATmega, gibt es eine
> Möglichkeit, mit diesem auch andere daten über ISP zu senden, um die
> Funktionsweise meines Codes zu testen?

Mit CMD_SPI_MULTI (STK500v2-Protokoll) könnte es gehen, die Frage ist, 
ob dabei die Reset-Leitung in Ruhe gelassen wird.

Marvin K. schrieb:
> Da ich generell noch nicht mit SPI gearbeitet habe

Nimm lieber den UART. Dein STK500 hat einen Pegelwandler dafür, dafür 
gibt es den zweiten RS232-Anschluss und die TXD- und RXD-Pins.

Für die Verbindung zum RPi sollte dann ein Pegelwandler in Richtung RPi 
(Spannungsteiler) ausreichen.

von EAF (Gast)


Lesenswert?

Marvin K. schrieb:
> Da ich generell noch nicht mit SPI gearbeitet habe (außer zum
> Programmieren der AVRs), würde ich auch gerne wissen, ob ich da noch
> irgendetwas zu beachten habe.

Ja!
Ein ATMega328P als Slave ist nicht ganz ohne.
Er hat in seiner SPI Hardware eigentliche keine Queue.
Somit muss der Master viele lange Pausen machen, damit der Slave die 
Zeit hat seine Daten abzuholen, zu verarbeiten.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nimm eine AVR128DA28 (falls SMD AVR128DA32/48/64) und schmeiß dieses 
ganz alten megas über Bord.

Das Programmieren per UPDI geht ganz einfach über serielle 
Schnittstelle. Der hat auch viele nette features, die Du gebrauchen 
kannst.  Läuft bspw. offiziell mit 24MHz, inoffiziell mit internem 
RC-Oszi mit 32MHz bis runter zu 1,8V.

von Marvin K. (m_marvin)


Lesenswert?

Hmmm schrieb:
> Nimm lieber den UART. Dein STK500 hat einen Pegelwandler dafür, dafür
> gibt es den zweiten RS232-Anschluss und die TXD- und RXD-Pins.

Geht nicht, die RXD und TXD Pins liegen auf PORTD welcher für die 100kHz 
Impulse genutzt wird, und aus diversen gründen kann ich daran nichts 
ändern.

EAF schrieb:
> Ein ATMega328P als Slave ist nicht ganz ohne.
> Er hat in seiner SPI Hardware eigentliche keine Queue.
> Somit muss der Master viele lange Pausen machen, damit der Slave die
> Zeit hat seine Daten abzuholen, zu verarbeiten.

Das sollte kein Problem sein (wenn ich das Protokoll richtig verstanden 
habe).
1. Der RPi hat es nicht "eilig" es macht nichts wenn er mal etwas warten 
muss.
2. Der ATmega läuft mit voller Taktfrequenz auf 16MHz, und führt kaum 
Code aus, die Abfrage des SPI währe also sehr schnell.

von Oliver S. (oliverso)


Lesenswert?

Marvin K. schrieb:
> aber dann hab ich im Datenblatt gelesen
> das das die Schnittstellen UART I2C und SPI gleichsetzt sind (Alle
> können Programmieren und auch Daten senden/empfangen).

Kannst du das mal dechiffrieren? Nur um zu verstehen, was du verstanden 
haben zu meinst.

Oliver
P.S. Schnittstellen können prinzipiell nicht „Programmieren“

von Marvin K. (m_marvin)


Lesenswert?

Wilhelm M. schrieb:
> Nimm eine AVR128DA28 (falls SMD AVR128DA32/48/64) und schmeiß dieses
> ganz alten megas über Bord.

Ich lese jedes mal wenn ich eine Frage stelle dass eine andere MCU 
besser geeignet ist.
Aber ich hab nunmal ein par ATmegas hier, und will nicht immer für ein 
Projekt den Controller bestellen der am besten geeignet ist.
Wenn es mit einem ATmega geht, und ich hier welche habe, möchte ich es 
gerne auch mit dem machen.
Außerdem würde es lange dauern eine MCU zu finden, die ALLEN 
anforderungen entspricht die ich habe.
Bisher hat der ATmega ziemlich gut funktioniert, er hat 3 Timer 
ausreichend Ports und läuft mit 16MHz.

von Wilhelm M. (wimalopaan)


Lesenswert?

Marvin K. schrieb:
> Wilhelm M. schrieb:
>> Nimm eine AVR128DA28 (falls SMD AVR128DA32/48/64) und schmeiß dieses
>> ganz alten megas über Bord.
>
> Ich lese jedes mal wenn ich eine Frage stelle dass eine andere MCU
> besser geeignet ist.
> Aber ich hab nunmal ein par ATmegas hier, und will nicht immer für ein
> Projekt den Controller bestellen der am besten geeignet ist.
> Wenn es mit einem ATmega geht, und ich hier welche habe, möchte ich es
> gerne auch mit dem machen.
> Außerdem würde es lange dauern eine MCU zu finden, die ALLEN
> anforderungen entspricht die ich habe.
> Bisher hat der ATmega ziemlich gut funktioniert, er hat 3 Timer
> ausreichend Ports und läuft mit 16MHz.

Verstehe ich, trotzdem rate ich Dir dringend dazu. Die neuen sind 
wesentlich flexibler und einfacher zu programmieren. Und sie sind 
deswegen nicht komplizierter als die alten. Wie gesagt, das fängt schon 
beim Programmieren an, Du brauchst keine ISP-Adapter mehr (ggf. macht ja 
auch die Doppelnutzung der Pins Probleme). Den STK500 kannst Du gleich 
mit entsorgen ;-) SPI und I2C mit den neuen ist super einfach. Geht 
alles ausreichend genau ohne Quartz, mit 3,3 oder 5 oder 1,8V bis 32 
MHz.
Überlege es Dir, bevor Du jetzt viel Arbeit hineinsteckst, denn Du 
scheinst ja ganz am Anfang zu sein.

von Marvin K. (m_marvin)


Lesenswert?

Oliver S. schrieb:
> Kannst du das mal dechiffrieren? Nur um zu verstehen, was du verstanden
> haben zu meinst.
>
> Oliver
> P.S. Schnittstellen können prinzipiell nicht „Programmieren“

Im Datenblatt steht, das das Programmieren über jede der verfügbaren 
Schnittstellen möglich ist.
Genauso auch die Kommunikation für andere Zwecke.
Ich dachte bisher, SPI sei ausschließlich zum Programmieren gedacht.

Hmmm schrieb:
> Mit CMD_SPI_MULTI (STK500v2-Protokoll) könnte es gehen, die Frage ist,
> ob dabei die Reset-Leitung in Ruhe gelassen wird.

Kannst du das genauer erklären?
Ich hab kenne mich mit dem Protokoll des STK500 nicht so gut aus.

von Oliver S. (oliverso)


Lesenswert?

Marvin K. schrieb:
> Im Datenblatt steht, das das Programmieren über jede der verfügbaren
> Schnittstellen möglich ist.
> Genauso auch die Kommunikation für andere Zwecke.


Da liest du falsch.

Die Schnittstellen sind dafür da, Daten zu senden und zu empfangen. Mit 
den empfangenen Daten kannst du dann alles machen was du willst. 
Natürlich kannst du die dann auch ins RAM, ins Eeprom, oder in den Flash 
schreiben. Das „als man kann über alle Schnittstellen programmieren“ zu 
zu bezeichnen ist leicht am Thema vorbei

> Ich dachte bisher, SPI sei ausschließlich zum Programmieren gedacht.

Nein, ist es nicht. Man könnte ehr sagen, es gibt eine SPI-Schnittstelle 
zum Programmieren des Flash, und eine für den Prozessor zur 
Kommunikation. Die liegen nur zufällig auf den selben Pins.

Oliver

von Marvin K. (m_marvin)


Lesenswert?

Was meinst du mit ich brauche keinen ISP-Adapter?
Die UDIP Schnittstelle benötigt auch einen Adapter.
Bisher hatte ich mit SPI keine Probleme, und ATmegas/ATtinys sind in 
großer Auswahl als THT/DPI Bauteile erhältlich, die neuen AVRs scheinen 
mehr in SMD Form produziert zu werden.
Für solche einfach aufgaben wie dieser Schrittmotor-Stepper, reicht ein 
ATmega aus, find ich.

von Stefan F. (Gast)


Lesenswert?

Marvin K. schrieb:
> Geht nicht, die RXD und TXD Pins liegen auf PORTD welcher für die 100kHz
> Impulse genutzt wird

Benutzt du denn alle 8 Pins von Port D?

Das Problem ist, dass UART die einzige Schnittstelle mit wenigstens 
einem Byte Puffer ist. Die anderen Schnittstellen haben gar keinen 
Puffer.

von Wilhelm M. (wimalopaan)


Lesenswert?

Marvin K. schrieb:
> Was meinst du mit ich brauche keinen ISP-Adapter?
> Die UDIP Schnittstelle benötigt auch einen Adapter.

UPDI. Nein, zum Programmieren und Debuggen reicht der eine UPDI-Pin ds 
µC an dem Du dann den PC per serieller Schnittstelle anschließt.

> Bisher hatte ich mit SPI keine Probleme, und ATmegas/ATtinys sind in
> großer Auswahl als THT/DPI Bauteile erhältlich, die neuen AVRs scheinen
> mehr in SMD Form produziert zu werden.

Übrigens: nicht ISP und SPI verwechseln ...

Der AVR128DA28 ist im DIP-28.

> Für solche einfach aufgaben wie dieser Schrittmotor-Stepper, reicht ein
> ATmega aus, find ich.

Sicher.
Leider sind viele der alten AtMegas in ihrer internen Peripherie immer 
leicht unterschiedlich.
Bei den neuen ist das regulär (bis auf NVM ;-) ). Du musst Dich also 
beim Controllerwechsel nicht umstellen.

Vielleicht ist auch noch interessant, dass man die interne Peripherie 
auf unterschiedliche Pins des µC mappen kann (PortMux).

von EAF (Gast)


Lesenswert?

Marvin K. schrieb:
> Im Datenblatt steht, das das Programmieren über jede der verfügbaren
> Schnittstellen möglich ist.

Ja, wenn da ein Bootloader dran horcht.

Merke:
SPI und ISP ist nicht das gleiche.

von Hmmm (Gast)


Lesenswert?

Marvin K. schrieb:
> Hmmm schrieb:
>> Mit CMD_SPI_MULTI (STK500v2-Protokoll) könnte es gehen, die Frage ist,
>> ob dabei die Reset-Leitung in Ruhe gelassen wird.
>
> Kannst du das genauer erklären?
> Ich hab kenne mich mit dem Protokoll des STK500 nicht so gut aus.

Die STK500v2-Programmer (wozu neben dem STK500 auch der AVRISP ohne mkII 
gehört) reichen nicht einfach nur stumpf Daten durch, sondern sprechen 
auf Controller-Seite das ISP-Protokoll.

Wenn Du darüber Daten übertragen willst, die nichts mit ISP zu tun 
haben, ist also wichtig, dass a) Du Rohdaten übertragen kannst und b) 
die Reset-Leitung nicht (wie bei ISP notwendig) auf GND gezogen wird.

Ersteres könnte mit CMD_SPI_MULTI erfüllt sein, letzteres weiss ich 
nicht.

Die Protokollbeschreibung findest Du z.B. dort:

https://www.electronicwings.com/download/attachment=Thu-12-17-17-01-49.AVR%20STK500.pdf

Ich würde an Deiner Stelle den AVR auch zum Testen schon an den RPi 
hängen, dann ersparst Du Dir diesen Aufwand.

von Marvin K. (m_marvin)


Lesenswert?

Stefan ⛄ F. schrieb:
> Benutzt du denn alle 8 Pins von Port D?
>
> Das Problem ist, dass UART die einzige Schnittstelle mit wenigstens
> einem Byte Puffer ist. Die anderen Schnittstellen haben gar keinen
> Puffer.

Ja, PORTD war der einzige Port an dem nicht irgend ein anderer 
wischtiger Pin wie RESET oder XTAL lagen.
Ich weise dem gesamten Port ein Byte als wert zu, um so die 8 Kanäle mit 
möglichst geringem Zeitaufwand schalten zu können und die höheren 
Frequenzen zu erreichen.

EAF schrieb:
> Merke:
> SPI und ISP ist nicht das gleiche.

Das weis ich.
ISP bezeichnet ja nur das Programmieren ohne den Chip aus der Schaltung 
zu entfernen (In System Programming) und SPI nur die Schnittstelle.

Hmmm schrieb:
> Ich würde an Deiner Stelle den AVR auch zum Testen schon an den RPi
> hängen, dann ersparst Du Dir diesen Aufwand.

Dann hätte ich wieder diesen Aufwand mit dem umstecken wenn ich das 
Programm testen will.
Gerade das will ich ja vermeiden.
Oder kommt das STK damit klar, wenn da ein weiteres Gerät (der RPi) 
inaktiv am SPI hängt ?

: Bearbeitet durch User
von Marvin K. (m_marvin)


Lesenswert?

Wenn der RPi inaktiv ist, sind die GPIOs ja standardmäßig als Eingänge 
geschaltet, dann müsste das ja gehen oder ?

von Hmmm (Gast)


Lesenswert?

Marvin K. schrieb:
> Oder kommt das STK damit klar, wenn da ein weiteres Gerät (der RPi)
> inaktiv am SPI hängt ?

Das STK500 verhält sich wie ein normaler In-System-Programmer, der (wie 
der Name schon sagt) dafür gedacht ist, in laufenden Systemen verwendet 
zu werden.

Jeweils 1kOhm in Reihe, dann ist völlig egal, was der RPi auf den 
ISP-Leitungen anstellt, während geflasht wird.

von Marvin K. (m_marvin)


Angehängte Dateien:

Lesenswert?

Hier ist mein vorläufiger Schaltplan, wie ich das gerade auf dem 
Steckbrett aufgebaut hab + die SPI Schnittstelle die aktuell noch direkt 
mit dem STK verbunden ist.

Darin sieht man ganz gut warum PORTD nicht verfügbar ist.
Alle Pins vom Port gehen direkt über Glättungskondensatoren auf die 
Anschlüsse für die Schrittmotoren.

Den SPI-Pin-Header hab ich so ausgelegt, dass er mit dem STK500 
kompatibel ist, und ich das Flachbandkabel nutzen kann.

von Marvin K. (m_marvin)


Lesenswert?

Hab gerade noch 2 Fehler bemerk:
"DIR_CH1" ist nicht verbunden und der Pin "OE" von dem Level-Shifter 
sollte auf 5V geklemmt sein.

von Marvin K. (m_marvin)


Lesenswert?

Ich hab mir jetzt mal den "Aufbau" des SPI Protokolls auf der seite des 
ATmegas angesehen (also die Register und der Lese/Schreib-Ablauf).
Es ist eigentlich perfekt für meine Zwecke geeignet, auch das fehlen 
eines Buffers stört nicht.
Will von außerhalb (über SPI) einen von 10 Registern/Variablen mit einem 
Byte beschreiben können.
Ich kann die SPI Schnittstelle also so nutzen, das ich das erste 
gelesene Byte nutze um den Register anzuwählen, und das zweite um dann 
den Wert zu schreiben.

Das ginge auch mit anderen Schnittstellen, aber SPI scheint besonders 
einfach zu sein, wenn ich das Datenblatt richtig verstanden hab.
Aktivieren, als Slave konfigurieren und dann einfach auf Daten warten.

von Marvin K. (m_marvin)


Lesenswert?

Ich habe jetzt folgenden Code um meine SPI Daten zu lesen und zu 
verarbeiten:
1
    if (SPSR & (1 << SPIF)) {
2
      if (spiWriteAdress == 0) {
3
        spiWriteAdress = SPDR;
4
      } else {
5
        uint8_t data = SPDR;
6
        if (data == 0) {
7
          if (spiWriteAdress == 1) {
8
            setBaseFrequencyDivident((uint16_t) spiWriteData);
9
          } else if (spiWriteAdress <= 9) {
10
            setPortDirection(spiWriteAdress - 2, spiWriteData > 0);
11
          } else if (spiWriteAdress <= 17) {
12
            portFrequency[spiWriteAdress - 10] = (uint8_t) spiWriteData;
13
          } else if (spiWriteAdress <= 25) {
14
            portSteps[spiWriteAdress - 18] = spiWriteData;
15
          }
16
          nByte = 0;
17
          spiWriteData = 0;
18
          spiWriteAdress = 0;
19
        } else {
20
          spiWriteData = (data << (nByte++ * 8));
21
        }
22
      }
23
    }

Jetzt stelle ich mir nur noch eine Frage.
Wenn der Pin SS auf low geht, bricht das ja die aktuelle Übertragung ab.
Das bedeutet, ich muss auch meinen "Buffer" leeren.
Kann ich den SS Pin einfach als Input konfigurieren und lesen, oder 
kommt das in Konflikt mit der SPI Hardware ?

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Marvin K. schrieb:

> Das ginge auch mit anderen Schnittstellen, aber SPI scheint besonders
> einfach zu sein, wenn ich das Datenblatt richtig verstanden hab.

Hast du nicht. Das entscheidende Problem ist das Fehlen eines 
Empfangspuffers. Das bedeutet: du musst innerhalb einer Zeit von knapp 
der Hälfte der Periode des vom Master vorgegebenen SPI-Taktes das 
empfangene Byte auslesen. Gelingt das nicht, werden die nachfolgenden 
Bytes "beschädigt".

Bei SPI wird typisch ein recht hoher Takt verwendet, was dann dazu 
führt, dass der ATmega als Slave nicht hinterherkommt, weil allein schon 
die Auslösung des Interrupts länger dauert als die für eine Reaktion 
verfügbare Zeit.

Im konkreten Fall kontrollierst du allerdings auch den Master und hast 
so die Möglichkeit, den Takt einfach weit genug herabzusetzen, so dass 
der ATmega noch sicher hinterkommt. Du wirst dich allerdings beim 
Nachrechnen des zulässigen Taktes erschrecken, WIE tief du 
heruntergehen musst...

von Stefan F. (Gast)


Lesenswert?

Wenn man das jetzt noch mit der Soft-PWM Ausgabe aus Marvin anderem 
Thread kombiniert, kommt man du dem Schluss, dass er es mit dem 
ATmega328P nicht einmal ansatzweise umsetzen kann.

von Jobst M. (jobstens-de)


Lesenswert?

Okay Marvin,

hast Du eigentlich schon sowas wie ein Konzept gemacht? "Was brauche ich 
alles für Funktionalitäten?" und im 2. Schritt dann "Was macht wer?" und 
"Schafft der das?"

Im Moment bist Du bei "schafft er nicht"

Was hast Du damit überhaupt vor? Willst Du nur Positionen anfahren? Oder 
willst Du mit 2 oder mehr Achsen Kurven fahren?

Wichtig: Wie stellst Du Dir die Kommunikation vor?

Welche Daten werden übermittelt in welche Richtung? - Und die müssen 
auch verarbeitet werden!

Außerdem wundere ich mich, dass Du nicht schon eine Frage gestellt hast.


Marvin K. schrieb:
> Ich weise dem gesamten Port ein Byte als wert zu, um so die 8 Kanäle mit
> möglichst geringem Zeitaufwand schalten zu können und die höheren
> Frequenzen zu erreichen.

Der Zusammenbau Deines Bytes wird mehr Zeit benötigen, als die einzelnen 
Pins zu setzen.

Marvin K. schrieb:
> Für solche einfach aufgaben wie dieser Schrittmotor-Stepper, reicht ein
> ATmega aus, find ich.

Du unterschätzt die Anforderungen deutlich.

Nimm Dir einen ATmega328, steck ihn auf ein Bread-Board, STK500 oder 
löte ihn auf Lochraster. Stepper-Treiber dazu und eine Schnittstelle 
Deiner Wahl zur Kommunikation. Und dann fang doch einfach mal an, einen 
Motor von A nach B zu fahren. Und dann baust Du es so um, dass Du dies 
über die Schnittstelle erledigen kannst.

Und wenn Du damit fertig bist, kannst Du überlegen, wie und ob Du noch 
weitere Kanäle in den Controller bekommst.

Und mach nicht jedes Mal einen neuen Thread auf!


Gruß
Jobst

von Peter D. (peda)


Lesenswert?

Marvin K. schrieb:
> Hier ist mein vorläufiger Schaltplan

Die 2,2nF schmeiß mal ganz schnell wieder raus. Man belastet IO-Pins 
nicht kapazitiv, das gibt nur Ärger.
Kondensatoren macht man höchstens nur an analoge Eingänge.

von Oliver S. (oliverso)


Lesenswert?

EAF schrieb:
> Merke:
> SPI und ISP ist nicht das gleiche.

Das Datenblatt drückt das so aus:
"The On-chip ISP Flash
allows the program memory to be reprogrammed in-system through an SPI 
serial interface"

Noch Fragen?

Oliver

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
Noch kein Account? Hier anmelden.