Is SEND cog safe in FastSpin?

rogloh

@ersmith

I have a program which seems to work okay in PNut but not FastSpin.

In one Cog I rapidly switch the SEND output mapping between two different methods and it test whether it affects the SEND output in another Cog.

I found it randomly does output to the wrong method (one of the two chosen) in FastSpin on the Cog being tested but apparently not in PNut. I was thinking SEND is meant to be stored per Cog, not shared and I've coded accordingly to make use of that.

Is there a known or unknown issue here with Fastspin's SEND implementation? Some race condition or overlapping storage?

I'm using FastSpin 4.2.5B, I can try to update it.

rogloh

Just downloaded the latest. Same problem with FastSpin 4.3.1, it looks like there is race condition somewhere when you update the SEND mapping. Might need to be stored 32 bit aligned?

ersmith

SEND in fastspin is global, not per COG, so that's why you're having problems. Sounds like it's a bug.

rogloh

Ok thanks Eric, that would explain it then. Are you planning to make it match Chip's SPIN or keep it as a global? Separating it per COG is useful for independent redirection and objects won't clash with each other if more than one uses SEND at the same time.

Is SEND also readable at all I wonder? Are we able to read/preserve the old value of SEND if we don't know it's current mapping and then reassign it back later? Maybe this is doable, I should test it out later. it might possibly come in handy in some cases if you need to alter it setting and restore afterwards in the same function. I know each called function can have its own SEND reassignment, so that is another way to deal with this, but might be more restrictive, requiring all code doing the send to another destination to happen in deeper called functions which may not always be convenient.

Eg:

SEND := @video.tx
SEND("Hello Video",10)
save := send ' can we do this?
SEND := @uart.tx
SEND("Now the UART",13,10)
send := save ' restore
SEND("Back to video",10)