Luup TestSerial

Latest revision as of 20:41, 17 April 2010

work in progress...

This is a simulated, hypothetical RS-232 controlled television. We will implement all the various commands using different techniques, some in Lua, some in XML script, and others as direct binary dumps, to illustrate all the ways to talk to serial devices.

Every command is surrounded by < and > symbols and followed by a CR+LF. Every command you send is echoed back if successful. All commands return instantly except POWON, which does not echo back until the TV warms up, and therefore needs to be handled asynchronously. The TV sends commands in response to manual user control too, for example: <VOLUME 5> when the user changes the volume to level 5.

Incoming data may not be in order. If you send, for example, CHUP and at the same time the user presses VOLUP on the remote, you may send <CHUP> and get <VOLUME 10> before you get the corresponding <CHANNEL 5>.

We will perform the following tests:

1. Choose power on from the UPNP action. This will start a job which sends <POWON> and waits 20 seconds for the power to come on. In the console type: <CHANNEL 4> CR+LF <POWON> CR+LF. The <CHANNEL 4> will be received by the job's incoming handler and since it's not for this job, we will return false so that the framework passes it on to other jobs and then to the incoming handler. When we get the POWON, we mark the job as done, but still return false so that the POWON is processed in the incoming handler to update the state variable and we don't need to handle it separately.

2. Choose the UPNP action <CHUP>. We will not use the job architecture because we want to return the output variable NewChannel to the UPNP action with the new channel number. Therefore, we call the lu_intercept handler before sending so that we will temporarily be able to intercept incoming data before letting the incoming handler get to it. The host should send <CHANNEL X> within 10 seconds or else the UPNP action fails.

3. Choose the UPNP action <CHDOWN>. This does the same thing as #2, but rather than doing it by hand as with CHUP, since it's common to send something and wait for something to come back, we'll use the lu_iop_send, which we'll use everywhere else. #2 is just for illustration.