I have a project where multiple sensors must be sampled at rates of up to 4MHz. I intend to use the GPIO and would like it if I could have the bits be read into memory or buffered to allow the fast read speed. There will be a 4MHz clock line available. I would like to use the 8 GPIO’s of the J21 header and perhaps use the I2C or SPI clocks if these can go up to 4MHZ (which I doubt). The original protocol from the sensor devices is I2S (not I2C).
I couldn’t say if that will work, but I suspect it is a lot of work for you. You might consider simplifying life with a USB serial breakout board. One question is do you know the logic level, e.g., 3.3V, 1.8V of the serial data? Even if you use serial UARTs you could still use a separate clock line. Typically the FTDI serial UARTs already have drivers present on both hosts and Jetsons.
I suppose one possibility which would prevent you from using serial UARTs is if you need a single bit at a time and not bytes…you couldn’t time individual bits with a clock, you could only time bytes (the UART sends bits, but it triggers a byte at a time when it sends/receives). For anyone to answer you probably need to give more details about the sensor’s data format and level.
Here’s a google search with an example of a lot of serial breakout boards for only a tiny cost:
…you would of course need a serial UART at the sensor end as well.
Are you referring to using a USB hub to control many USB serial ports and communicate to the devices over the UART?
I’m working with a board with a level converter that lifts the 1.8V GPIOs to 3.3V logic.
Is reading the value of a GPIO into a buffer something that’s possible?
Would you just recommend one of those EZ-USB FX3™ SuperSpeed USB 3.0 peripheral controllers and use its serializer GPIO bank to read the data into the Jetson for processing?
I’m suggesting using a USB serial UART instead of GPIO. The chips used are sufficiently available (especially for FTDI) in such a way that if you wanted to build your own custom HUB+multiple UARTs you could do this…one USB cable is capable of connecting multiple USB serial UARTs. Part of the question becomes how small does it need to be? How much does weight change the issue? This would skip GPIO entirely and use existing drivers.
I do not personally believe any USB UARTS are available that can operate at that clock speed. But, you may know of one that can.
Is GPIO capable of supporting that data rate?
If not, then I will need to look into other solutions.
You’ll probably need to test to know. You should probably still describe the nature of the data and whether it can survive some delays or whether it has to be real time.
The data that the GPIO’s would see is just 24 bits at a 1.8V logic level at 4MHz.
There can be a substantial delay and even zero processing while recording data.
Unfortunately, I think the way the GPIO’s were put in, Nvidia wanted developers to be able to interface to indicators like lights or motors instead of as a data bus.
Instead they probably intended for the USB3.0, Gigabit Ethernet, and CSI2 lanes to be used for sensor data acquisition.
I think I can accept this defeat, and use a USB development board for my sensors.
Do you think my reasoning is logical?
I do think a USB board would be both the fastest and most reliable way to go. GPIO could do what you want, but it is less predictable…especially when you start wiring over more and more distance (think inches/cm, not feet/meters). I’d recommend stick to the FTDI chips. At one time I considered using GPIO for hardware emulation, but decided this was not practical at any significant data rate. Your case is actually substantially slower in requirements than my case, but there are a lot of things which all have to come together if using several GPIO at high speed synchronized to a clock.
FYI, there are several serial UARTs which operate up to 12Mbit/s if you build your own custom system. On the other hand the ULPI USB transceivers can directly interface at 480Mbit/s. There is a lot out there…here’s one example URL:
FTDI has similar product lines and often some conveniences to go with them (such as being able to use their vendor ID which shows up in the “lsusb” command).