Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Is there a document available or in the works describing the FX3's peripheral register set (GPIO, UART, I2C, etc.)? I've read the datasheet, app notes, SDK documentation, and a number of firmware examples and they all assume the firmware stack API is used to interact with the peripherals. Are there any examples available that illustrate direct access to the peripherals?
Unless I'm misunderstanding something, without the peripheral register set, I wouldn't be able to develop an application without using the SDK which prevents me from accessing the peripherals in assembler if I run into performance issues. In some cases, the overhead of the API in both code space and time may make it difficult or impossible to take full advantage of the part's maximum performance.
In my application, I'd like to capture and decode long series of pulses that can be as short as 500 nS. My plan is to capture the widths of these pulses in an FPGA and stream them through the FX3 to a PC where they can be decoded. However, the Programmer Manual makes reference to what appear to be hardware timers associated with GPIO pins that can be used for pulse width measurement and other timing functions but there is no description of these registers or the capabilities of the timers and they don't appear in the block diagram of the part. The core has more than enough processing power to decode the pulses in real-time and if there are indeed hardware timers on the chip, I could eliminate the FPGA, but the overhead of an API and RTOS could significantly cut into the time available for decode or potentially affect the accuracy of the timing. Perhaps these hardware timers won't meet my needs, or I may be mistaken and they actually don't exist, but without a hardware desciption of the peripheral set, I can't tell.