Getting started with a simple two device thread network

[johanandrade]

Hey all. I've just gotten started on a Thread project and want to see if there are resources/advise people can share. Here’s the hardware I have:

• (x2) Rigado R41Z evaluation board kits based off NXP KW41Z
• (x1) Renesas Synergy S7G2 touchscreen
• Battery operated device w/ motor that opens and closes a small gate (currently using 3 batteries @ 1.5VDC each)

My devices are assigned to the following type:

• 1 Rigado board = Router eligible end device (frdmkw41z_wireless_examples_thread_router_eligible_device_freertos)
• 1 Rigado board for use on the battery operated device = Low Power End Device (frdmkw41z_wireless_examples_thread_low_power_end_device_freertos)

I've gone through the Kinetis Thread Stack Application Demo guide to get acclaimed with starting a thread network and joining. I now want to move on to doing a simple application and just use a button (SW3/SW4) on the REED Rigado board to wireless communicate with the battery operated device so it can open and close the gate. Afterwards I’d like to implement the S7G2 touchscreen device to the REED board to perform this. My questions are the following:

• The R41Z should be able to handle a device w/ 3 batteries @1.5VDC each correct? Any suggestions on which ports to use on the R41Z to plug in the wires from the motor?
• As mentioned above, I’m using the two projects examples as provided by NXP. Are these two projects a good base to getting started on what I’m trying to do?
  • On the REED device to get started, would I just program it for SW3 or SW4 to send a message to activate the ports on the LPED where the battery device is wired into? Are there any similar examples or references that can be shared? Which source files I should look into for programming this communication?
  • Once I get to the touchscreen phase for the REED device – how would I go about integrating the thread board with the touchgfx application? Are there any starting points I can use?
  • Last question is regarding running the LPED on battery. Can the 3 batteries be used to power both the motor on the device and the R41Z board?

Thanks!

[ovidiu_usturoi]

Hi Johan,

The function APP_SendLedCommand is only one example on how to send a command via CoAP using the uriPath as "/led", so it will be no problem to adapt this function for your use case.  You can also change the name of the uriPath with something like "/motor" .

To do this you can change this part: #define APP_LED_URI_PATH   "/led", or you can change one of the other uriPaths used in examples "/sink", "/temp". For the last one you will need also to look for equivalent functions.. e.g for sink - the callback for receiving messages is APP_CoapSinkCb, and to send a message is used APP_SendDataSinkCommand).

Now, based on the shared code, the changes seems to be correctly.

Regarding the shell commands, you should keep the uriPath of the new commands. For example, when you use the function APP_SendLedCommand, internally the uri path is set to gAPP_LED_URI_PATH using the COAP_SetUriPath(pSession,(coapUriPath_t *)&gAPP_LED_URI_PATH);

Based on this the shell commands should look like:

    "coap CON POST RemoteNodeAddress  /led open"

    "coap CON POST RemoteNodeAddress  /led close"

Regards,

Ovidiu

[johanandrade]

Finally got my DC motor to operate earlier this week. The code was fine. The issue is with the PORTS on the board. I had to use PTA18/PTA19. It appears the only ports that work are the ones defined in the gpio_pins.c for the board's LEDpins. There's also PTB18 that works and I use for the external LED that's not in the ledPins array. I commented out the two ports I wanted to use from the array and then declared it outside of it for my application. 

/* Declare Output GPIO pins */
gpioOutputPinConfig_t ledPins[] = {
{
.gpioPort = gpioPort_B_c,
.gpioPin = 0,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
},
{
.gpioPort = gpioPort_C_c,
.gpioPin = 1,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
},
// {
// .gpioPort = gpioPort_A_c,
// .gpioPin = 19,
// .outputLogic = 1,
// .slewRate = pinSlewRate_Slow_c,
// .driveStrength = pinDriveStrength_Low_c
// },
// {
// .gpioPort = gpioPort_A_c,
// .gpioPin = 18,
// .outputLogic = 1,
// .slewRate = pinSlewRate_Slow_c,
// .driveStrength = pinDriveStrength_Low_c
// },
{
.gpioPort = gpioPort_C_c,
.gpioPin = 18,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_High_c
}
};

gpioOutputPinConfig_t appExternalLed = {
.gpioPort = gpioPort_B_c,
.gpioPin = 18,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
};

gpioOutputPinConfig_t appDamper0 = {
.gpioPort = gpioPort_A_c,
.gpioPin = 18,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
};

gpioOutputPinConfig_t appDamper1 = {
.gpioPort = gpioPort_A_c,
.gpioPin = 19,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
};

Is there another function being used somewhere in the software that is configuring/driving the ports? It seems weird only these GPIO are working. In the LED.c file I did find something that could be related but this is my speculation:

void LED_Init
(
void
)
{
APP_InitExternalLED();
APP_InitDamper();
BOARD_InitLEDs();
(void)GpioOutputPinInit(ledPins, gLEDsOnTargetBoardCnt_c);     <-------

The only thing is it doesn't explain why PTB18 would work since it's not part of ledPins array in the gpio_pins.c file. Thanks again for the useful explanations!

My next step is to interface a Rigado/KW41Z based board with a touchgfx compatible touchscreen board (https://touchgfx.com/renesas/sk-s7g2/) or (https://touchgfx.com/nxp-semiconductors/lpc5460x/ ) 

I already have the GUI done on the touchscreen board but I'm trying to give it Thread communication/functionality. I'm not sure yet which IDE would take priority if using the S7G2 (e2 studio is the IDE for it) . I guess if I use the LPC by NXP it would use MCUexpress.

[ovidiu_usturoi]

Hi Johan,

From our comments, the PTB18 is the pin used for led operations, being defined in appExternalLed structure and  initialized in function APP_InitExternalLed.

As you observed, the ledPins entries are initialized in LED_Init. The gLEDsOnTargetBoardCnt_c is used to identify the number of entries in ledPins table. But as I mentioned in one of my previous comments, the ledPins  are also used for defining application specific states (like, out of network, joined...).

My recommendation is to use a similar approach for the rest of pins that you want to use, like you did for PTB18.

Let me know if you need more details,

Regards,

Ovidiu

[ovidiu_usturoi]

Hi Johan,

For the first part of the application, please consider  Kinetis Thread Stack Demo Applications User's Guide , chapter 14.2 ( pdf location: sdk folder -> docs-> wireless->Thread) for a summary of switches/ leds functionality.

The default SDK examples are for FRDM-KW41 (FRDM-KW41Z|Freedom Development Kit|NXP ). If you are using Rigado R41Z evaluation board you will need to update pins configuration (as example - for LED, consider function BOARD_InitLEDs - from file pin_mux.c  and  use the right pin configuration based on board schematic). 

For switches you should consider that in the default demo applications are 2 operation modes:

- configuration mode  (the device is not joined to a network): APP_ConfigModeHandleKeyboard

- application mode (device is active in the network, and the SW-s are used to send commands to other node): APP_AppModeHandleKeyboard;

Regarding the motor control. my recommendation is to use pins that have PWM support  (e.g PTA18).  For Motor power supply you should consider the required power when the motor is running. 

An application note used to evaluate the performance of the Kw41 based on supplied power is the following: https://www.nxp.com/docs/en/application-note/AN12041.pdf 

For the second part, what will be the role of Renesas Synergy S7G2 touchscreen? Do you wanna use as a Border Router?

Regards.

Ovidiu

[johanandrade]

Thanks Ovidiu.

The R41Z boards have the same pin layout as the KW41Z so pin configuration is the same. Before I start activating the DC motor wireless, I'm trying to use an external LED on a breadboard as a test point.

I have an LED wired to PTB2 on the R41Z using Lower Power End Device and I want to turn it OFF/ON with the other R41Z board (using REED code) with the PTC5 button.

On the LPED I have added PORTB2 initialization to the following:

gpio_pins.c

gpioOutputPinConfig_t ledPins[] = {
{
.gpioPort = gpioPort_B_c,
.gpioPin = 2,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
},

pin_mux.c

#define PIN2_IDX 2u   /*!< Pin number for pin 2 in a port */ //LED on breadboard//

void BOARD_InitLEDs(void) {

PORT_SetPinMux(PORTB, PIN2_IDX, kPORT_MuxAsGpio); /* PORTB2 (pin32) configured as PTB2 for LED on breadboard */
}

After doing this I noticed the LED is blinking on/off in 4sec intervals on its own so something else must be driving it. I see there is an APP_SendLedFlash function on low_power_end_device_app.c and router_eligible_device_app.c but I'm not sure if that affects every GPIO?

For switches you should consider that in the default demo applications are 2 operation modes:

- configuration mode  (the device is not joined to a network): APP_ConfigModeHandleKeyboard

- application mode (device is active in the network, and the SW-s are used to send commands to other node): APP_AppModeHandleKeyboard;

This is good to know there are 2 modes of operation. So in application mode, PTC5 button reports the temperature

case gKBD_EventPB2_c:
/* Report temperature */
(void)NWKU_SendMsg(APP_ReportTemp, NULL, mpAppThreadMsgQueue);
break;

Are you able to point me where in static void APP_ReportTemp(void *pParam) PTC5 is assigned to do this action? I'm having difficulties tracking this down. I believe I will need to write a function that replaces this one with a function that sends a message to PTB2 to turn on/off the LED when PTC5 is pushed.

For the second part, what will be the role of Renesas Synergy S7G2 touchscreen? Do you wanna use as a Border Router?

The S7G2 will be the REED R41Z board I'm using to turn on/off the LED/motor. It will basically do the same thing as pushing the button on board but via touchscreen. I'm not sure yet if it will be used as a full border router. 
Thank you again.

[ovidiu_usturoi]

Hi Johan,

The ledPins structure is a method to define a list of LEDs for the demo purpose. These are initialized using the function LED_Init() and controlled at the application level by using function Led_SetState(). Basically for each state of the device, you have a specific LED configuration.

For example, when the device is not joined the network, the LED configuration is (see file app_led.c):

   -  const appLedsConfig_t gLedCfgFactoryDefault =       {LedCfg_BlueFlashing(LED_RGB, gLedSetup_Rgb_c, LED_MAX_RGB_VALUE_c), LedCfg_Flashing(LED1)};

where LED1 represent the first entry in ledPins structure, and as you noticed, modifying the LedPins stucture, your PTB2 will be associated to LED1 => it will flash when the device is not in the network.

To not be influenced by the default demo scenario you can do the following:

- on low power end device project:

1. define PTB2 as output:

gpioOutputPinConfig_t appExternalLed = {
     .gpioPort = gpioPort_B_c,
    .gpioPin = 2,
    .outputLogic = 1,
    .slewRate = pinSlewRate_Slow_c,
    .driveStrength = pinDriveStrength_Low_c
}

2. Initialize the pin as output using :

void APP_InitExternalLed(void)

{

      GpioOutputPinInit(&appExternalLed , 1);

}

4. Control the Led by using the following defines (I assumed that the LED is pull down to Ground):

#define APP_EXTERNAL_LED_ON()   GpioSetPinOutput(&appExternalLed )

#define APP_EXTERNAL_LED_OFF()  GpioClearPinOutput(&appExternalLed )

5. Test locally the LED configuration:

- in function APP_ConfigModeHandleKeyboard () -> add an operation when you press SW1:

    switch(keyEvent){
        case gKBD_EventPB1_c:{  

                 /* locally toggle LED */

                 static bool_t isLedOn = FALSE;

                 if(isLedOn ){

                       APP_EXTERNAL_LED_OFF();

                       isLedOn= FALSE;

                 }else{

                       APP_EXTERNAL_LED_ON();

                       isLedOn= TRUE;

                  }

             ...

        }

6. To remotely control this LED from the router_eligible_device, the easiest way is to update the function APP_ProcessLedCmd as below:

change the :    

if (FLib_MemCmp(pCommand, "on",2))
        App_UpdateStateLeds(gDeviceState_AppLedOn_c);

with:

if (FLib_MemCmp(pCommand, "on",2))
        APP_EXTERNAL_LED_ON() ;

do the same for "off" event.

- on router eligible device project:

1. Update  APP_AppModeHandleKeyboard function to send a LED ON or LED Off command when the sw is pressed:

    switch(keyEvent){
        case gKBD_EventPB1_c:{  

                    /* remote led - on */
              (void)NWKU_SendMsg(APP_SendLedRgbOn, NULL, mpAppThreadMsgQueue);

        }

        case gKBD_EventPB2_c:{  

                    /* remote led rgb - on */
              (void)NWKU_SendMsg(APP_SendLedRgbOn, NULL, mpAppThreadMsgQueue);

        .........

}

2. Add the following functions to turn On/Off:

static void APP_SendLedOn(void *pParam)
{
    uint8_t aCommand[] = {"on"};
    APP_SendLedCommand(aCommand, sizeof(aCommand));
}

static void APP_SendLedOff(void *pParam)
{
    uint8_t aCommand[] = {"off"};
    APP_SendLedCommand(aCommand, sizeof(aCommand));
}

Test steps:

-  create a network using router_eligible device (you can use shell command ; thr create, or double press on SWs -- please check the switchPins stucture to see the Sw configuration);

- join the low power end device - (you can use shell comand: thr join , if the serial is enabled, or Press Sw2, if you added the item 5, otherwise you can use any SW to join the network)

- control the remote LED by pressing : SW1 or Sw2...or you can use shell commands (consider chapter 10.7 Sending application data CoAP messages using the shell from Kinetis Thread Stack Demo Application User Guide document):

          "coap CON POST RemoteNodeAddress  /led on"

          "coap CON POST RemoteNodeAddress  /led off"

Regards,

Ovidiu

[johanandrade]

Thanks for the great guide. I'm understanding the functionality much better now.

1) I was able to successful test the LED on/off locally on the LPED. There was one minor change I had to make for it to work though. In function APP_ConfigModeHandleKeyboard () for low_power_end_device_app.c put the toggle functions under gKGB_KeysCount_c > 1. When I had it under the first case the toggle function wasn't working.

switch(keyEvent)
{
case gKBD_EventPB1_c:
#if gKBD_KeysCount_c > 1
case gKBD_EventPB2_c:
{
/*locally toggle external LED */
static bool_t isLedOn = FALSE;
if(isLedOn){
APP_EXTERNAL_LED_OFF();
isLedOn = FALSE;
} else {
APP_EXTERNAL_LED_ON();
isLedOn = TRUE;
}
}
case gKBD_EventPB3_c:
case gKBD_EventPB4_c:
#endif

.....

2) For remote controlling the external LED from the REED board I'm still having issues. Creating a network on REED device works fine (Solid green LED for leader and solid blue LED for active router). The joined device LPED also connects to the created network fine with both LEDs off to indicate correct functionality according to Chapter 9 of the Kinetis Demo Application User Guide. However, pressing the SWs on the REED device is not remotely turning on/off the external LED on the LPED board.

I used CoAP shell commands and I'm getting ACK:

$ coap CON POST fd24:26db:bb04:9ea3:85ac:56e5:6b56:57ef /on
coap rsp from fd24:26db:bb04:9ea3:85ac:56e5:6b56:57ef ACK
$ coap CON POST fd24:26db:bb04:9ea3:85ac:56e5:6b56:57ef /off
coap rsp from fd24:26db:bb04:9ea3:85ac:56e5:6b56:57ef ACK

One thing I'm noticing on the joined device is that the blue LED on PTB0 flashes very lightly every 4 seconds. My external LED on this board is also flashing in sync with the PTB0 LED. I'm thinking a joined device has an LED configuration activated during this state that may be preventing the remote control from the other device. Here's how I have my code setup.

low_power_end_device_app.c

static void APP_ProcessLedCmd
(
uint8_t *pCommand,
uint8_t dataLen
)
{
/* Set mode state */
APP_SetMode(mThrInstanceId, gDeviceMode_Application_c);

/* Process command */
if(FLib_MemCmp(pCommand, "on", 2))
{
//App_UpdateStateLeds(gDeviceState_AppLedOn_c);
APP_EXTERNAL_LED_ON();
}
else if(FLib_MemCmp(pCommand, "off", 3))
{
//App_UpdateStateLeds(gDeviceState_AppLedOff_c);
APP_EXTERNAL_LED_OFF();
}

...................

router_eligible_device_app.c

/*==================================================================================================
Private prototypes
==================================================================================================*/
static void App_HandleKeyboard(void *param);
.......
#if gKBD_KeysCount_c > 1
static void APP_SendExtLedOn(void *pParam);
static void APP_SendExtLedOff(void *pParam);
.....

.....
#endif

static void APP_SendExtLedOn(void *pParam)
{
uint8_t aCommand[] = {"on"};
APP_SendLedCommand(aCommand, sizeof(aCommand));
}

static void APP_SendExtLedOff(void *pParam)
{
uint8_t aCommand[] = {"off"};
APP_SendLedCommand(aCommand, sizeof(aCommand));
}

static void APP_AppModeHandleKeyboard
(
uint32_t keyEvent
)
{
switch(keyEvent)
{
case gKBD_EventPB1_c:
/* Data sink create */
(void)NWKU_SendMsg(APP_SendDataSinkCreate, NULL, mpAppThreadMsgQueue);
break;
#if gKBD_KeysCount_c > 1
case gKBD_EventPB2_c:
/* Report temperature */
(void)NWKU_SendMsg(APP_ReportTemp, NULL, mpAppThreadMsgQueue);
break;
case gKBD_EventPB3_c:
/* Remote led RGB - on */
//(void)NWKU_SendMsg(APP_SendLedRgbOn, NULL, mpAppThreadMsgQueue);
(void)NWKU_SendMsg(APP_SendExtLedOn, NULL, mpAppThreadMsgQueue);
break;
case gKBD_EventPB4_c:
/* Remote led RGB - off */
//(void)NWKU_SendMsg(APP_SendLedRgbOff, NULL, mpAppThreadMsgQueue);
(void)NWKU_SendMsg(APP_SendExtLedOff, NULL, mpAppThreadMsgQueue);
break;
#endif

..............

[ovidiu_usturoi]

Hi Johan,

In default configuration, the short flashing on PTB0 is used for inform the user that a transmission is done.

Using a Low power device, at every THR_SED_POLLING_INTERVAL_MS the device is wakeUp and send a poll to parent. If you don't want this capability, please update in app_init.h the following defines:

from:

#define AppTxLedActivityOn()                LED_Operate(LED_TX_ACTIVITY, gLedOn_c)
#define AppTxLedActivityOff()               LED_Operate(LED_TX_ACTIVITY, gLedOff_c)  

to:

#define AppTxLedActivityOn()               // LED_Operate(LED_TX_ACTIVITY, gLedOn_c)
#define AppTxLedActivityOff()               // LED_Operate(LED_TX_ACTIVITY, gLedOff_c)  

Regarding your ExternalLed, please double check if it is no connection between PTB0 and PTB2.  Also you can do the same test using another pin.

For the shell commands please consider that the URI_PATH for the Coap request is /led and not /on or /off as I observed from your shell command description. The command should be something like the one below:

   "coap CON POST RemoteNodeAddress  /led on.

If after validated the PTB2 or changing the Pin number  the issue is still there,  you can put a breakpoint in APP_ProcessLedCmd to see if the function is called. To debug the code on low_power device, disable first the  low power capabilities (from config.h file -> set gLpmIncluded_d  and cPWR_UsePowerDownMode to 0).

Regards,

Ovidiu

[johanandrade]

I commented out the TX blue led flash and the external LED was still flashing on PTB2. The board's blue LED stopped flashing though. I then moved my external LED to PTB3 and had the same results. I decided to try another in PTB18 and now it's functioning correctly. 

The CoAP commands are also turning on and off the LED with good results.

$ coap CON POST fd15:e682:af27:1e28::ff:fe00:1 /led off
coap rsp from fd15:e682:af27:1e28::ff:fe00:1 ACK
$ coap CON POST fd15:e682:af27:1e28::ff:fe00:1 /led on
coap rsp from fd15:e682:af27:1e28::ff:fe00:1 ACK

Using the SW3/SW4 on the REED device to remotely control the external LED is a little inconsistent although it might just be me still not fully understanding the way the switches are configured as described in the guide.

REED device

• Switches
• SW5 Short Press Send create data sink multicast announcement
• SW5 Long Press (2-3 seconds) Send release data sink multicast announcement
• SW4 Short Press Send CoAP temperature report multicast or to Data Sink
• SW4 Long Press (2-3 seconds) Revert local temperature and LED control to use multicast
• SW3 Short Press Send CoAP LED ON with random RGB values
• SW3 Long Press (2-3 seconds) Send CoAP LED Cycle (Color)
• SW2 Short Press Send CoAP LED OFF
• SW2 Long Press (2-3 seconds) Send CoAP LED Blink/Flash
• SW2, SW3, SW4, SW5 Very Long Press (> 8 seconds) – Factory reset

To turn off the LED I usually need to press SW3 three times before it recognizes it. And to turn it on I have to press SW4 a couple of times. Although sometimes pushing the button and holding it half a second works more consistent. Also, is there a way to have one SW do both LED ON/LED OFF? Thank you.

router device app .c

static void APP_AppModeHandleKeyboard
(
uint32_t keyEvent
)
{
switch(keyEvent)
{
case gKBD_EventPB1_c:
/* Data sink create */
(void)NWKU_SendMsg(APP_SendDataSinkCreate, NULL, mpAppThreadMsgQueue);
break;
#if gKBD_KeysCount_c > 1
case gKBD_EventPB2_c:
/* Report temperature */
(void)NWKU_SendMsg(APP_ReportTemp, NULL, mpAppThreadMsgQueue);
(void)NWKU_SendMsg(APP_SendExtLedOff, NULL, mpAppThreadMsgQueue);
break;
case gKBD_EventPB3_c:
/* Remote led RGB - on */
(void)NWKU_SendMsg(APP_SendLedRgbOn, NULL, mpAppThreadMsgQueue);
(void)NWKU_SendMsg(APP_SendExtLedOn, NULL, mpAppThreadMsgQueue);
break;
case gKBD_EventPB4_c:
/* Remote led RGB - off */
(void)NWKU_SendMsg(APP_SendLedRgbOff, NULL, mpAppThreadMsgQueue);
//(void)NWKU_SendMsg(APP_SendExtLedOff, NULL, mpAppThreadMsgQueue);
break;
#endif

[ovidiu_usturoi]

Hi Johan,

How is your project going?

Regards,

Ovidiu

[johanandrade]

Hi Ovidiu,

I removed the RGB ON/OFF functions and the external LED performs much better now. There's a latency of about 1s when turning it on/off but it's fine for my application.

And to keep the on/off functionality on same switch I did as mentioned:

router device app .c

#if gKBD_KeysCount_c > 1
case gKBD_EventPB2_c:
/* Report temperature */
(void)NWKU_SendMsg(APP_ReportTemp, NULL, mpAppThreadMsgQueue);
break;
case gKBD_EventPB3_c:
{
/*toggle external LED on/off with same SW4 */
static bool_t isLedOn = FALSE;
if(isLedOn){
(void)NWKU_SendMsg(APP_SendExtLedOff, NULL, mpAppThreadMsgQueue);
isLedOn = FALSE;
} else {
(void)NWKU_SendMsg(APP_SendExtLedOn, NULL, mpAppThreadMsgQueue);
isLedOn = TRUE;
}
}
break;

....

I've now moved on to getting the DC motor to turn on/off. I'm using similar steps as the LED by first getting it to function on the lower power end device locally. So far I have been able to get the motor to rotate clockwise when I push the SW button and turn it off when pushed again. However, I'm trying to also get the motor to rotate anti clockwise (either using another SW or holding the same SW down for 2 seconds for a long event) and I'm in the process of troubleshooting this issue since it's currently not working.

The logic I'm using is:

PTA16 | PTA17 | Motor

1          |     0     |  clockwise

0          |     1     | anti clockwise

1          |     1     | stop

The DC motor I'm using operates at less than 5VDC  and I don't have a need to control the speed of it. 

gpioOutputPinConfig_t appDamper0 = {
.gpioPort = gpioPort_A_c,
.gpioPin = 16,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
};

gpioOutputPinConfig_t appDamper1 = {
.gpioPort = gpioPort_A_c,
.gpioPin = 17,
.outputLogic = 1,
.slewRate = pinSlewRate_Slow_c,
.driveStrength = pinDriveStrength_Low_c
};

#define APP_DAMPER0_HIGH() GpioSetPinOutput(&appDamper0)
#define APP_DAMPER0_LOW() GpioClearPinOutput(&appDamper0)
#define APP_DAMPER1_HIGH() GpioSetPinOutput(&appDamper1)
#define APP_DAMPER1_LOW() GpioClearPinOutput(&appDamper1)

case gKBD_EventPB3_c:
{
/* locally open damper (clockwise) */
static bool_t isDamperOn = FALSE;
if(isDamperOn){
APP_DAMPER0_LOW();
APP_DAMPER1_LOW();
isDamperOn = FALSE;
} else {
APP_DAMPER0_HIGH();
APP_DAMPER1_LOW();
isDamperOn = TRUE;
}
}

case gKBD_EventLongPB3_c:
{
/* locally close damper (anti-clockwise) */
static bool_t isDamperOn = FALSE;
if(isDamperOn){
APP_DAMPER0_LOW();
APP_DAMPER1_LOW();
isDamperOn = FALSE;
} else {
APP_DAMPER0_LOW();
APP_DAMPER1_HIGH();
isDamperOn = TRUE;
}
}

Will get back to it tomorrow. Thanks.

[johanandrade]

I got my DC motor working locally. It was a wiring issue on my part, the code was fine. I'm now working on controlling it remotely from the REED board. I'm having issues though. The APP_SendLedCommand function should work for all types of "on" "off" events correct? Not just for LEDs? 

I've done the following but pressing the SW3 doesn't activate the DC motor remotely. The external LED is still working remotely when pushing SW4 so the boards are communicating.

low_power_end_device_app.c

static void APP_ProcessLedCmd
(
uint8_t *pCommand,
uint8_t dataLen
)
{
/* Set mode state */
APP_SetMode(mThrInstanceId, gDeviceMode_Application_c);

/* Process command */
if(FLib_MemCmp(pCommand, "open", 4))
{
//App_UpdateStateLeds(gDeviceState_AppLedOn_c);
APP_DAMPER0_HIGH();
APP_DAMPER1_LOW();
}
else if(FLib_MemCmp(pCommand, "close", 5))
{
//App_UpdateStateLeds(gDeviceState_AppLedOff_c);
APP_DAMPER0_LOW();
APP_DAMPER1_HIGH();
}
else if(FLib_MemCmp(pCommand, "stop", 4))
{
//App_UpdateStateLeds(gDeviceState_AppLedOff_c);
APP_DAMPER0_LOW();
APP_DAMPER1_LOW();
}

....

router_eligible_device_app.c

static void APP_SendDamperOpen(void *pParam)
{
uint8_t aCommand[] = {"open"};
APP_SendLedCommand(aCommand, sizeof(aCommand));
}

static void APP_SendDamperClose(void *pParam)
{
uint8_t aCommand[] = {"close"};
APP_SendLedCommand(aCommand, sizeof(aCommand));
}

static void APP_SendDamperStop(void *pParam)
{
uint8_t aCommand[] = {"stop"};
APP_SendLedCommand(aCommand, sizeof(aCommand));
}

static void APP_AppModeHandleKeyboard
(
uint32_t keyEvent
)
{
switch(keyEvent)
{
case gKBD_EventPB1_c:
/* Data sink create */
(void)NWKU_SendMsg(APP_SendDataSinkCreate, NULL, mpAppThreadMsgQueue);
break;
#if gKBD_KeysCount_c > 1
case gKBD_EventPB2_c:
{
/* Open the damper remotely */
static bool_t isDamperOn = FALSE;
if(isDamperOn) {
(void)NWKU_SendMsg(APP_SendDamperStop, NULL, mpAppThreadMsgQueue);
isDamperOn = FALSE;
} else {
(void)NWKU_SendMsg(APP_SendDamperOpen, NULL, mpAppThreadMsgQueue);
isDamperOn = TRUE;
}
}
break;

....

Would the shell CoAP command for the new functions just be 

  "coap CON POST RemoteNodeAddress  /open"

  "coap CON POST RemoteNodeAddress  /close"

?

I do get an ACK when using the above command but no actual activation. I'm likely missing something. Thanks and happy holidays.

[ovidiu_usturoi]

Hi Johan,

Good to know that works from shell terminal. Should also work from SWs.

I observed that you updated the SW action to use APP_SendExtLedOn and APP_SendExtLedOff.  To keep the application simple you can comment the call for (void)NWKU_SendMsg(APP_SendLedRgbOn, NULL, mpAppThreadMsgQueue)  or (void)NWKU_SendMsg(APP_SendLedRgbOff, NULL, mpAppThreadMsgQueue) . The idea is to send only one command when the Sw is pressed.

To use only one SW for both operation,  you can use a static variable to keep information for the last command  and toggle between them, or to use the functionality for short button press and long button press. The short press event is the one from the following list: gKBD_EventPB1_c to gKBD_EventPB4_c. The long press, means to keep the button pressed for more than 2 seconds and the event is from the list: gKBD_EventLongPB1_c  to gKBD_EventLongPB4_c.

Other aspect that you should consider is the functionality for devices that are low power.  The inconsistency observed,  is actually related to the polling interval.The router device is waiting for sleepy device to poll and after that send the command.  Also, by default the destination of the commands sent from Sws is not a unicast address (as you did in shell terminal). In this case is a multicast address defined by  gCoapDestAddress.

To see the differences between sleepyEnddevice and non-sleepy you can set the following defines to 0:

#define gLpmIncluded_d                             0

#define cPWR_UsePowerDownMode      0

#define THR_DEFAULT_IS_POLLING_END_DEVICE       0

In this case you will see an immediate action when the Sw is pressed.

Regards,

Ovidiu