FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - atom1477

Pages: [1]
1

Perhaps due to unaligned read/write.

Not only. USB side of FTDI sends data to PC serially, not parallely.
So even when data is written to FTDI aligned (32 bit), it may disappears from FIFO byte by byte.
When I write alligned 1024 words of 32 bits, I fill all the FIFO. But FIFO will be send
via USB byte by byte, right?
It depends on what FIFO occupancy meter is used.
TXE_N indicates 1 byte, and nonaligned writes are supported, so I guess that meter is 1 byte, and counts to 4095. Every 32-bit (aligned) write to FTDI increase FIFO occupancy by 4. But continuous transmission via USB will decrease FIFO occupancy by 1 or by 4. It depends on FTDI hardware, which is not described in datasheet.
If it decreased by 1, it will cause issue that I asking for. Even when I write only aligned 32-bit data, FTDI
may sends it byte by byte indicating 1 byte free space in FIFO.
In this situation TXE_N
is useless, because it don't give enough information to next 32-bit aligned write. To do 32-bit writes, a 4-bytes free space information is necessary.

But in Your scenario, when nonaligned writes are made, the same issue appear even when USB transmission decreasing FIFO occupancy by 4.
So I'm surprised that You made TXE_N as 1-byte free space indicator, not as 4-byte free space indicator.
Unless it's a datasheet error and it's actually a 4-byte indicator. So I ask about that.

2
But this not answers my question.
Could You clarify that 32-bit wide IO is possible or not in this mode?

3
Are TXE_N really indicates only 1-byte/8-bit free space in FIFO?

FT601Q have 32-bit input/output port. To achieve full throughput, all of this 32 bits should be used.
But:

So it looks like that only 1-byte/8-bit input is correct to manage FIFO. Wider input, with only 1-byte TXE_N indication, could cause overflow the FIFO.
Is it even possible to achieve transmit without losing some of data, in this mode and 32-input?
I misunderstand something, or it is error in the structure of FT601Q, not described in the FT601Q errata?
Or maybe it is error in description, and TXE_N really indicates free words, not free bytes?

4
I asking here because of this:

5
Of course I read Programmers Guide.
But this version (seems to be better):
https://www.ftdichip.com/Support/Documents/AppNotes/AN_407%20D3xx%20.NET%20Programmers%20Guide.pdf
Unfortunately, it does not answer my questions. It does not tell if there are FIFO buffers inside DLL, or whether PipeReadAsync is non-blocking, and able to read past data (buffered data from previous packets).

6
As I understand, synchronus WritePipe is blocking function.
Instead, asynchronus WritePipeAsync is non-blocking functions which begin a transfer and then return immediately (and also setting FT_IO_PENDING / FT_IO_INCOMPLETE status).
So there must be such a buffer inside the D3xx DLL. FIFO buffer I guess.

But what about ReadPipe functions?
I expected it would be buffer (FIFO) in receive part of D3xx DLL.
So when I call ReadPipe function, I expect to read all previous received data. Regardless of whether I use ReadPipe or ReadPipeAsync function.
But I have some issues with it.
When I use ReadPipe, I lost some data. As I see, ReadPipe reads only new packets. It waits for new packet. All packet between this and previous function call, will be lost.
Maybe I should use ReadPipeAsyns function? Is this non-blocking function? And returns all previous received packets?

7
I can include this here:

But if You prefer contact on email it is fine.
How FT601Q settings can affects behaviour, if original (not-recompiled) exe works fine with the same FT601Q settings?

8
Discussion - Software / FT60X VS C# Example not compiling and not working.
« on: November 27, 2018, 02:49:52 PM »
Hello.
I have trouble witch Yours example codes for FT601Q.
Original exe file works fine.
But when I tryed to compile project I have errors (I tried this in Visual Studio 2017 and Visual Studio 2013, on Windows 10 64-bits).
First problem is that:

I fixed this by adding reference to FTD3XX_NET.dll file, and by copying FTD3XX_NET.dll and FTD3XX.dll file files to bin/x86/Debug folder.
Then application will compile without errors and starts correctly.
But I have second error, when i connect FT601Q USB Device (Hot Plug):

The same problem occurs when I Hot-unplug USB device (start application with USB Device already connected, and then disconnect USB Device from USB socket).
In application started outside the Visual Studio trouble still occurs, but of course it doesn't provide any message text output, but simply terminate.
Why?
As I said, Yours original exe file works fine. How You compile this source codes? The same source compliled in my computer works differently.

Pages: [1]