Mobile Phone control of PODdevices - A Tutorial - Led Driver

Android Mobile Phone control of pfodDevices - Completed - A Tutorial - Led Driver

Android™ Controlled LED Driver using pfodApp™

This tutorial extends the Bluetooth Controlled Led Driver to allow the LED to be controlled from your Android mobile.
NO Android programming is required!!
It replaces the original J2ME version with the Android version.

The pfodApp for Andriod provides a complete solution for controlling arbitrary microcontroller devices, such as Arduino, from your AndroidTM​ mobile phone.
For the Mobile Phone J2ME java version of the pfodApp see here.

These four posts are also available at
Part 1 – Introduction to pfodAppsTM​/pfodDevices™
Part 2 -- Intoduction to pfodApp™ – the Mobile Phone Application
Part 3 – Led Controller pfodDevice™ Messages
Part 4 – Coding the Led Controller pfodDevice™


Introduction

This tutorial will first cover the communication protocol, pfod (Protocol For Operations Discovery), that is used to control the LED driver and show some of the Android screens that will be used to control the LED driver. The next section will introduce the Android pfodApp application and show how you can test out the screens from your PC. The last two sections will cover the design of the micro-pages that will be used to control the LED driver and the coding of the micro itself.

Part 1 – Introduction to pfodApps/pfodDevices

Why pfodDevices?

I found the bluetooth connectivity to the Mobile Phone Controlled Led Driver very useful and wanted to extend it to my other torches, led lighting and household devices. But I did not want to have to remember what each device could do and did not want to have to re-code the mobile phone application to support each new device. The solution I come up with was to define a simple Protocol For Operations Discovery (pfod) by which the mobile application asked the device what commands it supports and then lets the user choose one.

pfodDevices™ are devices that support this protocol, as defined in pfodSpecificationV1.2.pdf

pfodAppsTM​ are applications that connect to pfodDevices and display the commands available and let the user choose one.
pfodApps are like micro-browsers that display the micro-pages served by the pfodDevice. But the messages defined in the pfodSpecificationV1.2 are much simpler then HTML and are designed for easy implementation in micro devices such as Arduino. The maximum message size is 255 bytes.

Non-English languages are optionally supported by the pfodSpecificationV1.2.pdf , but are not implemented in the current Android pfodApp. If you are a non-English speaker and would like to help in testing the Android pfodApp to another language, contact me.

In this tutorial I will show the Android version of pfodApp and what is need to convert the Mobile Phone Controlled Led Driver into a pfodDevice. Even if you don't make the Led Controller, you can play around with the Andriod Bluetooth pfodApp using the bluetooth connection on your laptop or download the free pfodAppDemo, which shows examples of how all the pfodApp screens will look on your mobile.

pfodDevice and pfodApp are trade marks of Forward Computing and Control Pty. Ltd.

What can pfodDevices™ do?

Before going into the details, let's see how the Android Bluetooth pfodApp can control a simple pfodDevice™, in this case the pfod Led Controller.
To see larger selection of screens look at the pfod Specification or install the pfodAppDemo application on your Android.
On starting the Android Bluetooth pfodApp it shows the Connect To screen.

This lists the names of the Bluetooth pfodDevices you have setup. To add a new pfodDevice click Add button (+). See pfodAppForAndroidGettingStarted.pdf for how to set up these connections.
This Andriod Bluetooth pfodApp can control any device which has a bluetooth/serial connection and implements pfod (Protocol For Operations Discovery). The protocol itself does not mandate using bluetooth, other implementations could use wifi, internet or SMS to make the connection and transfer the messages.
When you click on a pfodDevice to connect to,say the Led Controller, the pfodApp connects and requests the pfodDevice's main menu. In this the pfodDevice returns a Navigation Menu. Other devices might just show a selection list menu depending on their capabilities.

Pressing the "Fade On" button turns the Led on and updates the display with a "Darker" down button. Then, after a few seconds, when the Led has reached full brightness the display updates to

How does the pfodApp know that the Led has reached maximum brightness and that the "Brighter" button should no longer be shown.?
When the Led Controller sent the Navigation Menu, it also send a non-zero refresh interval. That tells the pfodApp to repeatedly re-request this menu each refresh interval. You can see these multiple requests and responses
Pressing the right direction key sends the command associated with the Menu label to the pfod Led Controller. The pfod Led Controller sends back "Settings Menu e.g.

Sending the "Set Level" command, the pfod Led Controller responds with a new sub-menu which lets you set the Led level to High, Med, Low or Off
Sending the "Data" command, the pfod Led Controller responds with a sub-menu of

Sending the "Light Level" command, the pfod Led Controller responds with the Streaming Raw Data message and then sends the current light level details in free text.

Other possible messages a pfodDevice™ could respond with include requesting text input, numeric input and single and multi-selections from a list.
What makes this pfodApp mobile application so useful is that the one application can control many different devices. It is the device that tells the mobile what functionality is available. The mobile then just displays the commands and lets you choose. Languages other then English can also be supported.

Protocol For Operations Discovery (pfod)

The specification for pfod is detailed in the pfod Specification It defines the message formats and some minimal connection details. The specification does not define how the messages are displayed to the user.
Here is another example of the initial connection message exchange. Each message, except streaming raw data, is contained within a start and end character { } . When the pfodApp mobile application establishes a connection, it first sends the getMainMenu message, {.} , to the pfodDevice. The pfodDevice responds with a menu of functionality that is supports. In this example the pfodDevice responds with{.|o~on|u~up|d~down|s~set Level->|a~data->} . This message defines a menu which defines 5 items on, up, down, set Level-> and data->

Each of these menu items is associated with a command that the pfodDevice will respond to. For example when the user selects the on menu item, the application will send the associated command o to the pfodDevice™ (as the message {o} ).
The pfodDevice™ then executes that command and responds to the application with some message, perhaps an empty one {}, to indicate the pfodDevice™ received the command and has executed it. In this case the pfod Led Controller responds with the message {:|o~off} This updates the display text for the o command to show off.

For a detailed description of the messages, examples and a sample displays, see the pfod Specification .
For simple devices, single letter commands are sufficient and no processing of user input is required. This minimizes the coding required in the micro-controller to implement the protocol. See the pfod Led Controller section for a detailed asm code example or see Arduino Garage Door remote control for an Arduino example.
The next section will cover setting connecting your Android mobile, via bluetooth, to a terminal session on your PC so that you can design and test the micro-pages your pfodDevice will serve to the pfodApp
Android is a trademark of Google Inc., Arduino is promoted by http://www.arduino.cc/

Android Mobile Phone control of pfodDevices - A Tutorial - Led Driver

Intoduction to pfodApp™ – the Mobile Phone Application

Part 1 of the tutorial introduced pfodDevices™ and the covered the specification of the operation discovery protocol. This part of the tutorial introduces pfodApp for Android. This application can be used to control any pfodDevice™ that has a bluetooth/serial connection. This is what makes this mobile phone application so useful. It is the pfodDevice™ that tells the phone what functionality is available. The phone then just displays the commands and lets you choose.

Part 2 – Introduction to pfodApp – the Mobile Phone Application

pfodApp™ for Android™

The pfodApp for Android is available from the Android App store. There is also a free Demo version, pfodAppDemo, which demonstrates a selection of screens the pfodDevice can send for the pfodApp to display.

pfodApp – Setting up the Connections

Before you can connect to a pfodDevice via bluetooth using the pfodApp, you need to first pair the device with your mobile. Once you have paired the device, you can then start the pfodApp and give that device a meaningful name that will appear on the Connections list. See pfodAppForAndroidGettingStarted.pdf for detailed instructions.

Connecting to a Terminal Session on your PC

It is convenient, when developing the user interface for your pfodDevice, to connect the pfodApp to a terminal session on your PC so that you can design and test the micro-pages the pfodDevive will send for the pfodApp to display.
How to Make and Remove serial connections from your Mobile Phone to your PC describes a number of methods of making this connection for various operating systems.
That page also covers installing TeraTerm, the terminal emulator for Windows. If you are using a Mac or Linux you will need to install similar terminal software to connect to the Serial port provided by the USB serial Bluetooth card.

Connecting pfodApp™ to TeraTerm

You should start TeraTerm before connecting from your mobile phone pfodApp, because the pfodApp™ sends the getMainMenu message, {.}, immediately after the connection is established. On my Windows 7 computer, and the Android mobile would not make a connection if TeraTerm was not running and listening on assigned COM port.
Start the pfodApp™ on your mobile and connect to your PC.
The TeraTerm window shows the {.} message from the pfodApp. If you don't see the {.} and the pfodApp shows "Waiting for Response...", then check that your terminal software is set to the same baud rate as the bluetooth COM port assigned to the mobile.

The pfodApp™ expects the pfodDevice™ to reply with its main menu of functionality. Type in the Main Menu response. Actually it is easier to type up the command in a text editor and then cut and paste it to the TeraTerm window because TeraTerm sends every character you type, immediately, including your typos. For example if you type

The pfodApp™ will display

The next section of this tutorial will cover defining the functionality of the pfod Led Controller and coding it into micro-controller.

Android Mobile Phone control of pfodDevices - A Tutorial - Led Driver

Led Controller pfodDevice™ Messages
(Protocol for Operations Discovery)

Part 3 – Led Controller pfodDevice Messages

Part 1 of the tutorial introduced pfodDevices™ and the covered the specification of the operation discovery protocol. Part 2 of this tutorial covered the mobile phone pfodApp. This part of the tutorial covers the messages the Led Controller will send and receive as a pfodDevice. As a pfodDevice, the Led Controller will advertise its functionality to the pfodApp™ and let the user control the Led.
For the Led Controller this functionality will include turning the Led on and off, fading the led on and fading it off, increasing and decreasing the brightness and two sub-menus, one to set specific levels, High, Med, Low and another to display the current level setting and led current.

Led Controller pfodDevice™ Messages

The first step is to design the messages the Led Controller is going to use to advertise it functions. The messages will be tested against the pfodApp™ to see how they will appear to the user, before coding them in the Led Controller.

The pfodDevice™ Main Menu

Start by connection the Mobile Phone pfodApp™ to a terminal emulator on your PC (see Connecting the pfodApp™ To TeraTerm ). On connection the pfodApp™ automatically sends the getMainMenu message, {.}. The Led Controller pfodDevice™ should respond to this with its main menu of functionality. In this case we will advertise the following navigation commands, fade on, brighter and one sub-menu. A place holder commandd is also sent so we can update this naviagation menu later. (Note: The PC connection in the pfodApp™ has 0 character timeout so the pfodApp™ will wait indefinitely for you to enter your response. However when connecting to the real pfodDevice, Led Controller needs to respond within its timeout settings. See the pfod specification for details)
Following the pfod specification we assign command characters to these menu items, o for on/off, f for fade up/down, u for up, d for down, l for Set Level sub-menu, a for Data submenu.
{^Led Control||m~menu|u~Brighter|d|f~Fade On}
Entering this message into the terminal window sends it to the MobilePhone pfodApp. (Hint: type the message into notepad first, get it correct and then cut and paste it into the terminal window)

On receiving this main menu, the pfodApp™ displays it.

The pfod specification also allows for sending an optional menu title which has been done here. If the menu title is not sent by the pfodDevice, the pfodApp™ to should display something suitable. The pfodApp™ shown in this tutorial will display the device name for the main menu title.

The Fade On/Off Command

When the user sends the Fade On command, the pfodApp™ sends the message {f}. The Led Controller then should turn the Led on and send back a menu update that changes the Fade On display to Fade Off so the user can toggle the Led on and off using the same menu item. When the led is on, the Darker display text also needs to be included in the menu update so that the d command is enabled.
Following the pfod specification for menu updates, the Led Controller needs to send back display updates for the o and f commands.
{:|u~Brighter|d~Darker|f~Fade Off}

The pfodApp™ now displays

The Up and Down Commands

Sending the Brighter or Darker menu items send the messages {u} and {d} respectively to the Led Controller to increase or decrease the led brightness and update the menu depending on whether or not the maximum brightness has been reached or the led has been turned off.

The Sub-Menu

The > menu item sends the message {m} and the Led Controller responds with the sub-menu.

The pfodApp™ displays

This menu has two further sub-menus, Set Level and Data

The Set Level Menu

Choosing the Set Level item displays sends the message {l} to the pfodDevice™ which responds with the menu
{.|1~Low|2~Medium|3~High|0~Off}

This menu message did not include a menu prompt so the pfodApp™ did not display any prompt

Low, Medium, High and Off Commands

Each of these menu items send the associated command when selected. That is Low sends {1}, Medium sends {2}, High send {3} and Off sends {0}. The Led Controller sets the corresponding led level and since there is no update needed for this menu, the Led Controller just sends back an empty command, {}, to let the pfodApp™ know it has received and processed the command.

The pfodApp Refresh and Back buttons

The pfodApp™ has a refresh button that can be used to re-request the current menu

In this case the pfodApp™ resends {l} to re-request the Set Level sub-menu and the Led Controller responds with the Set Level menu as before.

The pfodApp™ also has a Back button to go back to the previous menu.

The pfodApp™ does this by re-requesting the previous menu from the pfodDevice. In this case to choosing <- Back sends {m} to the Led Controller to re-request the previous menu.

The Data Sub-Menu

Selecting the Data-> menu item sends {a} to the Led Controller which responds with the Data sub-menu. This menu contains two items Light Level and Led Current with associated commands v and i

The pfodApp™ displays

The Light Level Command

Selecting Light Level sends the message, {v}, to the Led Controller. The Led Controller responds with a streaming raw data message {=} and then sends the present value of the level and the % setpoint.

The pfodApp™ displays a streaming raw data screen with the data sent by the Led Controller.

The Led Controller can continue to send as much raw data as it likes, although the pfodApp™ may need to discard old data to make room for the newer data.

The Led Current Command

Going back to the Data menu, using the Back button, and selecting the Led Current menu item sends the message {i} and the Led Controller responds with the same streaming raw data message, {=}, but this time follows it with the % Led current reading.

That completes the commands that will be supported by the Led Controller pfodDevice. The next section will cover the modifications needed to the existing Mobile Phone controlled Led Driver to make it a pfodDevice™ that provides these functions.

Android Mobile Phone control of pfodDevices - Completed -A Tutorial - Led Driver

Coding the Led Controller pfodDevice™
(Protocol for Operations Discovery)

Part 4 – Coding the Led Controller pfodDevice

Part 1 of the tutorial introduced pfodDevices and the covered the specification of the operation discovery protocol. Part 2 of this tutorial covered the mobile phone pfodApp. Part 3 covered the design and testing of the pfodDevice messages that the Led Controller would support.
This part of the tutorial covers the code changes need to turn the RemoteLedDriver into a pfodDevice. As a pfodDevice, the Led Controller will advertise its functionality to the pfodApp and let the user control the Led. For the Led Controller this functionality will include fading the led on and fading it off, increasing and decreasing the brightness and two sub-menus, one to set specific levels, High, Med, Low and another to display the current level setting and led current.

Coding the Led Controller pfodDevice™
The complete code for the Led Controller pfodDevice can be downloaded from pfodLedDriver.asm That code is based on the previously described RemoteLedDriver.asm code. This part of the tutorial will only cover the differences. Please refer to the previous tutorials, Mobile Phone Controlled Led Driver and Bluetooth Controlled Led Driver for descriptions of the other parts of the code.

The pfodDevice™ Message Handler
The main difference between the RemoteLedDriver and the pfodLedDriver is in the way the incoming serial data is handled. Based on the message design done in Part 3 of this tutorial, the pfodLedDriver needs to be able to parse and handle each of the following messages
{.} {o} {f} {u} {d} {l} {a} {0} {1} {2} {3} {i} {v} {m}
This is done in three stages
1) process the received characters looking for the starting { character, the command character and the terminating } - PROCESS_RECEIVED_CHAR
2) execute the command - PROCESS_CMD_CHAR
3) send back a response message to the pfodApp so that the pfodApp knows the command has been received and executed. - SEND_...

PROCESS_RECEIVED_CHAR

PROCESS_RECEIVED_CHAR: cpi Temp, '{' //
breq PROCESS_RECEIVED_START_CMD


cpi Temp, '}' //
breq PROCESS_RECEIVED_END_CMD


// else save last char
tst commandCharacter
brne RET_PROCESS_RECEIVED_CHAR
// else save the first
mov commandCharacter,Temp;
rjmp RET_PROCESS_RECEIVED_CHAR


PROCESS_RECEIVED_START_CMD:
clr commandCharacter // clear on msg start
rjmp RET_PROCESS_RECEIVED_CHAR


PROCESS_RECEIVED_END_CMD:
mov Temp, commandCharacter
rcall PROCESS_CMD_CHAR // process the cmd
ldi commandCharacter, -1 // finished processing


RET_PROCESS_RECEIVED_CHAR:
ret


This routine is called for each character received on the RS232 Rx pin (see Coding the RS232 Module for details). The received character is in the Temp register. When the message start character { is received the commandCharacter is cleared. Then then next character is saved as the commandCharacter. Any further character before the closing } are ignored. When the message termination character } is received then the saved commandCharacter is loaded into the Temp register and PROCESS_CMD_CHAR is called to execute the command. Finally the commandCharacter is set to -1 to prevent any character outside the message start { and end } characters being saved as a command character.

PROCESS_CMD_CHAR
The PROCESS_CMD_CHAR routine starts with a long switch statement which jumps to the appropriate label to handle that command. If the command is not recognized then the Led Controller just sends back an empty command { } to let the pfodApp to let it know it is connected. Since the pfodApp should only ever send commands that the Led Controller as advertised, this should not normally happen.

PROCESS_CMD_CHAR:
cpi Temp, 'o' // turn on/off
breq PROCESS_RECEIVED_ON_OFF


cpi Temp, 'f' // fade on/off
breq PROCESS_RECEIVED_FADE_ON_OFF
...
other commands here ...
cpi Temp, 'i' //
breq PROCESS_RECEIVED_CHAR_SEND_ADC_READING


cpi Temp, 'v' //
breq PROCESS_RECEIVED_CHAR_SEND_LIGHT_LEVEL


// else invalid char so just ignore
// send back {}
rjmp PROCESS_RECEIVED_CHAR_SEND_EMPTY_CMD


There are three types of commands. Those that just send back data, either menus or the streaming raw data message {=} plus data (i e. {.} {l} {a} {i} {v}, {m}), those that just set a level (i e. {u} {d} {0} {1} {2} {3} ) and those that toggle depending on the current state (i .e. {o} {f} )

Menu Commands
The commands that send back data or menus just set the appropriate flags to trigger the respective SEND_ routine to send the menu or data. For example

PROCESS_RECEIVED_MAIN_MENU:
// set flag to send menu
sbr CMDS, (1<<CMDS_MainMenu)
rjmp END_PROCESS_CMD_CHAR

Then in the MAIN_LOOP, when the SEND_MAIN_MENU routine is called, the main menu response is sent back to the pfodApp. There are three main menu messages defined one for when the led is off or fading down and one for when it is on but is not at it maximum level and one for when the led is at its maximum setting.. The BRANCH_IF_TORCH_OFF_OR_FADING_DOWN and BRANCH_IF_TORCH_NOT_MAX macros is used to choose the appropriate response menu to send back.

MAIN_LOOP
The MAIN_LOOP is

MAIN_LOOP:
mov New_TORCH_State, TORCH_State // set initial state
rcall PROCESS_RS232 // process char if there is one
// and process cmd if } received
rcall LED_CONTROL_PROCESSING // each time ADC completes and save value
rcall UPDATE_TORCH_STATE // transfer new state to TORCH_State and update setpoint etc.
//
// now call all the message routines
// they will just return if nothing set to send
rcall SEND_EMPTY_CMD // send this first if set
rcall SEND_MAIN_MENU
rcall SEND_ONOFF_UPDATE
rcall SEND_SET_MENU
rcall SEND_DATA_MENU
rcall SEND_SUB_MENU
rcall SEND_STREAMING_CMD
rcall SEND_LEVEL // send level
rcall SEND_LIGHT // then % light
rcall SEND_ADC_READING // send Amps if needed
rjmp MAIN_LOOP


As in the Bluetooth Controlled Led Driver , this MAIN_LOOP just runs continually processing characters received from the RS232 input, controlling the Led each time there is a new current measurement and acting on the trigger flags set by the push button debounce code and the PROCESS_RS232 routine. Each SEND_... routine is controlled by its own flag. If the flag is set then that message is sent back to the pfodApp. The PROCESS_CMD_CHAR and its support routines set the appropriate flag depending on the command received and the torch state.

BRANCH_IF_TORCH_OFF_OR_FADING_DOWN macro
In a number of places in the code we need to check if the led is currently on or off so that the correct toggle action is taken or the correct menu update is sent. We define the led as being off if either it is off or it is fading down. If it is fading down it will be off very soon. The BRANCH_IF_TORCH_OFF_OR_FADING_DOWN macro is similar to other BRANCH_ macro described in earlier tutorials and will branch to the label argument if the torch is either off or fading down. Otherwise the program flow continues to the next statement.

Level Setting Commands
The commands that just set a level (i e. {0} {1} {2} {3} ) just set that level e.g.

PROCESS_RECEIVED_CHAR_TORCH_HIGH: // 3 == high
ldi New_TORCH_State,Torch_State_HIGH
rjmp PROCESS_RECEIVED_CHAR_UPDATE


The up and down commands (i e. {u} {d} ) set the torch state to variable and then increment or decrement the level e.g.

PROCESS_RECEIVED_CHAR_TORCH_UP:
ldi New_TORCH_State, Torch_State_VARIABLE
// clear levels
rcall SHIFT_DOWN_LEVEL
inc Level
rcall SHIFT_UP_LEVEL
sbr CMDS, (1<<CMDS_OnOffUpdate)
rjmp END_PROCESS_CMD_CHAR


The call to SHIFT_DOWN_LEVEL and SHIFT_UP_LEVEL are there convert between the 10 user selectable levels and the 40 levels used for fad on and fad off. (e.g.)

//-------------------------------------
// Shift down level
// When get u or d cmd want to move level by 4
// so there is only 10 steps between off and MaxLevel 40
// this routine divides by 4 before the level is
// inc or dec
// -----------------------------------
SHIFT_DOWN_LEVEL:
push Temp
ldi Temp, Level_Shift
tst Temp
breq END_SHIFT_DOWN_LEVEL // nothing to do
SHIFT_DOWN_LEVEL_LOOP:
lsr Level
dec Temp
tst Temp
brne SHIFT_DOWN_LEVEL_LOOP
END_SHIFT_DOWN_LEVEL:
pop Temp
ret



The SHIFT_DOWN_LEVEL routine divides the Level register by 4 before it is incremented or decremented. The similar SHIFT_UP_LEVEL then multiplies the Level register by 4 again to scale the Level register back into the range 0 to maxLevel (40) These 40 levels are then mapped to an approximately logarithmic scale of current settings, via the Log_SetPoint table, to more closely match the eye's perception of brightness.

Log_SetPoint:
// this maps levels into current setpoints between 0 and 1000 (max ADC count is 1024)
// 0 == 0, 1==16 2==24 3 == 40
// 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
.dw 0, 1, 1, 2, 2, 3, 3, 5, 6, 7, 8, 10, 12, 15, 18, 21, 26, 32, 38, 47, 57
// 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
.dw 70, 86, 105, 129, 156, 188, 226, 273, 319, 373, 436, 509, 569, 636, 710,794, 841, 891, 944,1000



When the CMDS_OnOffUpdate flag is handled by SEND_ONOFF_UPDATE routine called from the MAIN_LOOP, the SEND_ONOFF_UPDATE routine checks the current level and state of the torch and chooses the correct update to send to the navigation menu.

On/Off and FadeOn/FadeOff Commands
The On/Off and FadeOn/FadeOff commands ({o} {f} ) are toggles. That is each time the command is received by the pfodDevice, the pfodDevice toggles the state from on to off or from fadeOn to fadeOff.
The on/off processing looks checks the current Led state using the BRANCH_IF_TORCH_OFF_OR_FADING_DOWN macro, and then sets the Led either off or to Low. The FadeOn/FadeOff processing is similar except that it set the torch state to either Torch_State_FADE_UP or Torch_State_FADE_DOWN.
In the background the TIMER_FADE routine is called every 2mS using the same timer the switch debounce uses. Each time it is called if the FADE_COUNTER has reached zero and torch is in a fadeOn or fadeOff state, the TRIGGER_FADE flag is set and the FADE_COUNTER is reloaded. If fading up, 6 counts are used. If fading down 12 counts are used so that the fade down is twice as slow as fading up.

//--------------------------
// TIMER_FADE:
// Called from TIMER1_2mS each 2 mSec
// FadeUp counts to 6
// FadeDown counts to 12
// 40 steps => 0.5 sec up and 1sec fade down
//-------------------------
TIMER_FADE:
lds Temp, FADE_COUNTER
dec Temp
brpl END_TIMER_FADE
// else == 0
ldi Temp, 1 // for next dec unless updated below
cpi Torch_State, Torch_State_FADE
brlo END_TIMER_FADE // not fade just load 1 in counter


// else set trigger
sbr TRIGGER_Flags, (1<<TRIGGER_FADE)
ldi Temp,Fade_Count_Up // reload
cpi Torch_State, Torch_State_FADE_UP
breq END_TIMER_FADE // load up timer


// else down
ldi Temp,Fade_Count_Down
//rjmp END_TIMER_FADE // drop through


END_TIMER_FADE:
sts FADE_COUNTER, Temp
ret


The TRIGGER_FADE flag is examined in the PROCESS_SWITCH_STATE_TRIGGER routine which is called from the MAIN_LOOP via the LED_CONTROL_PROCESSING routine. If the TRIGGER_FADE flag is set then the FADE routine is called.


//--------------------------------------
// FADE
// called every time FADE_TRIGGER is set
// if Torch_State_FADE_UP increase level
// if Torch_State_FADE_DOWN decrease level
// if not FADE do nothing
//
//--------------------------------------
FADE:
push Temp
cpi Torch_State, Torch_State_FADE
brmi END_FADE // not fading so return


cpi Torch_State, Torch_State_FADE_UP
breq FADE_FADE_UP


// else fade down
FADE_FADE_DOWN:
dec Level
rcall LOAD_SETPOINT_FROM_LEVEL
rjmp END_FADE


FADE_FADE_UP:
inc Level
rcall LOAD_SETPOINT_FROM_LEVEL
// rjmp END_FADE fall through

END_FADE:
pop Temp
ret


The FADE routine checks the torch state and increases or decreases the level as appropriate. The LOAD_SETPOINT_FROM_LEVEL routine cleans up levels that are <0 or > maxLevel.

Conclusion
This completes a full implementation of pfod (Protocol for Operations Discovery). Under the pfod protocol, the pfodDevice™ advertises its capabilities to the pfodApp™ so the same pfodApp can be used to control any pfodDevice. The pfod protocol is very simple with minimal message structures and is readily implemented by small micro-processors such as the Atmel ATTINY series.
The first section presented the definition of the pfod protocol. The second section presented a functioning implementation of a pfodApp for a Android mobile. The pfodApp is universal to all pfodDevices and allows multiple devices with different capabilities to be controlled from this one application. The third section covered the design of the pfodDevice commands for a sample LED driver. The last section built on the previous Bluetooth Controlled Led Drive and modified the code to make the LED controller a pfodDevice.

Re: Android Mobile Phone control of pfodDevices - Completed -A Tutorial - Led Driver

I have updated this thread with an Android mobile controller replacing the original J2ME mobile controller.