Date   

Re: Sanity check and test cases

Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

On Wed, 2016-03-30 at 15:38 +0000, Kalowsky, Daniel wrote:
Hey Yannis,

 

Is it safe to submit the patch to gerrit or should I first test it
on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good
enough.  I've added Inaky to the thread who can more than likely run
this through a series of hardware tests pretty quickly.
Can you point me to the patch? I can't see it in the original email in
the thread (save my email doing funky stuff :)

Thanks


Re: Sanity check and test cases

Benjamin Walsh <benjamin.walsh@...>
 

You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
Now that I've seen the patch it got me thinking. What if we added an
opt-in debug code for fiber/tasks that helped to measure stack usage?
This could be something really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks
with 0xaa when threads are initialized.

finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?


Re: Sanity check and test cases

Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Yannis,

-----Original Message-----
From: Yannis Damigos [mailto:giannis.damigos(a)gmail.com]
Sent: Wednesday, March 30, 2016 7:22 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Sanity check and test cases

Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically
allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and
arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good enough. I've added Inaky to the thread who can more than likely run this through a series of hardware tests pretty quickly.


Re: Sanity check and test cases

Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 30, 2016 at 4:47 PM, Maciek Borzecki
<maciek.borzecki(a)gmail.com> wrote:
Hi,

On Wed, Mar 30, 2016 at 4:21 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?
You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
Now that I've seen the patch it got me thinking. What if we added an
opt-in debug code for fiber/tasks that helped to measure stack usage?
This could be something really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?

Cheers,
--
Maciek Borzecki


Re: RFC: extend sanitycheck testcase filtering expressiveness

Boie, Andrew P
 

QA test suite actually has similar requirement for test case filtering by
expression. We took a lightweight approach, directly use "python
expression" instead of creating a new one. The benefit of "python
expression" is, the expression can be parsed by python eval() function
directly. Thus, below filter expression is naturally supported with a small code
snippets.
@tag_exp('soc not in ["quark_se", "quark_d2000"]')
def test_xxxx(self):
I briefly considered this approach but after doing some reading concluded it was unsafe.

http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html

Andrew


Re: Sanity check and test cases

Maciek Borzecki <maciek.borzecki@...>
 

Hi,

On Wed, Mar 30, 2016 at 4:21 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?
You can post the patch and add me for review. From what I've seen,
there's ~10 tests that fail under sanitycheck with SRAM overflow from
hundreds of bytes, to couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.

Cheers,
--
Maciek Borzecki


Re: FW: [users] TCP/IP support in network IP stack

Paul Duffy <paduffy@...>
 

Could MQTT-SN work for you?

On 3/30/2016 4:53 AM, Mahendravarman rajarao wrote:
Thanks a lot for the reply

If TCP support to the network stack is provided then Can I use the MQTT client library to make support for MQTT ?

Can you please tell me when can I expect the TCP support to network stack ?

Thanks again
.


Sanity check and test cases

Yannis Damigos
 

Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?

best regards,
Yannis


Re: FW: [users] TCP/IP support in network IP stack

Mahendravarman rajarao <mahendravarman.rajarao@...>
 

Thanks a lot for the reply

If TCP support to the network stack is provided then Can I use the MQTT client library to make support for MQTT ?

Can you please tell me when can I expect the TCP support to network stack ?

Thanks again


Re: RFC: extend sanitycheck testcase filtering expressiveness

Wang, Jing J
 

QA test suite actually has similar requirement for test case filtering by expression. We took a lightweight approach, directly use "python expression" instead of creating a new one. The benefit of "python expression" is, the expression can be parsed by python eval() function directly. Thus, below filter expression is naturally supported with a small code snippets.
@tag_exp('soc not in ["quark_se", "quark_d2000"]')
def test_xxxx(self):

Rgds
jwang

-----Original Message-----
From: Dmitriy Korovkin [mailto:dmitriy.korovkin(a)windriver.com]
Sent: Tuesday, March 29, 2016 4:23 AM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: RFC: extend sanitycheck testcase filtering expressiveness

On Fri, 25 Mar 2016, Boie, Andrew P wrote:

Proposed solution:

We need a more expressive language for filtering test cases. I propose
a simple boolean expression language with the following grammar:

expression ::= expression "and" expression
| expression "or" expression
| "not" expression
| "(" expression ")"
| symbol "==" constant
| symbol "!=" constant
| symbol "<" number
| symbol ">" number
| symbol ">=" number
| symbol "<=" number
| symbol "in" list
| symbol

list ::= "[" list_contents "]"

list_contents ::= constant
| list_contents "," constant

constant ::= number
| string

When symbols are encountered, they are looked up in an environment
dictionary. In sanitycheck the environment will initially consist of:

{
ARCH : <architecture>,
PLATFORM : <platform>,
<all CONFIG_* key/value pairs in the test's generated defconfig>
}

We can later augment this with additional interesting metadata if we
want. For example I was thinking of ways we could integrate some
footprint information for large tests.

For the case where

expression ::= symbol

it evaluates to true if the symbol is defined to a non-empty string.

For all comparison operators, if the config symbol is undefined, it
will be treated as a 0 (for > < >= <=) or an empty string "" (for == != in).
For numerical comparisons it doesn't matter if the environment stores
the value as an integer or string, it will be cast appropriately.

Operator precedence, starting from lowest to highest:

or (left associative)
and (left associative)
not (right associative)
all comparison operators (non-associative)

In testcase.ini the 'config_whitelist' directive will be removed and
replaced with 'filter' directives containing one of these expressions.
arch_whitelist, arch_exclude, platform_whitelist, platform_exclude are
all syntactic sugar for these expressions. For instance

arch_exclude = x86 arc

Is the same as:

filter = not ARCH in ["x86", "arc"]
I see nothing bad in the proposal.

Implementation details:

Writing a parser by hand is a pain and prone to bugs. The best way to
do a language like this is to use a LR parser generator like lex/yacc.
There exists an open source library called PLY which does lex/yacc for
Python, it has been around for a long time and works very well:

http://www.dabeaz.com/ply/index.html

The sample implementation I have drops a copy of PLY directly in the
Zephyr source tree since its license is compatible and this will
result in the least pain for users as they won't have to do anything.
If this is unacceptable we can either find a way to stick it in the
SDK, or add it to the list of workstation dependencies (either have
the user install with pip or their distribution's package manager.
Fedora appears to have PLY installed by default).
I would refrain from copying PLY into the source tree for the following
reasons:
- Support. Updating the library, which is not the part of the
project may be a headache.
- Licensing. There may be issues with distributing with Zephyr the code
that we have not developed.
- Importing. In case of side projects that, for instance, run all
sanity_chk projects on real hardware, using sanity_chk combined with
additional library may create problems.
- Distributions. Ubuntu has PLY 3.4 as a part of the distribution. As you
have mentioned, Fedora has it as well.
Regards,
/Dmitriy


Re: FW: [users] TCP/IP support in network IP stack

Jukka Rissanen
 

On Tue, 2016-03-29 at 15:30 +0000, Mahendravarman Rajarao (RBEI/EAA3)
wrote:
Hi

Under Zephyr RTOS net/ip/net_core.c, Support for IPPROTO_UDP is
available and Support for IPPROTO_TCP is mentioned as not yet
supported

Does it mean the Zephyr RTOS network stack has support only for UDP
and there is no support for TCP/IP?
Yes, TCP is not supported right now.


Any plans on support for TCP/IP on network stack ?
Yes, I am currently working on adding TCP support to the network stack.


Cheers,
Jukka


k64 rgb-led kernel module

Idupsle <idupsle@...>
 

Hello everybody,

I recently wanted to have a more fun with the k64 and wrote a little kernel
module. I don't know, if it is needed for the real kernel and if the structure
is right. But if anyone is interested in it... here!
Eg:

#include <drivers/k64_rgb.h>
rgb_set_color(0); // set red
rgb_set_color(1); // set green
rgb_set_color(2); // set blue
rgb_set_color(3); // set yellow
rgb_set_color(4); // set cyan
rgb_set_color(5); // set magenta
rgb_set_color(6); // set white
rgb_set_color(7); // set off



diff --git a/drivers/gpio/Kconfig.k64 b/drivers/gpio/Kconfig.k64
index 8854f73..837855a 100644
--- a/drivers/gpio/Kconfig.k64
+++ b/drivers/gpio/Kconfig.k64
@@ -136,4 +136,10 @@ config GPIO_K64_PORTE_PRI
help
K64 Port E IRQ priority

+config GPIO_K64_RGB_LED
+ bool "Freeschale K64-based board LED-RGB driver"
+ depends on GPIO_K64 && CONFIG_PINMUX_DEV_FRDM_K64F
+ default n
+ help
+ K64 Ports for RGB LED.
endif # GPIO_K64
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f34c0ce..61a815a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -8,4 +8,6 @@ obj-$(CONFIG_GPIO_SCH) += gpio_sch.o
obj-$(CONFIG_GPIO_QMSI) += gpio_qmsi.o
obj-$(CONFIG_GPIO_ATMEL_SAM3) += gpio_atmel_sam3.o
obj-$(CONFIG_GPIO_K64) += gpio_k64.o
+obj-$(CONFIG_GPIO_K64_RGB_LED) += k64_rgb.o
obj-$(CONFIG_GPIO_STM32) += gpio_stm32.o
+
diff --git a/drivers/gpio/k64_rgb.c b/drivers/gpio/k64_rgb.c
new file mode 100644
index 0000000..06df03d
--- /dev/null
+++ b/drivers/gpio/k64_rgb.c
@@ -0,0 +1,93 @@
+#ifdef CONFIG_GPIO_K64_RGB_LED
+
+#include <errno.h>
+
+#include <nanokernel.h>
+#include <device.h>
+#include <init.h>
+#include <gpio.h>
+#include <sys_io.h>
+#include <soc.h>
+
+#include <pinmux/frdm_k64f/pinmux_k64.h>
+
+#include "gpio_k64.h"
+#include "k64_rgb.h"
+
+void k64_rgb_set_red(uint8_t value)
+{
+ if (value) {
+ sys_set_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_RED%K64_PINMUX_NUM_PINS);
+ } else {
+ sys_clear_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_RED%K64_PINMUX_NUM_PINS);
+ }
+}
+void k64_rgb_set_blue(uint8_t value)
+{
+ if (value) {
+ sys_set_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_BLUE%K64_PINMUX_NUM_PINS);
+ } else {
+ sys_clear_bit((GPIO_K64_B_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_BLUE%K64_PINMUX_NUM_PINS);
+ }
+}
+void k64_rgb_set_green(uint8_t value)
+{
+ if (value) {
+ sys_set_bit((GPIO_K64_E_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_GREEN%K64_PINMUX_NUM_PINS);
+ } else {
+ sys_clear_bit((GPIO_K64_E_BASE_ADDR
+ +GPIO_K64_DIR_OFFSET),
+ K64_PIN_GREEN%K64_PINMUX_NUM_PINS);
+ }
+}
+
+void k64_rgb_set(uint8_t r, uint8_t g, uint8_t b)
+{
+ k64_rgb_set_red(0);
+ k64_rgb_set_blue(0);
+ k64_rgb_set_green(0);
+ if (r)
+ k64_rgb_set_red(1);
+ if (g)
+ k64_rgb_set_blue(1);
+ if (b)
+ k64_rgb_set_green(1);
+}
+int rgb_set_color(uint8_t color)
+{
+
+ if (color > 7) return 1;
+ switch(color)
+ {
+ case K64_RGB_RED: k64_rgb_set(1, 0, 0);
+ break;
+ case K64_RGB_GREEN: k64_rgb_set(0, 1, 0);
+ break;
+ case K64_RGB_BLUE: k64_rgb_set(0, 0, 1);
+ break;
+ case K64_RGB_YELLOW: k64_rgb_set(1, 1, 0);
+ break;
+ case K64_RGB_CYAN: k64_rgb_set(0, 1, 1);
+ break;
+ case K64_RGB_MAGENTA: k64_rgb_set(1, 0, 1);
+ break;
+ case K64_RGB_WHITE: k64_rgb_set(1, 1, 1);
+ break;
+ case K64_RGB_OFF: k64_rgb_set(0, 0, 0);
+ break;
+ }
+ return 0;
+}
+
+#endif
+
diff --git a/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c b/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c
index 9717ef5..9c39b0e 100644
--- a/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c
+++ b/drivers/pinmux/frdm_k64f/pinmux_board_frdm_k64f.c
@@ -38,11 +38,16 @@
* Since the K64 MCU configures these pins for JTAG/SWD signaling at reset,
* they should only be re-configured if the debug interface is not used.
*/
+#ifdef CONFIG_GPIO_K64_RGB_LED
+#define LED_RGB_PINS 3
+#else
+#define LED_RGB_PINS 0
+#endif

#ifndef CONFIG_PRESERVE_JTAG_IO_PINS
-#define NUM_DFLT_PINS_SET 22
+#define NUM_DFLT_PINS_SET 22 + LED_RGB_PINS
#else
-#define NUM_DFLT_PINS_SET (22 - 3)
+#define NUM_DFLT_PINS_SET (22 - 3) + LED_RGB_PINS
#endif

/*
@@ -58,6 +63,10 @@ struct pin_config mux_config[NUM_DFLT_PINS_SET] = {
#ifndef CONFIG_PRESERVE_JTAG_IO_PINS
{ K64_PIN_PTA1, K64_PINMUX_FUNC_GPIO },
#endif
+#ifdef CONFIG_GPIO_K64_RGB_LED
+ { K64_PIN_PTB21, K64_PINMUX_FUNC_GPIO },
+ { K64_PIN_PTB22, K64_PINMUX_FUNC_GPIO },
+#endif
{ K64_PIN_PTB23, K64_PINMUX_FUNC_GPIO },
#ifndef CONFIG_PRESERVE_JTAG_IO_PINS
{ K64_PIN_PTA2, K64_PINMUX_FUNC_GPIO },
@@ -76,6 +85,9 @@ struct pin_config mux_config[NUM_DFLT_PINS_SET] = {
{ K64_PIN_PTE25, (K64_PINMUX_ALT_5 | K64_PINMUX_OPEN_DRN_ENABLE) },
/* I2C0_SCL */
{ K64_PIN_PTE24, (K64_PINMUX_ALT_5 | K64_PINMUX_OPEN_DRN_ENABLE) },
+#ifdef CONFIG_GPIO_K64_RGB_LED
+ { K64_PIN_PTE26, K64_PINMUX_FUNC_GPIO },
+#endif
{ K64_PIN_PTB2, K64_PINMUX_FUNC_ANALOG }, /* ADC0_SE12/Analog In 0 */
{ K64_PIN_PTB3, K64_PINMUX_FUNC_ANALOG }, /* ADC0_SE13/Analog In 1 */
{ K64_PIN_PTB10, K64_PINMUX_FUNC_ANALOG }, /* ADC1_SE14/Analog In 2 */
diff --git a/drivers/pinmux/frdm_k64f/pinmux_k64.h b/drivers/pinmux/frdm_k64f/pinmux_k64.h
index ca40c14..bc30e25 100644
--- a/drivers/pinmux/frdm_k64f/pinmux_k64.h
+++ b/drivers/pinmux/frdm_k64f/pinmux_k64.h
@@ -280,6 +280,12 @@
#define K64_PIN_PTE30 158
#define K64_PIN_PTE31 159

+#ifdef CONFIG_GPIO_K64_RGB_LED
+#define K64_PIN_RED 54
+#define K64_PIN_GREEN 154
+#define K64_PIN_BLUE 53
+#endif
+
int _fsl_k64_set_pin(uint32_t pin_id, uint32_t func);

int _fsl_k64_get_pin(uint32_t pin_id, uint32_t *func);
diff --git a/include/drivers/k64_rgb.h b/include/drivers/k64_rgb.h
new file mode 100644
index 0000000..de63ae6
--- /dev/null
+++ b/include/drivers/k64_rgb.h
@@ -0,0 +1,39 @@
+#ifndef _K64RGB_H
+#define _K64RGB_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+
+#ifdef CONFIG_GPIO_K64_RGB_LED
+//#include "gpio_k64.h"
+#include <gpio.h>
+
+
+/* Available color slsections */
+#define K64_RGB_RED 0
+#define K64_RGB_GREEN 1
+#define K64_RGB_BLUE 2
+#define K64_RGB_YELLOW 3
+#define K64_RGB_CYAN 4
+#define K64_RGB_MAGENTA 5
+#define K64_RGB_WHITE 6
+#define K64_RGB_OFF 7
+
+
+extern int rgb_set_color(uint8_t color);
+//{
+// return k64_rgb_set_color(color);
+//}
+
+
+
+
+#endif /* CONFIG_GPIO_K64_RGB */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _K64RGB_H */


FW: [users] TCP/IP support in network IP stack

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi

Under Zephyr RTOS net/ip/net_core.c, Support for IPPROTO_UDP is available and Support for IPPROTO_TCP is mentioned as not yet supported

Does it mean the Zephyr RTOS network stack has support only for UDP and there is no support for TCP/IP?

Any plans on support for TCP/IP on network stack ?


Re: RFC: extend sanitycheck testcase filtering expressiveness

Nashif, Anas
 

On 28 Mar 2016, at 17:04, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:

On Mon, 2016-03-28 at 16:23 -0400, Dmitriy Korovkin wrote:
I would refrain from copying PLY into the source tree for the
following
reasons:
- Support. Updating the library, which is not the part of the
project may be a headache.
- Licensing. There may be issues with distributing with Zephyr the
code
that we have not developed.
- Importing. In case of side projects that, for instance, run all
sanity_chk projects on real hardware, using sanity_chk combined
with
additional library may create problems.
- Distributions. Ubuntu has PLY 3.4 as a part of the distribution. As
you
have mentioned, Fedora has it as well.
Yeah I'll take it out of the patch series.
I've asked Juro to look into including it into the Zephyr SDK, which is
where we typically put our dependent packages. If that doesn't work out
we would just have to add 'sudo dnf install python3-ply' (or
equivalent) to the workstation setup.
Beside the issue above, the proposal looks good to me and will definitely improve and expand the coverage.
Lets find a way to make this work without adding the parser into the tree please.

Thanks,

Anas


Andrew


Re: RFC: extend sanitycheck testcase filtering expressiveness

Boie, Andrew P
 

On Mon, 2016-03-28 at 16:23 -0400, Dmitriy Korovkin wrote:
I would refrain from copying PLY into the source tree for the
following 
reasons:
- Support. Updating the library, which is not the part of the
   project may be a headache.
- Licensing. There may be issues with distributing with Zephyr the
code
   that we have not developed.
- Importing. In case of side projects that, for instance, run all
   sanity_chk projects on real hardware, using sanity_chk combined
with
   additional library may create problems.
- Distributions. Ubuntu has PLY 3.4 as a part of the distribution. As
you
   have mentioned, Fedora has it as well.
Yeah I'll take it out of the patch series.
I've asked Juro to look into including it into the Zephyr SDK, which is
where we typically put our dependent packages. If that doesn't work out
we would just have to add 'sudo dnf install python3-ply' (or
equivalent) to the workstation setup.

Andrew


Cortex-M0 porting status? (was: Re: Re: STM32F103x port)

Anderson Lizardo <anderson.lizardo@...>
 

Hi Anas,

On Fri, Feb 26, 2016 at 4:52 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

On Feb 26, 2016, at 11:08, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Has anyone looked at ports to Cortex-M0?

There is an effort going on right now, details will be provided soon.
Any updates on the Cortex-M0 porting effort? Is there any public code
(even WIP) to look at?


Best Regards,
--
Anderson Lizardo


Re: RFC: extend sanitycheck testcase filtering expressiveness

Dmitriy Korovkin
 

On Fri, 25 Mar 2016, Boie, Andrew P wrote:

Proposed solution:

We need a more expressive language for filtering test cases. I propose a
simple boolean expression language with the following grammar:

expression ::= expression "and" expression
| expression "or" expression
| "not" expression
| "(" expression ")"
| symbol "==" constant
| symbol "!=" constant
| symbol "<" number
| symbol ">" number
| symbol ">=" number
| symbol "<=" number
| symbol "in" list
| symbol

list ::= "[" list_contents "]"

list_contents ::= constant
| list_contents "," constant

constant ::= number
| string

When symbols are encountered, they are looked up in an environment
dictionary. In sanitycheck the environment will initially consist of:

{
ARCH : <architecture>,
PLATFORM : <platform>,
<all CONFIG_* key/value pairs in the test's generated defconfig>
}

We can later augment this with additional interesting metadata if we
want. For example I was thinking of ways we could integrate some
footprint information for large tests.

For the case where

expression ::= symbol

it evaluates to true if the symbol is defined to a non-empty string.

For all comparison operators, if the config symbol is undefined, it will
be treated as a 0 (for > < >= <=) or an empty string "" (for == != in).
For numerical comparisons it doesn't matter if the environment stores
the value as an integer or string, it will be cast appropriately.

Operator precedence, starting from lowest to highest:

or (left associative)
and (left associative)
not (right associative)
all comparison operators (non-associative)

In testcase.ini the 'config_whitelist' directive will be removed and
replaced with 'filter' directives containing one of these expressions.
arch_whitelist, arch_exclude, platform_whitelist, platform_exclude
are all syntactic sugar for these expressions. For instance

arch_exclude = x86 arc

Is the same as:

filter = not ARCH in ["x86", "arc"]
I see nothing bad in the proposal.

Implementation details:

Writing a parser by hand is a pain and prone to bugs. The best way to do
a language like this is to use a LR parser generator like lex/yacc.
There exists an open source library called PLY which does lex/yacc for
Python, it has been around for a long time and works very well:

http://www.dabeaz.com/ply/index.html

The sample implementation I have drops a copy of PLY directly in the
Zephyr source tree since its license is compatible and this will result
in the least pain for users as they won't have to do anything. If this
is unacceptable we can either find a way to stick it in the SDK, or add
it to the list of workstation dependencies (either have the user install
with pip or their distribution's package manager. Fedora appears to have
PLY installed by default).
I would refrain from copying PLY into the source tree for the following
reasons:
- Support. Updating the library, which is not the part of the
project may be a headache.
- Licensing. There may be issues with distributing with Zephyr the code
that we have not developed.
- Importing. In case of side projects that, for instance, run all
sanity_chk projects on real hardware, using sanity_chk combined with
additional library may create problems.
- Distributions. Ubuntu has PLY 3.4 as a part of the distribution. As you
have mentioned, Fedora has it as well.
Regards,
/Dmitriy


RFC: remove microkernel Task IRQs from Zephyr

Boie, Andrew P
 

Problem statement:

The current implementation of Microkernel Task IRQs has a hard
dependency on dynamic interrupts, which we also want to remove from
Zephyr.

Although the mechanism could be redesigned to use static IRQs, the
value it provides to the kernel is dubious. It's very simple with other
APIs to have a driver that needs this functionality to create their own
task and have it wait on a kevent_t which the driver ISR releases.

Historically, when Zephyr used to have a user/kernel space separation,
Task IRQs were used for user space processes to register with an IRQ
coupled with MMIO mapping routines. We don't have user space any more.
We'd rather not continue to maintain this thing.

Solution:

Remove microkernel task IRQs and leave the uncommon use-cases where
they would be needed as a (simple) exercise for the application or
driver developer.


Re: Help for tests/benchmark/latency_measure run failed on Arduino Due board.

Li, Min A <min.a.li@...>
 

Hi Rodger,

You can first have a try without "TEST=max" option. Besides this, gdb can be used to debug this issue after disabled the other successful indicators.


Regards
Min

-----Original Message-----
From: Rodger Lin [mailto:caritas(a)163.com]
Sent: Monday, March 28, 2016 2:40 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Help for tests/benchmark/latency_measure run failed on Arduino Due board.

I built the test code at "tests/benchmark/latency_measure/microkernel" . It runs well using the qemu mode.
I want to try it on Arduino Due board, built it using:

make TEST=max BOARD=arduino_due

After the program runs on the Arduino Due board. I got the "failure" with some error items. Here is the result:

|-----------------------------------------------------------------------------|

| Nanokernel Latency Benchmark |

|-----------------------------------------------------------------------------|

| tcs = timer clock cycles: 1 tcs is 11 nsec |

|-----------------------------------------------------------------------------|

| 1- Measure time to switch from fiber to ISR execution |

| switching time is 156 tcs = 1857 nsec |

|-----------------------------------------------------------------------------|

| 2- Measure time to switch from ISR back to interrupted fiber |

| switching time is 117 tcs = 1392 nsec |

|-----------------------------------------------------------------------------|

| 3- Measure time from ISR to executing a different fiber (rescheduled) |

| switching time is 367 tcs = 4369 nsec |

|-----------------------------------------------------------------------------|

| 4- Measure average context switch time between fibers |

| Error: tick occurred |

|-----------------------------------------------------------------------------|

| 5- Measure average time to lock then unlock interrupts |

| Error: tick occurred |

|-----------------------------------------------------------------------------|

|-----------------------------------------------------------------------------|

| Microkernel Latency Benchmark |

|-----------------------------------------------------------------------------|

| tcs = timer clock cycles: 1 tcs is 11 nsec |

|-----------------------------------------------------------------------------|

| 1- Measure time to switch from ISR to back to interrupted task |

| switching time is 119 tcs = 1416 nsec |

|-----------------------------------------------------------------------------|

| 2- Measure time from ISR to executing a different task (rescheduled) |

| switch time is 694 tcs = 8261 nsec |

|-----------------------------------------------------------------------------|

| 3- Measure average time to signal a sema then test that sema |

| Average semaphore signal time 0 tcs = 0 nsec |

| Average semaphore test time 0 tcs = 0 nsec |

|-----------------------------------------------------------------------------|

| 4- Measure average time to lock a mutex then unlock that mutex |

| Average time to lock the mutex 504056 tcs = 6000668 nsec |

| Average time to unlock the mutex 587911 tcs = 6998948 nsec |

|-----------------------------------------------------------------------------|

| 5- Measure average context switch time between tasks using (task_yield) |

| Error: tick occurred |

|-----------------------------------------------------------------------------|

| E N D |

|-----------------------------------------------------------------------------|

===================================================================

PROJECT EXECUTION FAILED


Help for tests/benchmark/latency_measure run failed on Arduino Due board.

Rodger Lin
 

I built the test code at "tests/benchmark/latency_measure/microkernel" . It runs well using the qemu mode.
I want to try it on Arduino Due board, built it using:

make TEST=max BOARD=arduino_due

After the program runs on the Arduino Due board. I got the "failure" with some error items. Here is the result:

|-----------------------------------------------------------------------------|

| Nanokernel Latency Benchmark |

|-----------------------------------------------------------------------------|

| tcs = timer clock cycles: 1 tcs is 11 nsec |

|-----------------------------------------------------------------------------|

| 1- Measure time to switch from fiber to ISR execution |

| switching time is 156 tcs = 1857 nsec |

|-----------------------------------------------------------------------------|

| 2- Measure time to switch from ISR back to interrupted fiber |

| switching time is 117 tcs = 1392 nsec |

|-----------------------------------------------------------------------------|

| 3- Measure time from ISR to executing a different fiber (rescheduled) |

| switching time is 367 tcs = 4369 nsec |

|-----------------------------------------------------------------------------|

| 4- Measure average context switch time between fibers |

| Error: tick occurred |

|-----------------------------------------------------------------------------|

| 5- Measure average time to lock then unlock interrupts |

| Error: tick occurred |

|-----------------------------------------------------------------------------|

|-----------------------------------------------------------------------------|

| Microkernel Latency Benchmark |

|-----------------------------------------------------------------------------|

| tcs = timer clock cycles: 1 tcs is 11 nsec |

|-----------------------------------------------------------------------------|

| 1- Measure time to switch from ISR to back to interrupted task |

| switching time is 119 tcs = 1416 nsec |

|-----------------------------------------------------------------------------|

| 2- Measure time from ISR to executing a different task (rescheduled) |

| switch time is 694 tcs = 8261 nsec |

|-----------------------------------------------------------------------------|

| 3- Measure average time to signal a sema then test that sema |

| Average semaphore signal time 0 tcs = 0 nsec |

| Average semaphore test time 0 tcs = 0 nsec |

|-----------------------------------------------------------------------------|

| 4- Measure average time to lock a mutex then unlock that mutex |

| Average time to lock the mutex 504056 tcs = 6000668 nsec |

| Average time to unlock the mutex 587911 tcs = 6998948 nsec |

|-----------------------------------------------------------------------------|

| 5- Measure average context switch time between tasks using (task_yield) |

| Error: tick occurred |

|-----------------------------------------------------------------------------|

| E N D |

|-----------------------------------------------------------------------------|

===================================================================

PROJECT EXECUTION FAILED

7521 - 7540 of 7936