Forum: Mikrocontroller und Digitale Elektronik FIFO im MAX3100


von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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?

von foobar (Gast)


Lesenswert?

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
}

von Falk B. (falk)


Lesenswert?

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.

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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.

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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.

von Rainer S. (rsonline)


Lesenswert?

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?

von Falk B. (falk)


Lesenswert?

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
Noch kein Account? Hier anmelden.