There are actually two different queues - a TX and an RX queue. RX handles watches and Serial/USB input, and TX handles Serial/USB output. It's best to think of it as the interface between interrupts - interrupts put data in the RX queue, and get data from the TX queue.
And yes, you're right about the while loop - interrupts will be grabbing data and moving txTail up towards txHead in the background. Ideally the while loop would never get hit in most cases (the TX queue is 64 characters) but if you're sending data out faster than the serial port can transmit then it doesn't have much choice - it shouldn't drop characters, and saving them into memory would just fill up the available RAM after a few seconds.
32 is because you've got rising + falling edges, at 20ms intervals. The buffer size is still (I believe) 64.
What baud rate is your bluetooth dongle? still 9600? That's only ~1000 characters/sec, but you'd be trying to transmit: 64 /* chars per line in your example */ * 50 /* 20ms */ = 3200 characters/sec
If you don't do that then Espruino should end up significantly faster. I think you'd be able to hit the 20ms update rate pretty easily - even with I2C devices :)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
There are actually two different queues - a TX and an RX queue. RX handles watches and Serial/USB input, and TX handles Serial/USB output. It's best to think of it as the interface between interrupts - interrupts put data in the RX queue, and get data from the TX queue.
And yes, you're right about the while loop - interrupts will be grabbing data and moving txTail up towards txHead in the background. Ideally the while loop would never get hit in most cases (the TX queue is 64 characters) but if you're sending data out faster than the serial port can transmit then it doesn't have much choice - it shouldn't drop characters, and saving them into memory would just fill up the available RAM after a few seconds.
32 is because you've got rising + falling edges, at 20ms intervals. The buffer size is still (I believe) 64.
What baud rate is your bluetooth dongle? still 9600? That's only ~1000 characters/sec, but you'd be trying to transmit:
64 /* chars per line in your example */ * 50 /* 20ms */ = 3200
characters/secIf you don't do that then Espruino should end up significantly faster. I think you'd be able to hit the 20ms update rate pretty easily - even with I2C devices :)