Asynchronous Notifications

[babazaroni]

I would like to poke a core that is waiting in a select statement asynchronously. The core would then check a fifo for some events and not need to contact the poker for anything. I want the poker to not have to wait for a response, because the core could be busy responding to another event.

I was under the impression that outct(chan_poke_server,XS1_CT_END) should do the job, but it seems that if there are too many pokes without the target of the poker reading the channel, the poker will wait till the channel begins emptying its control tokens. The channel seems to have a capacity of about 7 tokens before it fills up.

So, is there any way to avoid locking up like this? Any other way to do an asynchronous notification of another core?


(interface notifications are out, as they require clearing the notification by calling the notifier. This creates race condition in my application)

[infiniteimprobability]

The architecture is designed to block when the channel is full to preserve it's CSPness..
It sounds like you are going cross tile if the other side can swallow 7 tokens before blocking, so I won't suggest shared memory with locks.

Only other thing I can think of suggesting is using outuchar/inuchar to make 4x better use of the channel buffering...

Have you considered an interrupt at the receiving end? That will let you be more asynchronous but of course things get a bit more complicated timing-wise.

[babazaroni]

Thanks, both good ideas. I had forgotten about interrupts as I've only seen them used in the usb audio firmware and they seem to be discouraged.

[infiniteimprobability]

Interrupts are not supported by the tools directly, so taking something like the UAC2 source is a good move. They have dangers though (especially when mixed with events which have strict timing constraints), but used correctly can be very useful.. Kind of like a single high priority event.