Date   

Re: Inconsistent and ever-changing device naming in Zephyr

Andy Gross
 

On 9 February 2017 at 03:52, Jon Medhurst (Tixy) <tixy@linaro.org> wrote:
On Wed, 2017-02-08 at 11:31 -0600, Andy Gross wrote:
On 6 February 2017 at 10:59, Daniel Thompson <daniel.thompson@linaro.org> wrote:
On 06/02/17 13:34, Paul Sokolovsky wrote:

Hello,

Writing on this was in my TODO at least since November, but I expected
this to be a controversial topic, so kind of skipped it. Controversial,
as in: different parties finding to be "obvious" quite different, if
not opposite solutions to the problem. Well, the breakage continues,
so this should be raised.

(Recent) facts:

1. Update to Kinetis (BOARD=frdm_k64f) port broke GPIO support in a
(complex) Zephyr-based application, Zephyr.js:
https://github.com/01org/zephyr.js/issues/665

2. A day or two, Arduino 101 I2C support in Zephyr.js was updated,
apparently because Zephyr upgrade broke it. Today it became known that
the fix for Arduino 101 broke FRDM-K64F.
https://github.com/01org/zephyr.js/issues/676

Investigating the issues, the causes of them are:

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!) "gpio_porta".

2. Name of (one of) I2C device for arduino_101 changed from "I2C_0" to
"I2C_SS_0".


This is not the first time when device names change in Zephyr (see
reference above to November 2016), it's the first time (at least for
last half-year), when the naming changes in relatively well developed
ports, which leads to cascade of breakage in the one. And one case, it
can be seen how inconsistent naming (and changes of it) can be.

The question what to do about this. Possible high-level approaches can
be:

a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.

b) Send a strong message to application developers that they should
not rely on any patterns of Zephyr device naming, and even on the naming
at all, and instead should treat it as a configuration parameter, which
ultimately should be set by a user (and thus apps should make such
configuration explicit and easy for users).

Or c) inherit the device names from device tree?

I don't actually remember that much about the proposed DT tooling but it
should certainly be included in this discussion.

It might be made slightly more complex by the presence of aliased names in
DT (often used to bridge SoC datasheet namings into board based names). I
guess Zephyr might prefer to use the most-derived alias rather then the SoC
datasheet name?
The alias {} node can indeed be used for this. But unless we define a
specific format, parsing this might be interesting. However we have
some solutions for that if we want to go that route. A board specific
yaml file could specify the alias format. It's need to be something
that can co-exist with existing DT files that might be imported from
Linux.

Maybe something along the lines of:
zephyr,uart-0 = &node@xxxxxxxx;
zephyr,uart-1 = &node@xxxxxxxx;
and so on and so forth. These can ghost the aliases already present
if they have something like uart0 = &node@xxxxxxxx; The zephyr,XXXXX
need to be standardized for each device type. We strip the zephyr
part and the generated string name becomes UART-0 or UART0 or whatever
standard we want.

I think this solves both the unified naming and the assigning of the
names to specific nodes.
So, if I get this right, this is device-tree aliases being used to
specify the driver name in Zephy? I.e. the drv_name parameter passed to
DEVICE_INIT and the string passed to device_get_binding to get a pointer
to that driver instance.

I thought aliases we're going to be used as a method to replace the
'fixup' files in the current DT RFC patches by matching device-tree node
names (<compataible-string>_<address>_<property>) to driver defines
(<foo>_<port_N>_<bar> or similar)

Is the latter wrong? Or is it a different alias entry in DT used for
that?
Right now the device names are defined in the Kconfig options. The
device tree aims to replace that by determining that via the contents
of the device tree file. Not only the device name needs to be derived
but also the current information that is fixed up by the fixup file.

So from a Linux perspective, the alias is used by client programs to
determine the device node for specific things. A good example is
mapping of serial ports to make sure the console ends up on the right
device.

In the zephyr use case, we don't care about client programs using the
compiled blob. And we don't want to conflict with DTS files that have
been imported from Linux and that need to work in both Zephyr and
Linux (STM has some examples coming of this). One way around this
collision is to follow the example of the zephyr entries in the
chosen{} node. Perhaps it would be better to define a zephyr node
that contains the zephyr specific mappings and the sram, flash, and
console entries.

That brings us to the device names themselves. I am of two minds on
this. On one hand, the names need to match the names on the board or
board documentation. It makes it difficult for users to have to
determine the zephyr name that matches the silkscreen name. On the
other hand, having all these different formats trigger my OCD. I feel
stronger about the silkscreen/documentation matching the names. So
place my vote in the chaos column.

As for matching device names to #defines to device tree data, I think
the solution for that lies in the YAML file itself. As part of the
config, we put in the device name we want and this is used to parse
the DT and get the right mapping. In addition this allows us to
generate whatever device specific prefix we need.

Regards,

Andy


Interrupt refactoring

Boie, Andrew P
 

I’ve contributed some patches to how static interrupts are configured. This is to enable ‘direct’ interrupts on ARM as well as allow enumerated types as IRQ line parameters, see:

 

https://jira.zephyrproject.org/browse/ZEP-1038

https://jira.zephyrproject.org/browse/ZEP-1165

 

Patches are here, review appreciated:

 

https://gerrit.zephyrproject.org/r/11026

https://gerrit.zephyrproject.org/r/11027

https://gerrit.zephyrproject.org/r/11028

https://gerrit.zephyrproject.org/r/11062

https://gerrit.zephyrproject.org/r/11071

https://gerrit.zephyrproject.org/r/11072

 

Andrew


Re: Inconsistent and ever-changing device naming in Zephyr

Chuck Jordan <Chuck.Jordan@...>
 

Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase).
However I *am* a fan of selecting labels from "facts" about the board (silk screening, datasheet port/connector names, etc).
As a trivial example I'd really dislike a system where "for consistency"
we force BSPs to call something "UART-0" when the silkscreen (or
front-panel) says "DB9-1".
I guess that is an argument *against* board-to-board consistency!
[chuck] Minor point, but the device driver talks to a UART and the UART may have a different designation on the schematic, not visible to the outside user.
A name like "DB9-1" is a physical connector name, and it can be unclear which UART is attached to it, which jumpers need to be changed, whether there is another layer of switching between UART and connector and so forth. I've seen boards where a UART can be directed to one of many different connectors via jumper choices. So opening "DB9-1" might fail if the jumpers are wrong, for example. Driver is for UART only ... not the physical wiring beyond the UART.


Re: CONFIG_SEMAPHORE_GROUPS

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Feb 09, 2017 at 09:43:23AM +0000, Shtivelman, Bella wrote:
Hi Benjamin,
Thank you for helping with this issue.

I verified that in case of the crash thread->base.thread.state is 0xF1.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In the latest code base, that's not a valid state: only bits 0-5 are
used, giving a max value of 0x3f.

./kernel/include/kernel_structs.h:#define _THREAD_DUMMY (1 << 0)
./kernel/include/kernel_structs.h:#define _THREAD_PENDING (1 << 1)
./kernel/include/kernel_structs.h:#define _THREAD_PRESTART (1 << 2)
./kernel/include/kernel_structs.h:#define _THREAD_DEAD (1 << 3)
./kernel/include/kernel_structs.h:#define _THREAD_SUSPENDED (1 << 4)
./kernel/include/kernel_structs.h:#define _THREAD_POLLING (1 << 5)

This looks like corruption. Are you sure the stack of that thread has
not overflowed ?

It means, _THREAD_DUMMY bit is set indeed.

Thanks again,
Bella

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh@windriver.com]
Sent: Tuesday, February 07, 2017 17:40
To: Shtivelman, Bella <bella.shtivelman@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] CONFIG_SEMAPHORE_GROUPS

On Tue, Feb 07, 2017 at 11:42:22AM +0000, Shtivelman, Bella wrote:
Hi,
I have a question regarding the impact of CONFIG_SEMAPHORE_GROUPS flag.

In my sample application I experienced weird failures in k_sem_give
being called from udp receive callback. After debugging this issue I
found out that the failure occurred in sem_give_common function, and
more precisely, when entering this if condition:

If(handle_sem_group(sem, thread))

where handle_sem_group is defined as follows:

#ifdef CONFIG_SEMAPHORE_GROUPS
static int handle_sem_group(struct k_sem *sem, struct k_thread *thread)
{

}
#else
#define handle_sem_group(sem, thread) 0
#endif

Disassembly shows the following (faulting instruction address is 0x0040f38c:)

0040f36c: ands.w r5, r3, #1
0040f370: beq.n 0x40f42a <sem_give_common+226>
177 list = (sys_dlist_t *)dummy->desc.thread->base.swap_data;
0040f372: ldr r3, [r4, #48] ; 0x30
0040f374: ldr.w r8, [r3, #12]
132 return list->head == list;
0040f378: ldr.w r4, [r8]
145 return sys_dlist_is_empty(list) ? NULL : list->head;
0040f37c: cmp r8, r4
0040f37e: it eq
0040f380: moveq r4, #0
176 return (!node || node == list->tail) ? NULL : node->next;
0040f382: cbz r4, 0x40f390 <sem_give_common+72>
0040f384: ldr.w r3, [r8, #4]
0040f388: cmp r3, r4
0040f38a: beq.n 0x40f394 <sem_give_common+76>
0040f38c: ldr r5, [r4, #0]
0040f38e: b.n 0x40f396 <sem_give_common+78>
0040f390: mov r5, r4
0040f392: b.n 0x40f396 <sem_give_common+78>
0040f394: movs r5, #0
0040f396: ldr r3, [r4, #12]
0040f398: cmp r6, r3
0040f39a: beq.n 0x40f3c8 <sem_give_common+128>
0040f39c: ldr.w r3, [r4, #-8]
0040f3a0: adds r3, #2
0040f3a2: beq.n 0x40f382 <sem_give_common+58>
0040f3a4: sub.w r9, r4, #40 ; 0x28
0040f3a8: sub.w r0, r4, #24
0040f3ac: bl 0x40f2a0 <_abort_timeout>
0040f3b0: mov r0, r9
0040f3b2: bl 0x40f290 <sys_dlist_remove>

The default value of CONFIG_SEMAPHORE_GROUPS is “y”, and after setting
it to “n” in my prj.conf I stopped facing this issue.
OK, so it seems that, since you can disable the CONFIG_SEMAPHORE_GROUPS
feature, you are _not_ using said feature. In theory, this if statement
should always be hit in handle_sem_group():

if (!(thread->base.thread_state & _THREAD_DUMMY)) {
/*
* The awakened thread is a real thread and thus was not
* involved in a semaphore group operation.
*/
return 0;
}

and handle_sem_group() should never do anything else, unless the
thread_state of some thread got corrupted.

Can you verify that the thread->base.thread.state _THREAD_DUMMY bit is
actually set when you get that crash ?

Looking at it, I think I found a bug in handle_sem_group():

if (desc->sem != sem) {
sem_thread = CONTAINER_OF(desc, struct _sem_thread,
desc);
struct k_thread *dummy_thread =
(struct k_thread *)&sem_thread->dummy;

if (_is_thread_timeout_expired(dummy_thread)) {
+ sys_dlist_remove(node);
+ node = next;
continue;
}
_abort_thread_timeout(dummy_thread);
_unpend_thread(dummy_thread);

sys_dlist_remove(node);
}

If you _are_ using sem groups, I would suggest using the new k_poll()
API instead: semaphore groups are part of the legacy API, and the
implemenation is pretty bad w.r.t. interrupt locking duration.

Regards,
Ben


But I’m not sure it is a correct handling of the issue.

Are you familiar with this issue?
Am I missing anything here?
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
Benjamin Walsh, SMTS
WR VxWorks Virtualization Profile
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


1.7 is coming close..

Nashif, Anas
 

Hi,

Please note that we are approaching the merge window close for 1.7, all major features documented in JIRA stories need to already be in the review process and ready to be merged. Please submit all your changes and address comments in Gerrit to allow merge of pending requests ASAP.

 

Zephyr 1.7 rc1 will be created in the next 2 days which will limit merges to bug fixes, documentation and test cases. Any late features that target 1.7 will need to be approved by the Zephyr TSC.

 

The first release candidate of a release also means that development for 1.8 can start on master. A branch for 1.7 will be created and master will be open for none intrusive changes targeting 1.8. The soft development phase for 1.8 will happen on master until 1.7 is released, after that the merge window for 1.8 will be declared open and master will be ready for major and intrusive changes.

 

For more details on the development model, please see https://wiki.zephyrproject.org/view/Development_Model

 

 

Anas

 

 

 


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/11043 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/11029 : arch: Disable watchdog at SAM E70 SoC init
- https://gerrit.zephyrproject.org/r/11024 : qemu_cortex_m3: fixed network connectivity
- https://gerrit.zephyrproject.org/r/11018 : net/mqtt: Fix inline doc for MQTT
- https://gerrit.zephyrproject.org/r/11025 : tests: add zephyr counter and timer api test
- https://gerrit.zephyrproject.org/r/11017 : misc: fix variable type mismatchs
- https://gerrit.zephyrproject.org/r/11003 : quark_se: Save/restore debug registers.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/7738 : RFC: Add support for Device Tree
- https://gerrit.zephyrproject.org/r/10859 : v2m_beetle: Add base DTS support
- https://gerrit.zephyrproject.org/r/10998 : net: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/11000 : drivers: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/10999 : Bluetooth: Convert FOR_EACH macro instances to use CONTAINER
- https://gerrit.zephyrproject.org/r/10853 : drivers: Add Atmel SAM RTC driver
- https://gerrit.zephyrproject.org/r/10473 : drivers: stm32: clean up after stm23cube based clock control
- https://gerrit.zephyrproject.org/r/10423 : board: stm32373c_eval: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10472 : clock control: clean up after stm32cube LL driver
- https://gerrit.zephyrproject.org/r/10424 : boards: nucleo_l476rg: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10471 : soc: stm32f3x: clean up after Cube LL clock control
- https://gerrit.zephyrproject.org/r/10648 : clock_control: stm32: code optimization
- https://gerrit.zephyrproject.org/r/10470 : soc: stm32l4x: clean up after Cube LL clock control
- https://gerrit.zephyrproject.org/r/10420 : soc: stm32l4xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10421 : soc: stm32f3xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10422 : board: nucleo_f334r8: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10801 : board: add nucleo_l476rg documentation
- https://gerrit.zephyrproject.org/r/10927 : tests/slist: Exercise CONTAINER macros
- https://gerrit.zephyrproject.org/r/10997 : kernel: Use SYS_DLIST_FOR_EACH_CONTAINER
- https://gerrit.zephyrproject.org/r/10993 : tests/common: Add tests for sys_dlist_*
- https://gerrit.zephyrproject.org/r/10992 : dlist: Introduce CONTAINER macros
- https://gerrit.zephyrproject.org/r/10944 : drivers: Remove unnecessary CONFIG_SYS_POWER_DEEP_SLEEP
- https://gerrit.zephyrproject.org/r/10952 : drivers/net/ieee802154: nRF5 802.15.4 radio driver
- https://gerrit.zephyrproject.org/r/10953 : samples/net: ieee802154: Add configuration for nrf5
- https://gerrit.zephyrproject.org/r/9820 : tests: add zephyr adc driver api test case
- https://gerrit.zephyrproject.org/r/10862 : ARC: fix I2C SPI and GPIO default name issue for ARC
- https://gerrit.zephyrproject.org/r/10793 : tests/gpio: fix test GPIO_INT_EDGE bug
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: enable PWM case to work on D2000 board
- https://gerrit.zephyrproject.org/r/10140 : tests/gpio: enable gpio cases to run on more platforms
- https://gerrit.zephyrproject.org/r/10784 : pinmux: fix default pinmux driver for quark_se_ss
- https://gerrit.zephyrproject.org/r/10376 : WIP stack sentinel x86
- https://gerrit.zephyrproject.org/r/10690 : tests: Introduced new config option to add extra stack size for tests.
- https://gerrit.zephyrproject.org/r/9890 : sys_bitfield*(): use 'void *' instead of memaddr_t
- https://gerrit.zephyrproject.org/r/10991 : eth/mcux: Add temporary workaround to unbreak IPv6 ND features.
- https://gerrit.zephyrproject.org/r/10412 : clock control:stm32: provide STM32Cube LL based driver
- https://gerrit.zephyrproject.org/r/10419 : flash: update stm32 flash_f3x to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10418 : pwm: update stm32 pwm to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10950 : ext: Import Nordic 802.15.4 radio driver
- https://gerrit.zephyrproject.org/r/10954 : samples/net/ieee802154: Update example with nrf5 802.15.4
- https://gerrit.zephyrproject.org/r/10951 : ext: Integrate Nordic's 802.15.4 radio driver into Zephyr
- https://gerrit.zephyrproject.org/r/10685 : drivers: mcr20a: refactor transceiver interrupt processing
- https://gerrit.zephyrproject.org/r/10720 : flash/stm32: driver for STM32F4x series
- https://gerrit.zephyrproject.org/r/10417 : i2c: update stm32 i2c_lx to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10920 : kw41z: add base DTS support
- https://gerrit.zephyrproject.org/r/10416 : i2c: stm32: change deprecated constant
- https://gerrit.zephyrproject.org/r/10415 : uart: update stm32 uart to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10414 : pinmux: update stm32 pinmux to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10413 : gpio: update stm32 gpio to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10926 : slist: Introduce CONTAINER macros

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/11036 : Bluetooth: GATT: Fix not updating previous node
- https://gerrit.zephyrproject.org/r/11030 : samples/dhcpv4_client: Reduce default debug to dhcpv4
- https://gerrit.zephyrproject.org/r/11031 : samples/dhcpv4_client: Increase number of DATA buffers.
- https://gerrit.zephyrproject.org/r/11032 : samples/dhcpv4_client: Switch from private net_sprint_ipv4_addr to public net_addr_ntop
- https://gerrit.zephyrproject.org/r/11033 : net/dhcpv4: Add further diagnostics.
- https://gerrit.zephyrproject.org/r/11034 : net/dhcpv4: Use unique XID on each request.
- https://gerrit.zephyrproject.org/r/11035 : net/dhcpv4: Correct backoff and retransmit behaviour
- https://gerrit.zephyrproject.org/r/11037 : samples/mbedtls_dtls_client: Use k_uptime_get_32()
- https://gerrit.zephyrproject.org/r/11038 : samples/mbedtls_dtls_server: Use k_uptime_get_32()
- https://gerrit.zephyrproject.org/r/11039 : samples/mbedtls_dtls_client: Fix wild write in entropy_source
- https://gerrit.zephyrproject.org/r/11040 : net: samples: Unref net_buf using net_nbuf_unref
- https://gerrit.zephyrproject.org/r/11041 : net: tests: Unref net_buf using net_nbuf_unref
- https://gerrit.zephyrproject.org/r/11042 : net: samples: Unref the buf if app data length is zero
- https://gerrit.zephyrproject.org/r/11006 : net: offload_ip: Update net_context_accept_cb_t to net_tcp_accept_cb_t
- https://gerrit.zephyrproject.org/r/11021 : xtensa: fix build warning if no coprocessors present
- https://gerrit.zephyrproject.org/r/11023 : ext: qmsi: fix an incomplete type issue
- https://gerrit.zephyrproject.org/r/11020 : riscv32: timer: disable riscv_machine_timer driver by default for riscv32
- https://gerrit.zephyrproject.org/r/11019 : Xtensa port: Fixed scheduling bug caused to missing Endianess related macros.
- https://gerrit.zephyrproject.org/r/11016 : Xtensa port: Added support for sample_controller core and set is as default.
- https://gerrit.zephyrproject.org/r/11005 : legacy: work around XCC issue in MDEF threads
- https://gerrit.zephyrproject.org/r/11001 : Xtensa port: Fixed scheduling bug caused to missing Endianess related macros.
- https://gerrit.zephyrproject.org/r/10883 : boards: add panther board
- https://gerrit.zephyrproject.org/r/10896 : xtensa: cleanup fatal error handling
- https://gerrit.zephyrproject.org/r/10772 : Revert "Xtensa port: Changed default core to D_233L."
- https://gerrit.zephyrproject.org/r/10848 : tinycrypt: Fixed compilation error on Xtensa caused by bad definition of bool.
- https://gerrit.zephyrproject.org/r/10956 : build: Separate out prebuilt kernel logic from toplevel
- https://gerrit.zephyrproject.org/r/10905 : toolchain: gcc.h: add indirection to _GENERIC_SECTION() macro
- https://gerrit.zephyrproject.org/r/10906 : section_tags.h: cleanup
- https://gerrit.zephyrproject.org/r/10134 : drivers: QMSI PWM: simplify driver reentrancy code using IS_ENABLED macro
- https://gerrit.zephyrproject.org/r/10136 : drivers: QMSI RTC: simplify driver reentrancy code using IS_ENABLED
- https://gerrit.zephyrproject.org/r/10135 : drivers: QMSI SOC flash: simplify driver reentrancy code using IS_ENABLED
- https://gerrit.zephyrproject.org/r/10903 : sw_isr_table.h: clean up definition
- https://gerrit.zephyrproject.org/r/10723 : ext qmsi: Update to QMSI 1.4 RC2


Re: Problems managing NBUF DATA pool in the networking stack

Luiz Augusto von Dentz
 

Hi Marcus,

On Thu, Feb 9, 2017 at 1:17 PM, Marcus Shawcroft
<marcus.shawcroft@gmail.com> wrote:
On 8 February 2017 at 13:18, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:

While I agree we should prevent the remote to consume all the buffer
and possible starve the TX, this is probably due to echo_server design
that deep copies the buffers from RX to TX, in a normal application
Indeed the echo server could perhaps be optimized not to deep copy
thus removing the issue. The wider question here is whether or not we
want a design rule that effectively states that all applications
should consume and unref their rx buffers before attempting to
allocate tx buffers. This may be convenient for some applications,
but I'm not convinced that is always the case. Such a design rule
effectively states that an application that needs to retain or process
information from request to response must now have somewhere to store
all of that information between buffers and rules out any form of
incremental processing of an rx buffer interleaved with the
construction of the tx message.
If you read the entire email it would be clearer that I did not
suggest it was fine to rule out incremental processing, in fact I
suggested to add pools per net_context that way the stack itself will
not have to drop its own packets and stop working because some context
is taking all its buffers just to create clones.

the RX would be processed and unrefed causing the data buffers to
return to the pool immediately. Even if we split the RX in a separate
pool any context can just ref the buffer causing the RX to stave
Maybe I missed the point here, but dropped packets due to rx buffer
starvation is no different to network packet loss, while undesirable,
high levels in the stack are already design to cope appropriately.
Indeed it might be considered the same as packet loss, while it is
handled properly it also cause a drop in throughput, but I wasn't
arguing against dropping packets but the fact that sharing data
buffers with TX don't work for the reason that the application may
hold their own references.

--
Luiz Augusto von Dentz


Re: Did 802.11 protocol supported on current sdk?

Tomasz Bursztyka
 

Hi,

Zephyr used to have a port of µIP, the same ip stack as Contiki.

But not anymore: now it's a complete new native stack, made especially for Zephyr.

And indeed, we don't support 802.11.

Br,

Tomasz

hi all:

    i search the whol project for symbole "NET_L2_INIT" and found that we support the L2 inteface as below,  seems no 802.11 protocol support, is that right?

  Cscope tag: NET_L2_INIT
   #   行    文件名 / 上下文 / 行
   1     97  /DISK0/WorkSpace/iot/network-zephyr/zephyr/include/net/net_l2.h <<GLOBAL>>
             #define NET_L2_INIT(_name, _recv_fn, _send_fn, _reserve_fn, _enable_fn) \
   2    121  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/bluetooth.c <<GLOBAL>>
             NET_L2_INIT(BLUETOOTH_L2, net_bt_recv, net_bt_send, net_bt_reserve,
   3     39  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/dummy.c <<GLOBAL>>
             NET_L2_INIT(DUMMY_L2, dummy_recv, dummy_send, dummy_reserve, NULL);
   4    311  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/ethernet.c <<GLOBAL>>
             NET_L2_INIT(ETHERNET_L2, ethernet_recv, ethernet_send, ethernet_reserve, NULL);
   5    311  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/ieee802154/ieee802154.c <<GLOBAL>>
             NET_L2_INIT(IEEE802154_L2,

and i hear many of words that the zephyr ip-stack are totaly porting from the contiki project,  i got the contiki project but did not find any the  identities,  so may be what the said was the legacy network driver, now  the ip-stack of zephyr is developed from the beginning, is it ?


thanks for your kindly support.



 



_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Did 802.11 protocol supported on current sdk?

曹子龙
 

hi all:

    i search the whol project for symbole "NET_L2_INIT" and found that we support the L2 inteface as below,  seems no 802.11 protocol support, is that right?

  Cscope tag: NET_L2_INIT
   #   行    文件名 / 上下文 / 行
   1     97  /DISK0/WorkSpace/iot/network-zephyr/zephyr/include/net/net_l2.h <<GLOBAL>>
             #define NET_L2_INIT(_name, _recv_fn, _send_fn, _reserve_fn, _enable_fn) \
   2    121  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/bluetooth.c <<GLOBAL>>
             NET_L2_INIT(BLUETOOTH_L2, net_bt_recv, net_bt_send, net_bt_reserve,
   3     39  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/dummy.c <<GLOBAL>>
             NET_L2_INIT(DUMMY_L2, dummy_recv, dummy_send, dummy_reserve, NULL);
   4    311  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/ethernet.c <<GLOBAL>>
             NET_L2_INIT(ETHERNET_L2, ethernet_recv, ethernet_send, ethernet_reserve, NULL);
   5    311  /DISK0/WorkSpace/iot/network-zephyr/zephyr/subsys/net/ip/l2/ieee802154/ieee802154.c <<GLOBAL>>
             NET_L2_INIT(IEEE802154_L2,

and i hear many of words that the zephyr ip-stack are totaly porting from the contiki project,  i got the contiki project but did not find any the  identities,  so may be what the said was the legacy network driver, now  the ip-stack of zephyr is developed from the beginning, is it ?


thanks for your kindly support.



 


Re: Inconsistent and ever-changing device naming in Zephyr

Erwan Gouriou
 

Hi Paul, 


But the current question is whether consistency is desirable at all,
i.e. would maintainers of individual SoCs agree each making some
changes to their code/config, and Zephyr maintainers agree to
uphold it afterwards. Given that DT has yet some way to go widely in
Zephyr, discussion or at least consideration of this "consistent
naming" idea might start in parallel.


For STM32, my view is as follows:
I understand the concern and need for having naming consistency,
thought, I'm concerned about different instances numbering.
Some starts from 0, some starts from 1:
UART_1 in ref manual being referenced as UART_2  in Zephyr 
could be source of error.

At least keeping numbering (or "lettering" for A/B/C) consistent from
board/manual to API is required from my point of view.
Then I'm ok if there is a naming convention "UART_x" accross vendors.

Erwan


Re: Inconsistent and ever-changing device naming in Zephyr

Daniel Thompson <daniel.thompson@...>
 

On 08/02/17 20:39, Paul Sokolovsky wrote:
Hello Daniel,

On Mon, 6 Feb 2017 16:59:26 +0000
Daniel Thompson <daniel.thompson@linaro.org> wrote:

[]

a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.

b) Send a strong message to application developers that they should
not rely on any patterns of Zephyr device naming, and even on the
naming at all, and instead should treat it as a configuration
parameter, which ultimately should be set by a user (and thus apps
should make such configuration explicit and easy for users).
Or c) inherit the device names from device tree?

I don't actually remember that much about the proposed DT tooling but
it should certainly be included in this discussion.

It might be made slightly more complex by the presence of aliased
names in DT (often used to bridge SoC datasheet namings into board
based names). I guess Zephyr might prefer to use the most-derived
alias rather then the SoC datasheet name?
I'm not familiar enough with devicetree details to imagine how exactly
that would be done, but Andy's response confirms it's possible to do
something along those ways. But as far as I can see, that still would
depend on establishing common conventions for naming. Perhaps, doing it
via DT would allow to achieve consistency easier, and verify/maintain
it.

But the current question is whether consistency is desirable at all,
i.e. would maintainers of individual SoCs agree each making some
changes to their code/config, and Zephyr maintainers agree to
uphold it afterwards. Given that DT has yet some way to go widely in
Zephyr, discussion or at least consideration of this "consistent
naming" idea might start in parallel.
Personally I'm not a fan of gratuitously different naming (for example different driver writers arbitrarily selecting ALLCAPS and lowercase). However I *am* a fan of selecting labels from "facts" about the board (silk screening, datasheet port/connector names, etc).

As a trivial example I'd really dislike a system where "for consistency" we force BSPs to call something "UART-0" when the silkscreen (or front-panel) says "DB9-1".

I guess that is an argument *against* board-to-board consistency!


Daniel.


Re: Problems managing NBUF DATA pool in the networking stack

Marcus Shawcroft <marcus.shawcroft@...>
 

On 8 February 2017 at 13:18, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:

While I agree we should prevent the remote to consume all the buffer
and possible starve the TX, this is probably due to echo_server design
that deep copies the buffers from RX to TX, in a normal application
Indeed the echo server could perhaps be optimized not to deep copy
thus removing the issue. The wider question here is whether or not we
want a design rule that effectively states that all applications
should consume and unref their rx buffers before attempting to
allocate tx buffers. This may be convenient for some applications,
but I'm not convinced that is always the case. Such a design rule
effectively states that an application that needs to retain or process
information from request to response must now have somewhere to store
all of that information between buffers and rules out any form of
incremental processing of an rx buffer interleaved with the
construction of the tx message.

the RX would be processed and unrefed causing the data buffers to
return to the pool immediately. Even if we split the RX in a separate
pool any context can just ref the buffer causing the RX to stave
Maybe I missed the point here, but dropped packets due to rx buffer
starvation is no different to network packet loss, while undesirable,
high levels in the stack are already design to cope appropriately.

Cheers
/Marcus


Re: Inconsistent and ever-changing device naming in Zephyr

Jon Medhurst (Tixy) <tixy@...>
 

On Wed, 2017-02-08 at 11:31 -0600, Andy Gross wrote:
On 6 February 2017 at 10:59, Daniel Thompson <daniel.thompson@linaro.org> wrote:
On 06/02/17 13:34, Paul Sokolovsky wrote:

Hello,

Writing on this was in my TODO at least since November, but I expected
this to be a controversial topic, so kind of skipped it. Controversial,
as in: different parties finding to be "obvious" quite different, if
not opposite solutions to the problem. Well, the breakage continues,
so this should be raised.

(Recent) facts:

1. Update to Kinetis (BOARD=frdm_k64f) port broke GPIO support in a
(complex) Zephyr-based application, Zephyr.js:
https://github.com/01org/zephyr.js/issues/665

2. A day or two, Arduino 101 I2C support in Zephyr.js was updated,
apparently because Zephyr upgrade broke it. Today it became known that
the fix for Arduino 101 broke FRDM-K64F.
https://github.com/01org/zephyr.js/issues/676

Investigating the issues, the causes of them are:

1. frdm_k64f GPIO port naming changed from "GPIO_0" to (!!) "gpio_porta".

2. Name of (one of) I2C device for arduino_101 changed from "I2C_0" to
"I2C_SS_0".


This is not the first time when device names change in Zephyr (see
reference above to November 2016), it's the first time (at least for
last half-year), when the naming changes in relatively well developed
ports, which leads to cascade of breakage in the one. And one case, it
can be seen how inconsistent naming (and changes of it) can be.

The question what to do about this. Possible high-level approaches can
be:

a) Establish (well, reconfirm/clarify) and uphold consistent naming
conventions across ports, architectures, and boards.

b) Send a strong message to application developers that they should
not rely on any patterns of Zephyr device naming, and even on the naming
at all, and instead should treat it as a configuration parameter, which
ultimately should be set by a user (and thus apps should make such
configuration explicit and easy for users).

Or c) inherit the device names from device tree?

I don't actually remember that much about the proposed DT tooling but it
should certainly be included in this discussion.

It might be made slightly more complex by the presence of aliased names in
DT (often used to bridge SoC datasheet namings into board based names). I
guess Zephyr might prefer to use the most-derived alias rather then the SoC
datasheet name?
The alias {} node can indeed be used for this. But unless we define a
specific format, parsing this might be interesting. However we have
some solutions for that if we want to go that route. A board specific
yaml file could specify the alias format. It's need to be something
that can co-exist with existing DT files that might be imported from
Linux.

Maybe something along the lines of:
zephyr,uart-0 = &node@xxxxxxxx;
zephyr,uart-1 = &node@xxxxxxxx;
and so on and so forth. These can ghost the aliases already present
if they have something like uart0 = &node@xxxxxxxx; The zephyr,XXXXX
need to be standardized for each device type. We strip the zephyr
part and the generated string name becomes UART-0 or UART0 or whatever
standard we want.

I think this solves both the unified naming and the assigning of the
names to specific nodes.
So, if I get this right, this is device-tree aliases being used to
specify the driver name in Zephy? I.e. the drv_name parameter passed to
DEVICE_INIT and the string passed to device_get_binding to get a pointer
to that driver instance.

I thought aliases we're going to be used as a method to replace the
'fixup' files in the current DT RFC patches by matching device-tree node
names (<compataible-string>_<address>_<property>) to driver defines
(<foo>_<port_N>_<bar> or similar)

Is the latter wrong? Or is it a different alias entry in DT used for
that?

--
Tixy


Re: Did the zephyr project support EHCI/OHCI usb controller currently?

Joseph, Jithu
 

We presently have only USB device (and not USB host)  support in Zephyr, that’s why you are unable to find host controller drivers under Zephyr/drivers/usb

 

> if not supported hci really, why?

USB device side  was the logical place to start for resource constrained devices targeted by Zephyr.

(Going forward It is possible that USB Host / OTG functionality can get added based on community  interest / demand / contributions.)

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of ???
Sent: Wednesday, February 8, 2017 7:25 PM
To: devel@...
Subject: [Zephyr-devel] Did the zephyr project support EHCI/OHCI usb controller currently?

 

Hi:

    i am doing the job of porting the zephy kernel to arm9  based socs, which embeded XHCI usb controller,    i reviewed the device drivers in ./zephyr/driver/usb  and did not found the EHCI moudle drver, even the "*HCI" symbol not found. so i want to know if i miss something?  if not supported hci really, why?

 

thanks for your kindly support.

 


 


Re: CONFIG_SEMAPHORE_GROUPS

Shtivelman, Bella <bella.shtivelman@...>
 

Hi Benjamin,
Thank you for helping with this issue.

I verified that in case of the crash thread->base.thread.state is 0xF1.
It means, _THREAD_DUMMY bit is set indeed.

Thanks again,
Bella

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh@windriver.com]
Sent: Tuesday, February 07, 2017 17:40
To: Shtivelman, Bella <bella.shtivelman@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] CONFIG_SEMAPHORE_GROUPS

On Tue, Feb 07, 2017 at 11:42:22AM +0000, Shtivelman, Bella wrote:
Hi,
I have a question regarding the impact of CONFIG_SEMAPHORE_GROUPS flag.

In my sample application I experienced weird failures in k_sem_give
being called from udp receive callback. After debugging this issue I
found out that the failure occurred in sem_give_common function, and
more precisely, when entering this if condition:

If(handle_sem_group(sem, thread))

where handle_sem_group is defined as follows:

#ifdef CONFIG_SEMAPHORE_GROUPS
static int handle_sem_group(struct k_sem *sem, struct k_thread *thread)
{

}
#else
#define handle_sem_group(sem, thread) 0
#endif

Disassembly shows the following (faulting instruction address is 0x0040f38c:)

0040f36c: ands.w r5, r3, #1
0040f370: beq.n 0x40f42a <sem_give_common+226>
177 list = (sys_dlist_t *)dummy->desc.thread->base.swap_data;
0040f372: ldr r3, [r4, #48] ; 0x30
0040f374: ldr.w r8, [r3, #12]
132 return list->head == list;
0040f378: ldr.w r4, [r8]
145 return sys_dlist_is_empty(list) ? NULL : list->head;
0040f37c: cmp r8, r4
0040f37e: it eq
0040f380: moveq r4, #0
176 return (!node || node == list->tail) ? NULL : node->next;
0040f382: cbz r4, 0x40f390 <sem_give_common+72>
0040f384: ldr.w r3, [r8, #4]
0040f388: cmp r3, r4
0040f38a: beq.n 0x40f394 <sem_give_common+76>
0040f38c: ldr r5, [r4, #0]
0040f38e: b.n 0x40f396 <sem_give_common+78>
0040f390: mov r5, r4
0040f392: b.n 0x40f396 <sem_give_common+78>
0040f394: movs r5, #0
0040f396: ldr r3, [r4, #12]
0040f398: cmp r6, r3
0040f39a: beq.n 0x40f3c8 <sem_give_common+128>
0040f39c: ldr.w r3, [r4, #-8]
0040f3a0: adds r3, #2
0040f3a2: beq.n 0x40f382 <sem_give_common+58>
0040f3a4: sub.w r9, r4, #40 ; 0x28
0040f3a8: sub.w r0, r4, #24
0040f3ac: bl 0x40f2a0 <_abort_timeout>
0040f3b0: mov r0, r9
0040f3b2: bl 0x40f290 <sys_dlist_remove>

The default value of CONFIG_SEMAPHORE_GROUPS is “y”, and after setting
it to “n” in my prj.conf I stopped facing this issue.
OK, so it seems that, since you can disable the CONFIG_SEMAPHORE_GROUPS
feature, you are _not_ using said feature. In theory, this if statement
should always be hit in handle_sem_group():

if (!(thread->base.thread_state & _THREAD_DUMMY)) {
/*
* The awakened thread is a real thread and thus was not
* involved in a semaphore group operation.
*/
return 0;
}

and handle_sem_group() should never do anything else, unless the
thread_state of some thread got corrupted.

Can you verify that the thread->base.thread.state _THREAD_DUMMY bit is
actually set when you get that crash ?

Looking at it, I think I found a bug in handle_sem_group():

if (desc->sem != sem) {
sem_thread = CONTAINER_OF(desc, struct _sem_thread,
desc);
struct k_thread *dummy_thread =
(struct k_thread *)&sem_thread->dummy;

if (_is_thread_timeout_expired(dummy_thread)) {
+ sys_dlist_remove(node);
+ node = next;
continue;
}
_abort_thread_timeout(dummy_thread);
_unpend_thread(dummy_thread);

sys_dlist_remove(node);
}

If you _are_ using sem groups, I would suggest using the new k_poll()
API instead: semaphore groups are part of the legacy API, and the
implemenation is pretty bad w.r.t. interrupt locking duration.

Regards,
Ben


But I’m not sure it is a correct handling of the issue.

Are you familiar with this issue?
Am I missing anything here?
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: dhcp integration into the platform

Shtivelman, Bella <bella.shtivelman@...>
 

Hi,

In the existing DHCP design it’s not enough for application just subscribe to NET_EVENT_IF_UP event.

For our client application we observed situations when the link was up, but IPV4 address still hasn’t been assigned yet.

The issue was solved by subscribing to NET_EVENT_IPV4_ADDR_ADD event.

So maybe in the new design it should be taken into account as well.

 

Thanks,

Bella

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Anas Nashif
Sent: Thursday, February 09, 2017 01:56
To: Marcus Shawcroft <marcus.shawcroft@...>
Cc: Rissanen, Jukka <jukka.rissanen@...>; Bursztyka, Tomasz <tomasz.bursztyka@...>; devel@...
Subject: Re: [Zephyr-devel] dhcp integration into the platform

 

Hi

 

On Thu, Feb 9, 2017 at 4:53 AM, Marcus Shawcroft <marcus.shawcroft@...> wrote:

Hi,

This evening I took a look at how we might better integrate dhcpv4
into the platform.

In the current tree, in order to use dhcp the application is expected
to start the dhcp client explicitly.  There is no synchronization
between network link up / link down events and the dhcp state machine.

The dhcp state machine will start issuing discover messages
irrespective of the link status, once the link comes up, dhcp will
typically run through request/ack and install an IP number and GW etc.
Should the link drop and subsequently up again the dhcp state machine
remains oblivious.

Better integration of dhcp into the stack looks reasonably straight forward.

I propose the following:

- dhcp_start() is modified to initialize the dhcp context, but remain
in the INIT state.
- net_if is modified to generate network management link up / down events
- dhcpv4 is modified to capture link up and link down events from net mgmt
- dhcpv4 enters discover on link up
- dhcpv4 performs unset_dhcpv4_on_iface for link down
- unset_dhcpv4_on_iface needs to net_if_ipv4_addr_rm (it should
probably do that anyway)
- dhcp_start is renamed and hooked in by SYS_INIT ?
- A new empty dhcp_start is defined and marked deprecated (to be nice
to apps that might currently call it).
- The current public include/dhcp.h exposed interface is removed.

 

What we see here are the first signs of a connection manager :)

 

We do need DHCP to act as a service, when writing an application that relies on DHCP it makes sense to have the initialisation and setup of the networking device consistently with having to reimplement the code over and over again in every application.

 

I can also see the DNS service being setup if we get a DNS server address via DHCP and set the context of the DNS client to allow resolution queries without having to do that by foot.

 

+1 for the approach described above.

 

 


There are a few details Ive not thought through properly yet, notably:

- The net_if layer already has link_up and link_down events.  These
however are defined to fire when a net_if is enabled or disabled, not
when its link goes up or down, hence either these events need to be
redefined or we introduce two new events to represent the link up and
down.

- I'm not sure what the appropriate way of managing the removal of a
public .h file should be.

 

 

Well, this API is not released yet, so I think it should be easy to remove, but we are running out of time for 1.7...

 

 

Anas

 

 


- There are several way of wiring up the network management link up /
down notifiers:
1) Drivers do it directly.
2) Drivers call the net_if layer which in turn issues the network
management events.

Before I take this any further I'd appreciate feed back on sanity of
the approach and indeed whether such patches would be welcome.

Cheers
/Marcus
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: dhcp integration into the platform

Ravi kumar Veeramally
 

Hi Marcus,

One more thing, we should avoid sending dhcpv4 discover messages
on unsupported interfaces. E.g. If we have 15.4 and Ethernet, both
IPv6 and IPv4 are enabled. We should not start DHCPv4 on 15.4 or
any unsupported interface. (we can not enable Kconfig options
per interface).

- Ravi.

On 02/09/2017 01:23 AM, Marcus Shawcroft wrote:
Hi,

This evening I took a look at how we might better integrate dhcpv4
into the platform.

In the current tree, in order to use dhcp the application is expected
to start the dhcp client explicitly. There is no synchronization
between network link up / link down events and the dhcp state machine.

The dhcp state machine will start issuing discover messages
irrespective of the link status, once the link comes up, dhcp will
typically run through request/ack and install an IP number and GW etc.
Should the link drop and subsequently up again the dhcp state machine
remains oblivious.

Better integration of dhcp into the stack looks reasonably straight forward.

I propose the following:

- dhcp_start() is modified to initialize the dhcp context, but remain
in the INIT state.
- net_if is modified to generate network management link up / down events
- dhcpv4 is modified to capture link up and link down events from net mgmt
- dhcpv4 enters discover on link up
- dhcpv4 performs unset_dhcpv4_on_iface for link down
- unset_dhcpv4_on_iface needs to net_if_ipv4_addr_rm (it should
probably do that anyway)
- dhcp_start is renamed and hooked in by SYS_INIT ?
- A new empty dhcp_start is defined and marked deprecated (to be nice
to apps that might currently call it).
- The current public include/dhcp.h exposed interface is removed.

There are a few details Ive not thought through properly yet, notably:

- The net_if layer already has link_up and link_down events. These
however are defined to fire when a net_if is enabled or disabled, not
when its link goes up or down, hence either these events need to be
redefined or we introduce two new events to represent the link up and
down.

- I'm not sure what the appropriate way of managing the removal of a
public .h file should be.

- There are several way of wiring up the network management link up /
down notifiers:
1) Drivers do it directly.
2) Drivers call the net_if layer which in turn issues the network
management events.

Before I take this any further I'd appreciate feed back on sanity of
the approach and indeed whether such patches would be welcome.

Cheers
/Marcus
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Did the zephyr project support EHCI/OHCI usb controller currently?

曹子龙
 

Hi:
    i am doing the job of porting the zephy kernel to arm9  based socs, which embeded XHCI usb controller,    i reviewed the device drivers in ./zephyr/driver/usb  and did not found the EHCI moudle drver, even the "*HCI" symbol not found. so i want to know if i miss something?  if not supported hci really, why?

thanks for your kindly support.



 


Re: what is the code in ./zephyr/tests and what is the difference of it between with ./zephyr/samples/ ?

Anas Nashif
 

Hi,
Tests  has many tests that can be run in Qemu or can be used to test additional functionality on real hardware, they do not server anything beside the purpose of testing functionality. Samples on the other hand are a bit more useful and show functionality and features of the OS.

There is a grey area where some samples are being used for basic testing and day to day development, for example the echo server/client combo under networking and probably some other samples that qualify more as tests. But in general the rule is, a sample has to do something useful and does not qualify as a test for a certain feature, but a way to show it.


Anas

On Wed, Feb 8, 2017 at 5:14 PM, 曹子龙 <13824125580@...> wrote:
Dear all:

   i am running some test pattern about network on arduino_due board, i found that both the  ./zephyr/tests  and ./zephyr/ssamples/ are have some test pattren about network,  they seems related  just frome the name, but each one has is own main entry, so i want to know what is the difference between them and when should i use the test pattern in ./zephyr/test directory.

this is my first time to zephyr network, please bear with me my mistake, thank you very much for your kindly support.



 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: what is the code in ./zephyr/tests and what is the difference of it between with ./zephyr/samples/ ?

Tidy(ChunHua) Jiang <tidyjiang@...>
 

Hi Zilong,

Sample code are a good reference to get started with network application development.
Test applications are used to verify the functionality of the IP stack, but are not the best
source for sample code(see samples/net instead).

More detail, please refer to https://www.zephyrproject.org/doc/subsystems/networking/overview.html

Best Regards,
At 2017-02-08 19:44:10, "曹子龙" <13824125580@...> wrote:
Dear all:

   i am running some test pattern about network on arduino_due board, i found that both the  ./zephyr/tests  and ./zephyr/ssamples/ are have some test pattren about network,  they seems related  just frome the name, but each one has is own main entry, so i want to know what is the difference between them and when should i use the test pattern in ./zephyr/test directory.

this is my first time to zephyr network, please bear with me my mistake, thank you very much for your kindly support.



 



5441 - 5460 of 7903