jshTransmit: Is it interrupt driven?

Howdy folks,
I'm studying jsdevices.c which, if I understand correctly, is a device independent handler of certain I/O operations for boards. As I look into it, I find jshTransmit() which appears to want to transmit a character through the UART (or other transmission vehicle). If I read it correctly, there is a section of code where we check that the buffer for output characters has nearly filled (the headNext == tail) and then we execute a loop. The loop is:

while(txHeadNext==txTail) {
}

I understand the logic ... but this seems to tell me that txTail will change outside of the primary flow of this loop and, since my target device is a single core processor, can only happen as the result of an interrupt being handled. What if UART doesn't generate interrupts on character consumption or otherwise needs processing logic? We might get into a deadlock here.

Also, on my target device (the ESP8266), the WiFi subsystem needs to be "fed" regularly. We have a "yield()" type function and I'm wondering if this needs to be exposed as a jshardware.c exposed logical capability with an invocation within this tight loop?

Still studying ... but I am hoping that there might be others in the community that have walked the insides of Espruino for board addition.

Neil

I actually wrote a little about this on the forum a week ago: http://forum.espruino.com/conversations/272743/#12452432

It's generally worth searching using google site:forum.espruino.com myKeywords as the forum's search is a bit noddy.

But yes, it's expecting that the contents of txBuffer will be read out via interrupt. Are you absolutely sure that the UART can't be fed from an interrupt, even if it's not exposed from the driver code. Pretty much every core I've seen has that capability.

There's a jshUSARTKick or similar function, which I guess could be called from that loop (and which could then do the USART send via polling). It's a pretty bad solution though - as Espruino needs a way to send characters while it's doing other stuff.

Or is this again a side-effect of the way the ESP8266 has its own RTOS. Maybe it does it's own output buffering and IRQ-driven output? If you did LED1=1;print("Hello World");LED1=0 in the ESP8266, would the LED go out before the text had finished sending? If so, you could actually change jshTransmit such that transmits to the UART don't ever go in txBuffer and just go straight to the ESP8266's RTOS.