Ritchie
09.04.2013, 11:44
Hallo Zusammen,
ich habe derzeit immer noch Ärger mit meiner SPI Verbindung zwischen einem Atmega644 (20MHz) und einem Atmega8 (16Mhz).
Selbst wenn ich die Taktrate des Bus auf f/128 setze, habe ich zeitweise Aussetzer.
Ich verwende hier die folgende Routine (https://www.roboternetz.de/community/threads/61494-Verständnisfrage-zur-SPI-Kommunikation?p=575383&viewfull=1#post575383)
Ich habe diese Routinen teilweise optimiert, kann aber den Fehler immer noch nicht eingrenzen.
Klar ist, das das Programm am Slave
//Slave transmitter ================================================== ==========================
if(m_buffer_adr != NULL) // Buffer set up ?
{
if(m_NumberOfBytesToSend > 0) // do we have to send bytes still
{
SPDR = *m_buffer_adr; // send the data byte
m_buffer_adr++; // get the next byte of the buffer
m_NumberOfBytesToSend--; // dec. counter of byte to send
}
else
{
m_buffer_adr=NULL; // Clear Buffer Pointer
SPDR=0x0; // No more values in the buffer
}
}
else
{
m_buffer_adr=NULL; // Clear Buffer Pointer
SPDR=0x0; // No more values in the buffer
}
in den Bereich
m_buffer_adr=NULL; // Clear Buffer Pointer
SPDR=0x0;
kommt. Obwohl Daten zu übertragen sind. In der Anzeige ändert sich der Anzeigewert dann auf 0.
Hier könnte sein, das
a) mir ein Zeichen am Master unterwegs verloren geht
b) der Slave ein Kommando nicht mitbekommt und somit
den Adresspointer nicht setzt/falsch setzt.
Hat jemand noch eine Idee, wie ich der Sache näher komme.
Info zur Hardware.
- Bis jetzt habe ich nur die SPI Verbindung auf meiner Steuerplatine in Betrieb genommen.
Hierbei sind die Leitung auf der Platine ca. 2-3 cm. lang.
Die Leitungen verlaufen aber noch zu zwei Stecker (ca. nochmals 3cm)
- Ich habe keine Pull-Ups oder Serienwiderstände in die MISO/MOSI/CLK eingebaut.
- Ich habe Software-Pullups mal eingeschaltet und mal nicht zu Testzwecken
(ohne Erfolg)
Ein Logikanalyser zeigt mir meist korrekte Werte an, da hier aber sehr viele Protokolle laufen,
ist es schwer den Wert zu treffen. Es scheinen aber Bit verloren zu gehen oder die Übertragung
nicht mehr Synchron zu laufen.
Gruss R.
ich habe derzeit immer noch Ärger mit meiner SPI Verbindung zwischen einem Atmega644 (20MHz) und einem Atmega8 (16Mhz).
Selbst wenn ich die Taktrate des Bus auf f/128 setze, habe ich zeitweise Aussetzer.
Ich verwende hier die folgende Routine (https://www.roboternetz.de/community/threads/61494-Verständnisfrage-zur-SPI-Kommunikation?p=575383&viewfull=1#post575383)
Ich habe diese Routinen teilweise optimiert, kann aber den Fehler immer noch nicht eingrenzen.
Klar ist, das das Programm am Slave
//Slave transmitter ================================================== ==========================
if(m_buffer_adr != NULL) // Buffer set up ?
{
if(m_NumberOfBytesToSend > 0) // do we have to send bytes still
{
SPDR = *m_buffer_adr; // send the data byte
m_buffer_adr++; // get the next byte of the buffer
m_NumberOfBytesToSend--; // dec. counter of byte to send
}
else
{
m_buffer_adr=NULL; // Clear Buffer Pointer
SPDR=0x0; // No more values in the buffer
}
}
else
{
m_buffer_adr=NULL; // Clear Buffer Pointer
SPDR=0x0; // No more values in the buffer
}
in den Bereich
m_buffer_adr=NULL; // Clear Buffer Pointer
SPDR=0x0;
kommt. Obwohl Daten zu übertragen sind. In der Anzeige ändert sich der Anzeigewert dann auf 0.
Hier könnte sein, das
a) mir ein Zeichen am Master unterwegs verloren geht
b) der Slave ein Kommando nicht mitbekommt und somit
den Adresspointer nicht setzt/falsch setzt.
Hat jemand noch eine Idee, wie ich der Sache näher komme.
Info zur Hardware.
- Bis jetzt habe ich nur die SPI Verbindung auf meiner Steuerplatine in Betrieb genommen.
Hierbei sind die Leitung auf der Platine ca. 2-3 cm. lang.
Die Leitungen verlaufen aber noch zu zwei Stecker (ca. nochmals 3cm)
- Ich habe keine Pull-Ups oder Serienwiderstände in die MISO/MOSI/CLK eingebaut.
- Ich habe Software-Pullups mal eingeschaltet und mal nicht zu Testzwecken
(ohne Erfolg)
Ein Logikanalyser zeigt mir meist korrekte Werte an, da hier aber sehr viele Protokolle laufen,
ist es schwer den Wert zu treffen. Es scheinen aber Bit verloren zu gehen oder die Übertragung
nicht mehr Synchron zu laufen.
Gruss R.