Date   

Re: fail to install python dependencies

KAY LI NG <kayli0109@...>
 

Hi Carles,

I tried google method as well. Including update the setup tools, change python version.
But it doesnt work.

Regards,
Kay Li

On Tue, 28 May 2019 at 21:26, Cufi, Carles <Carles.Cufi@...> wrote:

Googling a bit this shows that it might be related to an out of date setuptools.

Try running:

pip install --upgrade setuptools

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of via Lists.Zephyrproject.Org
Sent: 28 May 2019 09:00
To: users@...
Cc: users@...
Subject: [Zephyr-users] fail to install python dependencies

 

Hi,

 

I tried this, but the following error came out. What should I do?

$ pip3 install --user -r zephyr/scripts/requirements.txt

Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-hvx0atyk/pyocd/
Regards, Kay Li


Re: fail to install python dependencies

Carles Cufi
 

Googling a bit this shows that it might be related to an out of date setuptools.

Try running:

pip install --upgrade setuptools

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of via Lists.Zephyrproject.Org
Sent: 28 May 2019 09:00
To: users@...
Cc: users@...
Subject: [Zephyr-users] fail to install python dependencies

 

Hi,

 

I tried this, but the following error came out. What should I do?

$ pip3 install --user -r zephyr/scripts/requirements.txt

Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-hvx0atyk/pyocd/
Regards, Kay Li


fail to install python dependencies

KAY LI NG <kayli0109@...>
 

Hi,

I tried this, but the following error came out. What should I do?
$ pip3 install --user -r zephyr/scripts/requirements.txt

Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-hvx0atyk/pyocd/
Regards, Kay Li


API meeting and agenda

Carles Cufi
 

Hi all,

As you know, the Zephyr API meeting takes place on Tuesdays 9AM-10AM (PDT) (18h-19h (CEST)).

Until now the way to include an item (issue or Pull Request) added to the meeting agenda was to add the API label to it.
In order to simplify the management of issues, we now ask everybody to instead mark the item as belonging to the API review/cleanup/rework GitHub Project (use the Projects selector in the issue or Pull Request):
https://github.com/zephyrproject-rtos/zephyr/projects/18

During the API meeting we will go through the Triage column in that project.

Additional information about the meeting can be found here:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles


Re: Zephyr compatible motes for 802.15.4

Nikos Karamolegkos
 

On Tue, May 28, 2019 at 02:44 AM, Paul Sokolovsky wrote:
frdm_kw41z
The only bad thing is that this module supports only the FSK PHY.


Re: Zephyr compatible motes for 802.15.4

Paul Sokolovsky
 

On Tue, 28 May 2019 01:48:33 -0700
"Nikos Karamolegkos" <nkaram@...> wrote:

Thank you all. Paul can I use these modules with the zephyr's 6lowpan
stack? Theoretically, I believe yes
That's what I did, yes - ping6'ed from Linux host to frdm_kw41z over
6lowpan/15.4. More thorough testing is still in my backlog.

--
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: Zephyr compatible motes for 802.15.4

Nikos Karamolegkos
 

Thank you all. Paul can I use these modules with the zephyr's 6lowpan stack? Theoretically, I believe yes


Re: Zephyr compatible motes for 802.15.4

Paul Sokolovsky
 

Hello,

On Mon, 27 May 2019 06:43:44 -0700
"Nikos Karamolegkos" <nkaram@...> wrote:

What about FRDM-KW41Z? As I can see this low cost development
platform supports IEEE 802.15.4 and it's supported by the zephyr
RTOS.
https://docs.zephyrproject.org/1.11.0/boards/arm/frdm_kw41z/doc/frdm_kw41z.html
Yes, FRDM-KW41Z supports 802.15.4 in Zephyr, I issued pings over 15.4
connection using it.

Note that level of support for different features (especially advanced,
like 15.4) for different boards (and lack/presence of bugs) may vary.

[]

--
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: Zephyr compatible motes for 802.15.4

Andrei
 

Hi,

On Mon, May 27, 2019 at 06:43:44AM -0700, Nikos Karamolegkos wrote:
What about FRDM-KW41Z? As I can see this low cost development platform
supports IEEE 802.15.4 and it's supported by the zephyr RTOS.
https://docs.zephyrproject.org/1.11.0/boards/arm/frdm_kw41z/doc/frdm_kw41z.html
I have not tried that board, I know that FRDM-K64F works (somehow) with
802.15.4 through FRDM-CR20A shield (there is overlay for that
configuration overlay-frdm_k64f_mcr20a.conf).

I would personally recommend to use nrf based boards like reel_board,
etc.

Best regards
Andrei Emeltchenko


Re: west command not found

Kinder, David B <david.b.kinder@...>
 

When you install with “pip3 install —user” on Linux, you also need to add ~/.local/bin to the front of your PATH (as documented in https://docs.zephyrproject.org/latest/getting_started/index.html#gs-python-deps)

-- david kinder

On May 27, 2019, at 6:32 PM, KAY LI NG <kayli0109@...> wrote:

Hi,

I am facing a problem with the west installation. CAn figure out how to solve this.

$ pip3 install --user west
Collecting west
  Using cached https://files.pythonhosted.org/packages/e5/9f/7dcd8985532e9b42d76c0777bbfa411b58991f86e82e9d2a0c97948b26e1/west-0.5.8-py3-none-any.whl
Collecting configobj (from west)
Collecting PyYAML (from west)
Collecting colorama (from west)
  Using cached https://files.pythonhosted.org/packages/4f/a6/728666f39bfff1719fc94c481890b2106837da9318031f71a8424b662e12/colorama-0.4.1-py2.py3-none-any.whl
Collecting pykwalify (from west)
  Using cached https://files.pythonhosted.org/packages/36/9f/612de8ca540bd24d604f544248c4c46e9db76f6ea5eb75fb4244da6ebbf0/pykwalify-1.7.0-py2.py3-none-any.whl
Collecting six (from configobj->west)
  Using cached https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl
Collecting python-dateutil>=2.4.2 (from pykwalify->west)
  Using cached https://files.pythonhosted.org/packages/41/17/c62faccbfbd163c7f57f3844689e3a78bae1f403648a6afb1d0866d87fbb/python_dateutil-2.8.0-py2.py3-none-any.whl
Collecting docopt>=0.6.2 (from pykwalify->west)
Installing collected packages: six, configobj, PyYAML, colorama, python-dateutil, docopt, pykwalify, west
Successfully installed PyYAML-5.1 colorama-0.4.1 configobj-5.0.6 docopt-0.6.2 pykwalify-1.7.0 python-dateutil-2.8.0 six-1.12.0 west-0.5.8
You are using pip version 8.1.1, however version 19.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
$ west --version
No command 'west' found, did you mean:
 Command 'test' from package 'coreutils' (main)
west: command not found
Regards,
Kay Li


west command not found

KAY LI NG <kayli0109@...>
 

Hi,

I am facing a problem with the west installation. CAn figure out how to solve this.

$ pip3 install --user west
Collecting west
  Using cached https://files.pythonhosted.org/packages/e5/9f/7dcd8985532e9b42d76c0777bbfa411b58991f86e82e9d2a0c97948b26e1/west-0.5.8-py3-none-any.whl
Collecting configobj (from west)
Collecting PyYAML (from west)
Collecting colorama (from west)
  Using cached https://files.pythonhosted.org/packages/4f/a6/728666f39bfff1719fc94c481890b2106837da9318031f71a8424b662e12/colorama-0.4.1-py2.py3-none-any.whl
Collecting pykwalify (from west)
  Using cached https://files.pythonhosted.org/packages/36/9f/612de8ca540bd24d604f544248c4c46e9db76f6ea5eb75fb4244da6ebbf0/pykwalify-1.7.0-py2.py3-none-any.whl
Collecting six (from configobj->west)
  Using cached https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl
Collecting python-dateutil>=2.4.2 (from pykwalify->west)
  Using cached https://files.pythonhosted.org/packages/41/17/c62faccbfbd163c7f57f3844689e3a78bae1f403648a6afb1d0866d87fbb/python_dateutil-2.8.0-py2.py3-none-any.whl
Collecting docopt>=0.6.2 (from pykwalify->west)
Installing collected packages: six, configobj, PyYAML, colorama, python-dateutil, docopt, pykwalify, west
Successfully installed PyYAML-5.1 colorama-0.4.1 configobj-5.0.6 docopt-0.6.2 pykwalify-1.7.0 python-dateutil-2.8.0 six-1.12.0 west-0.5.8
You are using pip version 8.1.1, however version 19.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
$ west --version
No command 'west' found, did you mean:
 Command 'test' from package 'coreutils' (main)
west: command not found
Regards,
Kay Li


Re: Zephyr compatible motes for 802.15.4

Nikos Karamolegkos
 

What about FRDM-KW41Z? As I can see this low cost development platform supports IEEE 802.15.4 and it's supported by the zephyr RTOS. https://docs.zephyrproject.org/1.11.0/boards/arm/frdm_kw41z/doc/frdm_kw41z.html


Re: Closing an accepting BSD socket from a different thread

Marc Herbert
 

On 23 May 2019, at 23:29, Stephan Gatzka <stephan.gatzka@...> wrote

variables. E.g., following is a well-know pattern:
=== main loop thread ===
while (!should_exit) {
...
poll(..., MAIN_LOOP_PERIOD);
...
}
close(...);
exit();
=== other threads ===
should_exit = true;
Yeah sure, put this is polling and a waste of resources.
Even if MAIN_LOOP_PERIOD is somewhat longer than the network protocol timeout(s) after which the socket should be closed anyway if the other end disappears?
Well, for a normal socket connection this might be probably o.k., but what about a server socket blocking on an accept() There is no such thing like a network timeout.
You could have a second poll() thread for all accepts with a much bigger ACCEPTS_LOOP_PERIOD; hours or even days.


Re: Closing an accepting BSD socket from a different thread

Paul Sokolovsky
 

On Fri, 24 May 2019 08:29:27 +0200
Stephan Gatzka <stephan.gatzka@...> wrote:

[]

I have to
build another mechanism for asynchronous I/O (for sockets, files,
timers, DNS resolution etc.).
To "get forward" with this, I submitted
https://github.com/zephyrproject-rtos/zephyr/issues/16376 .

Note that recently, I stopped submitting such things, because if you
look at the current list of known issues/missing features for sockets,
https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aopen+is%3Aissue+label%3A%22area%3A+Sockets%22 ,
you'll see that majority of them submitted by me. Recently, I actually
have my issues closed "by timeout", e.g.
https://github.com/zephyrproject-rtos/zephyr/issues/3547 .

So, instead I encourage community members facing issues/missing
features to submit requests and "lobby" for them (best way to
"lobby" is to of course prepare patches ;-) ).

[]

--
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: Closing an accepting BSD socket from a different thread

Paul Sokolovsky
 

On Fri, 24 May 2019 08:29:27 +0200
Stephan Gatzka <stephan.gatzka@...> wrote:

You're assuming Unix signals work...

https://lwn.net/Articles/414618/ Unfixable designs
Well, not really. I know the drawbacks of dealing with signals and in
Linux with epoll() and nearly everything being a file descriptor you
can put into epoll() there is no need to rely on signals.

But because poll() in zephyr only accepts socket fd's, I have to
build another mechanism for asynchronous I/O (for sockets, files,
timers, DNS resolution etc.).
Well, Linux and Zephyr aren't made of stone and dropped from the
sky ;-). Linux has it, because men-centuries of effort were put into it.
Zephyr doesn't have it *yet*, because there's no critical mass gathered
yet to implement those features. They are on roadmap (though I must
add, that first we need to resolve some paradigmatic matters of how
Zephyr vs POSIX are laid out).

[]

--
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: Closing an accepting BSD socket from a different thread

Paul Sokolovsky
 

Hello,

On Thu, 23 May 2019 09:10:38 +0200
Stephan Gatzka <stephan.gatzka@...> wrote:

Hello Paul!

Thanks for the answer.


Paradigmatically correct approach to this situation is:

1. Avoid sharing I/O resources (not just sockets) across different
threads.
2. If/when you can't avoid it, you need to synchronize access to
those resources from different threads using synchronization
primitives (mutexes, semaphores, etc.)
Sure, no doubt on that. The problem is, that I need a mechanism to
"unblock" the accept.
Yes, I could use non-blocking sockets with poll(),
For completeness of covering the topic, the sockets for poll() don't
have to be non-blocking.

but I also found
no easy to use mechanism to "unblock" poll().
You can pass a timeout after which poll() will "unblock".

I can't just send a
signal to that thread which called poll() like it would work in Linux.
Yes, Unix signals aren't implemented in Zephyr, and I personally don't
see them coming anytime soon due to reasons hinted by Marc in another
mail. (But then somehow who may contribute a high-quality
implementation of them may think otherwise).

Eventually, we'll need to catch and fix such cases. But the only
visible effect for well-behaving applications following the
guidelines above will be bloating code size in the Zephyr network
stack/socket implementation (so hopefully, we won't get bad
community stereotypes due to that). If you have a small
reproduction testcase for the issue, definitely please submit it at
https://github.com/zephyrproject-rtos/zephyr/issues
Will do.

My question is how I can safely "unblock" the thread waiting in the
zsock_accept()?
A way to not block forever in accept() call is to use timed poll()
on that socket. The thread issuing the poll() call would be the best
party to know when to close this socket (e.g., if there's no
activity during some period of time). Other threads could signal the
owner thread that they want something to be done to the socket via
flag variables. E.g., following is a well-know pattern:

=== main loop thread ===
while (!should_exit) {
...
poll(..., MAIN_LOOP_PERIOD);
...
}
close(...);
exit();

=== other threads ===
should_exit = true;
Yeah sure, put this is polling and a waste of resources.
No, it's not, in a sense of "busy-wait polling". It's a well-known low
duty cycle design pattern. If you poll() with timeout of 100ms and then
wake up for 1ms, you you're sleeping 99% of time, 1% duty cycle. But 1ms
is a huge period of time, it's 100,000 cycles of a 100MHz CPU. If you
optimize that to some 1000s of cycles on event-free wakeups, you can
achieve >0.1% duty cycle.

That I
really don't like, especially an small battery powered systems.
Sure, Zephyr needs a lot of optimizations of low-power usage, any
contribution is welcome.

No, the only possible solution I see is an additional socket
connection via localhost which "signals" poll() and afterwards I can
see what needs to be done (e.g. calling close()).
There was actually a patch submitted to Zephyr mainline which used that
technique. I dissuaded the author from following that approach, as I
consider it to be definitely too heavy-weight to seriously used in
mainline. But you definitely can use it at prototyping stage on your
app's side.

The reason for my question is that I need to implement an event loop
based system. I need events for sockets, timers, DNS.
The idea is to use e zephyr message queue with a thread reading from
the queue and calling the callback functions.
Right, so everyone wants Zephyr to be able to do advanced things, and
everyone agrees that it's too young yet and missing a lot of such
advanced functionality. My response tried to outline ways to get
started right away, albeit with some compromises here and there.
Hopefully, such a smooth start-up curve would motivate you to
contribute for resolution of the issues you write about.

An alternative is to wait until someone implements it all. As an
example, I want to implement epoll() for 2 years now. And I can't even
bootstrap a good discussion of it (at least shoot a brain-dump message
once: https://lists.zephyrproject.org/g/devel/topic/25004178) - we have
much more mundane things to do so far :-I.


Regards,
Stephan

--
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: Closing an accepting BSD socket from a different thread

Stephan Gatzka
 

You're assuming Unix signals work...
https://lwn.net/Articles/414618/ Unfixable designs
Well, not really. I know the drawbacks of dealing with signals and in Linux with epoll() and nearly everything being a file descriptor you can put into epoll() there is no need to rely on signals.

But because poll() in zephyr only accepts socket fd's, I have to build another mechanism for asynchronous I/O (for sockets, files, timers, DNS resolution etc.).

variables. E.g., following is a well-know pattern:
=== main loop thread ===
while (!should_exit) {
...
poll(..., MAIN_LOOP_PERIOD);
...
}
close(...);
exit();
=== other threads ===
should_exit = true;
Yeah sure, put this is polling and a waste of resources.
Even if MAIN_LOOP_PERIOD is somewhat longer than the network protocol timeout(s) after which the socket should be closed anyway if the other end disappears?
Well, for a normal socket connection this might be probably o.k., but what about a server socket blocking on an accept()? There is no such thing like a network timeout.


Re: Closing an accepting BSD socket from a different thread

Marc Herbert
 

On 23 May 2019, at 00:10, Stephan Gatzka <stephan.gatzka@...> wrote:

I can't just send a signal to that thread which called poll() like it would work in Linux.

You're assuming Unix signals work...

https://lwn.net/Articles/414618/ Unfixable designs



variables. E.g., following is a well-know pattern:
=== main loop thread ===
while (!should_exit) {
...
poll(..., MAIN_LOOP_PERIOD);
...
}
close(...);
exit();
=== other threads ===
should_exit = true;
Yeah sure, put this is polling and a waste of resources.
Even if MAIN_LOOP_PERIOD is somewhat longer than the network protocol timeout(s) after which the socket should be closed anyway if the other end disappears?


No, the only possible solution I see is an additional socket connection via localhost which "signals" poll() and afterwards I can see what needs to be done (e.g. calling close()).
Nice.


Re: gptp example project

Jukka Rissanen
 

Hi Kay Li,

the documentation seems to be wrong. The prj_base.conf was renamed to
prj.conf in commit 4e5300ba7f30a21862f68c2e4e2b651f1189d84a
So just do

cmake -GNinja -DBOARD=sam_e70_xplained ..

and the compilation should succeed.

I will send a patch that fixes the doc.

Cheers,
Jukka

On Thu, 2019-05-23 at 09:37 +0800, KAY LI NG wrote:
Hi,

I would like to ask if this gptp example project is possible to run
on windows?

I run this code.

# On Windows
cd %ZEPHYR_BASE%\samples\net\gptp
mkdir build & cd build
cmake -GNinja -DBOARD=sam_e70_xplained -DCONF_FILE=prj_base.conf ..

but this error occur.
Zephyr version: 1.14.0
-- Selected BOARD sam_e70_xplained
-- Found west: C:/Python37/Scripts/west.exe (found suitable version
"0.5.6", minimum required is "0.5.4")
-- Loading
C:/Users/kayling/zephyrproject/zephyr/boards/arm/sam_e70_xplained/sam
_e70_xplained.dts as base
-- Overlaying
C:/Users/kayling/zephyrproject/zephyr//dts/common/common.dts
CMake Error at
C:/Users/kayling/zephyrproject/zephyr/cmake/kconfig.cmake:132
(message):
File not found:

C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/prj_base.conf
Call Stack (most recent call first):

C:/Users/kayling/zephyrproject/zephyr/cmake/app/boilerplate.cmake:397
(include)
CMakeLists.txt:3 (include)


-- Configuring incomplete, errors occurred!
See also
"C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/build/CMakeFi
les/CMakeOutput.log".
See also
"C:/Users/kayling/zephyrproject/zephyr/samples/net/gptp/build/CMakeFi
les/CMakeError.log".
Whats the problem with this? i didnt modify anything from the example
code.

Regards,
Kay Li


Re: Closing an accepting BSD socket from a different thread

Stephan Gatzka
 

Hello Paul!

Thanks for the answer.

Paradigmatically correct approach to this situation is:
1. Avoid sharing I/O resources (not just sockets) across different
threads.
2. If/when you can't avoid it, you need to synchronize access to those
resources from different threads using synchronization primitives
(mutexes, semaphores, etc.)
Sure, no doubt on that. The problem is, that I need a mechanism to "unblock" the accept.
Yes, I could use non-blocking sockets with poll(), but I also found no easy to use mechanism to "unblock" poll(). I can't just send a signal to that thread which called poll() like it would work in Linux.



Eventually, we'll need to catch and fix such cases. But the only
visible effect for well-behaving applications following the guidelines
above will be bloating code size in the Zephyr network stack/socket
implementation (so hopefully, we won't get bad community stereotypes
due to that). If you have a small reproduction testcase for the issue,
definitely please submit it at
https://github.com/zephyrproject-rtos/zephyr/issues
Will do.

My question is how I can safely "unblock" the thread waiting in the
zsock_accept()?
A way to not block forever in accept() call is to use timed poll() on
that socket. The thread issuing the poll() call would be the best
party to know when to close this socket (e.g., if there's no
activity during some period of time). Other threads could signal the
owner thread that they want something to be done to the socket via flag
variables. E.g., following is a well-know pattern:
=== main loop thread ===
while (!should_exit) {
...
poll(..., MAIN_LOOP_PERIOD);
...
}
close(...);
exit();
=== other threads ===
should_exit = true;
Yeah sure, put this is polling and a waste of resources. That I really don't like, especially an small battery powered systems.

No, the only possible solution I see is an additional socket connection via localhost which "signals" poll() and afterwards I can see what needs to be done (e.g. calling close()).

The reason for my question is that I need to implement an event loop based system. I need events for sockets, timers, DNS.
The idea is to use e zephyr message queue with a thread reading from the queue and calling the callback functions.

Regards,
Stephan