nRF mesh

RE: nRF mesh

ps_anu — Mon, 08 Apr 2019 07:05:52 GMT

how do i check in server side whether my message is received or not which i have sent from client

RE: nRF mesh

awneil — Fri, 05 Apr 2019 13:26:04 GMT

[quote userid="6462" url="~/f/nordic-q-a/45670/nrf-mesh/180506"]Why is x_in a uint16_t when you are assigning a char to it ?[/quote][quote userid="25682" url="~/f/nordic-q-a/45670/nrf-mesh/180510"]Why is x_in an unsigned 16 int & a is a character?[/quote]

ps_anu - these 2 questions are equivalent.

[quote userid="25682" url="~/f/nordic-q-a/45670/nrf-mesh/180510"]it will "work"[/quote]

ps_anu - It "works" because of the standard 'C' promotion rules - so long as you understand those, and don't get caught out by them ...

https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules

again, this is standard 'C' - not specific to Nordic.

RE: nRF mesh

Bjørn Kvaale — Fri, 05 Apr 2019 13:11:53 GMT

Why is x_in an unsigned 16 int & a is a character? I have tested it and it will "work", but I do not understand why you did this.

RE: nRF mesh

awneil — Fri, 05 Apr 2019 13:08:05 GMT

It is syntactically valid.

I have no idea what you are actually trying to achieve - so can't say whether or not it is "correct" in that sense.

Comments on 'C' style:

char a = 78;

What's with the magic number 78 ?

If you want a lowercase letter X, then say so:

char a = 'x';

Why have two cases here:

    switch(button_number)
    {
        case 0:
        case 2:
        
           x_in = a;
            break;

        case 1:
        case 3:
       
            x_in = a;
            break;
    }

They both do the same thing - so why not just

    switch(button_number)
    {
        case 0:
        case 2:
        case 1:
        case 3:
       
            x_in = a;
            break;
    }

and note that the value of x_in will be undefined in any other case.

Why is x_in a uint16_t when you are assigning a char to it ?

RE: nRF mesh

ps_anu — Fri, 05 Apr 2019 12:37:52 GMT

is this correct or wrong , i equallized both the sides... if it is wrong , what is wrong say me clearly please

 uint16_t x_in;
    char a = 78;
 //char arr[80] = "code";
// char ara [80] = "set";
 
    switch(button_number)
    {
        case 0:
        case 2:
        
           x_in = a;
            break;

        case 1:
        case 3:
       
            x_in = a;
            break;
    }

    set_params.tid = tid++;
    transition_params.delay_ms = APP_CONFIG_ONOFF_DELAY_MS;
    transition_params.transition_time_ms = APP_CONFIG_ONOFF_TRANSITION_TIME_MS;
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Sending msg: ONOFF SET %d\n",x_in);

RE: nRF mesh

ps_anu — Fri, 05 Apr 2019 05:42:58 GMT

but i have not used the bool state value even i have not included the generic_onoff_common.h which has definition , typestructure for bool state value, instead of that i created a variable which is used throughout the program

RE: nRF mesh

awneil — Thu, 04 Apr 2019 15:57:21 GMT

As noted in your previous thread, this code:

 char arr[5] = "code";
 char ara[5] = "set";

defines both 'arr' and 'ara' to be char arrays.

Therefore, for this code to work:

set_params.on_off = arr;

'set_params.on_off' mus be a char pointer.

You still haven't confirmed this.

This is because, as explained in your previous thread, the thing on the left-hand side of an assignment has to be of the same type (or a "compatible" type) as the thing on the right-hand side of the assignment.

Again, this is standard 'C' programming - nothing specific to Nordic or nRF52 or BLE.

And this line can't be right:

set_params.on_off = Ara;

because the 'C' programming language is case-sensitive - so 'ara' is not the same thing as 'Ara'

Surely, you must have got build errors or warnings for these?