SPI am AVR auf "Motorola SSP frame format" einstellen

[Peter (Gast)]

Hallo,

ich möchte ein IC über den SPI-Bus ansteuern, welches im "Motorola SSP 
frame format" kommuniziert. Wie muss ich den SPI am AVR (z.B. ATMega48) 
einstellen, damit sich die beiden Bausteine verstehen?

Im Forum von AVR Freaks habe ich etwas von der Einstellung

CPOL = 0
CPHA = 1

gelesen - stimmt das?

[Kobaltchlorid (Gast)]

Es wäre recht hilfreich, wenn du uns sagen würdest, WELCHEN IC du 
verwendest bzw. einen Link zu einem Datenblatt postest oder dieses hier 
hochlädst. Mit dem Begriff "Motorola SSP frame format" kann ich 
persönlich nichts anfangen. Üblicherweise werden die Datenframes und das 
Timing im Datenblatt genau erklärt. Ich glaube nicht, dass da nur 
"Motorola SSP Frame Format" ohne genauere Beschreibung drin steht.

Wenn es wirklich SPI-Kommunikation ist, die dein IC braucht:
Prinzipiell sind beim AVR vier verschiedene SPI-Modi möglich. Eine 
Beschreibung zu diesen Modi gibt's z.B. hier:
http://www.mikrocontroller.net/articles/Serial_Peripheral_Interface
Der Rest steht im Datenblatt deines AVR.

[Peter (Gast)]

Es handelt sich um diesen chip: 
http://focus.ti.com/lit/ds/symlink/ads1251.pdf

[Kobaltchlorid (Gast)]

Wie kommst du eigentlich auf die Idee, dass dieser Chip SPI braucht? 
Laut diesem Datenblatt hat der ADS1251 überhaupt kein SPI-Interface. Der 
wird über ein 2Wire-Interface angesprochen.

[Peter (Gast)]

Wenn ich auf der TI Seite nach ADCs suche und die Suchoption "Serial SPI 
Interface" anklicke, erscheint dieser Chip. Außerdem kann ich ihn mit 
einem ARM7 über SPI auslesen.

Kennst du dich mit diesem Chip aus oder hast du eine Library zur 
Kommunikation?

[Motorola SSP frame format (Gast)]

Naja ist halt wieder ne typische Peter (Gast) Anfrage:-)

Im ganzen Datasheet des ADS1251 kommt "Motorola SSP
frame format" nicht vor!

@Peter (Gast) was bastelst du eigentlich?
Lies doch mal das Datasheet ab Seite 12 "SERIAL INTERFACE" durch.. Wird 
wohl etwas aufwendig mit dem SPI Interface des AVR (ATMega48). Der 
ADS1251 ist wohl nichts für Anfänger.

[Peter (Gast)]

Auf das "Motorola SSP frame format" komme ich, weil ich beim 
ARM7-Controller dieses eingestellt habe und es damit funktioniert.

Heute habe ich einfach mal nach den zwei Flanken den SCLK Pin getoggelt 
so dass Daten ankamen. Werde das dann wohl "per Hand" ohne SPI machen.

"ADS1251 ist wohl nichts für Anfänger" --> Da hast du Recht - kein 
Mensch kennt sich damit aus - selbst die Gurus aus den Foren können 
nicht weiterhelfen. Naja, in den nächsten Tagen wird es bei mir laufen 
und dann poste ich den Code.

[Motorola SSP frame format (Gast) (Gast)]

>selbst die Gurus aus den Foren können
>nicht weiterhelfen.
Vieleicht haben die den Baustein noch nie verwendet. Ich habe das 
Datasheet ab Seite 12 "SERIAL INTERFACE" nochmals kurz überflogen. Ist 
eine "nicht übliche" Schnittstelle mit einigen Tücken. Die hatten halt 1 
Pin zu wenig!
Wie hoch ist den deine CLK Frequenz an Pin 4?

>Naja, in den nächsten Tagen wird es bei mir laufen
>und dann poste ich den Code.
Mit einger Erfahrung im Embedded-Design und eine guten Scope zum debugen 
ist das sicher möglich.
Viel Erfolg!

[Peter (Gast)]

Die Ansteuerung ist eigentlich echt simpel, wenn man KEIN SPI verwendet, 
sondern das "per Hand" macht:

Zunächst einmal muss man einen "beliebigen" Takt an den CLK Pin anlegen 
(beliebig in sofern, dass man damit die DATA OUTPUT RATE bestimmt - s. 
Datenblatt auf Seite 8).

Danach kann man mit dem Oszilloskop auf der DOUT-Leitung zwei Peaks 
erkennen (ein langer und ein kurzer). Diese Peaks muss man abwarten, 
bevor man die Daten dann über Toggles an SCLK am Pin DOUT "heraustakten" 
kann. Das muss man 24 mal machen (da 24 Bit).

Meine Realisierung dazu sieht so aus:

// Init Timer - initialization of the 16-Bit Timer
void init_timer(void)
{
  TCCR1A = (1<<COM1A0);            // Toggle on OC1A
  TCCR1B = (1<<CS10)|(1<<WGM12);
  
  OCR1A = 128;
} 

int main (void) 
{
  // local variables
  uint32_t single_value = 0;
  uint8_t n,m;
  uint8_t m_value[3] = {0,0,0};
  char buffer[12];
  
  // initialization
  init_main();
  init_timer();
  lcd_init();

  sei();

  // main program
  while(1)
  {
    while(!(PINB & (1<<4))){};
    _delay_us(500); // wait until the two peaks passed
    
    m_value[0] = 0;
    m_value[1] = 0;
    m_value[2] = 0;
    for (m = 0; m<3; m++) {
      for (n = 0; n<8; n++) {
        PORTB |= (1<<5);  // set
        _delay_us(3);
        PORTB &= ~(1<<5);  // reset
        m_value[m] |= (((PINB & (1<<4))>>4)<<(7-n));
        _delay_us(2);
      }
    }
    single_value = ((uint32_t)m_value[0]<<16) + ((uint32_t)m_value[1]<<8) + m_value[2];
    ultoa(single_value, buffer, 10);
    usart_write("SPI = %s\r", buffer);

    _delay_ms(500);
  }
}

Es geht mit Sicherheit noch einfacher (besonders die Shift-Operationen 
lassen sich noch vereinfachen - das sehe ich schon beim Posten, aber: 
"never change a running system" :-D)

Ich finde den Chip jetzt - seit er funktioniert - eigentlich ganz nett, 
da er sehr kompakt (8 SOIC) ist, eine hohe Auflösung bietet und über nur 
drei Leitungen + Versorgungsspannung betrieben werden kann.