SPI ADC lesen

[A. F. (artur-f)]

Ein Atmega soll aus einem 16Bit ADC lesen. Der eingesetzte ADC von 
Analog Devices AD7683 hat eine lustige Eigenschaft, dass der für diese 
16 Bit 3 Bytes anbietet, wobei die Nutzdaten im ersten Bytes an einer 
fast beliebigen Stelle anfangen können. Das heißt, dass der ADC paar SPI 
Takte zum Wandeln braucht. Es wäre alles easy, würde ich die Software 
SPI Routinen benutzen, da aber am BUS noch ca. 12 weitere SPI Bausteine 
hängen, für die ich Hardware SPI Routinen bereits programmiert habe, 
muss ich bei bei Hardware SPI bleiben, ist ja auch sicherer und 
schneller.

Also den Anfang der Nutzdaten kann man folgendermaßen erkennen. Hängt 
man an die MISO Leitung einen Pull-Up ran, muss man gucken, wo im 
erstempfangenen Byte die erste Null vorkommt (diese kommt laut dem 
Datenbyte immer vor). Jetzt habe ich was programmiert. Kann man das 
Ganze performance-technisch noch verbessern? Sicher gibt es für die 
Problemlösung noch paar andere Ansätze, von insgesamt 3 
unterschiedlichen habe ich mich für folgende Variante entschieden:

unsigned int ad7683_read_data (u8 sl_num) {

  unsigned long spi_data_long = 0;
  unsigned int  spi_data_int = 0;

  u8 adc_byte[3] = {0,0,0};
  u8 shift_operations;

  adc_byte[2] = spi_read_byte();
  adc_byte[1] = spi_read_byte();
  adc_byte[0] = spi_read_byte();  

  // wenn sich  die erste Null an der Posi befindet
  if (!(adc_byte[2] & 0x10)) {
    shift_operations = 4;
  }
  else
  // wenn sich  die erste Null an der Posi 3 befindet
  if (!(adc_byte[2] & 0x08))  {
    shift_operations = 3;
  }
  else
  // wenn sich  die erste Null an der Posi 2 befindet
  if (!(adc_byte[2] & 0x04)) {
    shift_operations = 2;
  }
  else
  // wenn sich  die erste Null an der Posi 1 befindet
  if (!(adc_byte[2] & 0x02)) {
    shift_operations = 1;
  }
  spi_data_long = *((unsigned long *)&adc_byte[0]);
  spi_data_long = (spi_data_long >> shift_operations);
  spi_data_int  = (u16*)spi_data_long;

  return spi_data_int;
}

Die Hardware ist leider noch nicht da, dass ich was ausprobieren könnte. 
Wenn ich später durch Test rausfinden kann, wo tendenziell die erste 
Null vorkommt, könnte man diese Routine noch weiter optimieren. Wie 
würdet Ihr das umsetzen?

[... .. (docean)]

woran siehst du dieses "lustige" Eigenschaft?

Ich erkenn aus deiner pdf nur das nach dem 5. Clock eine Null kommt und 
dann die daten...nix mit unterschiedliche Abstände

[A. F. (artur-f)]

>>NOTE:
>>A MINIMUM OF 22 CLOCK CYCLES ARE REQUIRED FOR 16-BIT CONVERSION. SHOWN ARE
>>24 CLOCK CYCLES. DOUT GOES LOW ON THE DCLOCK FALLING EDGE FOLLOWING THE LSB 
READING

Steht zumindest unter dem Bild. An einer anderen Position im Datenblatt 
steht tatsächlich was von 5 Clocks.

[Knut B. (Firma: TravelRec.) (travelrec)]

Nuja... 16Bit + führende '0' + 5 = 22 !