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.
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.
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
Außerdem arbeiten die Schrittmotortreiber mit 5V, dann bräuchte ich Levelschifter für die 16 Ausgänge des ATmegas.
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.
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.
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.
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.
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“
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.
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.
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.
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
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.
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.
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).
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.
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.
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
Wenn der RPi inaktiv ist, sind die GPIOs ja standardmäßig als Eingänge geschaltet, dann müsste das ja gehen oder ?
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.
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.
Hab gerade noch 2 Fehler bemerk: "DIR_CH1" ist nicht verbunden und der Pin "OE" von dem Level-Shifter sollte auf 5V geklemmt sein.
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.
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
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...
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.
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.