HW SPI und eigener GPIO als CS - zeitverschoben

[nachgefragt (Gast)]

Hi

wir haben einen Chip, nennen wir ihn einmal ESP8266.
Diesen haben wir konfiguriert für HW SPI nutzen aber unseren
eigenen GPIO für den Chip Select, da wir die Transaction selber
steuern wollen und eine einzige SPI_SEND_BYTE Function haben wollen,
die bei einem Dummy Byte auch ein DataByte lesen kann.

CPOL:0 ( clock ist low, wenn inactive )
Einen Chip Select stellen wir dem SPI_SEND_BYTE mit einem GPIO(5,LOW)
voran leiten dann ein SPI_SEND_BYTE(0xFF) ein und jagen nochmals
ein SPI_SEND_BYTE(0xFF) hinterher. Nun stellen wir unseren Chip Select 
wieder auf high.

Das Resultat ist links zu sehen.

Frage a)
Ist das normal?

Nun haben wir einen kleinen delay eingebaut, der im Bild rechts zu sehen 
ist.

Frage b)
Ist das Stand der Technik?


Uns ist aufgefallen, dass bei CPHA: 1 ( data valid on clock trailing 
edge )
das letzte Datenbit genau auf der Kante liegt und im Falle eines 
gesendeten 0xFF nur 0xFE gesendet wird. ( siehe Bild )

Kann man den MOSI (herabfallendes 8.Bit ) hinausziehen oder die CLK 
Flanke verkürzen, sodass das letzte Bit richtig gesendet wird?
Es schluckt das letze Bit förmlich in diesem Mode.
Genau auf dieser Kante liegen 'sichtlich' Mosi's High und Low,
der ESP entscheidet sich immer für '0'


Im Gegensatz zu Arduino Mega, PIC18 oder PIC24.
Gleiches vorgehen, gleicher Mode.
Ein gesendetes 0xFF wird vom LogicAnalyzer auch als 0xFF erkannt,
warum nicht beim ESP8266? Gibt es einen Trick?

Alle gesendeten letzten Bits werden beim ESP8266 begradigt -
keine einzige ungerade Zahl.

Wem ist das noch aufgefallen in diesem Mode?

txs

[Michael U. (amiga)]

Hallo,

das /CS zu früh zurückgenommen werden kann, weil das SPI in Hardware 
noch beim Senden ist, kann wohl vorkommen wenn der SPI-Takt recht 
langsam ist. Ansonsten sind mir ganz praktisch noch keine 
Ungereimtheiten aufgefallen. Ich nutze diese Kombi z.B. mit MCP23S17 bei 
8MHz SPI-Clock ohne Probleme.
Ich müßte jetzt allerdings in die Tiefen der Bibliothek absteigen und 
schauen, was spi_send() da bei mir veranstaltet, ist die 
Arduino-SPI-Bibliothek.

Gruß aus Berlin
Michael

[Falk B. (falk)]

@ nachgefragt (Gast)

>steuern wollen und eine einzige SPI_SEND_BYTE Function haben wollen,
>die bei einem Dummy Byte auch ein DataByte lesen kann.

>ein SPI_SEND_BYTE(0xFF) hinterher. Nun stellen wir unseren Chip Select
>wieder auf high.

Vorher MUSS man aber auf das Ende der SPI-Übertragung warten, denn die 
läuft per Hardware parallel zur CPU. Entweder direkt per Registerzugriff 
oder ein passende Funktion.

>Ist das normal?

Nö.

>Nun haben wir einen kleinen delay eingebaut, der im Bild rechts zu sehen
>ist.

>Ist das Stand der Technik?

Nö.

[Ralph (Gast)]

nachgefragt schrieb:
> Frage a)
> Ist das normal?
>
> Nun haben wir einen kleinen delay eingebaut, der im Bild rechts zu sehen
> ist.


aarggghhhhh

Diese Delay Funktion gehört gelöscht und verboten.
Die Funktion blockiert die Programm Abarbeitung des µc für eine gewisse 
Zeit.
Dabei kann man mit dem mitgegeben Parameter nur die minimal Zeit 
einstellen, jeder Interrupt verlängert den Delay.

DAS DING IST MURKS.

Für ein verlässliches Zeitverhalten nutzt man Timer mit Interrupts.
Genau dafür haben die µC diese Timerbausteine.


> Frage b)
> Ist das Stand der Technik?

NEIN !!!!!!


Nach Stand der Technik wäre die Sequenz wie folgt.
1. SPI HW so konfigurieren, das nach Abschluss der Übertragung ein 
Interrupt ausgelöst wird.
2. SendeDaten in einen Buffer kopieren
3. CS auf Aktiv setzen
4. Transmit starten
5. .... Jetzt beliebigen anderen Code ausführen.
6. In der Interruptroutine den CS auf Passiv setzen.
7. Empfangsdaten aus dem Buffer kopieren.

Nächste Übertragung ab Punkt 2.

[Falk B. (falk)]

@Ralph (Gast)

>aarggghhhhh

>Diese Delay Funktion gehört gelöscht und verboten.

Quark.

>Die Funktion blockiert die Programm Abarbeitung des µc für eine gewisse
>Zeit.

Mikrosekunden.

>Für ein verlässliches Zeitverhalten nutzt man Timer mit Interrupts.

Darum geht es hier gar nicht.

>Nach Stand der Technik wäre die Sequenz wie folgt.
>1. SPI HW so konfigurieren, das nach Abschluss der Übertragung ein
>Interrupt ausgelöst wird.

Nö. Denn meistens wird SPI mit so hohem Takt betrieben, daß sich das gar 
nicht lohnt. SPI wird meisten per Polling genutzt. Und ja, da wird auch 
ein bisschen Zeit mit Warten vertrödelt.

[nachgefragt (Gast)]

Hi

das Problem ist anscheinend schon länger bekannt ( txs @0xPIT ) , nur 
gab es bisher keine detailierte Beschreibung für das Setzen der 
einzelnen Bits.

Beitrag "ESP8266 HW-SPI + Clock Phase"

Der Murks mit dem delay passt uns auch nicht; für einen Testlauf war er 
gut genug, aber ein while (spi_send) passt uns auch nicht so recht bei 
HW Interface Verwendung. Ein ISR wäre da schon besser.

Sobald wir eine Lösung haben, ergänze ich das hier.

Es tritt auf, wenn CPOL:0 CPHA:1 verwendet wird, es verschiebt sich 
etwas zu sehr und am Schluss treffen Mosi Edge und Clk Edge zeitgleich 
aufeinander.

Da müsste ein kürzeres CLK duty rein oder besser ein Mosi delay.

Aber wie? Die Standard Docu gibt das nicht her, 'David' hat es auch 
nicht erwähnt oder wir haben es übersehen.

Bekanntlich sehen mehr Augen mehr und es hilft auch anderen:

http://d.av.id.au/blog/hardware-spi-hspi-command-data-registers


txs

'Grüsse nach Berlin & MUC & Rest

[Peter D. (peda)]

nachgefragt schrieb:
> Ist das normal?

Wenn Du nicht auf das SPI-Ende pollst, ja.

nachgefragt schrieb:
> Ist das Stand der Technik?

Wenn Du nicht auf das SPI-Ende pollen kannst, ja.

[nachgefragt (Gast)]

-Feedback-
Hi

der "Murks" von delay ist Geschichte, uns fehlte genau dieses Bit dafür:

while (READ_PERI_REG (SPI_CMD(1)) & (1<<18));

CPHA:1
Jetzt läuft auch bei diesem Mode alles sauber durch.

txs

'Grüsse nach Berlin & MUC & Rest