FTDI & MATLAB 1Mbit/s

[Robert B. (robert_b36)]

Hallo zusammen,

Ich plane, einen FT232RL einzusetzen und würde gerne aus MATLAB heraus 
Daten in Echtzeit auf den Controller streamen. gefordert wären so ca. 
1MBit/s. Der FT232 kann ja lt. DB bis 3MBit/s. Das würde also schon mal 
gehen. Meine Frage wäre, ob jemand schon mal aus MATLAB heraus mit einem 
COM-Port und einer Übertragungsrate von 1MBit/s gearbeitet hat? Der 
FTDI-Treiber sollte diese Baudrate ja eigentlich unterstützen, wenn der 
Chip es tut, oder?

Ich weiß, dass es andere Möglichkeiten gibt, das außerhalb von MATLAB zu 
lösen, wäre aber schön, wenn es direkt in MATLAB gehen würde.

VG
Robert

[Uwe (Gast)]

> Daten in Echtzeit auf den Controller streamen
Vergiss das mal gleich wieder. Für Echtzeit braucht man ein Echtzeit OS.
Läuft dein MathLab auf nem Realtime OS ?

zu USB:
- ist nicht Echtzeitfähig auch wenn du ein Realtime OS laufen hast
- Isochroner Transfer hat zumindest eine garantierte Datenrate aber 
keine Fehlerkorrektur
- Interrupt-Transfer hat Fehlerkorrektur und ist teilweise 
deterministisch da bei Übertragungsfehlern nur 3 mal wiederholt wird.

[Dominik S. (dasd)]

Uwe schrieb:
> Vergiss das mal gleich wieder. Für Echtzeit braucht man ein Echtzeit OS.

Spricht er hier von "echter" Echtzeit oder von "Echtzeit" im 
umgangssprachlichen Gebrauch (also im Sinne von kontinuierlich bzw. das 
was aus MATLAB rauskommt sofort auf den µC senden).
Denke mal nicht, dass er tatsächlich harte Echtzeitanforderungen stellt 
(oder doch?).

[Robert B. (robert_b36)]

Hallo zusammen,

danke erstmal für eure Antworten. Das hätte ich genauer erläutern 
müssen. Also es geht eigentlich lediglich um einen kontinuierlichen 
Stream von etwa 1MBit/s, also eher der umgangssprachliche Gebrauch. Der 
Controller soll die Daten mit einer fixen Samplerate auf mehreren DACs 
ausgeben. So der Plan. Fehlerkorrektur spielt erstmal keine Rolle.

Ich denke eigentlich schon, dass über USB ein zuverlässiger Stream von 
1MBit/s möglich sein sollte oder? Vom Prinzip her ist schon klar, dass 
USB an sich nicht echtzeitfähig ist, aber ich denke 1MBit/s über einen 
virtuellen COM-Port sollte möglich sein, sofern solche Übertragungsraten 
eben von MATLAB unterstützt werden, was zurück zur ursprünglichen Frage 
führt. Hat das schon mal jemand gemacht?

VG
Robert

[Uwe (Gast)]

Wenn kein anderes Gerät am USB dran ist, also auch keine Maus keine 
Tastatur USB-Stick usw. KÖNNTE es EVENTUELL, VIELEICHT klappen.
Weil jedes Gerät Frames zugeordnet bekommt.
Also:

1. FTDI ist dran und empfängt 512 Bytes in 1ms und ab in Puffer (FIFO) 
und mit 1Mbit auf RS232 ausgeben
2. Maus ist dran und Sendet nen Paar Bytes dauert auch 1ms (oder 
Länger!)
3. Tastartur ist dran ...
4. Explore guckt auf USB Stick ... oder was auch immer
--- so wenn hier jetzt mehr als 5,12ms vergangen sind gibs nen aussetzer 
am RS232 Stream
5. FTDI ist wieder dran ...

Also Kaugummie in alle anderen Ports und hoffen das Windows gerade 
nichts besseres zu tun hat als sich um USB zu kümmern.

Isochron kann FTDI nicht !
Nur Bulk wenn ich mich nicht täusche.

[TestX .. (xaos)]

benutzt auf KEINEN fall die VCP treiber und das matlab serial 
zeug..totlangsam....
die nativen ftdi treiber sind da pflicht

[Martin K. (skiko)]

> die nativen ftdi treiber sind da pflicht

Das Ganze würde mich auch interessieren. Hast du schon Erfahrung mit dem 
direkten Ansprechen der Treiber?

Mfg
Martin

[Robert B. (robert_b36)]

Ok, also ich hör da raus, dass das so über VCP nicht zuverlässig 
funktionieren wird. Danke Uwe.

@Andi: Meinst du, mit dem nativen FTDI Treiber geht das, was ich 
vorhabe? Hast du damit schon mal in MATLAB gearbeitet? Ein paar Infos 
wären cool. Danke!

VG
Robert

[quik (Gast)]

naja, ich hab mal gehört, das die VCP auf 300kbit/s beschränkt sind. 
Inwiefern das mit neuen **doof Versionen noch zutrifft, weiss ich jedoch 
nicht. Jedenfalls müsste dann mit der FTDI-Dll gearbeitet werden. Und 
soweit ich weiss, gabs da noch spezielle Dinge zu beachten, will man 
über die 980 kBaud hinaus, seitens der FTDI Konfiguration.

[quik (Gast)]

http://www.mathworks.com.au/matlabcentral/fileexchange/28875-testftd2xxnetbitbang

[quik (Gast)]

http://www.codeproject.com/KB/DLL/matlabconnector.aspx

[j. c. (jesuschristus)]

Man sollte dabei bedenken, dass Matlab nicht zwei Dinge gleichzeitig 
machen kann! Daten streamen und gleichzeitig verrechnen ist nicht. Immer 
nur Blockweise. Bei mir hat Matlab 64bit und FTDI immer gut 
funktioniert, nur 1 MBit habe ich nie gebraucht.

[Michael F. (startrekmichi)]

Wir haben an der Uni eine Simulink-Simulation am laufen, die per FTDI 
mit der Hardware redet. Die Simulation selbst läuft mit 1kHz, die 
C-S-Function (die dann wirklich die Daten an den virtuellen COM-Port 
rausschiebt) aber nur mit 100Hz, mehr geht unter Windows wahrscheinlich 
auch gar nicht. Baudrate liegt bei 1M, an eigentlichen Daten geht aber 
gar nicht so viel drüber.

Harte Echtzeit ist das natürlich nicht, reicht aber für unsere Zwecke 
aus. Mit irgendwelchen Standard-Matlab-Blöcken brauchst du glaube ich 
gar nicht erst anzufangen, das ist alles viel zu langsam.

[Robert B. (robert_b36)]

@quik: Danke für die Infos und die Links!

j. c. schrieb:
> Man sollte dabei bedenken, dass Matlab nicht zwei Dinge gleichzeitig
> machen kann! Daten streamen und gleichzeitig verrechnen ist nicht. Immer
> nur Blockweise. Bei mir hat Matlab 64bit und FTDI immer gut
> funktioniert, nur 1 MBit habe ich nie gebraucht.

@j. c.: Ja, das hätte ich auch nicht gewagt, sowas mit MATLAB zu 
versuchen, glaub ich. Die Signalverläufe sollen in MATLAB definiert 
werden. Wenn sie fertig sind, sollen sie nur noch gestreamt werden. Ich 
dachte eigentlich, dass 1 MBit/s nicht so schnell ist, dass es da schon 
Probleme gibt, ist aber scheinbar doch so.

Naja, alles in allem ist das auch nicht so hoch brisant, dass das jetzt 
funktionieren muss. Wäre ein nettes Addon, wenn man direkt streamen 
könnte. Eigentlich reicht es, wenn die Daten auf dem Gerät 
zwischengespeichert werden und dann abgespielt werden. Werde es bei 
Gelegenheit dann einfach mal ausprobieren.

@Michael: Danke auch dir für den Hinweis!

Viele Grüße
Robert

[Christian R. (supachris)]

Wenn du genügend Hardware-Puffer hast, geht das. Aber ungepuffert wird 
das nix. Windows ist nun mal kein Echtzeit-OS, und MatLab ist noch viel 
viel weiter von Echtzeit entfern. Da braucht man echt Zeit, wenn man 
damit was machen will. Also großen Puffer auf der Hardware vorsehen und 
dann die Daten auf jeden Fall blockweise übertragen und zwar mit den 
vollen 3 MBit/s, damit du auch mal Lücken haben kannst. Gerade bei USB 
macht das OS nämlich dauernd irgendwelche Lücken, und das ist nicht auf 
Windows beschränkt. Auch unter Linux ist USB in dieser Hinsicht nicht 
besser.

[Max (Gast)]

Ich verwede problemos im Simulink 1Mbit mit FTDI oder 1.228.800 bps mit 
PL-2303(!). Beim FTDI spreche ich, natürlich, direkt mit dll (hier nur 
eine Idee):

#include <windows.h>
#include <stdlib.h>
#include <stdio.h>

typedef unsigned long ULONG;

#include "FTD2XX.h"

char *pError;
static FT_HANDLE ftHandle;

void CSerCommOpen(void)
{
    FT_STATUS ftStatus;
    UCHAR LatencyTimer;

    if(ftHandle == 0)
    {
        ftStatus = FT_OpenEx("MYUSB_ID", FT_OPEN_BY_DESCRIPTION, &ftHandle);   // <- change USB-ID here!!!!!
        if (ftStatus == FT_OK)
        {
            ftStatus = FT_Purge(ftHandle, FT_PURGE_RX | FT_PURGE_TX);
            ftStatus = FT_SetBaudRate (ftHandle, 115200*4*2);  // maximum 921600 bs
            ftStatus = FT_SetDataCharacteristics (ftHandle, FT_BITS_8, FT_STOP_BITS_1, FT_PARITY_NONE);

            ftStatus = FT_GetLatencyTimer(ftHandle, &LatencyTimer);
            if(ftStatus == FT_OK && LatencyTimer != 2)
                ftStatus = FT_SetLatencyTimer(ftHandle, 2);
            ftStatus = FT_SetTimeouts(ftHandle, 1000, 0);  // 1sec timeout
        }
        else
        {
            pError = "USB Open Error";
        }
    }
}

BOOL CSerCommClose(void)
{
    FT_Close(ftHandle);
    ftHandle = 0;
}

void SerCommWrite(char *p, int len)
{
     FT_STATUS ftStatus;
     DWORD m, n;
     char buf[80];
     int ret = 0;

  ftStatus = FT_Write (ftHandle, p, len, &n);
        if(ftStatus != FT_OK)
        {
            pError = "USB Error on Write";
        }
}

char *SerCommRead(char *p, int len)
{
    FT_STATUS ftStatus;
    DWORD m, n;
    static char buf[256];

    ftStatus = FT_Read(ftHandle, buf, len, &m);
    //      printf("Status:%d, returned:%d\n", ftStatus, m);
    if(ftStatus != FT_OK)
     {
                    pError = "USB Read Timeout";
     }

  return buf;
}

[TestX .. (xaos)]

sry für die späte antwort
Martin K. schrieb:
>> die nativen ftdi treiber sind da pflicht
>
> Das Ganze würde mich auch interessieren. Hast du schon Erfahrung mit dem
> direkten Ansprechen der Treiber?
ja ich benutze die quasi nur noch, meistens aber mit dem JD2XX wrapper 
für java

Robert B. schrieb:
> @Andi: Meinst du, mit dem nativen FTDI Treiber geht das, was ich
> vorhabe? Hast du damit schon mal in MATLAB gearbeitet? Ein paar Infos
> wären cool. Danke!
ja das geht. habe das bisher über die JD2XX wrapper eingebunden und das 
ging bisher immer problemlos - das nervige ist nur der austausch der 
datenstrukturen zwischen java<>matlab.
die dll direkt einzubinden habe ich bisher noch nicht versucht, wird 
aber mal zeit. gibt ja einige dll loader mit denen man die libs direkt 
ansprechen kann

[Purzel H. (hacky)]

Der Grund fuer Matlab ? Sie haben bei der Mathematik etwas weiter 
gedacht wie der Standard C Programmierer. Aber Mutitthreading & 
Kommunikation ? Kann man das vernuenftig ansteuern ? Allenfalls kann man 
den Mathematikteil in C oder so neu schreiben, und die bessere 
Infrastruktur bezueglich Kommunikation und Mutithreading verwenden. Es 
ist ja unwahrscheinlich, dass die Kommunikation das einzig Zeitkritische 
ist. Die Mathematik ist nicht zeitkritisch. Was haengt denn sonst noch 
dran ?

Falls das FTDI es nicht hinbekommt, gibt es auch einen Nachfolger, auch 
wieder von FTDI : Serial zu USB-2, da gehen 10MByte drueber.