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
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
@ 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ö.
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.
@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.
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
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.
-Feedback- Hi der "Murks" von delay ist Geschichte, uns fehlte genau dieses Bit dafür:
1 | 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.