 |
|
 |
 |
AIRcable Industrial Programming Handbook - Part 9
Support : Industrial : AIRcable AIRmotes Programming Handbook : PART 9 PART 9: MASTER Code Example - A commented programming example This article describes the implementation of a serial port profile master program for the AIRcable Industrial. It is also a good example to see how to do wireless debugging. You can download the MASTER code here (zip file). To program the AIRcable Industrial with this new program see Part 4 of the Industrial Programming Manual. Operation Principle The intend is to program the AIRcable in BASIC to do this:
Debugging While the AIRcable Industrial is finding other Bluetooth devices and streaming data, it is still accepting slave connections. We use the second wireless serial port (the slave SPP) for debugging. Make a SPP connection to the AIRcable and run a terminal emulator (such as Hyperterminal) on the connected slave SPP port. The BASIC interpreter will write every BASIC line it executes and any debug strings the BASIC program writes to the slave port. This is independent of the data communication between the peer Bluetooth device we connected through the master port and the UART. Theories of Operation On the AIRcable Industrial (and other AIRmote based devices) a BASIC program controls the Bluetooth baseband processor. Since all operations (Bluetooth, BASIC, timer etc) are running on the same processor the device is implemented as a multi-tasking system where several tasks perform operations concurrently. The BASIC program controls the multi-tasking system underneath it. Routines The BASIC program is organized in routines. Each routine is a section in the BASIC program that starts with @ROUTINE and ends with RETURN. These routines are like interrupt routines in an operating system. The BASIC interpreter knows 11 of these routines:
The important programming principle is to keep the routines short. This means that routines should not occupy the processor for very long and then it should end quickly. This allows the Bluetooth baseband processor to execute other tasks that are important for the functionality of the whole system. Routines that don't end (even with WAIT) will block the system. These routines are scheduled for execution either by the system automatically, or by other parts of the program or by external hardware or Bluetooth events. Some of the routines are actually interrupting the execution of other routines because they have higher priority. For example, the @PIN_CODE routine has the highest priority and will interrupt any other routine. Otherwise routines are scheduled to run after the current routine is finished. The MASTER Program We will use the implementation of the master program to show the use of the various routines in an example. The master program starts with @ERASE. This is a command to the BASIC loader in the AIRcable when a new program is transmitted via wireless FTP. It will cause the AIRcable to erase its BASIC memory completely. The first routine is @INIT. It runs only once when the system is booted or a new BASIC program has been uploaded. In the example we first switch on the green LED to show that the AIRcable boots. The lines 7 to 19 configure the power to the RS232 level shifter and schedules a hardware interrupt on PIO4. This is DSR input on the RS232 connector. The PIN code that is used for connections (slave, master and ftp) is configured here in the BASIC program. The application then has more control over security this way. Since we only want to talk to devices with a friendly name starting with "PUMP" we initialize the string variables here too. Debugging is switched on using the special variable Z. A value of 2 means to send debugging to the slave port. We initialize the state engine and disconnect any pending wireless links. This is helpful when we change programs frequently without rebooting the AIRcable. We don't disconnect slave ports because we would like to see the initialization execution on the slave port when a new version is uploaded. @ERASE @INIT 10
The AIRcable Industrial knows 5 program controlled scheduled routines.
and 5 hardware or event scheduled routines.
Slave Connections @IDLE is called whenever a slave connection is not available or when a slave connection closed. This routine starts right after @INIT. Normally the BASIC program would open up the incoming serial slave port (SPP) for a number of seconds and then exits. It will be called again when the time is up and no connection was established. At this time the BASIC program will again open up the slave port for incoming connections to SPP. When a connection to the slave port was successful, meaning another Bluetooth device has initiated a connection to the AIRcable, the @SLAVE routine starts up. The BASIC program can find out who is connecting using the build-in function getconn. A successful connection requires that the two partners are paired. PIN code is exchanged and then the a unique link key is stored on both ends to indicate a successful pairing. Then the pairing information is stored persistently for future connections that will not need a PIN code anymore. Pairing information can be erased either when more than 8 peers are stored or manually with the unpair function (single peers) or the @UNPAIR command (all peers) at the beginning of a BASIC program upload. For a simple slave application the program would just link the wireless SPP port to the UART. In this example, that's fundamentally what we do here too. @IDLE 40 @SLAVE 90 @PIN_CODE 488 In our more complex master example we want the program to allow master and slave connections at the same time. Therefore we need to implement a state machine to allow the Bluetooth baseband processor to do master connections without conflicting with the slave connections. The variable X is used to keep state. The states are as follow, 0 state is initial state.
Looking at the @IDLE routine, slave connections are only allowed when either inquiries are still going on or when a master connection has been established. When the slave connection mechanism is scheduled while a master connection is being established it causes conflicts. @IDLE will return in those cases and will have to be rescheduled when a certain state is reached. The @MASTER routine is called whenever a master connection was successful. This is the second program controlled scheduled routine. The routine is pretty simple. It configures the UART with 9600 baud and odd parity and links the SPP master port to the UART. We also store the address of the peer in $4. When we lose connection we will try to reconnect to this address first before starting the inquiry process. Since a longer master connection timeout has been scheduled (20sec) we reschedule an alarm quicker. @MASTER 100 Let's take a peek forward to the main control mechanism of the whole application. We use the ALARM scheduler do control the whole application. All execution is initiated by @ALARM, depending on the state described above. When inquiries are going on, we wait. This is because inquiries are very expensive, in processing time and in power consumption too. We must leave the processor as much time as possible to do inquiries. The results are scheduled by calls to @INQUIRY. Inquiry routines are sensitive to interrupts by other inquiry results. To prevent interruption a semicolon can be placed after a BASIC instruction. Normally the BASIC interpreter executes one line of BASIC program and then allows other parts of the system to execute before it goes to the next line. At the moment it schedules the execution of each line for every 100ms. With the placement of the semicolon this wait does not happen, the BASIC interpreter executes the next line immediately without going back to the scheduler. You must be careful using the semicolon. @INQUIRY looks at the result and compares the name of the discovered Bluetooth device with the string in $2. If the name starts with that it sets the state to "found", cancels any further inquiries and prints some debug. See a chapter at the end about debugging. 0 REM process inquiry results 0 REM found, no more search 0 REM debug 213 PRINTS "connecting " 0 REM keep ';' 225 PRINTS "not " Now to @ALARM. We have a standard state engine switch at the beginning and fan out from there to the different procedures depending on the state. Note that in every state we reschedule another ALARM within a few seconds to keep the system running. Switching state forward is mostly done in these procedures. 0 REM use ALARM routine to make master connections 0 REM state machine 0 REM state 0: init, do inquiries 0 REM state 1: found 0 REM state 2: timeout connecting, restart slave 0 REM state 3: master connected, restart slave 0 REM state 4: connected, slave restarted 0 REM lost master connection, reset state The last 2 routines @PIO_IRQ and @CONTROL deal with even change on the RS232 ports. If the DSR input on the DB9 connection changes, @PIO_IRQ is called. Remember we initialized that with the instruction "A=pioirq "P000100" in the @INIT routine. The function modemctl transmits a message through an established SPP connection to the other end. Receiving this message will schedule the @CONTROL routine to be executed. In this example we set or reset the DTR pin of our RS232 connector. @PIO_IRQ 490 @CONTROL 495 Debugging Since version 24, debugging is much easier. A special variable Z is used to switch on debugging of the BASIC interpreter. Every line it executes is being printed on one of the 3 data channels, UART, SPP-slave or SPP-master. We use the SPP-slave port to send the BASIC lines executed and additional debugging information. The debugging code in the program makes sure that we don't send data to a channel that is not connected. The AIRcable will buffer some data when there is no connection but it will reduce memory and will cause unnecessary processing. The Code Here attached is the whole program, with debugging switched on. To use the program in production without debugging, change line 26 to "Z = 0". @ERASE @INIT 10 @IDLE 40 @SLAVE 90 @MASTER 100 0 REM process inquiry results 0 REM found, no more search 0 REM debug 213 PRINTS "connecting " 0 REM keep ';' 225 PRINTS "not " 0 REM use ALARM routine to make master connections 0 REM state machine 0 REM state 0: init, do inquiries 0 REM state 1: found 0 REM state 2: timeout connecting, restart slave 0 REM state 3: master connected, restart slave 0 REM state 4: connected, slave restarted 0 REM lost master connection, reset state @PIN_CODE 488 @PIO_IRQ 490 @CONTROL 495 www.aircables.net/support-ind-program-manual-mastercode.html
|
|
 |
 |
