SPI Bus (mit Glitches) per Software auslesen

[Dennis G. (master1991)]

Hi,

habe mich nun auch mal angemeldet hier. War neulich schonmal mit dem 
Problem hier besteht jedoch weiterhin, ich hoffe das hier jemand helfen 
kann:

Mikrocontroller: Attiny45
Als Programmer wird der Arduino benutzt (einen anderen habe ich hier 
nicht)

Zum testen nutze ich allerdings momentan den Arduino also den Atmega328 
(glaube ich)

Am besten schaut ihr euch die Screenshots an.

Gelb-->CLK
Grün-->MOSI
Blau-->Nicht wichtig/nicht angeschlossen am Controller (auch nicht MISO)
PINK-->CS (jedoch nicht das original ChipSelect vom SPI Bus)

Bild eins zeigt nun zunächst einmal alles was über den Bus läuft.
Bild zwei zeigt einmal links einen Glitch auf CS (Pink) sowie die 
gewollte übertragung rechts.

Bild drei ist dann eine der beiden Übertragungen am Ende von Bild eins 
(16Bit) , die die Nutzdaten für den Attiny beeinhalten.


Was ich will: die Nutzdaten einlesen.
Es handelt sich um 16Bit (Der Master sendet immer volle Bytes) - 
Aufgeteilt in Bit8: ChannelByte für PWM Channel Bit7-0: 8Bit PWM Duty 
Cycle

Der Attiny macht also nichts anderes als zwei PWM Signale zu generieren!

Da die Pins doppelt belegt sind, kann ich das Hardware SPI interface 
nicht nutzen und muss das einlesen per Software machen und genau da 
hängt es nun.

Wegen der Glitches auf CS (Ich weiß wo sie herkommen und sie sind NICHT 
entfernbar) kann ich nicht einfach auch CS low warten weil falsche Daten 
reinkommen, und der folgende Code produziert irgendwas aber nicht 
0x01FF, ich hoffe auf Hilfe ich bin langsam mit meinem Latein am Ende, 
den Code habe ich schon so oft umgeschrieben nun, nichts hilft):

/*
  created 22 December 2015
  modified 06 January 2016
  by Dennis
 */

word data;
word i;


void setup() {
  Serial.begin(115200);
  //Pins 2,3 and 4 are input ports
  //DDRB2 is ChipSelect
  //DDRB3 is MOSI
  //DDRB4 is CLK
  DDRB &= ~( (1<<DDB4) | (1<<DDB3) | (1<<DDB2) );

  i = 1;
}

void loop() {
  //Startbedingung (Takt High wegen der Glitches)
  if( !(PINB & (1<<PB2)) && (PINB & (1<<PB4)) ){
    //Auf HIGH Warten
    SPI_LOOP:  
    while( !(PINB & (1<<PB4)) ){} 
    //Datenbit einlesen
    data <<= 1;    
    data |= ( PINB >> PINB3 ) & 1; 
    //auf LOW warten  
    while( (PINB & (1<<PB4)) ){}
    //Bit eingelesen, Couter erhöhen (Ist schieben schneller als +1?!)
    i <<= 1;
    if( !(i & (1<<15)) ){goto SPI_LOOP;};
  } 
  //Testweise an die Serielle Schnittstelle ausgeben
  if(data != 0){
    Serial.println(data, HEX);
  }
  //Zurücksetzen
  i = 1;
  data = 0;
}

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>Mikrocontroller: Attiny45

>Gelb-->CLK
>Grün-->MOSI
>Blau-->Nicht wichtig/nicht angeschlossen am Controller (auch nicht MISO)
>PINK-->CS (jedoch nicht das original ChipSelect vom SPI Bus)

>Wegen der Glitches auf CS (Ich weiß wo sie herkommen und sie sind NICHT
>entfernbar)

Glaub ich nicht.

>  //Startbedingung (Takt High wegen der Glitches)
>  if( !(PINB & (1<<PB2)) && (PINB & (1<<PB4)) ){
>    //Auf HIGH Warten
>    SPI_LOOP:

Hä? Ein Label in C?

>    if( !(i & (1<<15)) ){goto SPI_LOOP;};

AUA!!! PFUI!!! Nimm eine NORMALE Schleife!

[Dennis G. (master1991)]

Kannst du ruhig glauben, ich kanns auch erklären aber dazu muss ich 
weiter ausholen.


Ich weiß das das Label/goto da nicht hingehört, änder ich auchnoch aber 
es ging ja nur um die Funktion und die sollte auch durch das Label nicht 
beeinträchtigt sein?!

Oder siehst du offensichtliche Fehler? Wie gesagt der Code liest 
vollkommenen stuss ein! (Das Signal ist schnell wie man sieht, aber der 
Testcode läuft auf dem Arduino mit 16Mhz also, das sollte doch wohl 
gehen?!)

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>Kannst du ruhig glauben,

Das tu ich in diesem Forum schon lange nicht mehr ;-)

> ich kanns auch erklären aber dazu muss ich
>weiter ausholen.

Tu es.

>Ich weiß das das Label/goto da nicht hingehört, änder ich auchnoch aber
>es ging ja nur um die Funktion und die sollte auch durch das Label nicht
>beeinträchtigt sein?!

Es geht, ist aber unsinnig.

>Oder siehst du offensichtliche Fehler? Wie gesagt der Code liest
>vollkommenen stuss ein! (Das Signal ist schnell wie man sieht, aber der
>Testcode läuft auf dem Arduino mit 16Mhz also, das sollte doch wohl
>gehen?!)

Woher sollen wir das wissen? Deine tollen Screenshots haben keinen 
Zeitmaßstab!

[Achim S. (Gast)]

Dennis G. schrieb:
> Wie gesagt der Code liest
> vollkommenen stuss ein!

komisch: ich hätte gedacht, dass er gar nichts einliest, weil er an 
dieser Stelle endlos hängen bleibt:

Dennis G. schrieb:
> while( !(PINB & (1<<PB4)) ){}

[Falk B. (falk)]

/*
  created 22 December 2015
  modified 06 January 2016
  by Dennis
 */

word data;
word i;


void setup() {
  Serial.begin(115200);
  //Pins 2,3 and 4 are input ports
  //DDRB2 is ChipSelect
  //DDRB3 is MOSI
  //DDRB4 is CLK
  DDRB &= ~( (1<<DDB4) | (1<<DDB3) | (1<<DDB2) );

  i = 1;
}

void loop() {
  //Startbedingung (Takt High wegen der Glitches)
  if( !(PINB & (1<<PB2)) && (PINB & (1<<PB4)) ){
    for (i=0; i<16; i++) {
      //Auf HIGH Warten
      while( !(PINB & (1<<PB4)) ); 
      //Datenbit einlesen
      data <<= 1;    
      if ( PINB & (1<<PINB3) ) data |= 1; 
      //auf LOW warten  
      while( (PINB & (1<<PB4)) );
    }
  } 
  //Testweise an die Serielle Schnittstelle ausgeben
  if(data != 0){
    Serial.println(data, HEX);
  }
}

[Falk B. (falk)]

Wenn ich scope_2.png richtig deute, sind dort 14 us/DIV der Maßstab. Die 
2x8 Taktze dauern ca. 2 DIV also 28us, macht ~1,75us/Takt. Das mit der 
Softwareabtastung zu erfassen wird knapp. Probier es mal mit DEUTLICH 
langsamerer SPI, sagen wir Faktor 100 langsamer.

[Dennis G. (master1991)]

Okay also langsam und der Reihe nach:

1. Wie ich das goto wegbekomme war mir klar dennoch danke für den Code

2. Ist

if ( PINB & (1<<PINB3) ) data |= 1;

 schneller als

data |= ( PINB >> PINB3 ) & 1;

? Wie du siehst geht es hier um Geschwindigkeit.

3. Zwischen zwei steigenden Flanken vergehen 2us = 500kHz. Ich habe es 
sogar mit 10kHz Frequenz versucht. Trotzdem keine richtigen Daten. 
(Langsamer kann ich den Master komischerweise nicht stellen, auch wenn 
ich 1 Hz einstelle geht er nur bis 7,xxx kHz runter)

4. Ich brauche es auch schnell, da mit den Daten geregelt wird.

@Achim:

while( !(PINB & (1<<PB4)) ){} Warum sollte er hängen bleiben...er wartet 
dort bloß auf den steigenden Takt bzw hintert das mitzählen von i das er 
am Ende hängen bleibt;)

5. Warum die Glitches nicht weggehen folgt.

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>2. Ist

>if ( PINB & (1<<PINB3) ) data |= 1;

> schneller als

>data |= ( PINB >> PINB3 ) & 1;

Ja. Denn die 1, Zeile übersetzt der schlaue GCC in 2 kleine ASM Befehle, 
die 2. ist eine langsame Schiebeorgie. Schau die das .lss File an, das 
liegt im etwas verstecken Projektordner vom Arduino.

>? Wie du siehst geht es hier um Geschwindigkeit.

>3. Zwischen zwei steigenden Flanken vergehen 2us = 500kHz.

2us sind 32 Takte bei 16 MHz. In reinem ASM mag man das hinbekommen, 
deine C-Funktion schafft es eher nicht.

> Ich habe es
>sogar mit 10kHz Frequenz versucht. Trotzdem keine richtigen Daten.

Dann gibt es noch einen anderen Fehler. Trotzdem muss es erstmal mit 
10kHz laufen.

>(Langsamer kann ich den Master komischerweise nicht stellen, auch wenn
>ich 1 Hz einstelle geht er nur bis 7,xxx kHz runter)

Weil dort wahrscheinlich die Hardware-SPI nicht langsamer laufen kann, 
die Vorteiler sind endlich.

>4. Ich brauche es auch schnell, da mit den Daten geregelt wird.

Erstmal langsam, dann geht es weiter. Soft-SPI ist so oder so nicht so 
toll, erst recht nicht als Empfänger!

Mach doch einfach mal folgendes. Setzte ein Testpin auf HIGH, wenn deine 
Funktion das CS erkannt hast und auf LOW, wenn alle 16 Bit eingelesen 
sind. Dann siehst du erstmal, wo du dich bewegst.

  if( !(PINB & (1<<PB2)) && (PINB & (1<<PB4)) ){
    PORTB |= (1<<TESTPIN);
    for (i=0; i<16; i++) {
      //Auf HIGH Warten
      while( !(PINB & (1<<PB4)) ); 
      //Datenbit einlesen
      data <<= 1;    
      if ( PINB & (1<<PINB3) ) data |= 1; 
      //auf LOW warten  
      while( (PINB & (1<<PB4)) );
    }
    PORTB &= ~(1<<TESTPIN);
  }

[Dennis G. (master1991)]

Zu den Glitsches:

Der SPI Master ist ein Raspberry PI, welcher von Codesys (Soft SPS) 
gesteuert wird. Innerhalb von Codesys bzw auch der Raspberry kann nur 
zwei SPI Geräte aufgrund von zwei ChipSelects ansteuern. An dem Bus 
hängen jedoch vier Geräte:

Encoder,DAC,ADC,ATtiny45

Für Codesys habe ich nun einen Treiber geschrieben der nur einen CS des 
PIs nutzt und einen zusätzlichen GPIO (Damit soviele wie möglich noch 
zur verfügung stehen wurden nicht direkt 4 GPIOs für 4 CS genommen)

Angeschlossen wie folgt:

Schieberegister 74HC595 an MOSI, CLK sowie mit seiner RCK leitung an den 
CS des Masters. Der Schieberegister kriegt nun 8Bit Daten im Format 
0xFFFE das wäre dann Teil des CS für den ADC...der Ausgang ist nun an 
ein OR Gate zusammen mit dem GPIO angeschlossen. Damit kann ich mit 
einem zusätzlichen Pins durch kaskadierung unendlich viele Geräte 
anschließen.

Der Glitsch kommt nun zustande dadurch dass der GPIO auf low ist und der 
Register einen Ausgang ebenfalls auf low hat (Ein Device aktiv) - Das 
Device bekommt nun Daten (die der Schieberegister auch bekommt) bei Ende 
der übertragung wird der richtige CS auf HIGH gezogen was die Latches im 
Schieberegister steuert. Je nachdem was für Daten übertragen wurden an 
das device kann es nun passieren das kurzzeitig ein falsches ChipSelect 
für ein anderes device low geht bevor der GPIO softwareseitig auf HIGH 
gezogen werden kann--> Glitsch.

Das wäre vermeidbar wenn:

1. Zusätzliche GPIOs verwendet worden wären (nicht praktikabel in diesem 
Fall)
oder
2. Der GPIO vor dem CS auf HIGH gezogen wird. An die Master library 
komme ich aber nicht ran, das geht nicht!


Siehe hierzu das Timing Diagramm

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>Für Codesys habe ich nun einen Treiber geschrieben der nur einen CS des

DU hast ihn geschrieben?

>PIs nutzt und einen zusätzlichen GPIO (Damit soviele wie möglich noch
zur verfügung stehen wurden nicht direkt 4 GPIOs für 4 CS genommen)

>Angeschlossen wie folgt:

>Schieberegister 74HC595 an MOSI, CLK sowie mit seiner RCK leitung an den
>CS des Masters. Der Schieberegister kriegt nun 8Bit Daten im Format
>0xFFFE das wäre dann Teil des CS für den ADC...der Ausgang ist nun an
>ein OR Gate zusammen mit dem GPIO angeschlossen. Damit kann ich mit
>einem zusätzlichen Pins durch kaskadierung unendlich viele Geräte
>anschließen.

Verstehe.

>Der Glitsch kommt nun zustande dadurch dass der GPIO auf low ist und der
>Register einen Ausgang ebenfalls auf low hat (Ein Device aktiv)

Warum eigentlich? Wenn du ZWEI CS hast, nimm doch eins für das 
Schieberegister mit den (unendlich vielen) Chip Selects und das 2. für 
die OR Verknüpfung! Dann gilbt es auch keinen Glitch!

> - Das
>Device bekommt nun Daten (die der Schieberegister auch bekommt) bei Ende
>der übertragung wird der richtige CS auf HIGH gezogen was die Latches im
>Schieberegister steuert. Je nachdem was für Daten übertragen wurden an
>das device kann es nun passieren das kurzzeitig ein falsches ChipSelect
>für ein anderes device low geht bevor der GPIO softwareseitig auf HIGH
>gezogen werden kann--> Glitsch.

Müll!

>Das wäre vermeidbar wenn:

>1. Zusätzliche GPIOs verwendet worden wären (nicht praktikabel in diesem
>Fall)

Wirklich nicht?

Ich würde das reparieren. Damit hat man ständig sinnlosen Stress!

[Dennis G. (master1991)]

Als alles nicht funktionierte habe ich zunächst folgendes versucht:

void loop() {
  if( !(PINB & (1<<PB2)) && newTransmission){
    newTransmission = false;
    i += 1; 
  }
  if( PINB & (1<<PD2) ){
    newTransmission = true;
  }
  if(millis() > 5000){Serial.println(i);while(true){}}
}

Letzte Zeile da die Soft-SPS auf 5s Zyklus gestellt ist (Zum Testen) - 
Später sollen <10ms erreicht werden (Tut sie momentan auch).

Selbst das ging komischerweise erst nicht richtig (Hat keine 11 CS low 
während einer Übertragung gezählt (und es ändert sich nicht da ich keine 
Daten ändere).
Irgendwann ging es dann doch den Grund versteh ich nicht, habe nichts 
verändert. Daraufhin habe ich folgendes getan

void loop() {
  if( !(PINB & (1<<PB2)) && (PINB & (1<<PB4)) && newPeriod){
    newPeriod = false;
    i += 1; 
  }
  if( PINB & (1<<PD2) ){
    newPeriod = true;
  }
  if(millis() > 5000){Serial.println(i);while(true){}}
}

Mit der Erwartung eine 2 zu erhalten, für die beiden Nutzdaten 
Übertragungen. Aber raus kamen eher so Sachen wie 20,23,27.

Und auch das habe ich eher langsam getestet.

Ich habe leider die Hardware in der Uni gelassen, war zu genervt heute 
davon. Ich werde jedoch auch jeglich hinweise deinerseits nochmal 
nachgehen.


-->Ich schreib das auch alles in Assembler wenn es dann schneller geht, 
aber kann ich dann immernoch den Arduino als Programmer nehmen? Ich 
glaube die IDE frisst assembler nicht oder?

[Dennis G. (master1991)]

@Falk B.

> DU hast ihn geschrieben?

Ja.

> Warum eigentlich? Wenn du ZWEI CS hast, nimm doch eins für das
> Schieberegister mit den (unendlich vielen) Chip Selects und das 2. für
> die OR Verknüpfung! Dann gilbt es auch keinen Glitch!

Also entweder versteh ich das nicht oder der Glitch würde trotzdem 
auftreten. Ist jedoch ohnedies nicht praktikabel in codesys.

> Wirklich nicht?
>
> Ich würde das reparieren. Damit hat man ständig sinnlosen Stress!

Ja bzw Nein, das ganze ist zeitlich nicht mehr praktikabel. Sicherlich 
wäre das eine Idee für Version zwei, aber für mich geht es nun nicht 
mehr. Das der Glitch überhaupt entstehen kann, fällt einem auch nicht 
auf anhieb auf.

-->Die anderen Geräte interessiert es übrigens überhaupt nicht das es 
Glitches gibt. Alle haben auf Anhieb funktioniert

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>> Warum eigentlich? Wenn du ZWEI CS hast, nimm doch eins für das
>> Schieberegister mit den (unendlich vielen) Chip Selects und das 2. für
>> die OR Verknüpfung! Dann gilbt es auch keinen Glitch!

>Also entweder versteh ich das nicht oder der Glitch würde trotzdem
>auftreten. Ist jedoch ohnedies nicht praktikabel in codesys.

Siehe Anhang. Die erste Version mit extra OR-Gatter, die 2. clever mit 
Pull-Ups und Tristatenutzung! Solang CS_RASPI_1 HIGH ist, sind CS0-3 
auch high, ohne Glitch!

>> Ich würde das reparieren. Damit hat man ständig sinnlosen Stress!

>Ja bzw Nein, das ganze ist zeitlich nicht mehr praktikabel.

In Anbetracht der Lage, daß im Moment bei dir fast nichts läuft mit der 
Soft-SPI, ist ganz sicher Zeit dazu.

>mehr. Das der Glitch überhaupt entstehen kann, fällt einem auch nicht
>auf anhieb auf.

Du weißt es jetzt aber!

Solve the problem!

[Dennis G. (master1991)]

Variante eins ist ja nun genau die, die ich am laufen habe. Nur halt 
statt des CS1 der GPIO. CS1 gehört ja auch zu einem anderen Master würde 
auch zeitversetzt low und high gehen. Das ändert nichts ob GPIO oder 
CS1.

Variante zwei habe ich natürlich zu allererst dran gedacht, geht aber 
nicht dummerweise komme ich gerade nicht darauf wieso...

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>Variante eins ist ja nun genau die, die ich am laufen habe. Nur halt
>statt des CS1 der GPIO. CS1 gehört ja auch zu einem anderen Master würde
>auch zeitversetzt low und high gehen. Das ändert nichts ob GPIO oder
>CS1.

Stimmt. Dann gibt es aber keine Glitches. Wenn doch, hast du einen Bug 
in deiner Software. Ist doch eigentlich einfach.

Beide CS auf High, alle CS sind HIGH
CS0 auf low
Neuen CS-Code ins Schieberegister takten
CS0 auf high
CS1 auf LOW, das neue CS wird LOW.

>Variante zwei habe ich natürlich zu allererst dran gedacht, geht aber
>nicht dummerweise komme ich gerade nicht darauf wieso...

[Dennis G. (master1991)]

> Stimmt. Dann gibt es aber keine Glitches. Wenn doch, hast du einen Bug
> in deiner Software. Ist doch eigentlich einfach.
>
> Beide CS auf High, alle CS sind HIGH
> CS0 auf low
> Neuen CS-Code ins Schieberegister takten
> CS0 auf high
> CS1 auf LOW, das neue CS wird LOW.

Genau so passiert es auch aber es geht ja weiter:

neues CS LOW
Daten für den Chip senden, dabei geht CS0 Low
Ende der Übertragung CS0 geht HIGH schiebregister übernimmt daten in 
latch
-->Zeitpunkt des Glitches
CS1 auf HIGH

und es ist nicht möglich nach der übertragung zuerst CS1 (oder eben 
GPIO) auf HIGH zu ziehen, in beiden Fällen müsste ich an die SPI Master 
library ran und die ist compiliert und nicht offengelegt.


Meine Idee wäre jetzt noch folgende:

Ich lese einfach die 8 Bits nach dem Glitch ein und vergleiche in der 
software mit ner mask da der PWM in seinem High byte immer nur 0x00 oder 
0x01 bekommt und der schieberegister (Byte nach Glitch) immer 0x1X kann 
man das relativ einfach verwerfen.

Mich stört nun gerade das ich gerade absolut keinen Grund mehr finde 
warum variante zwei nicht ging und ich das Gatter zuviel habe, ändert 
aber am Glitch nichts CS0 kommt immer und unausweichlich vor CS1. Hätte 
ich das vorher gewusst hätte ich zwei GPIOs genommen für RCK und G. Das 
große Problem warum es nicht änderbar ist, ist das für dieses layout 
schon eine Platine existiert/gefertigt wird. (Wer konnte damit Rechnen 
das drei Geräte gehen und das vierte nicht, die Zeit drängte)

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>> Beide CS auf High, alle CS sind HIGH
>> CS0 auf low
>> Neuen CS-Code ins Schieberegister takten
>> CS0 auf high
>> CS1 auf LOW, das neue CS wird LOW.

>Genau so passiert es auch aber es geht ja weiter:

>neues CS LOW
>Daten für den Chip senden, dabei geht CS0 Low
>Ende der Übertragung CS0 geht HIGH schiebregister übernimmt daten in
>latch
>-->Zeitpunkt des Glitches

Nö

>CS1 auf HIGH

Falsch. CS1 muss VORHER auf HIGH! Schrieb ich nicht umsonst!
Das da oben ist die Funktion zum Setzen von CS0-3! Glitchfrei!

>und es ist nicht möglich nach der übertragung zuerst CS1 (oder eben
>GPIO) auf HIGH zu ziehen,

Musst du gar nicht. Es reicht vor dem nächsten setzen.

> in beiden Fällen müsste ich an die SPI Master
>library ran und die ist compiliert und nicht offengelegt.

Wer steuert das GPIO? Du oder diese komische Lib?

>Ich lese einfach die 8 Bits nach dem Glitch ein und vergleiche in der

Ohne mich. Irgendwann ist Schluß mit Workarounds! Mach es richtig!

>aber am Glitch nichts CS0 kommt immer und unausweichlich vor CS1.

Ein Softwarefehler!

> Hätte
>ich das vorher gewusst hätte ich zwei GPIOs genommen für RCK und G. Das
>große Problem warum es nicht änderbar ist, ist das für dieses layout
>schon eine Platine existiert/gefertigt wird.

Das kann man ändern! Leitungen auftrennen, Draht ziehen, fertig! 
Menschenskinder, sowas von unbeweglich!

> (Wer konnte damit Rechnen
>das drei Geräte gehen und das vierte nicht, die Zeit drängte)

Wenn du es eilig hast, gehe langsam. Konfuzius

Gerade heute wieder in der 4ma erlebt 8-0.

[Dennis G. (master1991)]

> Falsch. CS1 muss VORHER auf HIGH! Schrieb ich nicht umsonst!
> Das da oben ist die Funktion zum Setzen von CS0-3! Glitchfrei!

Nein :D ... Tut mir leid ich möchte dir ja wirklich gerne glauben, aber 
es ist nicht der Fall. Bzw, doch, du hast recht du setzt dort oben 
Glitchfrei den gewünschten CS. Genau das gleiche tue ich auch.

Was du misachtest ist die Tatsache das nun Datenbytes kommen die 
gesendet werden und die liegen auf der selben SPI Leitung CS0 wird auch 
bei dieser übertragung auf LOW gezogen. Am ENDE dieser Übertragung (CS1 
ist nach wie vor LOW) wird CS0 vom Master den ich nicht beeinflussen 
kann auf HIGH gezogen. Erst DANACH habe ich wieder die möglichkeit GPIO 
auf HIGH zu ziehen und genau in dieser Zwischenzeit passiert ABHÄNGIG 
von den Daten die vorher gesendet wurden der Glitch. Also nicht beim 
setzen von CS sondern beim RÜCKSETZEN.


> Wer steuert das GPIO? Du oder diese komische Lib?

ich

> Ohne mich. Irgendwann ist Schluß mit Workarounds! Mach es richtig!

fair enough, allerdings müssen die anderen Chips es genauso machen, 
sonst wären sie ebenfalls von den Glitches betroffen

> Das kann man ändern! Leitungen auftrennen, Draht ziehen, fertig!
> Menschenskinder, sowas von unbeweglich!

Sollte es nicht funktionieren mit meinem, wie du sagst, workaround, lege 
ich nen zweiten GPIO an RCK. Dann wars das mit Glitches

> Wenn du es eilig hast, gehe langsam. Konfuzius
>
> Gerade heute wieder in der 4ma erlebt 8-0.

Wir sind ja alle zum lernen hier :)


-->Der GPIO ist übrigens der blaue Channel im Oszi

[Falk B. (falk)]

@ Dennis GehtEuchNichtsAn (master1991)

>> Falsch. CS1 muss VORHER auf HIGH! Schrieb ich nicht umsonst!
>> Das da oben ist die Funktion zum Setzen von CS0-3! Glitchfrei!

>Nein :D ... Tut mir leid ich möchte dir ja wirklich gerne glauben,

Nicht glauben, VERSTEHEN!

>aber
>es ist nicht der Fall. Bzw, doch, du hast recht du setzt dort oben
>Glitchfrei den gewünschten CS. Genau das gleiche tue ich auch.

Also?

>Was du misachtest ist die Tatsache das nun Datenbytes kommen die
>gesendet werden und die liegen auf der selben SPI Leitung

Hä?

> CS0 wird auch
>bei dieser übertragung auf LOW gezogen.

Fehler! Was soll der Müll?

> Am ENDE dieser Übertragung (CS1
>ist nach wie vor LOW) wird CS0 vom Master den ich nicht beeinflussen
>kann auf HIGH gezogen. Erst DANACH habe ich wieder die möglichkeit GPIO
>auf HIGH zu ziehen und genau in dieser Zwischenzeit passiert ABHÄNGIG
>von den Daten die vorher gesendet wurden der Glitch. Also nicht beim
>setzen von CS sondern beim RÜCKSETZEN.

Ein grundlegender Fehler dieser dämlichen Lib!
Fix it!
Dann musst du an ein "virtuelles" SPI-Device senden, das NICHT am CS0 
hängt, dann wird auch CS0 nicht aktiv!

>> Wer steuert das GPIO? Du oder diese komische Lib?

>ich

Also los! Du kannst es beeinflussen!

>> Ohne mich. Irgendwann ist Schluß mit Workarounds! Mach es richtig!

>fair enough, allerdings müssen die anderen Chips es genauso machen,
>sonst wären sie ebenfalls von den Glitches betroffen

???

>> Das kann man ändern! Leitungen auftrennen, Draht ziehen, fertig!
>> Menschenskinder, sowas von unbeweglich!

>Sollte es nicht funktionieren mit meinem, wie du sagst, workaround, lege
>ich nen zweiten GPIO an RCK. Dann wars das mit Glitches

MACH ES JETZT!

>Wir sind ja alle zum lernen hier :)

Worauf wartest du? So ein Workaround ist in 5 Minuten erledigt!

[Dennis G. (master1991)]

> Ein grundlegender Fehler dieser dämlichen Lib!
> Fix it!
> Dann musst du an ein "virtuelles" SPI-Device senden, das NICHT am CS0
> hängt, dann wird auch CS0 nicht aktiv!

Tja, das liegt halt daran das ich Pins sparen wollte und mir aufgefallen 
ist das ich ja eh nen pin hab der automatisch low gezogen wird, warum 
diesen nicht als takt für die latches nutzen. Stimmt, virtuelles SPI 
device würde gehen, kann aber die Sende lib nach wie vor nicht 
beeinflussen.

> MACH ES JETZT!

Okay!

Dann bin ich die Glitches los, aber die Software hätte auch so laufen 
sollen!
Naja ich werd das in Angriff nehmen und das auf der Platine wohl ändern 
wenn das den Mikrocontroller zum laufen bringt.

Würde nur gerne wissen, wieso die anderen Geräte laufen. Auf deren CS 
Leitungen sind die gleichen Glitches.

Aber du hast ja recht, unschön ist es allemal.

[Falk B. (falk)]

Ergänzung zu diesem Beitrag.

Beitrag "Re: SPI Bus (mit Glitches) per Software auslesen"

Man kann eine Funktion erstellen, die einfach und schnell das Chip
Select schaltet. Der Code ist nur exemplarisch, weil er allgemein
gehalten ist. Das Pinwackeln muss man individiuell anpassen. Die
Funktion gilt für beide Versionen, mit OR-Gatter und Pull-Ups.
Parameter cs 0-7 schaltet die Ausgänge QA-QH am 74HC595 aktiv auf LOW.
Werte >7 schalten "ins Leere", sprich, CS wird HIGH. Zu beachten ist, 
dass JEDE SPI-Transaktion mit einem chip_select(8) oder einer höheren 
Zahl abgeschlossen werden muss, damit die CS0-3 HIGH werden, bevor ein 
neues Chip Select an den 74HC595 geschickt wird!

// adjust port access to your hardware!

#define CS_RASPI_0_HIGH PORTA |=  (1<<PA0);
#define CS_RASPI_0_LOW  PORTA &= ~(1<<PA0);

#define CS_RASPI_1_HIGH PORTA |=  (1<<PA1);
#define CS_RASPI_1_LOW  PORTA &= ~(1<<PA1);

void chip_select(uint8_t cs) {
  uint8_t cs_code;

  if (cs > 7 ) {
    CS_RASPI_1_HIGH     // CS goes inactive
  } else {
    cs_code = ~(1<<cs);
    CS_RASPI_0_LOW
    spi_send(cs_code);
    CS_RASPI_0_HIGH
    CS_RASPI_1_LOW      // CS goes acvtive
  }
}

[Dennis G. (master1991)]

Das Chipselect wird vom SPI Master übertragen.

An dieser Stelle kurz Rückmeldung ich hab die ganze Zeit drüber 
nachgedacht warum die intelligente Lösung mit dem Enable nicht 
funktioniert.

Sie funktioniert. Ich bin nur nicht auf die Idee mit den PullUps 
gekommen, da hab ich definitiv was dazugelernt. Wusste einfach nicht das 
es so geht. Ich habe halt gedacht, dass ich einen undefinierten Pegel am 
Ausgang dann habe. Tja die Widerstände ändern dies natürlich.

Gott sei dank ist das extra OR Gate nicht sonderlich tragisch.

[Falk B. (falk)]

Und, schon das Signal umgelegt?