Hallo liebe Gemeinde, ich hab hier gerade einen MAX3100 mittels FTDI232-Kabel an einen Arduino angeschlossen, das ist mein Testaufbau. Später kommt ein anderer Mikrocontroller dran. Im Prinzip funktionierte alles auf Anhieb, naja, der IC ist ja nicht komplex. Allerdings scheint der RX FIFO ein Problem zu haben. Wenn ich den ausschalte (FEN=1 im Config-Register) dann kann ich im Arduino einfach prüfen, ob ein BYte empfangen wurde und das direkt zurück senden. Im Terminalprogramm auf dem PC kommt auch alles normal an. Wenn ich aber jetzt den FIFO einschalte (FEN=0), dann gibt es den merkwürdigen Effekt, daß das Echo zum PC mit 7 Zeichen Verspätung eintrifft! Sprich, wenn ich aaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbb eintrippe, erhalte ich als Antwort aaaaaaaaaaaaaaaaaaaaaaaaaaab Es scheint so, als ob der FIFO zwar aktiv ist, aber die Signalisierung, daß noch Daten im RX-FIFO auf ihre Abholung warten irgendwie nicht stimmt. Selbst wenn man bei gesetztem R-Bit im Statuswort einfach 8mal Daten aus dem FIFO liest und zurück sendet, sendet man 8 mal den gleichen Buchstaben, der Effekt ist wie oben gleich. Diverse Seiten im Netz, welche sich mit dem IC befassen, meistens Treiber, brachten da auch kein weiteren Erkenntnisse. Ein Errata gibt es auch nicht. Hat jemand eine Idee?
Hmmm... > DOUT transitions on SCLK’s falling edge, and DIN is > latched on SCLK’s rising edge (Figure4). Der Beispielcode im Datenblatt macht die Kommunikation etwas anders als du (liest erst nach CLK high, könnte das oberste Bit (R) betreffen):
1 | uint16_t MAX_IO(uint16_t data) { |
2 | uint16_t i; |
3 | |
4 | digitalWrite(MAX_CS, LOW); |
5 | for (i=0; i<16; i++) { |
6 | if (data & 0x8000) { |
7 | digitalWrite(MAX_MOSI, HIGH); |
8 | } else { |
9 | digitalWrite(MAX_MOSI, LOW); |
10 | }
|
11 | data <<= 1; |
12 | digitalWrite(MAX_SCK, HIGH); |
13 | if (digitalRead(MAX_MISO)) { |
14 | data |= 1; |
15 | }
|
16 | digitalWrite(MAX_SCK, LOW); |
17 | }
|
18 | digitalWrite(MAX_CS, HIGH); |
19 | return data; |
20 | }
|
foobar schrieb: > Der Beispielcode im Datenblatt macht die Kommunikation etwas anders als > du (liest erst nach CLK high, könnte das oberste Bit (R) betreffen): Nein, das passt schon.
Ich hab mal ein wenig probiert und bin auch weiter gekommen. Die Abfrage der R und T Bits habe ich bisher immer über 0x8400 gemacht (Write Date mit TE=1, damit wird der echte Schreibvorgang nicht ausgelöst). Damit geht es NICHT, der Effekt ist wie oben beschrieben! Wenn man aber statt dessen 0x4000 nutzt (Read config), geht es schon besser! Es gibt keine Verzögerung durch das FIFO! Aber es klemmt immer noch was. Wenn man einen Burst von 8 Zeichen sendet, sollten die ja dank FIFO immer wieder zurück kommen, egal wie langsam das SPI bzw. der Prozessor ist. Kommen sie aber nicht! Trotz Geschwindigkeitssteigerung meiner Soft-SPI von 50kHz mit den einfachen digitalRead/Write Funktionen zu 500kHz mit Pointerzugriffen (Arduino-konform dekodiert), erscheint als Antwort bei 12345678 immer 1357, d.h. jedes 2, Zeichen verschwindet! Erst wenn man mit der Baudrate deutlich runter geht, hier auf 57k6, kommen alle Zeichen zurück, was aber anscheinend NICHT der Verdienst des FIFOs ist. Alles in allem scheint der IC an der Stelle etwas Buggy oder SEHR speziell in der Ansteuerung zu sein. Egal, für meine Tests reicht es.
Ok, irgendwie hat mir das keine Ruhe gelassen. Ich hab nochmal was probiert und siehe da, es funktioniert! Der Trick ist, daß der Schreibzugriff auf das Datenregister zum Senden von Daten auch Lesedaten liefert, wenn welche vorhanden sind! Die muss man dann auswerten, sonst sind sie weg! Das ist von den Entwicklern wahrscheinlich gut gemeint gewesen, um die Bandbreite des SPI besser ausnutzen zu können und weniger SPI-Transfers zu benötigen, aber damit wird der Vollduplexbetrieb komplizierter. Vermutlich muss man dann in der Software noch einen FIFO für RX und TX einbauen, damit die Sache aus Softwaresicht handhabbar wird. Das steht aber nicht explizit im Datenblatt, da hätte man weiß Gott mal drei sinnvolle Sätze zu schreiben können! Siehe Anhang.
Falk B. schrieb: > ich hab hier gerade einen MAX3100 mittels FTDI232-Kabel an einen Arduino > angeschlossen, das ist mein Testaufbau. Später kommt ein anderer > Mikrocontroller dran. Warum keinen vernünftigen Mikrocontroller direkt mit USART?
Rainer S. schrieb: > Warum keinen vernünftigen Mikrocontroller direkt mit USART? Weil ich eine Platine mit einem Mikrocontroller habe, bei dem alle IOs und damit auch der UART benutzt sind. Es gibt aber ein SPI und ein IO-Pin, was als Chip Select genutzt werden kann. Das Ganze ist ein Debugger für Arme. An der Platine kann und will ich nix ändern.
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.