Date   

Re: samples: BLE Mesh : finding possib =?utf-8?Q?i_lities_to_optimise_onoff_level_lighting_vnd_app_further_??=

wxzzzh
 

Hi, Johan,

I'm researching zephyr ble mesh too, have a questions to ask you:

In zephyr/samples/boards/nrf52/mesh/onoff-app example, use meshctl as the provisioner and configurer, is there a way to save/update the configure results in some varibles in main.c so that it's possible to send some messages to other node or group from controller side?

Thanks & Regards,

On 1/18/2019 15:01Johan Hedberg<johan.hedberg@...> wrote:

I’m here on the mailing list as well, but I don’t have much knowledge of the “black boxes” of proprietary Mesh products that Vikrant was referring to.

Johan


On 18 Jan 2019, at 7.34, wxzzzh <wxzzzh@...> wrote:

Hi,  vikrant,

You can go here: https://zephyrproject.slack.com/messages/C18PLHN8H/convo/C18PLHN8H-1547649579.774500/?cdn_fallback=1
in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.


wxzzzh
wxzzzh@...
签名由 网易邮箱大师 定制
On 1/17/2019 21:01,vikrant8051<vikrant8051@...> wrote:
Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented.

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
in mentioned app ?  

Thanks & regards,
vikrant








Re: samples: BLE Mesh : finding possibi lities to optimise onoff level lighting vnd app further ?

Johan Hedberg
 

I’m here on the mailing list as well, but I don’t have much knowledge of the “black boxes” of proprietary Mesh products that Vikrant was referring to.

Johan

On 18 Jan 2019, at 7.34, wxzzzh <wxzzzh@tom.com> wrote:

Hi, vikrant,

You can go here: https://zephyrproject.slack.com/messages/C18PLHN8H/convo/C18PLHN8H-1547649579.774500/?cdn_fallback=1
in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.


wxzzzh
wxzzzh@tom.com
签名由 网易邮箱大师 定制
On 1/17/2019 21:01,vikrant8051<vikrant8051@gmail.com> wrote:
Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented.

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
in mentioned app ?

Thanks & regards,
vikrant



Re: samples: BLE Mesh : finding possibi =?utf-8?Q?lities_to_optimise_onoff_level_lighting_vnd_app_further_??=

wxzzzh
 

Hi,  vikrant,

in general channel, talk to Johan Hedberg by @jhe, who's the leader of this project and should can help you.

On 1/17/2019 21:01vikrant8051<vikrant8051@...> wrote:

Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented. 

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
 From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
   in mentioned app ?  

Thanks & regards,
vikrant



Re: Deprecating and removing net-app based APIs

Paul Sokolovsky
 

Hello,

On Wed, 16 Jan 2019 18:45:34 +0200
"Jukka Rissanen" <jukka.rissanen@linux.intel.com> wrote:

Hi all,

I sent a PR#12506 [1] that marks these APIs as deprecated:
* net-app
* HTTP server / client
* Websocket
* SNTP

The idea is that these APIs would eventually be removed from 1.14
release.
+1 for deprecation, -1 for removal in 1.14. 1.14 is supposed to be LTS
release, and we shouldn't leave users who used prior versions of Zephyr
in the cold with the first LTS which removes a lot of familiar APIs
(even without providing replacements, as discussed below).

Over a year ago, it was agreed among network API users, that
the API to user applications would be BSD socket API interface.
Because of this various networking APIs like MQTT, CoAP and LWM2M
have been converted to use BSD socket APIs instead of net-app API.
Good. But one year isn't that big a timeframe. Some higher-level
network libs were converted to sockets, some not.

I sent a mail in the beginning of December 2018 [2] about HTTP
client/server APIs, if there would be anyone willing to maintain and
convert HTTP APIs to use BSD socket API. So far no volunteers have
been found.
Well, I responded to it with some proposals, and that's were it stands.
There should be discussion on the way to approach. It's a bit of
wishful thinking that someone will pop up at them moment that we
asked. Likewise, I'd call it a leap of faith that someone will start
to work on it just to not lose HTTP libs from Zephyr - this doesn't
guarantee quality of implementation, nor even that it'll be merged (we
had cases like "oh, you wrote something? but that's not what we
need"). Again, discussion and sustainable approach.

This removal of these APIs also means that there would
not be replacement BSD socket based APIs for HTTP, Websocket and SNTP
in 1.14.
That would be the reason to not remove them, and definitely not for
the LTS.

It is important that we do not have multiple implementations for the
same features so the old net-app based APIs need to be removed. We
will remove the duplicate (old) CoAP and MQTT API implementations as
there exists BSD socket versions for CoAP and MQTT.


Links:
[1] https://github.com/zephyrproject-rtos/zephyr/pull/12506
[2] https://lists.zephyrproject.org/g/devel/message/5537


Cheers,
Jukka
--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Dev Review Meeting Agenda (Jan 17, 2019)

Kumar Gala
 

Here are the discussion items for today’s meeting, if you have any others let me know:

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Target Capabilities / Board Directory Layout Capabilities
* Include: Clean up header file namespace
* scripts/dts/extract: Generate fully qualified name define
* [DNM]Convert MCUX UART to use DT_<COMPAT> defines

- k


samples: BLE Mesh : finding possibilities to optimise onoff_level_lighting_vnd_app further ?

vikrant8051 <vikrant8051@...>
 

Hello,

Available Bluetooth Mesh App layers (which are based on resp. Semiconductor
manufacture BLE Mesh stack) are black boxes. So we can't mimic what they
have implemented. 

So is there anyone(developer) who is behind those black boxes to optimise zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app further?

(Please refer Bluetooth Mesh Model Specification Table 6.128 for details .
 From my point of view, current implementation is pretty much stable or Okay
& that makes me biased for it).

Is there any one who has successfully implemented
- Light HSL Server/Client models using Zephyr Mesh stack
- which has clear all PTS test rquirements 😃
- and have used something indigenous/superior way than proposed implementation
   in mentioned app ?  

Thanks & regards,
vikrant



Re: RFC - C99 issue regarding unnamed union/structs

Thomas Törnblom
 



Den 2019-01-16 kl. 18:31, skrev Andy Ross:

I'd also look more favorably on and be more likely to recommend
toolchains that implement broadly-used industry extensions. :)

By "broadly-used industry extensions" you mean "gcc extensions" I guess?

I did a quick test using some other C compilers I have, SunStudio 11/12, Keil uVision 5, VisualStudio 2015, and none of them accepts the "..." extension to the case labels in switch statements, at least not out of the box, so I would hardly call that "broadly-used industry extensions".

To be fair, I did find that SunStudio 12 Update 1 appears to have introduced this.

I might file an RFE for this ;)


Andy


/Thomas

--

Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@... Website: www.iar.com
Twitter: www.twitter.com/iarsystems


Re: RFC - C99 issue regarding unnamed union/structs

Andy Ross
 

Thomas Törnblom wrote:
Would there be a problem adding a single anonymous member to this to
make it standards compliant?

After all, in C++ empty structs take up space while they don't with gcc.
And we'd never use this trick in C++ for that reason. :)

I'd personally prefer to see this done via rework that doesn't
introduce needless memory. I know I mocked it, but an
ARCH_HAS_WHATEVER kconfig really isn't an awful thing.

Note that some smarter refactoring could probably find space for this
info in other arch-defined spots that don't have this problem (like on
the stack of the caller instead of in the struct thread, which is done
for various things already and could be unified). That's getting way
beyond language standards compliance though.

Would it be OK to fix issues 1 - 4 in a PR?
I'm not the gatekeeper really, but I wouldn't object, no.

I'd also look more favorably on and be more likely to recommend
toolchains that implement broadly-used industry extensions. :)

Andy


Deprecating and removing net-app based APIs

Jukka Rissanen
 

Hi all,

I sent a PR#12506 [1] that marks these APIs as deprecated:
* net-app
* HTTP server / client
* Websocket
* SNTP

The idea is that these APIs would eventually be removed from 1.14
release. Over a year ago, it was agreed among network API users, that
the API to user applications would be BSD socket API interface. Because
of this various networking APIs like MQTT, CoAP and LWM2M have been
converted to use BSD socket APIs instead of net-app API.

I sent a mail in the beginning of December 2018 [2] about HTTP
client/server APIs, if there would be anyone willing to maintain and
convert HTTP APIs to use BSD socket API. So far no volunteers have been
found. This removal of these APIs also means that there would not be
replacement BSD socket based APIs for HTTP, Websocket and SNTP in 1.14.

It is important that we do not have multiple implementations for the
same features so the old net-app based APIs need to be removed. We will
remove the duplicate (old) CoAP and MQTT API implementations as there
exists BSD socket versions for CoAP and MQTT.


Links:
[1] https://github.com/zephyrproject-rtos/zephyr/pull/12506
[2] https://lists.zephyrproject.org/g/devel/message/5537


Cheers,
Jukka


Re: RFC - C99 issue regarding unnamed union/structs

Thomas Törnblom
 



Den 2019-01-15 kl. 17:45, skrev Andy Ross:
In order:

1. Empty structs are really useful, for example the spot you're noticing that allows arch code to define its own set of private data, which might be zero-length.  Obviously that could be worked around with appropriate preprocessor trickery (e.g. CONFIG_ARCH_HAS_CALLER_SAVED_STRUCT or something similarly wordy), but not as cleanly.
Would there be a problem adding a single anonymous member to this to make it standards compliant?

After all, in C++ empty structs take up space while they don't with gcc.


2. That looks wrong.   We should surely be using a consistent way to specify packed structs.

3. Flexible arrays are valid C99.  You mean a literal zero in the brackets in the declaration?  Yeah, that's the wrong syntax, the standard specifies "[]" for this.

Correct, just the extern declarations, which should be changed to "[]".


4. That's a "case '1' ... '9':" expression to detect decimal digits in the middle of an otherwise giant switch.   Sure, I guess we could turn that into nine separate case labels, but wow is it nicer this way and boy is it a useful feature that the compiler gives us to express this.  Hint, hint.

I agree that it sure looks convenient, but that switch is ~110 lines of code, unrolling that case makes it 119 lines, and standard C.
 

5. Dynamic stack allocation (via either variable arrays or alloca()) is problematic for a various reasons (some dumb, but some good -- note that systemd just got hit by a local root exploit last week due to an attacker-controlled alloca!), and I'm actually the worst offender in the current tree.   These are likely all going to have to go away soon, or at least be reworked into a form such that the code will build without dynamic stacks.

I'm glad to see that the issue with alloca is at least being discussed (https://github.com/zephyrproject-rtos/zephyr/issues/9892).

I see it is a problem also with other vendors tools (https://github.com/zephyrproject-rtos/zephyr/issues/10182).

Andy



Would it be OK to fix issues 1 - 4 in a PR?

/Thomas


On 1/15/2019 12:47 AM, Thomas Törnblom wrote:
While on the subject of language compliance, what about the frequent usage of non-standard gcc extensions that limits portability?

I've started looking at making IAR Embedded Workbench a supported tool chain for Zephyr, and while I have not looked at the cmake build tools yet, I've tried to build one of the examples (hello) using our IDE, and have run into several non-standard things like:

1) Empty structs (struct _caller_saved in kernel_arch_thread.h)

2) Packed structs, "struct __packed__ ..." vs "__packed struct .." or "struct __attribute__((__packed__)) ...", the latter two variants are accepted by our tools, the first is not ( _k_thread_stack_element in kernel.h)

3) Zero sized arrays (several places in the include files for logging)

4) Ellipses/ranges in case (printk.c)

5) alloca

Of these alloca() is probably the most problematic for us as we have no alloca, and no easy way to implement it either as we have no frame pointer. In one place I could use a variable size array, but the rb code requires more work, and I would really prefer not having to use the variable size array either.

Comments?

/Thomas

Den 2019-01-14 kl. 22:11, skrev Peter A. Bigot:
I don't have a solution, but since the question came up I am interested in any reaction to https://github.com/zephyrproject-rtos/zephyr/issues/9552#issuecomment-449718078 since that's relevant to the topic.

Peter

On 1/14/19 1:47 PM, Flavio Ceolin wrote:
Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a lot
of unnamed struct/unions. One example is:




--

Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@... Website: www.iar.com
Twitter: www.twitter.com/iarsystems

--

Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@... Website: www.iar.com
Twitter: www.twitter.com/iarsystems


Re: RFC - C99 issue regarding unnamed union/structs

Flavio Ceolin
 

Hi,

In order:

1. Empty structs are really useful, for example the spot you're noticing
that allows arch code to define its own set of private data, which might
be zero-length.  Obviously that could be worked around with appropriate
preprocessor trickery (e.g. CONFIG_ARCH_HAS_CALLER_SAVED_STRUCT or
something similarly wordy), but not as cleanly.
I'm with Thomas, this is a GCC extension we should rely on them.


2. That looks wrong.   We should surely be using a consistent way to
specify packed structs.
Thumbs up


3. Flexible arrays are valid C99.  You mean a literal zero in the
brackets in the declaration?  Yeah, that's the wrong syntax, the
standard specifies "[]" for this.
Literal zero is GCC extension and about flexible array "[]" it can be
used *only* as the last element in a struct (and this struct cannot be
used in array or inside other struct/union - GCC allows it).



4. That's a "case '1' ... '9':" expression to detect decimal digits in
the middle of an otherwise giant switch.   Sure, I guess we could turn
that into nine separate case labels, but wow is it nicer this way and
boy is it a useful feature that the compiler gives us to express this. 
Hint, hint.

5. Dynamic stack allocation (via either variable arrays or alloca()) is
problematic for a various reasons (some dumb, but some good -- note that
systemd just got hit by a local root exploit last week due to an
attacker-controlled alloca!), and I'm actually the worst offender in the
current tree.   These are likely all going to have to go away soon, or
at least be reworked into a form such that the code will build without
dynamic stacks.
Yeah, remove alloca usage is something that is being tracked (in some
issues actually). e.g >https://github.com/zephyrproject-rtos/zephyr/issues/9892

Andy


On 1/15/2019 12:47 AM, Thomas Törnblom wrote:
While on the subject of language compliance, what about the frequent
usage of non-standard gcc extensions that limits portability?

I've started looking at making IAR Embedded Workbench a supported tool
chain for Zephyr, and while I have not looked at the cmake build tools
yet, I've tried to build one of the examples (hello) using our IDE,
and have run into several non-standard things like:

1) Empty structs (struct _caller_saved in kernel_arch_thread.h)

2) Packed structs, "struct __packed__ ..." vs "__packed struct .." or
"struct __attribute__((__packed__)) ...", the latter two variants are
accepted by our tools, the first is not ( _k_thread_stack_element in
kernel.h)

3) Zero sized arrays (several places in the include files for logging)

4) Ellipses/ranges in case (printk.c)

5) alloca

Of these alloca() is probably the most problematic for us as we have
no alloca, and no easy way to implement it either as we have no frame
pointer. In one place I could use a variable size array, but the rb
code requires more work, and I would really prefer not having to use
the variable size array either.

Comments?

/Thomas

Den 2019-01-14 kl. 22:11, skrev Peter A. Bigot:
I don't have a solution, but since the question came up I am
interested in any reaction to
https://github.com/zephyrproject-rtos/zephyr/issues/9552#issuecomment-449718078
since that's relevant to the topic.

Peter

On 1/14/19 1:47 PM, Flavio Ceolin wrote:
Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a
lot
of unnamed struct/unions. One example is:

--

*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Regards,
Flavio Ceolin


Re: RFC - C99 issue regarding unnamed union/structs

Andy Ross
 

In order:

1. Empty structs are really useful, for example the spot you're noticing that allows arch code to define its own set of private data, which might be zero-length.  Obviously that could be worked around with appropriate preprocessor trickery (e.g. CONFIG_ARCH_HAS_CALLER_SAVED_STRUCT or something similarly wordy), but not as cleanly.

2. That looks wrong.   We should surely be using a consistent way to specify packed structs.

3. Flexible arrays are valid C99.  You mean a literal zero in the brackets in the declaration?  Yeah, that's the wrong syntax, the standard specifies "[]" for this.

4. That's a "case '1' ... '9':" expression to detect decimal digits in the middle of an otherwise giant switch.   Sure, I guess we could turn that into nine separate case labels, but wow is it nicer this way and boy is it a useful feature that the compiler gives us to express this.  Hint, hint.

5. Dynamic stack allocation (via either variable arrays or alloca()) is problematic for a various reasons (some dumb, but some good -- note that systemd just got hit by a local root exploit last week due to an attacker-controlled alloca!), and I'm actually the worst offender in the current tree.   These are likely all going to have to go away soon, or at least be reworked into a form such that the code will build without dynamic stacks.

Andy


On 1/15/2019 12:47 AM, Thomas Törnblom wrote:
While on the subject of language compliance, what about the frequent usage of non-standard gcc extensions that limits portability?

I've started looking at making IAR Embedded Workbench a supported tool chain for Zephyr, and while I have not looked at the cmake build tools yet, I've tried to build one of the examples (hello) using our IDE, and have run into several non-standard things like:

1) Empty structs (struct _caller_saved in kernel_arch_thread.h)

2) Packed structs, "struct __packed__ ..." vs "__packed struct .." or "struct __attribute__((__packed__)) ...", the latter two variants are accepted by our tools, the first is not ( _k_thread_stack_element in kernel.h)

3) Zero sized arrays (several places in the include files for logging)

4) Ellipses/ranges in case (printk.c)

5) alloca

Of these alloca() is probably the most problematic for us as we have no alloca, and no easy way to implement it either as we have no frame pointer. In one place I could use a variable size array, but the rb code requires more work, and I would really prefer not having to use the variable size array either.

Comments?

/Thomas

Den 2019-01-14 kl. 22:11, skrev Peter A. Bigot:
I don't have a solution, but since the question came up I am interested in any reaction to https://github.com/zephyrproject-rtos/zephyr/issues/9552#issuecomment-449718078 since that's relevant to the topic.

Peter

On 1/14/19 1:47 PM, Flavio Ceolin wrote:
Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a lot
of unnamed struct/unions. One example is:




--

Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@... Website: www.iar.com
Twitter: www.twitter.com/iarsystems


Re: RFC - C99 issue regarding unnamed union/structs

Andy Ross
 

On 1/15/2019 4:25 AM, Paul Sokolovsky wrote:
On Mon, 14 Jan 2019 11:47:19 -0800
"Flavio Ceolin" <flavio.ceolin@intel.com> wrote:
One problem with have in Zephyr regarding C99 is that we are using a
lot of unnamed struct/unions.
Anonymous unions are important part of the C language. An obvious
solution to the problem is switching to the C11 standard.
Yeah, I have a ton of sympathy for poor Flavio having to deal with all
these conflicting rules and requirements, but not a lot for this
particular rule that was clearly solved by the C standards committee
the better part of a decade ago.

That said, the specific example given is just there for compatibility,
to reduce the impact of the SMP introduction. There's no reason we
can't go in and change all instances of e.g. "_kernel.irq_stack" to
"_kernel.cpus[0].irq_stack" (or actually "_current_cpu.irq_stack").

IIRC the change was looking to get a little messy when dealing with
the assembly offset generation, but a little code motion never hurt
anything.

Andy


Re: RFC - C99 issue regarding unnamed union/structs

Paul Sokolovsky
 

On Mon, 14 Jan 2019 11:47:19 -0800
"Flavio Ceolin" <flavio.ceolin@intel.com> wrote:

Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a
lot of unnamed struct/unions.
Anonymous unions are important part of the C language. An obvious
solution to the problem is switching to the C11 standard.

One example is:

"""
struct z_kernel {
/* For compatibility with pre-SMP code, union the first CPU
* record with the legacy fields so code can continue to use
* the "_kernel.XXX" expressions and assembly offsets.
*/
union {
struct _cpu cpus[CONFIG_MP_NUM_CPUS];
#ifndef CONFIG_SMP
struct {
/* nested interrupt count */
u32_t nested;

/* interrupt stack pointer base */
char *irq_stack;

/* currently scheduled thread */
struct k_thread *current;
};
#endif
};

...
"""
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: RFC - C99 issue regarding unnamed union/structs

Thomas Törnblom
 

While on the subject of language compliance, what about the frequent usage of non-standard gcc extensions that limits portability?

I've started looking at making IAR Embedded Workbench a supported tool chain for Zephyr, and while I have not looked at the cmake build tools yet, I've tried to build one of the examples (hello) using our IDE, and have run into several non-standard things like:

1) Empty structs (struct _caller_saved in kernel_arch_thread.h)

2) Packed structs, "struct __packed__ ..." vs "__packed struct .." or "struct __attribute__((__packed__)) ...", the latter two variants are accepted by our tools, the first is not ( _k_thread_stack_element in kernel.h)

3) Zero sized arrays (several places in the include files for logging)

4) Ellipses/ranges in case (printk.c)

5) alloca

Of these alloca() is probably the most problematic for us as we have no alloca, and no easy way to implement it either as we have no frame pointer. In one place I could use a variable size array, but the rb code requires more work, and I would really prefer not having to use the variable size array either.

Comments?

/Thomas

Den 2019-01-14 kl. 22:11, skrev Peter A. Bigot:

I don't have a solution, but since the question came up I am interested in any reaction to https://github.com/zephyrproject-rtos/zephyr/issues/9552#issuecomment-449718078 since that's relevant to the topic.

Peter

On 1/14/19 1:47 PM, Flavio Ceolin wrote:
Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a lot
of unnamed struct/unions. One example is:




--

Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@... Website: www.iar.com
Twitter: www.twitter.com/iarsystems


Re: RFC - C99 issue regarding unnamed union/structs

Flavio Ceolin
 

Hi Peter,

I don't have a solution, but since the question came up I am interested
in any reaction to
https://github.com/zephyrproject-rtos/zephyr/issues/9552#issuecomment-449718078
since that's relevant to the topic.
I've given my opnion there :)


Peter

On 1/14/19 1:47 PM, Flavio Ceolin wrote:
Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a lot
of unnamed struct/unions. One example is:
Flavio Ceolin


Re: RFC - C99 issue regarding unnamed union/structs

Peter A. Bigot
 

I don't have a solution, but since the question came up I am interested in any reaction to https://github.com/zephyrproject-rtos/zephyr/issues/9552#issuecomment-449718078 since that's relevant to the topic.

Peter

On 1/14/19 1:47 PM, Flavio Ceolin wrote:
Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a lot
of unnamed struct/unions. One example is:


RFC - C99 issue regarding unnamed union/structs

Flavio Ceolin
 

Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a lot
of unnamed struct/unions. One example is:

"""
struct z_kernel {
/* For compatibility with pre-SMP code, union the first CPU
* record with the legacy fields so code can continue to use
* the "_kernel.XXX" expressions and assembly offsets.
*/
union {
struct _cpu cpus[CONFIG_MP_NUM_CPUS];
#ifndef CONFIG_SMP
struct {
/* nested interrupt count */
u32_t nested;

/* interrupt stack pointer base */
char *irq_stack;

/* currently scheduled thread */
struct k_thread *current;
};
#endif
};

...
"""

Named this structs/unions is OK, just a matter of text-replace around
the project. The problem is that we have some symbols being generated by
macros and I didn't find a clean way to fix it without extra changes.
The macro in question is GEN_OFFSET_SYM(). Take as example the following
code:

"""
GEN_OFFSET_SYM(_kernel_t, current);
"""
If I change it for something like:
"""
GEN_OFFSET_SYM(_kernel_t, cpu.state.current);
"""

It won't work because this macro concats parameters 1 and 2 to make a
new symbol. One solution is using a variadic parameter hack:

"""
#define GEN_OFFSET_SYM_INTERNAL_0(S, M) \
GEN_ABSOLUTE_SYM(__##S##_##M##_##OFFSET, offsetof(S, M))
#define GEN_OFFSET_SYM_INTERNAL_1(S, M, ALIAS) \
GEN_ABSOLUTE_SYM(__##S##_##ALIAS##_##OFFSET, offsetof(S, M))
#define GET_OVERRIDE(_1, _2, _3, NAME, ...) NAME

#define GEN_OFFSET_SYM(...) \
GET_OVERRIDE(__VA_ARGS__, GEN_OFFSET_SYM_INTERNAL_1, \
GEN_OFFSET_SYM_INTERNAL_0)(__VA_ARGS__)
"""

The problem with this solution is that C99 requires at least one
argument in a variadic macro. In other words, it also violates C99.

The other possible solution is change (or add a new) macro that receives three
parameters (the third is an alias).

Do you guys have other solution ? if now which one you prefer, add a new
macro or change the current one (and consequently all invocations).


Regards,
Flavio Ceolin


Re: Get RSSI in DTM(Zephyr)

Chettimada, Vinayak Kariappa
 

Hi Chen,

 

  1. As I know, BLE RSSI can’t be measured in standard DTM mode. Is it possible to add new feature in DTM to support BLE RSSI measurement?

[vich] Yes, this is possible, but the command will have to be proprietary as per your test requirements.

 

  1. If the answer to the above question is “no”, I still need your confirmation if other test modes exist that can measure RSSI except DTM mode.

In our experiences of other algorithm(LTE/WCDMA…etc.), RSSI usually can be detected easily in test mode via a CW tone. So it’s why we want

to double check this.

[vich] RSSI can be easily measured in nRF5x series chips during Radio Rx mode. Implementation will have to be as per your requirement, as standard DTM mode does not define any interface for RSSI in DTM mode.

 

  1. Do you have any customers who have experiences to measure conductive RSSI in factory or in lab? If so, can you share the methodology?

[vich] Other customers may be doing so, but I am not aware of unless the implementation is submitted upstream via a PR.

 

 

Regards,

Vinayak

 

From: Isaac Chen (陳尚航) <Isaac_Chen@...>
Sent: 14 January 2019 04:08
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Tommy Lin (
林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Rung-Sheng Lee (
李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: RE: Get RSSI in DTM(Zephyr)
Importance: High

 

Hi Vinayak,

 

Our customer requested us to test conductive BLE RSSI in factory for accuracy improvement.

Could you please clarify the following questions?

  1. As I know, BLE RSSI can’t be measured in standard DTM mode. Is it possible to add new feature in DTM to support BLE RSSI measurement?

[vich] Yes, this is possible, but the command will have to be proprietary as per your test requirements.

  1. If the answer to the above question is “no”, I still need your confirmation if other test modes exist that can measure RSSI except DTM mode.

In our experiences of other algorithm(LTE/WCDMA…etc.), RSSI usually can be detected easily in test mode via a CW tone. So it’s why we want

to double check this.

[vich] RSSI can be easily measured in nRF5x series chips during Radio Rx mode. Implementation will have to be as per your requirement, as standard DTM mode does not define any interface for RSSI in DTM mode.

  1. Do you have any customers who have experiences to measure conductive RSSI in factory or in lab? If so, can you share the methodology?

[vich] Other customers may be doing so, but I am not aware of unless the implementation is submitted upstream via a PR.

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Wednesday, January 09, 2019 8:00 PM
To: Tommy Lin (
林志聰); zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (
陳尚航); Rung-Sheng Lee (李榮盛); Brent Tsai (蔡旻其); Ryan Hsu (徐振鋒)
Subject: RE: Get RSSI in DTM

 

Hi Tommy,

 

I don’t remember if DTM mode has any RSSI command in the Specification.

 

Could you please elaborate on your requirements?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Tommy Lin (???)
Sent: 08 January 2019 13:25
To: zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Rung-Sheng Lee (李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: [Zephyr-devel] Get RSSI in DTM

 

Hi ,

We have a product using nRF51824 with zephyr.

We use hci_uart sample code and follow below link , and we can get other BT device’s RSSI.

https://devzone.nordicsemi.com/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos

 

We have a question , If it is in DTM(Direct Test Mode) , how can we get RSSI?

Could you give us some suggestions.

 

Best regards,

Tommy


Re: Get RSSI in DTM(Zephyr)

lairdjm
 

Hi Isaac,

Generally you would be measuring the RSSI on the test equipment from a signal generated by your Bluetooth radio, and would be using a calibrated accurate test system. The nRF51824 (from the product spec) has an RSSI accuracy of +/-6dB, that is wildly inaccurate and I cannot see any reason to want to measure/record it on every module. You can add a non-standard command to read and return the RSSI if needed to the DTM code.

Thanks,

Jamie

 

From: devel@... [mailto:devel@...] On Behalf Of Isaac Chen (???)
Sent: 14 January 2019 03:08
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>; Tommy Lin (
林志聰) <Tommy.Lin@...>; zephyr-devel@...
Cc: Hanyu.Hsu@...; Rung-Sheng Lee (
李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: Re: [Zephyr-devel] Get RSSI in DTM(Zephyr)
Importance: High

 

Hi Vinayak,

 

Our customer requested us to test conductive BLE RSSI in factory for accuracy improvement.

Could you please clarify the following questions?

  1. As I know, BLE RSSI can’t be measured in standard DTM mode. Is it possible to add new feature in DTM to support BLE RSSI measurement?
  2. If the answer to the above question is “no”, I still need your confirmation if other test modes exist that can measure RSSI except DTM mode.

In our experiences of other algorithm(LTE/WCDMA…etc.), RSSI usually can be detected easily in test mode via a CW tone. So it’s why we want

to double check this.

  1. Do you have any customers who have experiences to measure conductive RSSI in factory or in lab? If so, can you share the methodology?

 

 

Best Regards

 

Isaac Chen

Quanta Computer Inc.

Business Unit 11 BL1

Tel  : +886-3-327-2345 Ext : 17585

 

This transmission is intended only for the use of the addressed recipient and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any use of this communication is strictly prohibited. If you have received this communication in error, please kindly notify the sender and delete this message immediately. 

 

From: Chettimada, Vinayak Kariappa [mailto:vinayak.kariappa.chettimada@...]
Sent: Wednesday, January 09, 2019 8:00 PM
To: Tommy Lin (
林志聰); zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (
陳尚航); Rung-Sheng Lee (李榮盛); Brent Tsai (蔡旻其); Ryan Hsu (徐振鋒)
Subject: RE: Get RSSI in DTM

 

Hi Tommy,

 

I don’t remember if DTM mode has any RSSI command in the Specification.

 

Could you please elaborate on your requirements?

 

Regards,

Vinayak

 

From: devel@... <devel@...> On Behalf Of Tommy Lin (???)
Sent: 08 January 2019 13:25
To: zephyr-devel@...
Cc: Hanyu.Hsu@...; Isaac Chen (
陳尚航) <Isaac_Chen@...>; Rung-Sheng Lee (李榮盛) <Rung.Sheng.Lee@...>; Brent Tsai (蔡旻其) <Brent.Tsai@...>; Ryan Hsu (徐振鋒) <Ryan.Hsu@...>
Subject: [Zephyr-devel] Get RSSI in DTM

 

Hi ,

We have a product using nRF51824 with zephyr.

We use hci_uart sample code and follow below link , and we can get other BT device’s RSSI.

https://devzone.nordicsemi.com/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos

 

We have a question , If it is in DTM(Direct Test Mode) , how can we get RSSI?

Could you give us some suggestions.

 

Best regards,

Tommy

 

2441 - 2460 of 8041