Confirm the timings and data rate achieved through the AMDS boards

[mohamed-dek1]

Context

Related Issues / PRs: (To do: list all related issues)

• Implement daisy-chain firmware and demonstrate first data exchange on AMDS #92
• Determine achievable speeds on AMDS #93
• Demonstrate 3x AMDS’s in series using the DCP meeting timing requirements #95

We need to be able to daisy chain 3 AMDS (or FBC REVB) boards and have all the data arrive and be parsed by the AMDC at a reasonable data rate. This issue tracks further improvement to the current firmware implementation, such that we meet timing requirements.

Approach

Close this issue by:

• Implementing the new transmit and receive logic per the conversation with @elsevers and the image above.
• Ensuring that this implementation still works with 1-3 AMDS boards.

[mohamed-dek1]

Per 3/26:

Below is a successful capture from my first implementation of the new transmit scheme. There is definitely something wrong with the timing because it took 640ms to get data exchange across 2 AMDS boards.

[mohamed-dek1]

Per 3/26:

After making some further modifications, this is the current speed of the transmit function. The bottleneck at the moment is that the DMA isn't ready to send as fast as we want it, so we end up waiting for it to get free for so long. I will try to do something similar to how the previous drv_uart_putc_fast functions were working.

A single transmission

[elsevers]

Okay, so we need to figure out a non-blocking send function. This should approximately be implemented like this:

1. you create your own static/global buffer (can be circular) that you collect data to send (i.e. char dma_tx_data_staged[]) and a function that adds data to this (i.e. dma_tx_stage_data(char *data, int length). Anyone can call dma_tx_stage_data() any time. All it does is copy length bytes from data into dma_tx_data_staged and maintain any associated indices for dma_tx_data_staged.
2. you have a static/global buffer char tx_data_buffer[] which is the live data that the DMA is actively sending.
3. you notice (either via ISR or polling in your while(1) loop in main when the TX DMA is idle (i.e., tx_data_buffer is empty) and if there is data in dma_tx_data_staged you move that data into tx_data_buffer and get it going on sending it.
   • Best practice is to have a function of something like byes_read = dma_tx_unstage_data(char *buffer, int max_bytes) that will move at most max_bytes from dma_tx_data_staged into buffer and returns a count of how many bytes were actually moved in bytes_read. The dma_tx_unstage_data() function would update the associated indices for dma_tx_data_staged

Caution

If there is any possibility of dma_tx_stage_data or dma_tx_unstage_data being called from interrupts, you need to protect these functions to avoid face conditions by disabling interrupts when you enter the function and enabling them when you leave the function.

You can generalize all of these functions/variables to apply to each of the DMAs by adding an index number. I.e., dma_tx_stage_data(int dma_channel, char *data, int length) - where dma_channel tells the function which DMA to add the tx data to.

[mohamed-dek1]

Per 3/27:

I will move ahead with implementing this intermediary buffer for putting data into the DMA. Also, consider removing the 1-second stall in the main loop...

[mohamed-dek1]

Per 4/1:

After the first implementation, this is the updated capture of one AMDS trigger. It has improved significantly, but still not quite at the speeds we are looking for.