devel@lists.zephyrproject.org

Deprecating and removing net-app based APIs

Jukka Rissanen

#5596

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 <thomas.tornblom@...>

#5595

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

#5594

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

#5593

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

Show quoted text

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

#5592

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

#5591

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.tornblom@...

#5590

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:

Show quoted text

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

#5589

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

#5588

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

Show quoted text

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

#5587

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

#5586

Hi Chen,

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.

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.

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

Show quoted text

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?

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.

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.

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

#5585

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

Show quoted text

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?

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?
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.

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

Re: Get RSSI in DTM(Zephyr)

Isaac Chen (陳尚航) <Isaac_Chen@...>

#5584

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.

3. 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.

Show quoted text

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: Timer using FRDM-K64F

Nicholas Yameen <Nicholas.Yameen@...>

#5583

Hi,

Thank you for the replies.

I will look into the suggested API’s as well as the other suggestions.

Regards,

Nick

Nicholas Yameen
R&D Engineer

D 978-975-9675 x59675
E Nicholas.Yameen@...

800 Federal Street
Andover, MA 01810
United States

*Please consider the environment before printing this e-mail

Show quoted text

From: Andy Ross [mailto:andrew.j.ross@...]
Sent: Thursday, January 10, 2019 2:04 PM
To: Cufi, Carles <carles.cufi@...>; Nicholas Yameen <Nicholas.Yameen@...>; devel@...
Subject: Re: [Zephyr-devel] Timer using FRDM-K64F

[External email: Use caution with links and attachments]

Changing the k_timer API to work in some other unit than milliseconds is doable, though a little messy from a compatibility standpoint.

The underlying unit of ticks is configurable, and except for the tiny handful of remaining non-tickless targets, can now be arbitrary small (it's just the "unit of timekeeping" and doesn't correspond to interrupt frequency). The limits are the precision of the underlying timer and the overflow potential of 32 bit timeout API. Setting it to microseconds (and expecting it to be accurate at that level) should be possible on fast boards like K64F.

The suggestion to use a driver for external hardware (and not the system timer) is a good one though, especially if you have tight requirements. IIRC the K64 has a bunch of timer devices instanced in addition to the ARM SysTick that Zephyr is using.

Andy

From: Cufi, Carles <carles.cufi@...>
Sent: Thursday, January 10, 2019 9:25AM
To: Nicholas Yameen, Devel
Subject: Re: [Zephyr-devel] Timer using FRDM-K64F

Hi there,

This has been requested several times, but as far as I know has not been completely solved yet.

There is an issue here: https://github.com/zephyrproject-rtos/zephyr/issues/6498, please read through it and comment on your specific requirements so we try to gather all of them there in order to provide an implementation.

In the meantime you can use the HAL’s APIs directly (this is mcux for the Freedom board I believe), which is what other users have done with nRF-based platforms.

Regards,

Carles

From: devel@... <devel@...> On Behalf Of Nicholas Yameen
Sent: 10 January 2019 17:42
To: devel@...
Subject: [Zephyr-devel] Timer using FRDM-K64F

Hello,

My team and I are developing an application that will need the use of timers using the FRDM-K64F board. The application requires a timer to be set using microseconds as the unit. Looking through the Zephyr and FRDM board documentation, I found that it supports millisecond resolution. Is it possible for Zephyr and the FRDM board to have a microsecond resolution? If so, are there examples of microsecond resolution? Thank you.

Regards,

Nick

Nicholas Yameen
R&D Engineer

D  978-975-9675 x59675
E  Nicholas.Yameen@...

800 Federal Street
Andover, MA 01810
United States



*Please consider the environment before printing this e-mail

Re: Timer using FRDM-K64F

Andy Ross

#5582

Changing the k_timer API to work in some other unit than milliseconds is doable, though a little messy from a compatibility standpoint.

The underlying unit of ticks is configurable, and except for the tiny handful of remaining non-tickless targets, can now be arbitrary small (it's just the "unit of timekeeping" and doesn't correspond to interrupt frequency). The limits are the precision of the underlying timer and the overflow potential of 32 bit timeout API. Setting it to microseconds (and expecting it to be accurate at that level) should be possible on fast boards like K64F.

The suggestion to use a driver for external hardware (and not the system timer) is a good one though, especially if you have tight requirements. IIRC the K64 has a bunch of timer devices instanced in addition to the ARM SysTick that Zephyr is using.

Andy

Show quoted text

From: Cufi, Carles <carles.cufi@...>
Sent: Thursday, January 10, 2019 9:25AM
To: Nicholas Yameen, Devel
Subject: Re: [Zephyr-devel] Timer using FRDM-K64F

Hi there,

This has been requested several times, but as far as I know has not been completely solved yet.

There is an issue here: https://github.com/zephyrproject-rtos/zephyr/issues/6498, please read through it and comment on your specific requirements so we try to gather all of them there in order to provide an implementation.

In the meantime you can use the HAL’s APIs directly (this is mcux for the Freedom board I believe), which is what other users have done with nRF-based platforms.

Regards,

Carles

From: devel@... <devel@...> On Behalf Of Nicholas Yameen
Sent: 10 January 2019 17:42
To: devel@...
Subject: [Zephyr-devel] Timer using FRDM-K64F

Hello,

My team and I are developing an application that will need the use of timers using the FRDM-K64F board. The application requires a timer to be set using microseconds as the unit. Looking through the Zephyr and FRDM board documentation, I found that it supports millisecond resolution. Is it possible for Zephyr and the FRDM board to have a microsecond resolution? If so, are there examples of microsecond resolution? Thank you.

Regards,

Nick

Nicholas Yameen
R&D Engineer

D  978-975-9675 x59675
E  Nicholas.Yameen@...

800 Federal Street
Andover, MA 01810
United States



*Please consider the environment before printing this e-mail

Re: Timer using FRDM-K64F

Carles Cufi

#5581

Hi there,

This has been requested several times, but as far as I know has not been completely solved yet.

There is an issue here: https://github.com/zephyrproject-rtos/zephyr/issues/6498, please read through it and comment on your specific requirements so we try to gather all of them there in order to provide an implementation.

In the meantime you can use the HAL’s APIs directly (this is mcux for the Freedom board I believe), which is what other users have done with nRF-based platforms.

Regards,

Carles

Show quoted text

From: devel@... <devel@...> On Behalf Of Nicholas Yameen
Sent: 10 January 2019 17:42
To: devel@...
Subject: [Zephyr-devel] Timer using FRDM-K64F

Hello,

My team and I are developing an application that will need the use of timers using the FRDM-K64F board. The application requires a timer to be set using microseconds as the unit. Looking through the Zephyr and FRDM board documentation, I found that it supports millisecond resolution. Is it possible for Zephyr and the FRDM board to have a microsecond resolution? If so, are there examples of microsecond resolution? Thank you.

Regards,

Nick

Nicholas Yameen
R&D Engineer

D 978-975-9675 x59675
E Nicholas.Yameen@...

800 Federal Street
Andover, MA 01810
United States

*Please consider the environment before printing this e-mail

Timer using FRDM-K64F

Nicholas Yameen <Nicholas.Yameen@...>

#5580

Hello,

My team and I are developing an application that will need the use of timers using the FRDM-K64F board. The application requires a timer to be set using microseconds as the unit. Looking through the Zephyr and FRDM board documentation, I found that it supports millisecond resolution. Is it possible for Zephyr and the FRDM board to have a microsecond resolution? If so, are there examples of microsecond resolution? Thank you.

Regards,

Nick

Nicholas Yameen
R&D Engineer

D 978-975-9675 x59675
E Nicholas.Yameen@...

800 Federal Street
Andover, MA 01810
United States

*Please consider the environment before printing this e-mail

Re: Dev Meeting on Thursdays

Kumar Gala

#5579

I’ve created the ‘dev-review’ label for us to mark PRs for review in the meeting.

- k

Show quoted text

On Jan 9, 2019, at 3:54 PM, Kumar Gala <kumar.gala@linaro.org> wrote:

All,

If you have a PR or Issue that needs discussion we will use this call to talk about it.  The meeting will use the time slot that we had for the bug triage meeting (10a Central US Standard Time).

Here’s the meeting details:

Zephyr Working Group is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
       +1 669 900 6833 US (San Jose)
       +1 646 558 8656 US (New York)
       +1 877 369 0926 US Toll-free
       +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Dev Meeting on Thursdays

Kumar Gala

#5578

All,

If you have a PR or Issue that needs discussion we will use this call to talk about it.  The meeting will use the time slot that we had for the bug triage meeting (10a Central US Standard Time).

Here’s the meeting details:

Zephyr Working Group is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/993312203

One tap mobile
+16699006833,,993312203# US (San Jose)
+16465588656,,993312203# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 993 312 203
Find your local number: https://zoom.us/u/ankEMRagf

Re: Get RSSI in DTM

Chettimada, Vinayak Kariappa

#5577

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

Show quoted text

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