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 - Jaholmes

Pages: [1]
1
Discussion - Software / Re: Best practices for low-latency, low-data-rate writes from PC to device
« on: December 01, 2021, 08:02:30 PM »
Thank you, I'd love to get a copy of the draft app note.  I'll email shortly.

Yes, I'm familiar with Purge().  In this instance, I'm not looking to discard anything, though as a general rule we do Purge() the RX and TX buffers upon first connecting to the device just to minimize consumption of stale data at both ends of the cable.

To the docs thing:  That would be great also.  I'll often scratch my head while reading the datasheets and app notes when I come across terms like "transmit" and "receive," because they obviously mean very different things according to whether you're talking about the host PC or the chip, and if the chip, then whether you're talking about the USB side or the UART/parallel/etc. side.  Sometimes the context is enough to disambiguate, but often times it's not, at least not for me.  I'm all for excessive explicitness when it comes to these things.  (Then I don't have to come here and ask possibly dumb questions either! :))

2
Discussion - Software / Best practices for low-latency, low-data-rate writes from PC to device
« on: November 30, 2021, 04:03:26 PM »
I was somewhat amused to discover that the application note on latency contains exactly zero instances of the word "write," heh.  Sigh...  Obviously there will be a lot of platform dependencies here, but I'm curious if FTDI can offer any guidance on best practices for minimizing PC->device latency, specifically in situations where the data rate is very low.  As I understand it, the latency timer only applies to data being moved from device to PC.  If I write only a single byte using FT_Write() (not exactly a real-world scenario for me, but for discussion's sake...), how much buffering is done by the driver?  What, if anything, can be assumed about the frequency with which that buffer will be committed to USB if not completely filled?  D2XX does not appear to have any analog of a "flush" operation.  Would it be better if I used VCP and the Windows serial API, which does have a flush?  Does VCP do anything special when the associated port is "flushed" via the Windows serial port API?

I expect these questions have all been asked many times before, however all searches for latency seem to lead to the FTDI app note on latency, which appears solely concerned with latency device->PC and not the other way around.

(As an aside, it would be great if FTDI could make a quality pass on their documentation.  As it stands, there are just far too many ambiguities and outright contradictions, and in places that are pretty unbecoming of a communication device company, as they pertain to such basic terms as "transmit," "receive," and "buffer."  As an example, the product page for the FT232R talks about "256 Byte receive buffer and 128 Byte transmit buffer..." and "Adjustable receive buffer timeout," while in the datasheet you have "128 byte receive buffer and 256 byte transmit buffer."  The datasheet says nothing about the "receive buffer timeout," which in other documentation is called the "latency timer," and is described as pertaining to transmit, not receive.  As well, the block diagram for the device doesn't refer to buffers, but to FIFOs, making one wonder whether they're truly the same thing.)

3
Discussion - Hardware / Re: ft245 (232 or 2232 in 245 mode) interface to 68000 bus?
« on: December 18, 2019, 05:39:54 AM »
Quote from: mc68000 on December 14, 2019, 07:16:25 PM
If I can get more than 1MBPS out of this setup, I'd be very happy. (I'm guessing that those SCSI cards and Ethernet controllers for say the Mac Plus, likely got nowhere near that much bandwidth, and likely they used DMA.)
I don't know about DMA, but lowendmac.com says the Plus could do about 250kbytes/sec, which seems pretty darned good to me, actually.  Getting 1Mbyte/sec with just an 8MHz 68k plus an FT245 is going to be really difficult, I fear.  The minimum bus cycle on the 68k is 4 clocks, and you'll be burning a few of those just to fetch your write instruction.  So that 8MHz divides down really fast.  Especially if you're wanting to do more than just spam the FT245--which seems a foregone conclusion.

Using a dual-port device for 16-bit writes is interesting.  I like abuses like that in general, although I'd probably favor a wider single port out of sympathy for whoever or whatever is at the other end of the pipe.  And I'd still call 1Mbyte/sec a feat at 8MHz sans DMA.

But post your results!

Years ago, I mated a UM245 module to an 80MHz chipKit board and wrote byte as fast as I could.  At the other end, on Windows, I wrote a little D2XX app that implemented all the throughput tips from the FTDI app notes and just sucked down bytes as fast as it could.  (This was to see how fast I could stream samples from a sensor.)  IIRC, I was able to sustain about 990kbyte/sec.

Quote from: mc68000 on December 14, 2019, 07:16:25 PM
Yes, that PLD does sound interesting actually, that might save me a bunch of work elsewhere, thanks for the tip!
I take it stuff like flops and tri-state buffers, address muxes can be built in that PLD, or if not maybe one with more pins?
Yeah.  This thing is a living fossil--one of the only remaining PLDs on the market where you can look at the logic diagram in the datasheet and actually grasp the capabilities of the device.  It does have (optionally) registered outputs with tristate buffers, but you might find it more useful for basic async combinational stuff like address decoding.  It's amazing how many elementary logic gate ICs you can replace with one of these.  Plus, again, they date from the early 80's (just with flash instead of OTP fuses), so you're not poisoning your retro build with too much stuff from a different millennium--in case that matters to you.  (When you download the CUPL tools from Microchip, you'll be amused to see that all the code samples are dated from the 80's too. :)))

You'll need a programmer for these devices.  If you don't already have a somewhat general-purpose programmer, there are some good cheapies around.  I like my XGecu TL866II Plus (~$60).  There's probably a newer version (or two) by now.

4
Discussion - Hardware / Re: ft245 (232 or 2232 in 245 mode) interface to 68000 bus?
« on: December 03, 2019, 04:13:26 PM »
Hey there, mc68000 - Fellow retro computer engineering hobbyist here. :)  I don't have any schematics to share, but I have a few comments:  First off, the FT245 is a 5V-capable device.  Supply 5V to VCC and VCCIO.  No level translation needed.  Regardless of interrupts, you'll still want a way to poll the FT245 for status, as sending a block of data with interrupts between every byte would be horrendous, performance-wise.  So, map the TXE# and RXF# using a tri-state buffer at some other memory location.  You may have other peripherals with similar needs, so you can probably find things to do with the remaining bits.  /DTACK is a larger topic, but if you're using all reasonably fast peripherals and memories you might get away with simply tying /DTACK to ground, as many others have done in simplistic designs.

If your memory map and selection of peripherals are complex, however, you might bite the bullet and throw a cheap PLD into the mix.  A little will go a long way.  I recently did a 6502 build and fit all the address decoding into a $1.50 22V10 chip.  They're still available from Digikey, and you earn extra 'retro' bonus points by programming them in the ancient CUPL language. ;)

5
Discussion - Hardware / 245 FIFO modes: Ok for WR to remain high between writes? (FT240X, FT245)
« on: December 02, 2019, 05:31:45 PM »
I'm building a USB sensor application using discrete logic--no MCU or CPU.  I have a few candidate designs drawn up, and noticed that I could simplify things if it was permissible to keep WR normally high, then pulse low-high to write.  Datasheets for the FT240X and FT245 are a bit ambiguous about this.  I should mention that I'm also reading bytes, so RD must also being pulsed low-high periodically.  Can this happen while WR is held high--without anything bad happening?  Or must WR be low to read?  I'd guess it would be ok, but figure I ought to put it out there just in case.

Very best,
Aaron

Pages: [1]