Ich habe mich heute etwas mit der Datenübertragung über SPI herumgeschlagen. Dabei war es recht interessant zu beobachten, was kleine Änderungem am C-Code für Auswirkungen haben können. Da das ganze recht lang ist und auch ein paar Bilder dabei sind, werde ich das nicht hier reinkopieren, sondern verweise mal auf: http://www.matuschek.net/atmega-spi.0.html Wenn jemand noch zusätzliches Optimierungspotenzial sieht, würde mich das unbedingt interessieren!
Ich habe gerade festgestellt, dass der Code in Beispiel 2 und 3 doch noch einen Fehler hat. Am Ende fehlt nach der Schleife noch eine Abfrage des SPIF-Bits. An den Timings ändert das aber nichts.
Hallo, mal so als Denkaufgabe: SPI mit dem Maximum, also CLK/2. Senden von 1 Byte = 8Bit Macht also 16 Takte für ein Byte. Länger darf also die SPI-Schleife nicht werden, wenn er ohne Pause senden soll. Reicht zum Datenbyte holen, auf SPI frei warten, raus zum SPI, Zähler -1 und zurück, wenn nicht Ende. Eigentlich muß man da garnicht auf das "fertig" warten, sondern könnte die Takte mit NOP ausgleichen. Macht durchaus Sinn, wenn man einen Datenburst z.B. zum ENC schickt, sowieso nichts sinnvolles in dieser Zeit machen kann und notfalls ein paar Zeilen inline.ASM einbindet. Gruß aus Berlin Michael
Ist mir auch ein Rätsel, warum die AVRs kein gepuffertes SPI haben, wie z.B. der AT89LP4052 oder C8051F330. Da kann man dann das nächste Byte schon schreiben, während das alte noch rausgeschoben wird. Peter
@Michael U: Die Variante mit den NOPs habe ich auch erwähnt. Da im ATMega-Datenblatt aber keine Informationen enthalten sind, die sagen, dass ein Datentransfer immer eine bestimmte Anzahl Taktzyklen nach Beschreiben des Datenregisters braucht, ist mir das etwas riskant. Wenn aus irgendeinem Grund nur einen Takt später gestartet wird, geht das zu sendende Byte verloren.
Hallo, @usul27: ich will es mal so ausdrücken: ein AVR würfelt nicht. ;) SPI und Takt sind fest verknüpft. Entweder er startet mit dem Takt nach dem Schreiben oder evtl. einen Takt später aufgrund des internen Aufbaus. Ich bin mir aber sicher, daß er das immer gleich macht, könnte man also testen. Gruß aus Berlin Michael
Da ich den Innenaufbau eines AVRs nicht kenne und nicht 100%ig sicher bin, dass es garantiert keine Abhängigkeiten zu anderer Peripherie gibt, ist mir die Vorstellung, dass es höchstwahrscheinlich immer gleich läuft, einfach zu wenig. Ich habe einfach schon zu viele Programme erlebt, die von falschen Annahmen ausgingen und dann Mist produzierten, daher verlasse ich mich da wirklich voll und ganz auf das, was im Datenblatt steht.
Hallo, interessant das jemand die gleichen Probleme findet. Ich hatte das schon mal vor ca 1 Monat gehabt in Verbindung mit einen ENC28j60 und habe mir Routinen geschrieben die dieses Problem bewältigen. Hier ein auszug aus meinen Sourcen, habe dann die gleiche lösung gefunden.
1 | /* -----------------------------------------------------------------------------------------------------------*/
|
2 | /*! Eine schnelle MEM->SPI Blocksende Routine mit optimierungen auf Speed.
|
3 | * \param buffer Zeiger auf den Puffer der gesendet werden soll.
|
4 | * \param Datalenght Anzahl der Bytes die gesedet werden soll.
|
5 | */
|
6 | /* -----------------------------------------------------------------------------------------------------------*/
|
7 | void SPI_FastMem2Write( unsigned char * buffer, unsigned int Datalenght ) |
8 | {
|
9 | unsigned int Counter = 0; |
10 | unsigned char data; |
11 | |
12 | // erten Wert senden
|
13 | SPDR = buffer[ Counter++ ]; |
14 | while( Counter < Datalenght ) |
15 | {
|
16 | // Wert schon mal in Register holen, schneller da der Wert jetzt in einem Register steht und nicht mehr aus dem RAM geholt werden muss
|
17 | // nachdem das senden des vorherigen Wertes fertig ist,
|
18 | data = buffer[ Counter ]; |
19 | // warten auf fertig
|
20 | while(!(SPSR & (1<<SPIF))); |
21 | // Wert aus Register senden
|
22 | SPDR = data; |
23 | Counter++; |
24 | }
|
25 | while(!(SPSR & (1<<SPIF))); |
26 | return; |
27 | }
|
@usul27
Ein echt interessanter Logikanalyser. Und auch der günstige Preis mit
34 Kanälen.
Ich habe fragen zu dem Teil, weil ich plane einen
Logicanalyser zukaufen.
- Bei aufzeichnen von Pegeln, kann man da sofort das am Bildschirm
mitverfolgen?
- Ist die Aufzeichnung auf eine bestimmte Zeit beschränkt. Also das man
75s auf Stück aufzeichnen kann.
- In der Beschreibung habe es schon zum Teil gelesen. Kann man
einstellen ab welcher Spannung es als HIGH und wann es als LOW
angezeigt werden soll?
- Signal 1 bis 0,5V LOW ab 2,5V HIGH
- Signal 2 bis 0,8V LOW ab 4,5V HIGH
- Signal 3 ...
- ...
oder
- Signal 1 bis 2V LOW ab 2V HIGH
- Signal 2 bis 4V LOW ab 4V HIGH
- Signal 3 ....
- ...
Das SPI Tuning ist auch eine interessante Sache. Bei SD Card auch
enorm wichtig.
Eine SUPER Homepage von dir. Ich schreib am WE etwas in dein Gästebuch
rein.
PS Du kannst da auch einen neuen Thread dazu aufmachen. Verlink ihn dann
aber.
@ulm8bit: Ist zwar etwas o.T., aber trotzdem mal zum Logic Analyzer - Man sieht den aktuellen Pegel direkt am Bildschirm. Macht aber bei den üblicherweise hohen Frequenzen nicht viel her. - Aufzeichnung ist auf 2kSamples/Kanal begrenzt, da aber nur State-Changes gespeichert werden, kann das bei langsamen Sachen (z.B. RS232) recht lange reichen. - High/Low Pegelschwelle kann eingestellt werden, ist aber für alle Kanäle gleich Wenn man aber z.B. 1.5V wählt, kann man trotzdem problemlos 3.3V und 5V-Sachen gleichzeitig messen Wenn du mehr zu dem Ding wissen willst, such mal nach "34-Kanal Logic Analyzer", da gab es vor 1-2 Wochen einen längeren Thread. @Dirk: Sieht wirklich so aus, als wäre deine Lösung im Prinzip gleich. Der Code sieht zwar etwas anders aus, aber der erzeugte Maschinencode dürfte vermutlich nahezu gleich sein. Da ich bisher nur den Write implementiert habe, würde mich auch mal deine READ-Routine interessieren. Laut Datenblatt, müsste dann noch schlimmer werden, da man erst das letzte empfangene Byte lesen muss und dann wieder eins schreiben muss, um einen neuen Takt auf der Clock-Leitung zu erzeugen. Also ist wohl die Pause zwischen 2 Bytes noch einen Takt länger - oder?
In der tat ist hier di optimierung etwas schwerer. Wie man untern sieht gibt eigentlich nur zwei möglichkeiten. Auf einen ATmega32 gehen beide. Standartkonform ist aber nur eine bei der zuerst SPDR ausgelesen wird und dann das nächste dummy gesendet wird. Man kann das auch anders herum machen, zuerst SDPR bescheiben und gleich danach den Puffer auslesen. Interessantweise geht das auf besagten Controller, aber wie es auf anderen aussieht weis ich nicht. Anbei der Code.
1 | /* -----------------------------------------------------------------------------------------------------------*/
|
2 | /*! Eine schnelle SPI->MEM Blockempfangroutine mit optimierungen auf Speed.
|
3 | * \warning Auf einigen Controller laufen die Optimierungen nicht richtig. Bitte teil des Sourcecode der dies verursacht ist auskommentiert.
|
4 | * \param buffer Zeiger auf den Puffer wohin die Daten geschrieben werden sollen.
|
5 | * \param Datalenght Anzahl der Bytes die empfangen werden sollen.
|
6 | */
|
7 | /* -----------------------------------------------------------------------------------------------------------*/
|
8 | void SPI_FastRead2Mem( unsigned char * buffer, unsigned int Datalenght ) |
9 | {
|
10 | unsigned int Counter = 0; |
11 | unsigned char data; |
12 | |
13 | // dummywrite
|
14 | SPDR = 0x00; |
15 | |
16 | while( Counter < Datalenght ) |
17 | {
|
18 | // warten auf fertig
|
19 | while(!(SPSR & (1<<SPIF))); |
20 | |
21 | // einfache Optimierung
|
22 | // Daten einlesen in Register
|
23 | data = SPDR; |
24 | // dummy-write
|
25 | SPDR = 0x00; |
26 | |
27 | /* // bessere Optimierung, aber nicht auf jeden controller
|
28 | // dummy-write
|
29 | SPDR = 0x00;
|
30 | // Daten einlesen in Register
|
31 | data = SPDR;
|
32 | */
|
33 | // Register speichern
|
34 | buffer[ Counter++ ] = data; |
35 | }
|
36 | while(!(SPSR & (1<<SPIF))); |
37 | return; |
38 | }
|
So in etwas hatte ich mir das auch vorgestellt. Ich werde mal die Variante ohne Optimierung nehmen, ich bleibe gerne auf der sicheren Seite.
Ich habe mal geschaut und überlegt, die richtige Optimierung sollte auch gehen. Wenn SPI mit halben Controller-Takt läuft hat man genau 2 Taktzyklen Zeit bis das erste Bit in den SPI-Puffer geshiftet wird, sollte also gemnach auf jeden Controller gehen.
ATmega48/88/168 hat "USART in SPI Mode" das doppelt-gepuffert ist (sage ich das richtig auf Deutch?), also könnte theoretisch schneller werden...
Hallo,habe die Variante mit den NOPs getestet. Nach dem Senden eines Bytes(16 Takte) muß 2 Takte gewartet werden ehe das nächste Byte gesendet werden kann. Sonst verschluckt sich das SPI-Interface Macht am Ende 18 CPU-Takte pro Byte.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.