Hi All,
I am building a DAC/ADC solution that communicates via a custom tcp/ip protocol with a host computer. I have host software that sends commands to the XMOS and receives data for visualization. So far I have a lot of it working, but have run in to a problem bringing up the analog read capability because it dumps a pretty good amount of data back to the host.
in thread 1 (T1) I use a select statement to either output instructions received from tcp to T2, or output data received from T2 to TCP.
This worked great until T2 had to spend a while receiving the data. Now T1 gets a command and tries to open a channel to T2, but T2 is trying to open a channel to T1 and both threads are frozen inside their select statements.
I'm wondering if there is common design pattern to deal with this situation or if I need to re-think my event handling architecture (probably the latter, but I keep on running into situations that I feel the need to buffer a lot, and this doesn't seem to fit into XMOS philosophy).
bidirectional spontaneous event design pattern
I had similar problems where I had two threads communicating with each other over a single channel. Either thread could initiate transmission, and sometimes the system would throw an ET_ILLEGAL_RESOURCE exception when both threads would try to simultaneously transmit on the channel.
It is easy to run into deadlock problems if you use two channels between two threads, each channel used unidirectionally for each direction.
There is a useful module in sc_util called module_mutual_thread_comm that can be used to implement spontaneous transfers from either of two threads over a single channel. The idea is to have one thread act as a ReactiveMaster and the other thread as a NotifyingSlave. When the ReactiveMaster wants to send data, it does it immediately. When the NotifyingSlave wants to send data, it notifies the ReactiveMaster and waits for permission, while actively looping, before actually sending.
See app_mutual_comm_example in sc_util for an example of using the module.
It is easy to run into deadlock problems if you use two channels between two threads, each channel used unidirectionally for each direction.
There is a useful module in sc_util called module_mutual_thread_comm that can be used to implement spontaneous transfers from either of two threads over a single channel. The idea is to have one thread act as a ReactiveMaster and the other thread as a NotifyingSlave. When the ReactiveMaster wants to send data, it does it immediately. When the NotifyingSlave wants to send data, it notifies the ReactiveMaster and waits for permission, while actively looping, before actually sending.
See app_mutual_comm_example in sc_util for an example of using the module.