ADC über SPI

[RT (mcu-programmer)]

Hallo,

ich habe bereits viel gegoogelt, aber finde einfach keine Lösung für 
mein Problem...

Ziel: ADU Wert auslesen und an PC senden.

Hardware: Nucleo-Board mit STM32F446RE, AZDelivery UART-TTL USB Adapter 
mit CH340G und AD Wandler MCP3008

Problem: Über SPI lässt sich weder etwas an den ADU senden oder etwas 
auslesen. Das RX bzw. TX Buffer wird nach einem Lese- bzw. 
Schreibvorgang durch SPI1->DR nicht zurücksetzen.

Code:

#define SPI_Startbyte (0x1 << 7) 
#define SPI_SelectChannel   
#define SPI_RandomByte (0xFF)

// Funktionsprototypen
void sendeChar(char character);
void SPIEmpfange(uint8_t *data, int size);
void SPISende(uint8_t *data, int size);

int main(void)
{


  // Initialisierung der GPIO

  // Aktivieren der Clock für GPIO Port A
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;

  // Definition von GPIO A Pin 5, 6, 7, 9 und 10 als alternative Funktion (Für USART1 und SPI1) und Pin 8 als Output (Für CS)
  GPIOA->MODER |= GPIO_MODER_MODER5_1; // SPI1 CLK
  GPIOA->MODER |= GPIO_MODER_MODER6_1; // SPI1 MISO
  GPIOA->MODER |= GPIO_MODER_MODER7_1; // SPI1 MOSI
  GPIOA->MODER |= GPIO_MODER_MODER9_1; // USART 1 TX
  GPIOA->MODER |= GPIO_MODER_MODER10_1; // USART 1 RX
  GPIOA->MODER |= GPIO_MODER_MODER8_0; // GPIO OUTPUT

  // Definition von GPIO A Pin 5, 6 und 7 als alternative Funktion AF5
  GPIOA->AFR[0] &= ~(GPIO_AFRL_AFSEL5);
  GPIOA->AFR[0] |= GPIO_AFRL_AFSEL5_0 | GPIO_AFRL_AFSEL5_2;

  GPIOA->AFR[0] &= ~(GPIO_AFRL_AFSEL6);
  GPIOA->AFR[0] |= GPIO_AFRL_AFSEL6_0 | GPIO_AFRL_AFSEL6_2;

  GPIOA->AFR[0] &= ~(GPIO_AFRL_AFSEL7);
  GPIOA->AFR[0] |= GPIO_AFRL_AFSEL7_0 | GPIO_AFRL_AFSEL7_2;

  GPIOA->AFR[0] |= (5<<20)|(5<<24)|(5<<28);

  // Definition von GPIO A Pin 9 und 10 als alternative Funktion AF7

  GPIOA->AFR[1] |= GPIO_AFRH_AFSEL9;
  GPIOA->AFR[1] &= ~GPIO_AFRH_AFSEL9_3;

  GPIOA->AFR[1] |= GPIO_AFRH_AFSEL10;
  GPIOA->AFR[1] &= ~GPIO_AFRH_AFSEL10_3;

  //Pegel an GPIO A Pin 8 auf High, damit SPI Modul ruht, bis die Kommunikation beginnt.
  GPIOA->BSRR |= GPIO_BSRR_BS8;


  // Initialisierung des SPI
        
        // Clock für die SPI 1 Schnittstelle
  RCC->APB2ENR |= RCC_APB2ENR_SPI1EN;

  // SPI Clock Polarität (CPOL) und Phasenverschiebung (CPHA) werden eingestellt
  SPI1->CR1 &= ~SPI_CR1_CPHA_Msk;
  SPI1->CR1 &= ~SPI_CR1_CPOL_Msk;

  // Selektieren, ob es sich um einen Master oder Slave handelt
  SPI1->CR1 |= SPI_CR1_MSTR;

  // Einstellen der Baudrate = Clock des jeweiligen SPI Bus (fPCLK) / Prescaler (PSC)
  SPI1->CR1 |= SPI_CR1_BR; // 111: fPCLK/256

  // SPI1 wird aktiviert
  SPI1->CR1 |= SPI_CR1_SPE;

  // Format of the data: LSB
  SPI1->CR1 |= SPI_CR1_LSBFIRST;

  // Software Slavemanagement: 
  // SSM = SSI = 1 --> Software Slave management
  SPI1->CR1 |= SPI_CR1_SSM;
  SPI1->CR1 |= SPI_CR1_SSI;

  // SPI1->CR1 Bit 15 = 0: 2 Leitungen --> Voll-Duplex
  SPI1->CR1 &= ~(SPI_CR1_BIDIMODE_Msk);
  SPI1->CR1 &= ~(SPI_CR1_RXONLY_Msk);

  // DFF: Data frame format: 8-Bit
  SPI1->CR1 &= ~(SPI_CR1_DFF_Msk);

  // Das Register CR2 wird erstmal nicht genutzt
  SPI1->CR2 = 0;

  uint8_t initData[3] = {(uint8_t)SPI_Startbyte, (uint8_t)SPI_SelectChannel, (uint8_t)SPI_RandomByte};

  //Pegel an GPIO A Pin 8 auf Low, damit SPI Modul für die Kommunikation aktiv ist.
  GPIOA->BSRR |= GPIO_BSRR_BR8;

  // Senden der Startkonfig an SPI:
  SPISende(initData,3);

  //Pegel an GPIO A Pin 8 auf High, damit SPI Modul ruht, bis die Kommunikation beginnt.
  //GPIOA->BSRR |= GPIO_BSRR_BS8;


       // Initialisierung USART1

       // Aktivieren der Clock für USART 1 Schnittstelle
  RCC->APB2ENR |= RCC_APB2ENR_USART1EN;

  // Aktiviere/Starte USART1
  USART1->CR1 |= USART_CR1_UE;

  // 1 Start-Bit and 8 Databits and n Stopp-Bits
  USART1->CR1 &= ~USART_CR1_M;

  // Oversampling 16
        USART1->CR1 &= ~USART_CR1_OVER8_Msk;

  // Baudrate einstellen:
  USART1->BRR = 0x8B;

  // Aktiviere/Starte Sender
  USART1->CR1 |= USART_CR1_TE;

        uint8_t messDaten = 0;

  // Einfacher Test

  while(1)
  {
    GPIOA->BSRR |= GPIO_BSRR_BR8;
    SPIEmpfange(&messDaten, 1);
    GPIOA->BSRR |= GPIO_BSRR_BS8;
    sendeChar(messDaten);
    sendeChar('5');
  }
}

void SPISende(uint8_t *data, int size)
{
  int i = 0;
  while (i < size)
  {
    while (!((SPI1->SR) & (SPI_SR_TXE))){};

    SPI1->DR = data[i];

    i++;
  }

  while (!(SPI1->SR & SPI_SR_TXE)){};

  while(SPI1->SR & SPI_SR_BSY){}; 
  uint8_t temp;
  temp = SPI1->DR;
  temp = SPI1->SR; 
}

void SPIEmpfange(uint8_t *data, int size)
{
  while (size)
  {
    while(SPI1->SR & SPI_SR_BSY){};

    SPI1->DR = 0; // senden von dummy Daten

    while (!(SPI1->SR & SPI_SR_RXNE)){}; 

    *data++ = (SPI1->DR); 
    size--;
  }
}

void sendeChar(char character)
{
  USART1->DR = character;
  while(!(USART1->SR & USART_SR_TC)){;}
}

[fuck (Gast)]

RT schrieb:
> ich habe bereits viel gegoogelt

Dafür um so weniger nachgedacht bevor du gepostet hast.

Lese den Anhang, verstehe ihn, verinnerliche ihn und handle
danach.
"Längerer Sourcecode" ist es wenn man dauernd scrollen muss um
alles zu sehen. Hast du es jetzt verstanden?

[Gerald K. (geku)]

Bei SPI existieren verschiefene Modi:

https://de.m.wikipedia.org/wiki/Serial_Peripheral_Interface#:~:text=SLK%20(englisch%20Serial%20Clock)%20auch,englisch%20Master%20Output%2C%20Slave%20Input

Siehe Kapitel Protokollablauf und Einstellmöglichkeiten

Vielleicht ist im STM ein anderer Mode (Parameter „Clock Polarity“ 
(CPOL) und „Clock Phase“ (CPHA)) als beim ADC eingestellt.

[c-hater (Gast)]

Gerald K. schrieb:
> Bei SPI existieren verschiefene Modi:
>
> 
https://de.m.wikipedia.org/wiki/Serial_Peripheral_Interface#:~:text=SLK%20(englisch%20Serial%20Clock)%20auch,englisch%20Master%20Output%2C%20Slave%20Input
>
> Vielleicht ist im STM ein anderer Mode (Parameter „Clock Polarity“
> (CPOL) und „Clock Phase“ (CPHA)) als beim ADC eingestellt.

Ja. Das ist ein Problem. Ein ganz anderes (und allein auf STM-Mist 
gewachsenes) ist die Unterstützung für einen doch eher exotischen 
MultiMaster-SPI-Bus und die an völligen Schwachsinn grenzende Idee, dass 
auch noch zum Default für den SPI zu machen.

Die Typen sind doch völlig gehirnamputiert!!!

Allerdings: ob das auch bei dem genannten konkreten STM32 so verhält, 
entzieht sich derzeit meiner Kenntnis. Das möge der TO selber im 
passenden DB nachschlagen.

[Gerald K. (geku)]

c-hater schrieb:
> Allerdings: ob das auch bei dem genannten konkreten STM32 so verhält,
> entzieht sich derzeit meiner Kenntnis. Das möge der TO selber im
> passenden DB nachschlagen.

Sehe ich auch so.

[fuck (Gast)]

RT schrieb:
> SPISende(initData,3);

Das nützt erst mal gar nichts da der Wandler aktuell bei jedem
Lesen konfiguriert wird.

RT schrieb:
> void SPIEmpfange(uint8_t *data, int size)
{
   ......
}

Das ist Käse. Lies das Datenblatt auf Seite 20, dort steht was
zu tun ist: ein_ Konfigurations-Byte schreiben und danach _zwei
Bytes abholen. Tip: für jedes abzuholende Byte wird auch erst
eines geschrieben.

RT schrieb:
> #define SPI_SelectChannel

Und was soll dieses define bitte sehr?

[Purzel H. (hacky)]

Standardmaessig nimmt man irgendwelche Portpins und macht den SPI, 
genaustens gemaess Datenblatt des ADC zu Fuss.

[PittyJ (Gast)]

Bei meinem STM32H7 benutze ich:
HAL_SPI_TransmitReceive()
Das wurde von STM mitgeliefert, und funktionierte auf Anhieb.
Gibt es so etwas nicht für den STM32F, dass man alles von Hand machen 
muss?

Als nächstes würde ich ein Scope anschliessen, um zu sehen, was auf dem 
Bus los ist.

[Gerald K. (geku)]

Purzel H. schrieb:
> Standardmaessig nimmt man irgendwelche Portpins und macht den SPI,
> genaustens gemaess Datenblatt des ADC zu Fuss.

Aber erst wenn es anders nicht geht.
Aber das "studieren" des Datenblattes ist Voraussetzung für die 
Verwendung von ADC & STM. Speziell wenn man das Interface selbst 
realisiert.

[Steve van de Grens (roehrmond)]

Ich finde es einfacher, diesen ADC per Bit-Banging (also ohne SPI 
Hardware) zu benutzen.

[Peter D. (peda)]

Steve van de Grens schrieb:
> Ich finde es einfacher, diesen ADC per Bit-Banging (also ohne SPI
> Hardware) zu benutzen.

Max 3,6MHz des MCP3008 sollte selbst zu Fuß kein Problem sein. Das 
HW-SPI wäre also auch nicht schneller.

Warum will man aber einen externen 10Bit-ADC benutzen, wenn der 
STM32F446RE schon 3*12Bit-ADCs mit 24 Eingängen intern hat?

[Fillo Soof (Gast)]

Man kann viel finden um am Thema vorbei zu reden und
den Thread in die Länge zu ziehen.

[Peter D. (peda)]

Fillo Soof schrieb:
> Man kann viel finden um am Thema vorbei zu reden

Man hätte eben den Controller im Titel nennen sollen.
So ohne jede Information lockt man viele an, die z.B. den ATmega8 
kennen, aber den STM32F446RE nicht.

[Steve van de Grens (roehrmond)]

Peter D. schrieb:
> Max 3,6MHz des MCP3008 sollte selbst zu Fuß kein Problem sein. Das
> HW-SPI wäre also auch nicht schneller.

Allerdings könnte man den SPI Port theoretisch mit DMA kombinieren, 
damit die CPU während der Übertragung nicht warten muss sondern etwas 
anderes nützliches tun kann.

[M. K. (sylaina)]

Anbei meine C-Funktion um die MCP3008 bzw. MCP3208 via SPI auszulesen. 
Die MCPs verstehen SPI-Mode 0 und 1. Die sind eigentlich mega simpel zu 
verwenden und die Datenblätter sind IMHO gut beschrieben.

uint16_t getValueFromMCP(uint8_t channel, uint8_t mode){
  uint8_t message[3] = {0b100|(mode << 1)|((channel & 0b100) >> 2), (channel & 0b11) << 6, 0x00};
  uint8_t answer[3] = {0x00, 0x00, 0x00};
  spiTransferMessage(message, answer, sizeof(message)/sizeof(uint8_t), &mcp3208);
  return (uint16_t)(((answer[1] & 0x0f) << 8)|answer[2]);
}

Sollte (zusammen mit dem Datasheet des MCP) selbsterklärend sein. 
Eigentlich mega einfach.

spiTransferMessage erwartet zwei Arrays (ginge eigentlich auch eines, 
die Größe des Arrays und ein SPI-Device (sodass man weiß, welcher Pin 
der CS-Pin für das Device ist)

[RT (mcu-programmer)]

Erstmal danke an alle Antworten. Ich muss mich hier erstmal 
durcharbeiten.

[RT (mcu-programmer)]

> "Längerer Sourcecode" ist es wenn man dauernd scrollen muss um
> alles zu sehen. Hast du es jetzt verstanden?

Das ist mir wohl entgangen merke ich mir.

[RT (mcu-programmer)]

> Vielleicht ist im STM ein anderer Mode (Parameter „Clock Polarity“
> (CPOL) und „Clock Phase“ (CPHA)) als beim ADC eingestellt.

Die Modi kenne ich. Ich habe auch geschaut (Datenblatt und diverse 
Implementierungen für Raspberry Pi) und meine da die richtige 
Einstellung zu haben.

Aktuell habe ich glaube ich den falschen Pegelwandler, weshalb ich auf 
CS kein High Signal bekomme, dass der ADU erkennt. Ich hab mir die 
"richtige" Hardware bestellt und probiere es nochmal aus.

[RT (mcu-programmer)]

c-hater schrieb:
> Gerald K. schrieb:
>> Bei SPI existieren verschiefene Modi:
>>
>>

> Allerdings: ob das auch bei dem genannten konkreten STM32 so verhält,
> entzieht sich derzeit meiner Kenntnis. Das möge der TO selber im
> passenden DB nachschlagen.

Da müsste ich schauen.

[RT (mcu-programmer)]

fuck schrieb:
> RT schrieb:
>> SPISende(initData,3);
>

 Tip: für jedes abzuholende Byte wird auch erst
> eines geschrieben.
>
> RT schrieb:
>> #define SPI_SelectChannel
>
> Und was soll dieses define bitte sehr?


Vergiss das Define.

Ich hatte gedacht man schickt die 3 Byte aus dem Datenblatt und darauf 
folgen dann nur noch Bytes die erhalten werden
... Dann habe ich das falsch verstanden.

Danke

[RT (mcu-programmer)]

PittyJ schrieb:
> Bei meinem STM32H7 benutze ich:
> HAL_SPI_TransmitReceive()
> Das wurde von STM mitgeliefert, und funktionierte auf Anhieb.
> Gibt es so etwas nicht für den STM32F, dass man alles von Hand machen
> muss?
>
Ich habe das so in einem Buch gelernt und fand das eigentlich 
verständlich. Deshalb arbeite ich weiter damit.

[RT (mcu-programmer)]

Steve van de Grens schrieb:
> Ich finde es einfacher, diesen ADC per Bit-Banging (also ohne SPI
> Hardware) zu benutzen

Hmm ... So weit bin ich wohl noch nicht... Das sagt mir nichts

[RT (mcu-programmer)]

Peter D. schrieb:
> Steve van de Grens schrieb:

> Warum will man aber einen externen 10Bit-ADC benutzen, wenn der
> STM32F446RE schon 3*12Bit-ADCs mit 24 Eingängen intern hat?

Es ist eine Übung ein SPI Modul zu nutzen.

[RT (mcu-programmer)]

Peter D. schrieb:
> Fillo Soof schrieb:
>> Man kann viel finden um am Thema vorbei zu reden
>
> Man hätte eben den Controller im Titel nennen sollen.
> So ohne jede Information lockt man viele an, die z.B. den ATmega8
> kennen, aber den STM32F446RE nicht.

Merke ich mir.

[RT (mcu-programmer)]

M. K. schrieb:

> Sollte (zusammen mit dem Datasheet des MCP) selbsterklärend sein.
> Eigentlich mega einfach.

Das liegt im Auge des Betrachters:D Danke das sieht sehr hilfreich aus. 
Ich habe wohl das Prinzip von SPI nicht verstanden, aber hiermit wird 
das glaube ich.

[RT (mcu-programmer)]

M. K. schrieb:
> Anbei meine C-Funktion um die MCP3008 bzw. MCP3208 via SPI auszulesen.
> Die MCPs verstehen SPI-Mode 0 und 1. Die sind eigentlich mega simpel zu
> verwenden und die Datenblätter sind IMHO gut beschrieben.
>
>

uint16_t getValueFromMCP(uint8_t channel, uint8_t mode){
>   uint8_t message[3] = {0b100|(mode << 1)|((channel & 0b100) >> 2), 
> (channel & 0b11) << 6, 0x00};
>   uint8_t answer[3] = {0x00, 0x00, 0x00};
>   spiTransferMessage(message, answer, sizeof(message)/sizeof(uint8_t), 
> &mcp3208);
>   return (uint16_t)(((answer[1] & 0x0f) << 8)|answer[2]);
> }

>

Also das verstehe ich nicht.

Ich möchte den ADU im single-ended Mode und Channel 0 nutzen.

gemäß deinem Code wären die messages:
uint8_t message[3] = {0b100|(1 << 1)|((0 & 0b100) >> 2), (0 & 0b11) << 
6, 0x00};
uint8_t message[3] = {0b110, 0b00000000, 0x00};

ich hätte aber gedacht man müsste der Reihenfolge entsprechend:
uint8_t message[3] = {0b00000001, 0b10000000, 0x00};

Ich habe die Auslese-Funktion geändert in

void SPICommunicate(uint8_t *transmittedData, uint8_t *receivedData, int size)
{

  int i = 0;
    //Pegel an   uint8_t transmittedData[3] = {(uint8_t)SPI_Startbyte, (uint8_t)SPI_SelectChannel, SPI_RandomByte};
    // GPIO A Pin 8 auf Low, damit SPI Modul für die Kommunikation aktiv ist.

    GPIOB->BSRR |= GPIO_BSRR_BR0;
  while (i < size)
  {
    while (!((SPI1->SR) & (SPI_SR_TXE))){};
    SPI1->DR = transmittedData[i];

    receivedData[i] = SPI1->DR;

    i++;

    // Warten, bis der RX Zwischenspeicher leer ist
    while (!(SPI1->SR & SPI_SR_RXNE)){};

    // Am Anfang der Nachricht wird nochmal zur Sicherheit gewartet bis das SPI Protokoll nicht mehr beschäftigt ist!
    while(SPI1->SR & SPI_SR_BSY){};
  }

    //Pegel an GPIO B Pin 0 auf High, damit SPI Modul ruht, bis die Kommunikation beginnt.
    GPIOB->BSRR |= GPIO_BSRR_BS0;
}

Es wird kein Byte gesendet, glaube ich, weil die (SPI1->SR) & 
(SPI_SR_TXE) Register nicht zurückgesetzt werden.

[mitlesa (Gast)]

RT schrieb:
> Es wird kein Byte gesendet, glaube ich

Glauben kann man viel. Ich kanns nicht mit ansehen .....
Bring doch mal Ordnung in dein Chaos.

Hier mein Vorschlag das Ganze übersichtlich zu gestalten:

uint8_t SPI_TransferByte (uint8_t val)
{
  uint8_t ret_val;

  /*  wait for TX empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_TXE) == 0)
  { /*  wait  */  };
  SPI1->DR = (uint8_t)(val);

  /*  wait for RX not empty  */
  while ((SPI1->SR & SPI_I2S_FLAG_RXNE) == 0)
  { /*  wait  */  };
  ret_val = SPI1->DR;

  /*  wait for Busy flag not active  */
  while ((SPI1->SR & SPI_I2S_FLAG_BSY) != 0);

  return ret_val;

} /* --- SPI_TransferByte --- */

uint16_t Read_ADC (void)
{
  uint8_t   byte_low, byte_high;
  uint8_t   config_byte;
  uint16_t  adc_val;
  uint8_t   mode = 1;
  uint8_t   channel = 0;

  config_byte = 0b100|(mode << 1) | ((channel & 0b100) >> 2);

  GPIOB->BSRR |= GPIO_BSRR_BR0;      // CS aktiv
  SPI_TransferByte (config_byte);    // Konfiguration schreiben
  byte_high = SPI_TransferByte (0);  // dummy schreiben, byte holen
  byte_low = SPI_TransferByte (0);   // dummy schreiben, byte holen
  GPIOB->BSRR |= GPIO_BSRR_BS0;      // CS inaktiv

  adc_val = ( ((uint16_t)byte_high) << 8) || ( (uint16_t)byte_low);

  return  adc_val;

} /* --- Read_ADC --- */

<SPI_TransferByte > ist voll ausgetestet, bei <Read_ADC> musst
du noch geeignete Werte für mode und channel einsetzen. Vielleicht
sind da noch noch kleine Unsauberkeiten drin, aber so kann man
das Ganze wenigstens sauber überblicken.

[mitlesa (Gast)]

RT schrieb:
> return (uint16_t)(((answer[1] & 0x0f) << 8)|answer[2]);

Was glaubst du wohl was passiert bzw. was herauskommt wenn
man ein Byte achtmal nach links schiebt?

[Jupp (Gast)]

Peter D. schrieb:
> Warum will man aber einen externen 10Bit-ADC benutzen, wenn der
> STM32F446RE schon 3*12Bit-ADCs mit 24 Eingängen intern hat?

Weil sich der nur nutzen lässt, wenn der Pin nicht bereits mit einer 
anderen alternativen Funktion benutzt wird - was bei kleineren 
Pin-Counts schon mal vorkommt.
Abgesehen davon sind die fertigen Entwicklungsboards selten mit einer 
hochstabilen und sauberen Referenzspannung versehen. Die Wandler werden 
zu gern mit der Versorgungsspannung verbunden. Die Dinger bekommt man 
nie ruhig. Am Ende würde ich die 3.3V sehen, die im Verhältnis zur 
unsauberen Referenzspannung sehr gering ausfällt.
Ich nutzte auch einen diskreten 12Bit AD-Wandler, der über SPI an einen 
STM32F746 angeheftet wurde. Der lässt sich gut und stabil betreiben.

Ich habe mit bei der Programmierung des SPI an einem vorhandenen Init 
für ein Touch-Panel orientiert. Beim DMA muss man aber unbedingt auf die 
ERATA zum STM Controller achten. Die STM32 sind sehr interessante 
Cortex-M Vertreter, aber sie haben manchmal sehr üble Bugs in den ersten 
Versionen.
DMA geht manchmal nicht wie beschrieben, wenn andere Ressourcen 
zeitgleich verwendet werden. Deren Interrupt-Handling ist auch gern mal 
problematisch.
Also - sollte ein Verhalten nicht erklärbar sein, nach einem Erata 
schauen.

[M. K. (sylaina)]

RT schrieb:
> gemäß deinem Code wären die messages:
> uint8_t message[3] = {0b100|(1 << 1)|((0 & 0b100) >> 2), (0 & 0b11) <<
> 6, 0x00};
> uint8_t message[3] = {0b110, 0b00000000, 0x00};
>

Schau dir noch mal genau an, was mein Code macht. Für Kanal 0 im 
Single-Ended Mode hast du die Bytes richtig ausgerechnet aber direkt 
danach schreibst du:

RT schrieb:
> ich hätte aber gedacht man müsste der Reihenfolge entsprechend:
> uint8_t message[3] = {0b00000001, 0b10000000, 0x00};

und das ist natürlich nicht das selbe wie:

RT schrieb:
> uint8_t message[3] = {0b110, 0b00000000, 0x00};

Dass er bei dir dann aber auch gar kein Byte sendet ist direkt noch ein 
anderes/weiteres Problem. Hast du denn zumindest ein Clock-Signal? Wenn 
du das nicht hast klingt das für mich schwer danach, dass dein 
SPI-Transmitter/Master gar nicht erst arbeitet, dann musst du da noch 
mal ran.

[RT (mcu-programmer)]

Hallo,

ich hatte jetzt lange keine Zeit mich mit dem Thema zu beschäftigen und 
sitzte wieder daran.

Ich verstehe das SPI Prinzip irgendwie nicht.

Also wenn ein Bit gesendet wird, erhält man stets ein Bit zurück.

Es gibt bei der initialisierung des SPI für STM32FXX Prozessoren das 
Register SPI control register 1 (SPI_CR1).

Und dort gibt es die Bits

Bit 10 (RXONLY): Im Fall: Bit 10 = 0 --> Das SPI-Modul kann nur 
Nachrichten empfangen, Im Fall Bit 10 = 1:  Das SPI-Modul kann 
Nachrichten empfangen und senden?
Bit 14 (BIDOE): Aktiviert oder deaktiviert den Ausgang?
Bit 15 (BIMODE): Entscheidet, ob die Verbindung voll Duplex ist oder 
halbduplex?

Wenn ich jetzt nur Messwerte eines ADU auslesen möchte, welchen Wert 
müssen die oben genannten Bits haben, kann mir das einer erklären?

schöne Grüße

[C-hater (c-hater)]

RT schrieb:

> Bit 10 (RXONLY): Im Fall: Bit 10 = 0 --> Das SPI-Modul kann nur
> Nachrichten empfangen, Im Fall Bit 10 = 1:  Das SPI-Modul kann
> Nachrichten empfangen und senden?
> Bit 14 (BIDOE): Aktiviert oder deaktiviert den Ausgang?
> Bit 15 (BIMODE): Entscheidet, ob die Verbindung voll Duplex ist oder
> halbduplex?
>
> Wenn ich jetzt nur Messwerte eines ADU auslesen möchte, welchen Wert
> müssen die oben genannten Bits haben, kann mir das einer erklären?

Sollte im DB stehen. Man muß halt bloß auch den Rest lesen und nicht nur 
die Bezeichner der Bits...

Fazit: Faulschwein. Aber sowas von...

[RT (mcu-programmer)]

Ich erhalte einfach keine Antwort vom ADU, sodass der Code aus
while ((SPI1->SR & SPI_SR_RXNE) == 0){};
nicht raus kommt.

Hat einer eine Idee woran das liegt?

[RT (mcu-programmer)]

Okey jetzt habe ich den Fehler gefunden. Ich habe die SPI Einstellungen 
auf Default gesetzt, die SPI Frequenz mit dem BR Teiler so stark 
reduziert, wie im Datenblatt gefordert und Das SPI nach den 
Einstellungen aktiviert. Jetzt klappt beinahe alles wie gewollt.

Das einzige, was nicht funktioniert ist, ich kriege falsche Werte vom 
ADU.

Ich habe ein VDD = VREF = 3,3V

Somit sollte, wenn am Eingang des ADU 3,3V vorliegt den 16-Bit Wert 
65.536 erhalten. Aber ich erhalte nur ca. 50.000.

Ich frage mich woran das liegt.

Ich habe den Code angehangen. Weiß einer weiter?

[Nils S. (wall-e)]

Das ist doch ein 10-bit AD-Wandler. Der kann nur 0...1023 ausgeben.
Im Datenblatt FIGURE 6-1: SPI Communication with the MCP3004/3008 using 
8-bit segments
(Mode 0,0: SCLK idles low).

steht ganz explizit vorgegeben wie die Kommunikation aussehen soll. 
Sogar mit Beispiel. Deine SW macht m.E. was anderes.

[Nils S. (wall-e)]

Wahrscheinlich Bitreihenfolge vertauscht. In deiner SPI-Config seht "LSB 
first".
Der Chip gibt aber MSB-first aus. Wenn ich den Wert "0000 0011 1111 
1111" = 1023 in Dezimal LSB-MSB-tausche kommt ca. 49407 in Dezimal raus.

[RT (mcu-programmer)]

Nils S. schrieb:
> Das ist doch ein 10-bit AD-Wandler. Der kann nur 0...1023 ausgeben.
> Im Datenblatt FIGURE 6-1: SPI Communication with the MCP3004/3008 using
> 8-bit segments
> (Mode 0,0: SCLK idles low).
>
> steht ganz explizit vorgegeben wie die Kommunikation aussehen soll.
> Sogar mit Beispiel. Deine SW macht m.E. was anderes.

Hallo,

ich habe mir das angesehen und ja du hast recht mit den 10-Bit. 3,3 V 
wären dann 1024.
Ich habe den Ausleseteil derartig geändert, dass die Bits 9 bis 0 aus 
der 16-Bit Variable verwendet werden (Mit der Zeile *WertDesADUx &= 
0x3FF).

Ich habe jetzt einen kleinen Offset. Jetzt erhalte ich bei 3,3V Eingang 
ca. die Dezimalzahl 950, obwohl es 1024 sein sollten. Kann sich jemand 
die Differenz erklären?

[RT (mcu-programmer)]

Nils S. schrieb:
> Wahrscheinlich Bitreihenfolge vertauscht. In deiner SPI-Config seht "LSB
> first".
> Der Chip gibt aber MSB-first aus. Wenn ich den Wert "0000 0011 1111
> 1111" = 1023 in Dezimal LSB-MSB-tausche kommt ca. 49407 in Dezimal raus.

Jetzt komme ich auf 1024. Danke!!!!