FPGA + FT232H

[amadeok]

Hello
I'm working on a project to make a sort of eink pc monitor and we were discussing with the guy who made a Eink controller board ( https://github.com/vroland/epdiy) on how we could get the data fast from the pc to the board. We already have something working:
But we are using the ESP32's wifi to transfer the data and it's quite slow at 20mbps in particular to do greyscale.
So we wanted to use a FT232H in 245 synchronous fifo mode which is a 8 bit parallel bus with a clock at 60mhz to transfer the data from the pc, but we would need some sort of FPGA to receive the data, and once it's  in the fpga, we could write it to the display. It seems we cannot attach the ft232h directly to the display because eink displays usually have a buffer of only around 200-400 bytes in which a row is store before it is written, and making hundreds of calls to the ft232h write function seems to add way too much delay, while if we can send a whole framebuffer (300kilobytes) in one function call would be very fast.
So, i'd like to ask if someone could advice some fpga maybe from altera or xilinx that can store around 300-500  kilobytes of data in its logic cells or memory blocks, one that i was looking was the EP4CE6E22C8N .
thanks

[BrianHG]

Before you consider the FPGA route, if you have experience developing with FPGAs, then OK, you understand what you are in for.

Otherwise, I would first look at 32bit MCU, like a PIC32 with a full speed USB built in to interface with the screen.  Some of the larger ones have 512kilobytes or even 1megabyte and a DMA IO port fast enough for your app.  You will have the luxury of a C compiled code environment which you may already be used to.  You might get away with a much cheaper design, no bootprom, and very-very low power consumption, & fewer parts.

Yes, there is no question that an FPGA with USB interface will work for you.  You will probably use a smaller one than the one you listed with some external ram.  Remember, FPGA internal ram is listed in bits, not bytes, and not all of it may be accessible.

As an option, if you can successfully get this board for 37$ (Don't pay more), it already has plenty on it for you to play with and proper Verilog/VHDL code will run on smaller parts like the 'EP4CE6E22C8N' as well.  (This guy has 594kbits of ram, or, you can expect to get 64 kilobytes of usable on-chip ram.)

[FlyingDutch]

Hello @amadeok,

first device from seven series of Xilinx (sorting ascending by price) is Spartan7 model XC7S50 wich has 2,700 Kb of Block RAM what is about 337  KB.
You can make a frame-buffer in this Block RAM of this FPGA (dual-port). You can also consider use of external SRAM IC - for example one of them:

https://www.tme.eu/pl/en/details/61lv25616al-10tli/parallel-sram-memories-integ-circ/issi/is61lv25616al-10tli/

https://www.tme.eu/pl/en/details/61lv5128al-10tli/parallel-sram-memories-integ-circ/issi/is61lv5128al-10tli/

But in such case you have to additionaly implement SRAM controller on FPGA - there is free IPCore for Xilinx devices (for seven series of FPGA).

Regards

[SiliconWizard]

Just a note, but the FT232H (like the FT2232H) has an internal FIFO - which means data transfer from the host side (PC) is "handshaked". You can send a whole large buffer in just one write call. The driver will send it by chunks and will wait for the FIFO when it's full, so there's no loss of data. So the question is just if you can read data fast enough - from the device side - to update the "screen" in a reasonable amount of time. But there is no need for an intermediate buffer here. There would be if the display you were handling needed constant refresh, but eInk displays do not.

BTW, what's the use of an eInk "monitor"? eInk displays are pretty slow to update, so that's probably for very infrequent image updates?

[amadeok]

Before you consider the FPGA route, if you have experience developing with FPGAs, then OK, you understand what you are in for.

Otherwise, I would first look at 32bit MCU, like a PIC32 with a full speed USB built in to interface with the screen.  Some of the larger ones have 512kilobytes or even 1megabyte and a DMA IO port fast enough for your app.  You will have the luxury of a C compiled code environment which you may already be used to.  You might get away with a much cheaper design, no bootprom, and very-very low power consumption, & fewer parts.

Yes, there is no question that an FPGA with USB interface will work for you.  You will probably use a smaller one than the one you listed with some external ram.  Remember, FPGA internal ram is listed in bits, not bytes, and not all of it may be accessible.

As an option, if you can successfully get this board for 37$ (Don't pay more), it already has plenty on it for you to play with and proper Verilog/VHDL code will run on smaller parts like the 'EP4CE6E22C8N' as well.  (This guy has 594kbits of ram, or, you can expect to get 64 kilobytes of usable on-chip ram.)

Hi yes in fact i started getting fpgas then i realized that is a whole new different thing to learn from programming MCUs
an mcu with high speed usb would be great i was also looking into the stm32 but most of them don't have a built'in phy for hs usb, except for some like the STM32F730Z8, STM32F730I8, and the STM32F73xVx, STM32F73xIx, and STM32F73xZx , and i were not able to find any development boards for these chips so i would have to find maybe a open source pcb for them.

Just a note, but the FT232H (like the FT2232H) has an internal FIFO - which means data transfer from the host side (PC) is "handshaked". You can send a whole large buffer in just one write call. The driver will send it by chunks and will wait for the FIFO when it's full, so there's no loss of data. So the question is just if you can read data fast enough - from the device side - to update the "screen" in a reasonable amount of time. But there is no need for an intermediate buffer here. There would be if the display you were handling needed constant refresh, but eInk displays do not.

BTW, what's the use of an eInk "monitor"? eInk displays are pretty slow to update, so that's probably for very infrequent image updates?

Are you sure it is handshaked? because i'm able to start a transfer of 1gb  using FT_Write() simply by pulling a couple pins low by shorting them to ground (without any other connection)and with a single call of  it goes at speeds of 30-40 megabytes per second, whereas calling FT_Write() 825 times with transfer of 300 bytes takes 85ms in my pc. Then again i heard that the ft232h 245 sync fifo mode does not work properly in linux (where i've been testing). In fact the displays we use pretty much all have 8 pins for data and a clock, seems perfect for the ft232h, but the displays can only hold around 200-400 bytes (a row) at a time before having to actually write the data to the display.

If you see the video i posted you can see pretty much the speed it goes, it's about 10fps when the screen didn't change much, and drops to around 5-6 fps when a lot changed (because of the speed of the wifi transfer). I've been using it for office work/programming, and it can work with some compromises. it's not perfect but my eyes hurt less so i use it.

[rstofer]

The Teensy 4.1 is very fast at 600 MHz and implements both USB host and USB Device.

https://www.pjrc.com/store/teensy41.html

I haven't used the board for USB so I don't know what the library includes.

[SiliconWizard]

The Teensy 4.1 is very fast at 600 MHz and implements both USB host and USB Device.

https://www.pjrc.com/store/teensy41.html

I haven't used the board for USB so I don't know what the library includes.

I have tested a few things with the Teensy 4.1 and the NXP SDK, and there are a number of USB device (and host) example projects, including CDC. Definitely an option here.

[gnuarm]

I recommend you try something easy to work with like a Raspberry Pi.  You won't be limited by the CPU in any way although you may need to learn some details of the OS to make sure it is out of the way.  That should be the simplest way of getting something going. 

Once you get that running, it wiil be much easier to get another device going such as a smaller MCU or an FPGA. 

There are many bottlenecks in this data path, so tackle them separately with devices that provide good tools.

I don't understand your numbers.  The eInk device does not accept data fast.  You can see the screen update as it flashes a few times to erase the previous screen.  Sections can be updated more quickly.  I see your images scrolling and video.  I was not aware that could be done on eInk.

[amadeok]

I recommend you try something easy to work with like a Raspberry Pi.  You won't be limited by the CPU in any way although you may need to learn some details of the OS to make sure it is out of the way.  That should be the simplest way of getting something going. 

Once you get that running, it wiil be much easier to get another device going such as a smaller MCU or an FPGA. 

There are many bottlenecks in this data path, so tackle them separately with devices that provide good tools.

I don't understand your numbers.  The eInk device does not accept data fast.  You can see the screen update as it flashes a few times to erase the previous screen.  Sections can be updated more quickly.  I see your images scrolling and video.  I was not aware that could be done on eInk.

I see and a raspberry pi is capable of producing all the timing critical signals that the display requires? Here there's some info on what they need: http://essentialscrap.com/eink/
I did consider a raspberry pi but i didn't know if it was suitable to produce precise signals like MCUs do.
With a board that provices low level control on the signals we can pretty much control every pixel in the display, so yes it can be fast, and there is the dasung eink monitor which is an actual hdmi commercial monitor and it's even faster

[gnuarm]

From the web page you linked,

To drive a plain E-ink panel, you need to provide it with specified supply voltages and to drive the digital signals with the timing that it expects. Unlike with normal TFT-panels, E-ink screens do not have a minimum refresh rate so you can do this even on a very slow microcontroller.

This will suffice to get your logic down and learn about the timing.  The interface is similar to an SPI port, but with a bit of control signals for managing the details.  I was looking at the rPi for something requiring careful timing and it is possible from the rPi.  It has a DMA port which can be programmed for a very high speed to output up to 8 signals if I recall. 

Ultimately a simple FPGA is ideal for driving an eInk display, but it is better to tackle one new thing at a time.  You are already familiar with programming sequential CPUs, so play with an rPi to learn about the eInk device with that, then switch to an FPGA if needed.

I reread your initial post and I expect I don't really understand your problem.  You are saying you have something working in an ESP32, but the 20 mbps link rate isn't fast enough.  What speed are you shooting for?  The web page doesn't indicate write pulse timing.  How fast can you get data into the display?

I will say it has always irritated me that the display makers don't give this information to users.  It seems the controllers are made by separate companies and the display makers don't actually set the rules.  Very odd.  Somewhere I have a video from a guy who is showing how to do partial updates on a display that isn't rated for them, if I recall properly.

[amadeok]

From the web page you linked,

To drive a plain E-ink panel, you need to provide it with specified supply voltages and to drive the digital signals with the timing that it expects. Unlike with normal TFT-panels, E-ink screens do not have a minimum refresh rate so you can do this even on a very slow microcontroller.

This will suffice to get your logic down and learn about the timing.  The interface is similar to an SPI port, but with a bit of control signals for managing the details.  I was looking at the rPi for something requiring careful timing and it is possible from the rPi.  It has a DMA port which can be programmed for a very high speed to output up to 8 signals if I recall. 

Ultimately a simple FPGA is ideal for driving an eInk display, but it is better to tackle one new thing at a time.  You are already familiar with programming sequential CPUs, so play with an rPi to learn about the eInk device with that, then switch to an FPGA if needed.

I reread your initial post and I expect I don't really understand your problem.  You are saying you have something working in an ESP32, but the 20 mbps link rate isn't fast enough.  What speed are you shooting for?  The web page doesn't indicate write pulse timing.  How fast can you get data into the display?

I will say it has always irritated me that the display makers don't give this information to users.  It seems the controllers are made by separate companies and the display makers don't actually set the rules.  Very odd.  Somewhere I have a video from a guy who is showing how to do partial updates on a display that isn't rated for them, if I recall properly.

Yes i have it working already, i'm using the Epdiy controller board which supplies the positive and negatives voltages that the display requires. THe display i use is the ED097TC2 which is the fastest supported by that board. The Epdiy board uses the esp32's 8bit parallel i2s interface in lcd master transmitting mode to send the data to the display. From the datasheet of the display (https://www.welectron.com/mediafiles/datasheets/waveshare/Waveshare-9.7inch-e-Paper-HAT-Datasheet.PDF ) it seems that the minimum frequency of the clock (which is labeled XCL) for the display is 16ns which i believe should be almost 60Mhz .
I'd like a speed of maybe 10 megabytes/s or higher, but to do greyscale maybe we could need more. I found Sams70 based boards on aliexpress, i'd like to try one as it says they support HS USB