SPI-Kommunikation Atmega644 - ADS1118

[Eros (Gast)]

Guten Tag

Ich versuche die SPI Kommunikation zwischen einem 16-Bit ADC von TI - 
genauer der ADS1118 - und meinem ATMEGA644 zum Laufen zu bringen. Das 
Schicken der Daten funktioniert einwandfrei, allerdings scheint der ADC 
einfach keine Daten ausspucken zu wollen. Habe auch bereits mit dem 
Logic Analyzer nachgemessen, Clock vorhanden, Daten gehen raus, MISO 
bleibt tot. Die Hardwareverbindungen habe ich schon mehrmals 
nachgemessen und überprüft, sogar mal den ADC ersetzt... Ohne Erfolg, da 
tut sich nichts.

Aussschnitt main.c:

int main(void)
{
   uint16_t u16_measval;

   AdcExt_Init();
   u16_measval = AdcExt_Read();
}

Ausschnitt DrvAdc.c:

void AdcExt_Init(void)
{  
  // SPI enable
  SPIInit(ENABLE_SPI);
  
  // CS auf Low ziehen um ADC zu enablen
  DEF_EADC_SEL;
  CLR_EADC_SEL;
  _delay_ms(1000);
  _delay_us(3);
  
  // Die zwei Bytes für das Konfigurationsregister des ADCs schicken.
  SPITransmit(CONFIG_MSB);
  SPITransmit(CONFIG_LSB);
  
  // SPI Interface resetten
  SET_EADC_SEL;
  
  // SPI disable
  SPIInit(DISABLE_SPI);
}
uint16_t AdcExt_Read(void)
{
  uint16_t u16_measVal;
  uint8_t u8_adcDataRegMSB, u8_adcDataRegLSB, u8_adcConfigRegMSB, u8_adcConfigRegLSB;
  
  // SPI enable
  SPIInit(ENABLE_SPI);
  
  // CS auf Low ziehen um ADC zu enablen
  DEF_EADC_SEL;
  CLR_EADC_SEL;
  _delay_us(3);

  
  u8_adcDataRegMSB = SPIReceive(CONFIG_MSB);
  u8_adcDataRegLSB = SPIReceive(CONFIG_LSB);

  
  // SPI Interface resetten
  SET_EADC_SEL;
  
  // SPI disable
  SPIInit(DISABLE_SPI);
  
  // 16-Bit Wert aus zwei 8-Bit Werten zusammenstellen
  u16_measVal = ((uint16_t)u8_adcDataRegMSB << 8) | u8_adcDataRegLSB;
  
  return u16_measVal;
}

Ausschnitt aus DrvAdc.h:

// Konfigurationsregister des externen ADC
#define CONFIG_MSB 0xC3    // Bits 15-8 des Config Registers des ADS1118, AIN0 enabled, Singleshot Mode, Mode Bit 1, FSR +/- 4.096 V
#define CONFIG_LSB 0x8A    // Bits 7-0 des Config Registers des ADS1118, 128SPS, ADC Mode enabled, Pullup Resistor enabled

Ausschnitt aus SPI.c:

#include <avr/io.h>
#include <util/delay.h>

uint8_t SPITransmitting;
uint8_t gudt_ReceivedData;

void SPIInit(uint8_t u8_SPE)
{
  // MOSI, SCK, und SS pins als Ausgänge definieren
  DDRB |= (1 << PB5) | (1 << PB7) | (1 << PB4); 
  
  // MISO als Eingang definieren
  DDRB &= ~(1 << PB6);
  
  // SPI Register initialisieren
  SPCR =  (0 << SPIE)    |  // SPI Interrupt enable
      (u8_SPE << SPE)  |  // SPIE Enable
      (0 << DORD)    |  // Data order      --> 1 = LSB first, 0 = MSB first
      (1 << MSTR)    |  // Master/Slave select  --> 1 = Master Mode, 0 = Slave
      (0 << CPOL)    |  // Clock Polarity    --> 1 = SCK high when idle, 0 = SCK low when idle
      (0 << CPHA)    |  // Clock Phase      --> 1 = Sample on Trailing Edge, 0 = Sample on Leading Edge
      (0 << SPR1)    |  // SPI Clock Rate Select
      (1 << SPR0);    // f_osc/8
  SPSR = 1;          // Sets SPI2X Double Speed bit. SCK Frequency will be doubled when the SPI is in Master mode
  
  // Die aktuellen Einstellungen löschen das SPI Interrupt Flag im Register SPSR,
  // also wird das globale Flag genutzt um zu signalisieren, dass noch keine Übertragung stattfindet
  SPITransmitting = 0;
}

void SPITransmit(uint8_t data)
{
  // Globales Flag abfragen, ob gerade eine Übertragung stattfindet
  if (SPITransmitting)
  {
    while ( ! (SPSR & (1 << SPIF)));  // Warten bis aktuelle Übertragung abgeschlossen
  }
  SPDR = data;        // Übertragung starten
  SPITransmitting = 1;  // Mit dem Flag kennzeichnen, dass eine Übertragung in Arbeit ist
}

uint8_t SPIReceive(uint8_t data)  // data ist in der Regel ein dummy byte --> 0
{
  if (SPITransmitting)
  {
    while ( ! (SPSR & (1 << SPIF)));  // Warten bis aktuelle Übertragung abgeschlossen
  }
  _delay_us(3);

  
  SPDR = data;              // Bidirektionalen Transfer starten
  while ( ! (SPSR & (1 << SPIF)));    // Warten bis Übertragung abgeschlossen
  
  // Die aktuellen Einstellungen löschen das SPI Interrupt Flag im Register SPSR,
  // also wird das globale Flag genutzt um zu signalisieren, dass noch keine Übertragung stattfindet
  SPITransmitting = 0;
  return SPDR;
}

Ausschnitt aus DrvGPIO.h:

/*********** PA4 ALS AUSGANG DEFINIEREN FÜR ADC CS ***************/
#define EADC_SEL    (1<<PA4)
#define DEF_EADC_SEL  DDRA  |= EADC_SEL
#define SET_EADC_SEL  PORTA |= EADC_SEL
#define CLR_EADC_SEL  PORTA &=~EADC_SEL

Der Chip Select funktioniert, das habe ich bereits nachgemessen. Gemäss 
Datenblatt S.25 des ADCs müsste ein 16Bit-Transmission Cycle genau so 
funktionieren. Ich schicke das MSB des Konfigurationsregisters und 
müsste das MSB des Dataregisters auslesen können. Danach schicke ich das 
LSB des Konfigurationsregisters, um direkt im Anschluss das LSB des 
Dataregisters auslesen zu können. Das Senden funktioniert einwandfrei, 
allerdings bleibt DOUT vom ADC stets low. Gemäss Datasheet bedeutet das, 
dass DANN Daten zum abholen anliegen müssten. Allerdings kann ich mit 
dem Logic Analyzer keine Datenübertragung feststellen. Gar nichts. Das 
macht in meinen Augen keinerlei Sinn und ich werkel nun schon seit einer 
Woche daran. Nichts tut sich. Vielleicht hat einer von euch eine Idee 
oder kann mir sagen, was genau ich falsch mache.

[Mitlesa (Gast)]

Eros schrieb:
> Vielleicht hat einer von euch eine Idee
> oder kann mir sagen, was genau ich falsch mache.

Nach dem Datenblatt auf Seite 26 und folgende musst du den ADC
erst mal konfigurieren.

Im Einschaltzustand befindet sich der Chip im Single-Shot-Mode
den du auch per Kommando erst auslösen musst. Einfach mal das
Datenblatt lesen. Manchen Leute sagen auch RTFM.

[Mitlesa (Gast)]

Sorry ich war ein wenig zu voreilig. Du willst ja erst mal
das Config-Register nur zurückbekommen ....

Zeig doch mal deinen Aufbau und das Schaltbild dazu.

[Mitlesa (Gast)]

Eros schrieb:
> SPIInit(ENABLE_SPI);

Das ist gefährlich, da undurchsichtig. Du verwendest ENABLE_SPI
direkt als Variable in der Initialisierung der Bits. Du hast
auch nicht die Definition davon angegeben. Allgemein ist es un-
günstig nur Codefragemente zu zeigen. Zeige deinen volständigen
Code und poste ihn als Anhang.

[Sascha W. (sascha-w)]

@Eros,

ohne jetzt das DB gelesen zu haben. Bei SPI findet eine Transaktion 
immer zwischen CS=L und CS=H statt. Das heißt wenn du ein Register lesen 
willst sendest du hier eben die Adresse mit 2 Byte und anschließend 2 
Dummybytes um die 16Bit des Registers zu lesen. Der Bus überträgt immer 
Daten in beide Richtungen zur gleichen Zeit.

Sascha

[Eros (Gast)]

Erstmal danke an alle für die raschen Antworten.

>Nach dem Datenblatt auf Seite 26 und folgende musst du den ADC
>erst mal konfigurieren.

Das ist eigentlich genau DAS, was ich in meiner Funktion AdcExt_Init 
mache:

 // Die zwei Bytes für das Konfigurationsregister des ADCs schicken.
  SPITransmit(CONFIG_MSB);
  SPITransmit(CONFIG_LSB);

Das sich der ADC im Einschaltmodus in einem Defaultzustand befindet ist 
mir durchaus bewusst.

>Sorry ich war ein wenig zu voreilig. Du willst ja erst mal
>das Config-Register nur zurückbekommen ....

Nicht ganz. Ich versuche eine an AIN0 angelegte Spannung auszulesen. Das 
Config Register muss ich dafür nicht auslesen. Daher nur die 
16-Bit-Transmission. Allerdings wäre ich mal froh überhaupt IRGENDWAS 
zurückzulesen.

Schaltbild ist eigentlich ganz simpel:
ADS1118  ATMEGA644
DOUT     MISO
DIN      MOSI
SCK      SCK
CS       PA4

Mehr ist da nicht.

>Das ist gefährlich, da undurchsichtig. Du verwendest ENABLE_SPI
>direkt als Variable in der Initialisierung der Bits. Du hast
>auch nicht die Definition davon angegeben. Allgemein ist es un-
>günstig nur Codefragemente zu zeigen. Zeige deinen volständigen
>Code und poste ihn als Anhang.

Okay undurchsichtig, das macht sicherlich Sinn. ENABLE_SPI ist 1 und 
DISABLE_SPI ist 0. Die sind im Header des SPI Treibers definiert, das 
habe ich vergessen reinzukopieren. Grundsätzlich kann ich schon den 
ganzen Code hochladen, bin mir aber ziemlich sicher, dass es Aufwändiger 
ist, sich durch den Quellcode zu arbeiten. Aber wenn das hilft nur allzu 
gerne.

>Das heißt wenn du ein Register lesen willst sendest du hier eben die >Adresse mit 
2 Byte und anschließend 2 Dummybytes um die 16Bit des Registers >zu lesen.

Das heisst ich sollte es mal so versuchen:

 // Konfigurationsregister
SPITransmit(CONFIG_MSB);
SPITransmit(CONFIG_LSB);
// Dummy Bytes
u8_adcDataRegMSB = SPIReceive(0x0);
u8_adcDataRegLSB = SPIReceive(0x0);

Macht das Sinn? Das wäre dann aber eine 32-Bit-Transmission, die gemäss 
Datasheet SO funktioniert wie im angehängten JPG. Ergo wären dann in 
meinen Variablen u8_adcDataRegMSB/LSB ja dann einfach nur das 
zurückgelesene ConfigRegister. Ich will ja aber das DataRegister. In 
meinen Augen macht das, was TI da in das Datenblatt schreibt 
grundsätzlich wenig Sinn für mich. Es mag sein, dass das Register vom 
ADC beim Aufstarten Defaultwerte annimmt. Die interessieren ja aber 
erstmal nicht. Gemäss Bild müsste ich ja dann bei der SPI Übertragung 
einerseits das MSB vom Konfigurationsregister übertragen und 
gleichzeitig bereits schon das MSB des Datenregisters erhalten. Woher 
will denn der ADC wissen, was er da nun zu übertragen hat, wenn er noch 
nichtmal das LSB vom Konfigurationsregister erhalten hat? Das erscheint 
mir ein wenig unlogisch..

[S. Landolt (Gast)]

Vorab: diese kunstvoll-künstliche Aufspaltung von SPI in -Transmit und 
-Receive ist mir zu undurchsichtig und ich halte sie für schlecht; es 
gibt nur doch, sozusagen, nur ein 'SPItransceive'.
  Es mag also sein, dass ich das falsch verstehe, aber:

  SPITransmit(CONFIG_LSB);
  
  // SPI Interface resetten
  SET_EADC_SEL;

Hier wird mitten in der Übertragung das /CS high gesetzt, oder?

[Sascha W. (sascha-w)]

ok, ich dachte du willst das Configregister zurücklesen. Da das Teil 
aber nur das eine Configregister hat passt das mit dem 16Bit Transfer 
mit dem das Configr. geschrieben und gleichzeitig das Datenregister 
gelesen wird.

was mich allerdings sutzig macht ist Punkt 9.5.5, dort wird auf 
DOUT/DRDY (ganz SPI unüblich) das vorliegen neuer Daten signalisiert. 
Was passiert wenn man vor DRDY Daten lesen will konnte ich auf die 
Schnelle nicht finden.

Sascha

[Mitlesa (Gast)]

S. Landolt schrieb:
> Hier wird mitten in der Übertragung das /CS high gesetzt, oder?

Ja richtig, denn er wartet nach dem Schreiben nicht auf das
gelöschte Busy-Flag im Statusregister.

[S. Landolt (Gast)]

Ich hätte es als "gesetztes Ready-Flag" bezeichnet, aber wir meinen 
dasselbe, SPIF.

[Mitlesa (Gast)]

S. Landolt schrieb:
> Ich hätte es als "gesetztes Ready-Flag" bezeichnet, aber wir meinen
> dasselbe, SPIF.

Ja hab mich fehlerhaft ausgedrückt.

Eigentlich müsste so eine Funktion ausreichen, Lesen und Schreiben.

uint8_t SPITransfer (uint8_t data)
{
  SPDR = data;       // Bidirektionalen Transfer starten
  while ( ! (SPSR & (1 << SPIF)));  // Warten bis Transfer abgeschlossen
  return SPDR;
}

[S. Landolt (Gast)]

Genau!
  Alles andere mag für Spezialisten sein, die ein paar Systemtakte 
einsparen wollen/müssen.

[S. Landolt (Gast)]

Es bleiben allerdings Fragezeichen:

> Das Schicken der Daten funktioniert einwandfrei
> Habe auch bereits mit dem Logic Analyzer nachgemessen
> Das Senden funktioniert einwandfrei

[Eros (Gast)]

Mitlesa schrieb:
> Eigentlich müsste so eine Funktion ausreichen, Lesen und Schreiben.
> uint8_t SPITransfer (uint8_t data)
> {
>   SPDR = data;       // Bidirektionalen Transfer starten
>   while ( ! (SPSR & (1 << SPIF)));  // Warten bis Transfer abgeschlossen
>   return SPDR;
> }

Das ist genau das, was ich in meiner Funktion "SPITransmit" mache:

void SPITransmit(uint8_t data)
{
  // Globales Flag abfragen, ob gerade eine Übertragung stattfindet
  if (SPITransmitting)
  {
    while ( ! (SPSR & (1 << SPIF)));  // Warten bis aktuelle Übertragung abgeschlossen
  }
  SPDR = data;        // Übertragung starten
  SPITransmitting = 1;  // Mit dem Flag kennzeichnen, dass eine Übertragung in Arbeit ist
}

In der Funktion "SPIReceive" genau so:

uint8_t SPIReceive(uint8_t data)  // data ist in der Regel ein dummy byte --> 0
{
  if (SPITransmitting)
  {
    while ( ! (SPSR & (1 << SPIF)));  // Warten bis aktuelle Übertragung abgeschlossen
  }
  _delay_us(3);

  
  SPDR = data;              // Bidirektionalen Transfer starten
  while ( ! (SPSR & (1 << SPIF)));    // Warten bis Übertragung abgeschlossen
  
  // Die aktuellen Einstellungen löschen das SPI Interrupt Flag im Register SPSR,
  // also wird das globale Flag genutzt um zu signalisieren, dass noch keine Übertragung stattfindet
  SPITransmitting = 0;
  return SPDR;
}

Somit wird durchaus gewartet, bis das Flag im Status Register gesetzt 
ist, bevor ich den CS wieder auf high setze. Das Senden der Daten 
funktioniert einwandfrei und kann auch genau so nachgemessen werden. 
Zurück kommt trotzdem nichts. MISO bleibt low.

Grundsätzlich sehe ich das aber genau so, die Aufspaltung der Funktionen 
Receive und Transmit macht wenig Sinn, da beim Senden ja gleichzeitig 
immer auch etwas empfangen wird. Eine Funktion SPITransceive würde 
sicherlich mehr Sinn machen.

Dennoch löst es das Problem leider nicht. Der ADC scheint seine Daten 
nicht ausspucken zu wollen.

[Eros (Gast)]

Sascha W. schrieb:
> was mich allerdings sutzig macht ist Punkt 9.5.5, dort wird auf
> DOUT/DRDY (ganz SPI unüblich) das vorliegen neuer Daten signalisiert.
> Was passiert wenn man vor DRDY Daten lesen will konnte ich auf die
> Schnelle nicht finden.

Unter Punkt 9.5.7.2 steht:
If Config Register data are not required to be readback, the ADS1118 
conversion data can also be clocked out in
a short 16-bit data transmission cycle, as shown in Figure 42. 
Therefore, CS must be taken high after the 16th
SCLK cycle. Taking CS high resets the SPI interface. The next time CS is 
taken low, data transmission starts
with the currently buffered conversion result on the first SCLK rising 
edge. If DOUT/DRDY is low when data
retrieval starts, the conversion buffer is already updated with a new 
result. Otherwise, if DOUT/DRDY is high, the
same result from the previous data transmission cycle is read.

Das bedeutet wenn ich Daten lesen will, bevor DRDY low geht, werde ich 
wieder dasselbe Resultat wie im vorherigen Conversion Cycle zurücklesen, 
die Daten sind dann also nicht aktuell. Figure 42 ist übrigens das JPG, 
dass ich oben gepostet habe mit dem 16 Bit Übertragungszyklus.

Grundsätzlich ist es genau das, was ich mache:
 -AdcExt_Init aufrufen, daher wird CS low gesetzt, die 16-Bit für das 
Config
  Register geschickt, CS wieder high gesetzt
 -AdcExt_Read aufrufen, CS wird wieder low gesetzt, dann schicke ich 
erneut
  dieselben Daten für das Config Register (damit der ADC für die nächste
  Conversion bereits richtig initialisiert ist) und versuche dabei das
  Dataregister auszulesen, von dort kommt allerdings nichts. Nach der
  Übertragung setze ich CS wieder high..

[Mitlesa (Gast)]

Eros schrieb:
> Das ist genau das, was ich in meiner Funktion "SPITransmit" mache

Nein! Und nochmals nein.

In SPITransmit(...) wartest du erst auf das Statusregister, dann
schreibst du ins Datenregister. Aber dir ist nicht bewusst dass
die Hardware erst den 8-Bit Transfer startet wenn das Register
beschrieben ist. Noch während die Hardware die 8 Bit überträgt
reisst du nach Rückkehr aus dieser Funktion am Chip Select (machst
ihn inaktiv, also high) und deaktivierst damit den ADS1118 der
noch mit Empfangen des Datenstroms beschäftigt ist.

Insofern ist Landolts Bermerkung haarscharf richtig:

S. Landolt schrieb:
> Hier wird mitten in der Übertragung das /CS high gesetzt, oder?

Deswegen gilt auch der Ablauf meiner vorgeschlagenen SPI-Transfer
Funktion als korrekt:

- SPI Datenregister schreiben
- SPI Statusregister abwarten
- (Rückkehr aus Funktion)
- Chip Select deaktivieren

[S. Landolt (Gast)]

> Das ist genau das, was ich in meiner Funktion "SPITransmit" mache
Das sollten Sie sich nochmals genauer anschauen; und auch den 
Logikanalysator zu Rate ziehen.

[S. Landolt (Gast)]

Hier Mitlesas Vorschlag in der Nomenklatur von Microchip (aus TB3215):

{
uint8_t SPI0_exchangeData(uint8_t data)
{
SPI0.DATA = data;
while (!(SPI0.INTFLAGS & SPI_IF_bm)) /* waits until data is exchanged*/
{
;
}
return SPI0.DATA;
}
}

[Eros (Gast)]

Mitlesa schrieb:
> In SPITransmit(...) wartest du erst auf das Statusregister, dann
> schreibst du ins Datenregister. Aber dir ist nicht bewusst dass
> die Hardware erst den 8-Bit Transfer startet wenn das Register
> beschrieben ist. Noch während die Hardware die 8 Bit überträgt
> reisst du nach Rückkehr aus dieser Funktion am Chip Select (machst
> ihn inaktiv, also high) und deaktivierst damit den ADS1118 der
> noch mit Empfangen des Datenstroms beschäftigt ist.

Ihr habt absolut Recht. Die Funktion SPITransmit wird verlassen, noch 
bevor gewartet wird dass SPIF gesetzt wird.

Ich habe nun das hier übernommen

uint8_t SPITransfer (uint8_t data)
{
  SPDR = data;       // Bidirektionalen Transfer starten
  while ( ! (SPSR & (1 << SPIF)));  // Warten bis Transfer abgeschlossen
  return SPDR;
}

Dann rufe ich zunächst AdcExt_Init auf, um das Konfigurationsregister zu 
setzen:

void AdcExt_Init(void)
{  
  // SPI enable
  SPIInit(ENABLE_SPI);
  
  // CS auf Low ziehen um ADC zu enablen
  DEF_EADC_SEL;
  CLR_EADC_SEL;
  _delay_ms(1000);
  _delay_us(3);
  
  // Die zwei Bytes für das Konfigurationsregister des ADCs schicken.
  SPITransfer(CONFIG_MSB);
  SPITransfer(CONFIG_LSB);
  
  // SPI Interface resetten
  SET_EADC_SEL;
  
  // SPI disable
  SPIInit(DISABLE_SPI);
}

Im Anschluss dann AdcExt_Read, um die Daten zurückzulesen:

uint16_t AdcExt_Read(void)
{
  uint16_t u16_measVal;
  uint8_t u8_adcDataRegMSB, u8_adcDataRegLSB, u8_adcConfigRegMSB, u8_adcConfigRegLSB;
  
  // SPI enable
  SPIInit(ENABLE_SPI);
  
  // CS auf Low ziehen um ADC zu enablen
  DEF_EADC_SEL;
  CLR_EADC_SEL;
  _delay_us(3);

  
  u8_adcDataRegMSB = SPITransfer(CONFIG_MSB);
  u8_adcDataRegLSB = SPITransfer(CONFIG_LSB);

  
  // SPI Interface resetten
  SET_EADC_SEL;
  
  // SPI disable
  SPIInit(DISABLE_SPI);
  
  // 16-Bit Wert aus zwei 8-Bit Werten zusammenstellen
  u16_measVal = ((uint16_t)u8_adcDataRegMSB << 8) | u8_adcDataRegLSB;
  
  return u16_measVal;
}

Das Resultat bleibt allerdings dasselbe. Es findet kein Datenaustausch 
statt. Nun müsste der Transfer ja abgeschlossen sein, wenn ich CS wieder 
high ziehe oder?

Ich kann mit dem Logikanalyzer erkennen, dass Daten rausgehen.. Aber 
zurück kommt nichts.

Ich habe mal das Bild hochgeladen
D0 ist SCLK
D1 ist MISO
D2 ist MOSI hier sieht man auch, dass offenbar Daten rausgehen
D3 ist aktuell nicht belegt.

[Mitlesa (Gast)]

Sorry aber mit diiser Unsitte dauernd SPIInit() aufzurufen
bringst du die Konsistenz deiner Hardware völlig ausser Tritt.

SPIInit() ruft man einmal beim Programmstart auf und dann nie
mehr!

Ebenso ist das Makro DEF_EADC_SEL unsinning es jedesmal auszu-
führen.

Ich würde mir beim Init bereits durch Debugger oder Testprints
ansehen ob ich etwas vom Slave zurückbekomme was nicht null ist.

[Mitlesa (Gast)]

Also so etwa, mehr braucht es nicht. Die SPI Hardware muss
natürlich einmal vorher initialisiert werden.

void AdcExt_Init (void)
{
  uint8_t  temp1, temp2;

  CLR_EADC_SEL;    // CS low
  _delay_us(3);

  // Konfigurationsregister beschreiben
  temp1 = SPITransfer(CONFIG_MSB);
  temp2 = SPITransfer(CONFIG_LSB);

  SET_EADC_SEL;    // CS high

  // hier was mit temp1, temp2 machen
  // ......
}

[Patrick C. (pcrom)]

Ich kann mich irren, aber muszz MISO kein pullup haben ?
Dann geht MISO sowieso immer hoch wenn CS nicht aktiv ist

Anfangen mit einfachste comm, also nur status register auslesen

[S. Landolt (Gast)]

> nur status register auslesen

Dem schließe ich mich an, also '9.5.7.1 32-Bit Data Transmission Cycle', 
in Ergänzung von Mitlesa:

void AdcExt_Init (void)
{
  uint8_t  temp1, temp2;

  CLR_EADC_SEL;    // CS low
  _delay_us(3);

  // Konfigurationsregister beschreiben
  temp1 = SPITransfer(CONFIG_MSB);
  temp2 = SPITransfer(CONFIG_LSB);
  temp1 = SPITransfer(CONFIG_MSB);
  temp2 = SPITransfer(CONFIG_LSB);

  SET_EADC_SEL;    // CS high
}

Nun muss in temp1 0xC3 sowie in temp2 0x8A stehen.
(The Config register setting written in the first two bytes of a 32-bit 
transmission cycle is read back in the last two bytes of the same cycle)
Danach sieht man weiter.

[Mitlesa (Gast)]

S. Landolt schrieb:
> Danach sieht man weiter.

Danke sehr, S.!

[Mitlesa (Gast)]

Das Makro

DEF_EADC_SEL;

führt man auch genau einmal aus, am besten bei der 
SPI-Initialisierung.

Aber es ist natürlich im Zusammenhang mit diesen Änderungen
wichtig dass es an irgendeiner Stelle gemacht wird, was vorher
vielleicht untergegangen ist.

[Mitlesa (Gast)]

Die plötzliche Stille die jetzt gerade auftritt ist
symptomatisch für (eines wird schon zutreffen):

a) der TO hat sich aus Verzweiflung aus dem 20. Stockwerk
eines Hochhauses gestürzt und kann gesundheitsbedingt nicht
mehr antworten.

oder

b) der TO hat sein Problem gelöst und ist dermassen begeistert
über seine Leistung (die natürlich in keinster Weise mit der
Abhandlung hier im Forum koreliert!) dass er alles um sich herum
vergessen hat und nur noch mit Stolz geschwellter Brust herumläuft.

oder

c) der TO hat mal wieder keine Ahnung von

https://www.mikrocontroller.net/articles/Netiquette

im Speziellen darin dass zu einem Thread auch ein Happy End in
Form einer Erfolgs- oder Fehlmeldung gehört.

Dass man - wenn einem geholfen wurde - sich auch für die heissen
Tipps bedanken kann ist natürlich völlig abwegig darüber nach-
zudenken. Das wäre echt zu viel verlangt!

[Sascha W. (sascha-w)]

Eros schrieb:
> Ich kann mit dem Logikanalyzer erkennen, dass Daten rausgehen.. Aber
> zurück kommt nichts.
>
> Ich habe mal das Bild hochgeladen
> D0 ist SCLK
> D1 ist MISO
> D2 ist MOSI hier sieht man auch, dass offenbar Daten rausgehen
> D3 ist aktuell nicht belegt.

na immerhin zieht der AD MISO auf LOW, macht 0x0000 als Ergebnis.
Wenn du schon noch einen Kanal hast, dann klemm den doch mal an CS.

Sascha

[S. Landolt (Gast)]

Spielt zum jetzigen Zeitpunkt der Fehlersuche vielleicht keine Rolle, 
aber:

Wenn ich mir 'Figure 1. Serial Interface Timing' im Datenblatt anschaue, 
so scheint es sich um 'sample on trailing (falling) edge' zu handeln, 
was aber Eros' SPI-Initialisierung mit
> (0 << CPHA) |  // Clock Phase  --> 1 = Sample on Trailing Edge, 0 = Sample on 
Leading Edge
widerspräche.

[Eros (Gast)]

Mitlesa schrieb:
> Die plötzliche Stille die jetzt gerade auftritt ist
> symptomatisch für (eines wird schon zutreffen):
>
> a) der TO hat sich aus Verzweiflung aus dem 20. Stockwerk
> eines Hochhauses gestürzt und kann gesundheitsbedingt nicht
> mehr antworten.
>
> oder
>
> b) der TO hat sein Problem gelöst und ist dermassen begeistert
> über seine Leistung (die natürlich in keinster Weise mit der
> Abhandlung hier im Forum koreliert!) dass er alles um sich herum
> vergessen hat und nur noch mit Stolz geschwellter Brust herumläuft.
>
> oder
>
> c) der TO hat mal wieder keine Ahnung von
>
> https://www.mikrocontroller.net/articles/Netiquette
>
> im Speziellen darin dass zu einem Thread auch ein Happy End in
> Form einer Erfolgs- oder Fehlmeldung gehört.

Einen guten Morgen wünsche ich allen. Schade, dass man andere hier 
offenbar mit Aussagen wie "hat mal wieder keine Ahnung" als blöd 
hinstellen muss, nur weil die Kenntnisse im Bereich 
Microcontrollerprogrammierung noch nicht so fundiert sind und man sich 
halt dann doch irgendwann mal an Leute mit mehr Erfahrung wendet. Andere 
als Stolz und Eitel (und im selben Atemzug dann als blöd) zu bezeichnen 
und dann auch noch auf Etikette hinzuweisen ist schon next Level.

An die anderen, die ein wenig mehr Geduld haben: Ich bin gestern leider 
nicht mehr dazu gekommen, die vorgeschlagenen Tipps auszutesten, werde 
das allerdings heute noch machen und dann ein entsprechendes Feedback 
geben.

S. Landolt schrieb:
> Wenn ich mir 'Figure 1. Serial Interface Timing' im Datenblatt anschaue,
> so scheint es sich um 'sample on trailing (falling) edge' zu handeln,
> was aber Eros' SPI-Initialisierung mit
>> (0 << CPHA) |  // Clock Phase  --> 1 = Sample on Trailing Edge, 0 = Sample on
> Leading Edge
> widerspräche.

Das ist sicherlich noch ein guter Hinweis, danke dafür.

[S. Landolt (Gast)]

> ... heute noch machen ...
Na, dann besteht ja Hoffnung, das Problem in vernünftiger Zeit vom Tisch 
zu bekommen.
  Wenn ich die Vorschläge zusammenfassen darf: ein 32-bit-Transfer, und 
davon ein Bild mit dem Logikanalysator mit allen SPI-Leitungen sollte 
uns ein gutes Stück weiterbringen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Eros schrieb:
> Schaltbild ist eigentlich ganz simpel:
> ADS1118  ATMEGA644
> DOUT     MISO
> DIN      MOSI
> SCK      SCK
> CS       PA4
> Mehr ist da nicht.
Dann ist es ja einfach: Masse fehlt. Und die Versorgungsspannung...

Eros schrieb:
> Der Chip Select funktioniert, das habe ich bereits nachgemessen.
Hast du ein Oszilloskop? Oder einen Logikanalyzer?
Dann könntest du einfach mal das Timing der 4 beteiligten Signale messen 
und kontrollieren, ob es dem im Datenblatt entspricht. Solange es das 
nicht tut, kann alles passieren.

[Mitlesa (Gast)]

Eros schrieb:
> mit Aussagen wie "hat mal wieder keine Ahnung" als blöd
> hinstellen muss, nur weil die Kenntnisse im Bereich
> Microcontrollerprogrammierung noch nicht so fundiert sind

Wer lesen kann ist klar im Vorteil. Ich fasse meine Aussage
nochmal in Kurzform (man beachte den Link im hervorgehobenen
Wort):

---------------------------------------------------------------
c) der TO hat mal wieder keine Ahnung von Netiquette,
im Speziellen darin dass zu einem Thread auch ein Happy End in
Form einer Erfolgs- oder Fehlmeldung gehört.
---------------------------------------------------------------

Von einer Ahnunglosigkeit wie du sie hineininterpretierst
habe ich niemals gesprochen! Wer lesen kann ist klar im Vorteil.

[Pete K. (pete77)]

Schaltplan und Layout wären auch nicht schlecht (siehe auch den 3. 
Beitrag).

[Eros (Gast)]

So meine lieben Freunde der gepflegten Digitaltechnik.

Ich habe die Vorschläge vom Herrn Landolt wie auch von Mitlesa 
umgesetzt.

Die Übertragung ist dabei sehr einfach gehalten:

uint16_t AdcExt_Xfer(uint8_t data)
{
  SPDR = data;
  while( ! (SPSR & (1 << SPIF)));
  return SPDR;
}

In der Funktion AdcExt_Read übertrage ich die 4 Bytes:

uint16_t AdcExt_Read(void)
{
  uint16_t u16_measVal;
  uint8_t u8_adcDataRegMSB, u8_adcDataRegLSB, u8_adcConfigRegMSB, u8_adcConfigRegLSB;

  // ADC SPI ENABLEN
  ADC_ENABLE;
  
  // ADC CS auf Low ziehen um ADC zu aktivieren
  CLR_EADC_SEL;
  _delay_ms(1);
  
  u8_adcDataRegMSB = AdcExt_Xfer(CONFIG_MSB);
  u8_adcDataRegLSB = AdcExt_Xfer(CONFIG_LSB);
  u8_adcConfigRegMSB = AdcExt_Xfer(CONFIG_MSB);
  u8_adcConfigRegLSB = AdcExt_Xfer(CONFIG_LSB);

  // CS auf High ziehen um ADC zu deaktivieren
  SET_EADC_SEL;
  //ADC SPI disablen
  ADC_DISABLE;
  
  // 16-Bit Wert aus zwei 8-Bit Werten zusammenstellen
  u16_measVal = ((uint16_t)u8_adcDataRegMSB << 8) | u8_adcDataRegLSB;
  
  return u16_measVal;
}

Der ADC wird zu Beginn des Programms initialisiert und CS High gesetzt, 
damit er mir nicht ständig dazwischenschwafelt (was nämlich auch so eine 
Sache war), Dank an der Stelle an Mitlesa.

Mit dem Makro ADC Enable werden die SPI-Leitungen als Aus- bzw Eingang 
definiert (SCL/MOSI als Ausgänge, MISO als Eingang) und das Status 
Register für die SPI Kommunikation korrekt gesetzt (SPI Enable, CPHA 1, 
CPOL 0, wie im Datenblatt gefordert, danke für den Hinweis an Herrn 
Landolt). Mit dem Makro ADC_DISABLE wird SPI auch wieder disabled. Des 
weiteren war die Zeit mit 3us Delay sehr kurz, so dass es teilweise 
funktioniert hat, teilweise aber der Output zu wenig schnell geschaltet 
hat, CS noch HIGH war und das Programm bereits die Übertragung gestartet 
hat. Im Datenblatt wird angegeben, dass zwischen CS Low und Übertragung 
mindestens 100ns vergehen sollten, dachte ich wäre mit 3us mehr als 
übers Ziel hinaus. Allerdings braucht der uC ja auch seine Zeit, bis der 
Eingang schaltet. Mit 1ms Delay funktioniert es aber sehr zuverlässig.

Fazit der ganzen Geschichte: Datenaustausch im Datenblatt grundsätzlich 
richtig verstanden, allerdings eine Menge Fehler bei der Übertragung 
gemacht, was CS angeht. Teilweise bereits wieder auf High gesetzt, 
während die Übertragung lief und teilweise noch nicht auf Low während 
die Übertragung bereits lief.

Nun aber läuft es und ich denke ich konnte eine Menge über die SPI 
Kommunikation lernen. Vielen Dank an alle und ich hoffe ihr nehmt es mir 
nicht übel, wenn ich trotzdem mit Stolz geschwellter Brust herumlaufe ;)

[Falk B. (falk)]

Eros schrieb:
> Mit 1ms Delay funktioniert es aber sehr zuverlässig.

So ein Käse. Da ist was faul!

[Falk B. (falk)]

>Mit dem Makro ADC Enable werden die SPI-Leitungen als Aus- bzw Eingang
>definiert (SCL/MOSI als Ausgänge, MISO als Eingang) und das Status
>Register für die SPI Kommunikation korrekt gesetzt (SPI Enable, CPHA 1,
>CPOL 0, wie im Datenblatt gefordert,

Noch so ein Käse. Das macht man EINMALIG zum Programmstart und dann NIE 
wieder. Bei der Sache kann man sich, je nach Konstellation auch ins Knie 
schiessen, vor allem mit dem SS Ausgang. Der MUSS als Ausgang definiert 
sein, bevor das SPI als MAster aktiviert wird. Siehe Datenblatt SS Pin 
functionality.

>uint16_t AdcExt_Xfer(uint8_t data)
>{

Warum 16 Bit? SPI ist vor allem beim AVR nur 8 Bit.

[Eros (Gast)]

Falk B. schrieb:
> Noch so ein Käse. Das macht man EINMALIG zum Programmstart und dann NIE
> wieder. Bei der Sache kann man sich, je nach Konstellation auch ins Knie
> schiessen, vor allem mit dem SS Ausgang. Der MUSS als Ausgang definiert
> sein, bevor das SPI als MAster aktiviert wird. Siehe Datenblatt SS Pin
> functionality.

Da hängen noch 3 andere Bauteile am SPI, die jeweils unterschiedliche 
Konfigurationen im Status Register bekommen. Zumal ich den ADC-Treiber, 
so wie auch die Treiber der anderen Bausteine gerne so geschrieben 
hätte, dass ich sie problemlos auch in andere Projekte einbinden kann. 
Für dich mag das Käse sein, für mich macht es Sinn so.

Falk B. schrieb:
>>Mit dem Makro ADC Enable werden die SPI-Leitungen als Aus- bzw
> Eingang
>>definiert (SCL/MOSI als Ausgänge, MISO als Eingang) und das Status
>>Register für die SPI Kommunikation korrekt gesetzt (SPI Enable, CPHA 1,
>>CPOL 0, wie im Datenblatt gefordert,
>
> Noch so ein Käse. Das macht man EINMALIG zum Programmstart und dann NIE
> wieder. Bei der Sache kann man sich, je nach Konstellation auch ins Knie
> schiessen, vor allem mit dem SS Ausgang. Der MUSS als Ausgang definiert
> sein, bevor das SPI als MAster aktiviert wird. Siehe Datenblatt SS Pin
> functionality.
>
>>uint16_t AdcExt_Xfer(uint8_t data)
>>{
>
> Warum 16 Bit? SPI ist vor allem beim AVR nur 8 Bit.

Der SPI mag 8 Bit sein, der ADC ist es nicht. Scheint aber ein 
Überbleibsel meiner Aufräumaktion zu sein, da ich MSB und LSB vorher in 
dieser Funktion zusammengerechnet und zurückgegeben habe. Danke für den 
Hinweis.

[Falk B. (falk)]

Eros schrieb:
> Falk B. schrieb:
>> Noch so ein Käse. Das macht man EINMALIG zum Programmstart und dann NIE
>> wieder. Bei der Sache kann man sich, je nach Konstellation auch ins Knie
>> schiessen, vor allem mit dem SS Ausgang. Der MUSS als Ausgang definiert
>> sein, bevor das SPI als MAster aktiviert wird. Siehe Datenblatt SS Pin
>> functionality.
>
> Da hängen noch 3 andere Bauteile am SPI, die jeweils unterschiedliche
> Konfigurationen im Status Register bekommen.

Bestenfalls im Control Register, denn dort wird alles eingestellt. Mit 
Ausnahme von SPI2x. Wie sieht das MACRO aus?

> Zumal ich den ADC-Treiber,
> so wie auch die Treiber der anderen Bausteine gerne so geschrieben
> hätte, dass ich sie problemlos auch in andere Projekte einbinden kann.
> Für dich mag das Käse sein, für mich macht es Sinn so.

Jaja. Dumm nur, das DIESE Funktion NIE 16 Bit werte liefern wird. 
Bestenfalls eine übergeordnete Funktion, welche 16 Bit ADC-Werte 
ausliest.

Ich wage zu behaupten, daß mit deinem CS-Signal was nicht stimmt. 
Möglicherweise ist das Pin als EINGANG konfiguriert und du schaltest nur 
unbewußt den internen Pull-Up Widerstand ein und aus. Dann sind die 
Schaltflanke SCHNARCHLANGSAM, vor allem die steigende Flanke. Wenn da 
nicht irgend ein Leckstrom auf LOW zieht, geht das Signal nie auf LOW. 
Schau dir die Signale mit einem Oszi an, ein Logicanalyser ist hier 
blind.

[Eros (Gast)]

Falk B. schrieb:
> Bestenfalls im Control Register, denn dort wird alles eingestellt. Mit
> Ausnahme von SPI2x. Wie sieht das MACRO aus?

#define BM_ADC_SCK    0x80  //PB7
#define BM_ADC_SI    0x20  //PB5
#define BM_ADC_SO    0x40  //PB6
#define ADC_ENABLE    DDRB|=(BM_ADC_SCK|BM_ADC_SI|BM_ADC_SO);SPSR = (1<<SPI2X);SPCR = (1<<SPE)|(1<<MSTR)|(0<<SPR0)|(0<<SPR1)|(0<<CPOL)|(1<<CPHA)|(0<<DORD);gu8_Tmp=SPSR;gu8_Tmp=SPDR
#define ADC_DISABLE    SPCR = 0; PORTB &=~(BM_ADC_SCK|BM_ADC_SI|BM_ADC_SO);DDRB &= ~(BM_ADC_SCK|BM_ADC_SI|BM_ADC_SO)

Falk B. schrieb:
> Ich wage zu behaupten, daß mit deinem CS-Signal was nicht stimmt.
> Möglicherweise ist das Pin als EINGANG konfiguriert und du schaltest nur
> unbewußt den internen Pull-Up Widerstand ein und aus.

#define EADC_SEL    (1<<PA4)
#define DEF_EADC_SEL  DDRA  |= EADC_SEL
#define SET_EADC_SEL  PORTA |= EADC_SEL
#define CLR_EADC_SEL  PORTA &=~EADC_SEL

CS funktioniert meiner Meinung nach einwandfrei...

[Falk B. (falk)]

Eros schrieb:
> Falk B. schrieb:
>> Bestenfalls im Control Register, denn dort wird alles eingestellt. Mit
>> Ausnahme von SPI2x. Wie sieht das MACRO aus?
> #define BM_ADC_SCK    0x80  //PB7
> #define BM_ADC_SI    0x20  //PB5
> #define BM_ADC_SO    0x40  //PB6
> #define ADC_ENABLE    DDRB|=(BM_ADC_SCK|BM_ADC_SI|BM_ADC_SO);SPSR =
> (1<<SPI2X);SPCR =
> (1<<SPE)|(1<<MSTR)|(0<<SPR0)|(0<<SPR1)|(0<<CPOL)|(1<<CPHA)|(0<<DORD);gu8 
_Tmp=SPSR;gu8_Tmp=SPDR
> #define ADC_DISABLE    SPCR = 0; PORTB
> &=~(BM_ADC_SCK|BM_ADC_SI|BM_ADC_SO);DDRB &=
> ~(BM_ADC_SCK|BM_ADC_SI|BM_ADC_SO)

Ohjemine! Glaubst du allen Ernstes, mit diesem Makro-Unsinn irgend etwas 
sinnvolles zu bewirken? Zu allererst sollte ein Programm sauber 
strukturiert, lesbar und vor allem funktional KORREKT sein! Dann kann 
man irgendwann über Optimierungen nachdenken!

https://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung#Prinzipien_der_Optimierung

Und warum in aller Welt glaubst du, permanent die IOs umkonfigurieren zu 
müssen? Das muss man nicht! Bestenfalls die Einstellung für den SPI-Mode 
und den SPI-Taktteiler umstellen!

> Falk B. schrieb:
>> Ich wage zu behaupten, daß mit deinem CS-Signal was nicht stimmt.
>> Möglicherweise ist das Pin als EINGANG konfiguriert und du schaltest nur
>> unbewußt den internen Pull-Up Widerstand ein und aus.
> #define EADC_SEL    (1<<PA4)
> #define DEF_EADC_SEL  DDRA  |= EADC_SEL
> #define SET_EADC_SEL  PORTA |= EADC_SEL
> #define CLR_EADC_SEL  PORTA &=~EADC_SEL

Völliger Käse! Das IO-Pin für CS muss nicht dauern von Ausgang auf 
Eingang umgestellt werden!

> CS funktioniert meiner Meinung nach einwandfrei...

Jaja, meinen und glauben kann man viel. WISSEN kann man nur durch 
kritischens MESSEN! Tu das!

[Mitlesa (Gast)]

Falk B. schrieb:
> Noch so ein Käse. Das macht man EINMALIG zum Programmstart und dann NIE
> wieder. Bei der Sache kann man sich, je nach Konstellation auch ins Knie
> schiessen

Bei solchen Dingen die beharrlich zäh im Sourcecode verbleiben
drängt sich dann doch allmählich der Verdacht auf Starrsinn
bzw. Beratungsresistenz auf. Insbesondere weil bereits schon
früh darauf hingewiesen wurde.

Mitlesa schrieb:
> Sorry aber mit diiser Unsitte dauernd SPIInit() aufzurufen
> bringst du die Konsistenz deiner Hardware völlig ausser Tritt.
>
> SPIInit() ruft man einmal beim Programmstart auf und dann nie
> mehr!
>
> Ebenso ist das Makro DEF_EADC_SEL unsinning es jedesmal auszu-
> führen.

[S. Landolt (Gast)]

Ich weiß nicht - also ich sehe nur ein paar Definitionen, aber nicht, 
wie oft sie in Eros' aktuellem Programm verwendet werden.
  Und dass letzteres vermutlich alles andere als optimal ist - je nun, 
Hauptsache ist doch, dass es erstmal läuft, worüber er sich freuen kann 
(und ich mich mit ihm). Wenn er Unterstützung bei der Optimierung 
wünscht/benötigt, wird er sich schon melden.
  Dieser aufkommende leicht aggressive Unterton aber ärgert mich.

[Falk B. (falk)]

S. Landolt schrieb:
> Hauptsache ist doch, dass es erstmal läuft, worüber er sich freuen kann

Wenn er 1 MILLISEKUNDE nach dem Aktivieren des Chip select warten muss, 
damit die Übertragung "funktioniert", läuft da gehörig was schief.

>   Dieser aufkommende leicht aggressive Unterton aber ärgert mich.

Diese permanente Ignoranz gegenüber sachlicher Kritik und Hinweisen erst 
recht.

[S. Landolt (Gast)]

> permanente Ignoranz

Schließen Sie das aus diesem einen Satz von ihm
> CS funktioniert meiner Meinung nach einwandfrei...
? Da irrt er vermutlich, aber "permanente Ignoranz"? Sehe ich nicht so.

[Mitlesa (Gast)]

Meine Erkenntnis des heutigen Tages:

Probleme die auf Beratungsresistente, Starrsinnige, Ignoranten,
Unbelehrbaren beruhen bzw. zurückzuführen sind, sind weitaus
schwieriger zu lösen als massive Hardware- oder Software-Probleme
die eindeutig und klar dokumentiert sind.

[Eros (Gast)]

Unabhängig davon, was hier genau das Thema ist, ist es immer so, dass 
der Ton die Musik macht. Wenn man von sachlicher Kritik spricht, im 
selben Atemzug die Arbeit eines anderen aber als Käse und Unsinn 
bezeichnet (auch unabhängig davon, ob es nun so ist oder nicht), dann 
braucht man sich nicht wundern, wenn solches mit Starrsinn, Ignoranz 
oder Sturheit quittiert wird. Und das zieht sich so durchs ganze Leben. 
So spricht man meiner Meinung nach weder mit Angestellten, noch mit 
Vorgesetzten und schon gar nicht mit dem Lebenspartner. Aber jeder hat 
da wohl seine eigene Vorgehensweise.

Dennoch bedanke ich mich und wünsche allen einen angenehmen Start in die 
Woche. Ich denke dieser Thread hier kann geschlossen werden.