I’m writing an application which will run on a Raspberry Pi in a box with only some LEDs, hardware buttons and a 4-line LCD as a display. And lots of input/output (sensors, relays etc.).
To offer more insight as to what it’s doing I’ve added quite a lot of spoken messages, which really do help. I’m using a system call to flite, via shell.execute.
This all works, but because the program execution is blocked until the shell.execute command returns, and speaking a message takes a while, I’ve had a few instances of high-priority signal inputs havng to wait until a stream of messages has been spoken.
To try to get around this I’ve put the shell.execute command in a thread, accessing an array of messages which can be updated in the main program. Here is the thread.run code:
[code]var message as string
var s as new Shell
var command as string
while speakQueue.LastRowIndex >= 0
message = speakQueue(0)
command = “flite -voice kal16 -t “”” + message + “”""
speakQueueEmpty = true
and here is the method which is called in the main program to speak the message. It has message as string as its argument.
[code]// add new message to the speakQueue
AddMessage(“added message to speakQueue:” + message, MessageType.Normal)
AddMessage("speakQueue length = " + str(speakQueue.LastRowIndex + 1), MessageType.Normal)
if speakQueueEmpty then
AddMessage(“speakQueueEmpty is TRUE, so starting speakThread”, MessageType.Normal)
speakQueueEmpty = false
The properties speakQueueEmpty and speakQueue have Public scope.
The AddMessage() entries here are for debugging: they send the appropriate message to a serial console, with ANSI text emphasis according to the MessageType.
What they show me is that even for a string of spoken messages issued one immediately after the other, the thread is processing them individually.
So is it the case that even for a shell.execute in a thread that the whole program waits for the return? Or have I made a coding error?