[cags12]

Hi Jerome,
Thank you for your reply and looking into this.

I did not really mean forwarding the SYSEX directly without buffering. What I meant is to forward the data from the buffer as it is (sort of bit by bit). The IC can maintain a status flag (accessible to both threads) that gets set up as soon as it sees a SYSEX start “F0”, this would indicate to keep forwarding data from the buffer (even multiple times) as it is, until it sees the SYSEX end “F7”. At this point the flag gets unset and then going back to normal mode of operation.

I obviously do not know all the ins and outs and how the internal driver is programmed but that is just an idea on how I imagine to solve this limitation. If it is possible, It will even allow super long SYSEX messages with no need to increase the internal buffers. Does it make sense?

To answer your question:
I am receiving the long SYSEXs “BLE Rx to USB Tx”. Normally the SYSEX Dumps are done from the controller. However, the other way around is also important when restoring the Dumps back to the controller. In my specific application “BLE Rx to USB Tx” is more important (for now).

If my suggestion above about how to handle the buffering is not possible; then I have another idea on how to manage the buffer size for Rx and Tx.

The Widi Plus application can have a “settings” section where from a pool of buffer memory of the IC we can slide Tx and Rx. Say we have Tx+Rx=512 Bytes, the slide setting could allow removing buffer memory from Tx to allocate to Rx; ie: Tx(112)+Rx(400)=512 Bytes. This would “mitigate” a bit the situation and would allow the user to select what direction is more important in a give time.

How much more memory can we squeeze from the IC’s internal memory to allocating to the buffers?

Thanks again.