Date   

Re: app runs using 1.13 but does not using 1.14

Jiří Kubias <jiri.kubias@...>
 

Hi,
you can get the error line by issuing command
/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-addr2line -e zephyr/zephyr.elf 0x200049a0  - this will show you where the error is. 

Best regard, 
Jiri 

pá 26. 4. 2019 v 15:33 odesílatel Abderrezak Mekkaoui <ab.mekka@...> napsal:

Hi All,

I have an app, based on the Bluetooth peripheral_esp sample, that builds
and runs as expected using zephyr 1.13.99. Using 1.14, it builds
correctly but crashes with the following message:

***** MPU FAULT *****
   Instruction Access Violation
***** Hardware exception *****
Current thread ID = 0x200022d0
Faulting instruction address = 0x200049a0
Fatal fault in essential thread! Spinning..

Before crashing it displays some expected sensor readings. It looks like
Bluetooth fails completely.
Any quick hints on what might be the cause?
Thanks

Abderrezak






--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


app runs using 1.13 but does not using 1.14

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,

I have an app, based on the Bluetooth peripheral_esp sample, that builds and runs as expected using zephyr 1.13.99. Using 1.14, it builds correctly but crashes with the following message:

***** MPU FAULT *****
  Instruction Access Violation
***** Hardware exception *****
Current thread ID = 0x200022d0
Faulting instruction address = 0x200049a0
Fatal fault in essential thread! Spinning..

Before crashing it displays some expected sensor readings. It looks like Bluetooth fails completely.
Any quick hints on what might be the cause?
Thanks

Abderrezak


Re: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Paul Sokolovsky
 

On Fri, 26 Apr 2019 09:25:17 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@oticon.com> wrote:

Thanks Paul,
Do you have some indication of when did this break?
Well, I was on vacation for two weeks before Apr 15. It definitely
worked before that. And I saw first problematic case last week, after
returning from vacation. No idea if that might be related to
https://github.com/zephyrproject-rtos/zephyr/commit/636a7af43e704e25af29b31d565399fc02fef408
- nothing wrong is seen here.

Actually, fishing for that link, I see that a whole bunch of changes
was made to the CODEOWNERS file just recently:
https://github.com/zephyrproject-rtos/zephyr/commits/master/CODEOWNERS

Just imagine that any of those changes could break syntax a bit or
propagation of changes to it could glitch on Github side, leading to
the effect we see. And that's not counting a possible coincidence of
Github tighting up the syntax for that file...


BR
Alberto

-----Original Message-----
From: tsc@lists.zephyrproject.org
[mailto:tsc@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky via
Lists.Zephyrproject.Org Sent: Friday 26 April 2019 11:10 To:
devel@lists.zephyrproject.org; tsc@lists.zephyrproject.org Cc:
tsc@lists.zephyrproject.org Subject: [Zephyr-tsc] Github CODEOWNERS
auto-assignment doesn't work as expected

Hello,

As was noticed in a few (multiple?) PRs, automatic reviewer
assignment based on the CODEOWNERS file no longer works as expected,
specifically fails to assign reviewers.

A recent example of this is
https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while
there's an entry:

/subsys/net/ip/ @jukkar @tbursztyka @pfalcon

in CODEOWNERS, I wasn't requested for review. Again, that's not the
only case.

For a clean-room test, I submitted
https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be
seen, the reviewer list is empty.

This is problematic, because there's a risk that under-reviewed
changes will get into the codebase, causing regressions. So, raising
to the awareness of the TSC.


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




--
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-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

alpi@...
 

Thanks Paul,
Do you have some indication of when did this break?

BR
Alberto

-----Original Message-----
From: tsc@lists.zephyrproject.org [mailto:tsc@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky via Lists.Zephyrproject.Org
Sent: Friday 26 April 2019 11:10
To: devel@lists.zephyrproject.org; tsc@lists.zephyrproject.org
Cc: tsc@lists.zephyrproject.org
Subject: [Zephyr-tsc] Github CODEOWNERS auto-assignment doesn't work as expected

Hello,

As was noticed in a few (multiple?) PRs, automatic reviewer assignment based on the CODEOWNERS file no longer works as expected, specifically fails to assign reviewers.

A recent example of this is
https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while there's an entry:

/subsys/net/ip/ @jukkar @tbursztyka @pfalcon

in CODEOWNERS, I wasn't requested for review. Again, that's not the only case.

For a clean-room test, I submitted
https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be seen, the reviewer list is empty.

This is problematic, because there's a risk that under-reviewed changes will get into the codebase, causing regressions. So, raising to the awareness of the TSC.


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


Github CODEOWNERS auto-assignment doesn't work as expected

Paul Sokolovsky
 

Hello,

As was noticed in a few (multiple?) PRs, automatic reviewer assignment
based on the CODEOWNERS file no longer works as expected, specifically
fails to assign reviewers.

A recent example of this is
https://github.com/zephyrproject-rtos/zephyr/pull/15670 - while there's
an entry:

/subsys/net/ip/ @jukkar @tbursztyka @pfalcon

in CODEOWNERS, I wasn't requested for review. Again, that's not the
only case.

For a clean-room test, I submitted
https://github.com/zephyrproject-rtos/zephyr/pull/15683 and as can be
seen, the reviewer list is empty.

This is problematic, because there's a risk that under-reviewed changes
will get into the codebase, causing regressions. So, raising to the
awareness of the TSC.


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


#bluetoothmesh Using the Period Publish in Mesh #bluetoothmesh

paul.leguennec@...
 

Hi,

How could I use periodic publishing in Mesh ? I have looked through the Mesh Spec (especially section 3.7.6.1), and I tried to understand in include files how to use it but I haven't understood where I should be using it (in the cfg_srv implementation ?/ in the cfg_cli implementation ?).

For now I tried using my vendor model to send a get message when I push a button but it din't work and I want to see if periodic publishing would work better.

Regards,
Paul


Re: Support for Open Supervised Device Protocol (OSDP) in Zephyr

Siddharth Chandrasekaran
 

Hi Thea,

Thanks for helping me out; have you had a chance to look into this?

Sid.

---- On Sun, 14 Apr 2019 01:24:31 +0530 Thea Aldrich <aldrich.thea@...> wrote ----

Hi Sid,
Thanks so much for reaching out.  Let me do some asking around as to which working group within Zephyr Project can best look into and,  if things align, help with coordination. I'll be back with more specific information on Monday. Thanks so much for your patience!

Best, 
Thea


On Sat, Apr 13, 2019, 1:54 PM Siddharth Chandrasekaran <siddharth@...> wrote:

Hi,

Can anyone comment on this? It'd be helpful to know such information earlier on.

Sid.

 ---- On Sun, 07 Apr 2019 00:39:04 +0530 Siddharth Chandrasekaran <siddharth@...> wrote ----
 > Hello,
 >
 > I'm working on an project that involves Open Supervised Device Protocol (OSDP) [1], an access control communication protocol used in the security industry. I'm working on this as an application at this point but I think this protocol may be useful for others too. So I'm looking at options for upstreaming it.
 >
 > I would like to know if this is something that the upstream is interested at this point. If so, some pointers on where to add such protocol implementations and other references would be of help.
 >
 > Thanks,
 > Sid.
 >
 >
 >







Re: Zephyr 1.14.0 Released (corrected)

Kumar Gala
 

Developers,

I wanted to thank everyone again that’s been part of the Zephyr community and contributed to the project and this major milestone in the project’s history.

As we now have an LTS release with 1.14 we will be putting in some processes on how code gets incorporated into the LTS branch. The first such activity is marking any PR that should be considered for LTS with the 'backport v1.14-branch’ tag. We are going to try and utilize a GitHub App that should hopefully help with the backport processes to the v1.14-branch. By tagging the PR with the label, the app will try and automatically create a PR for the backport once the original PR gets merged (if it can).

The TSC is meeting Face to Face next Week (April 24/25th) and one of the topics that we will be discussing is further processes around the LTS branch.

Additionally, now that 1.14 is out, we will slowly start merging PRs, the focus will first be on bug fix PRs as these might also be candidates for 'backport v1.14-branch'. I’d ask all developers, maintainers, and users to look at any outstanding PRs and mark them with the 'backport v1.14-branch’ label if you think they are candidates. Please bare with us as we slowly get back to the normal pace of development.

Thanks everyone!

- k

On Apr 16, 2019, at 4:02 PM, Kumar Gala <kumar.gala@linaro.org> wrote:

All,

In my rush to get 1.14 released, I reported on the Major Enhancements from 1.13. Sorry for the confusion. Here is the corrected list of Major Enhancements in 1.14:

* The Zephyr project now supports over 160 different board configurations
spanning 8 architectures. All architectures are rigorously tested and
validated using one of the many simulation platforms supported by the
project: QEMU, Renode, ARC Simulator, and the native POSIX configuration.

* The timing subsystem has been reworked and reimplemented, greatly
simplifying the resulting drivers, removing thousands of lines
of code, and reducing a typical kernel build size by hundreds of bytes.
TICKLESS_KERNEL mode is now the default on all architectures.

* The Symmetric Multi-Processing (SMP) subsystem continues to evolve
with the addition of a new CPU affinity API that can "pin" threads to
specific cores or sets of cores. The core kernel no longer uses the
global irq_lock on SMP systems, and exclusively uses the spinlock API
(which on uniprocessor systems reduces to the same code).

* Zephyr now has support for the x86_64 architecture. It is currently
implemented only for QEMU targets, supports arbitrary numbers of CPUs,
and runs in SMP mode by default, our first platform to do so.

* We've overhauled the Network packet (net-pkt) API and moved the majority
of components and protocols to use the BSD socket API, including MQTT,
CoAP, LWM2M, and SNTP.

* We enhanced the native POSIX port by adding UART, USB, and display
drivers. Based on this port, we added a simulated NRF52832 SoC which enables
running full system, multi-node simulations, without the need of real
hardware.

* We added an experimental BLE split software Controller with Upper Link Layer
and Lower Link Layer for supporting multiple BLE radio hardware
architectures.

* The power management subsystem has been overhauled to support device idle
power management and move most of the power management logic from the
application back to the BSP.

* We introduced major updates and an overhaul to both the logging and
shell subsystems, supporting multiple back-ends, integration
of logging into the shell, and delayed log processing.

* Introduced the `west` tool for management of multiple repositories and
enhanced support for flashing and debugging.

* Added support for application user mode, application memory
partitions, and hardware stack protection in ARMv8m

* Applied MISRA-C code guideline on the kernel and core components of Zephyr.
MISRA-C is a well established code guideline focused on embedded systems and
aims to improve code safety, security and portability.

- kumar

On Apr 16, 2019, at 3:44 PM, Kumar Gala <kumar.gala@linaro.org> wrote:

Hi,

We are pleased to announce the release of Zephyr kernel version 1.14.0. The 1.14.0 will be the first Zephyr LTS release that we will support for at least 2 years.

Major enhancements with this release include:

* Extensible and Pluggable Tracing Support
* Compartmentalized application memory organization
* Logging System Overhaul
* Introduce system calls for BSD socket APIs
* Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)
* Link Layer Discovery Protocol (LLDP) TX support
* Support for TLS and DTLS using BSD socket API
* Support for Link Layer Multicast Name Resolution (LLMNR)
* Introduced reworked ADC API and updated Nordic, NXP, Atmel, and Synopsys DesignWare drivers
* Support OS driven Power Management framework
* Basic support for Arm TrustZone in Armv8-M

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.14.0

I would like to thank all the contributors to this release. In total 250 contributors participated in the development of 1.14. Its taken a lot of hard work from everyone in the Zephyr community!

Thank you again,

Kumar Gala


Re: Zephyr 1.14.0 Released (corrected)

Kumar Gala
 

All,

In my rush to get 1.14 released, I reported on the Major Enhancements from 1.13. Sorry for the confusion. Here is the corrected list of Major Enhancements in 1.14:

* The Zephyr project now supports over 160 different board configurations
spanning 8 architectures. All architectures are rigorously tested and
validated using one of the many simulation platforms supported by the
project: QEMU, Renode, ARC Simulator, and the native POSIX configuration.

* The timing subsystem has been reworked and reimplemented, greatly
simplifying the resulting drivers, removing thousands of lines
of code, and reducing a typical kernel build size by hundreds of bytes.
TICKLESS_KERNEL mode is now the default on all architectures.

* The Symmetric Multi-Processing (SMP) subsystem continues to evolve
with the addition of a new CPU affinity API that can "pin" threads to
specific cores or sets of cores. The core kernel no longer uses the
global irq_lock on SMP systems, and exclusively uses the spinlock API
(which on uniprocessor systems reduces to the same code).

* Zephyr now has support for the x86_64 architecture. It is currently
implemented only for QEMU targets, supports arbitrary numbers of CPUs,
and runs in SMP mode by default, our first platform to do so.

* We've overhauled the Network packet (net-pkt) API and moved the majority
of components and protocols to use the BSD socket API, including MQTT,
CoAP, LWM2M, and SNTP.

* We enhanced the native POSIX port by adding UART, USB, and display
drivers. Based on this port, we added a simulated NRF52832 SoC which enables
running full system, multi-node simulations, without the need of real
hardware.

* We added an experimental BLE split software Controller with Upper Link Layer
and Lower Link Layer for supporting multiple BLE radio hardware
architectures.

* The power management subsystem has been overhauled to support device idle
power management and move most of the power management logic from the
application back to the BSP.

* We introduced major updates and an overhaul to both the logging and
shell subsystems, supporting multiple back-ends, integration
of logging into the shell, and delayed log processing.

* Introduced the `west` tool for management of multiple repositories and
enhanced support for flashing and debugging.

* Added support for application user mode, application memory
partitions, and hardware stack protection in ARMv8m

* Applied MISRA-C code guideline on the kernel and core components of Zephyr.
MISRA-C is a well established code guideline focused on embedded systems and
aims to improve code safety, security and portability.

- kumar

On Apr 16, 2019, at 3:44 PM, Kumar Gala <kumar.gala@linaro.org> wrote:

Hi,

We are pleased to announce the release of Zephyr kernel version 1.14.0. The 1.14.0 will be the first Zephyr LTS release that we will support for at least 2 years.

Major enhancements with this release include:

* Extensible and Pluggable Tracing Support
* Compartmentalized application memory organization
* Logging System Overhaul
* Introduce system calls for BSD socket APIs
* Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)
* Link Layer Discovery Protocol (LLDP) TX support
* Support for TLS and DTLS using BSD socket API
* Support for Link Layer Multicast Name Resolution (LLMNR)
* Introduced reworked ADC API and updated Nordic, NXP, Atmel, and Synopsys DesignWare drivers
* Support OS driven Power Management framework
* Basic support for Arm TrustZone in Armv8-M

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.14.0

I would like to thank all the contributors to this release. In total 250 contributors participated in the development of 1.14. Its taken a lot of hard work from everyone in the Zephyr community!

Thank you again,

Kumar Gala


Zephyr 1.14.0 Released

Kumar Gala
 

Hi,

We are pleased to announce the release of Zephyr kernel version 1.14.0. The 1.14.0 will be the first Zephyr LTS release that we will support for at least 2 years.

Major enhancements with this release include:

* Extensible and Pluggable Tracing Support
* Compartmentalized application memory organization
* Logging System Overhaul
* Introduce system calls for BSD socket APIs
* Support for IEEE 802.1AS-2011 generalized Precision Time Protocol (gPTP)
* Link Layer Discovery Protocol (LLDP) TX support
* Support for TLS and DTLS using BSD socket API
* Support for Link Layer Multicast Name Resolution (LLMNR)
* Introduced reworked ADC API and updated Nordic, NXP, Atmel, and Synopsys DesignWare drivers
* Support OS driven Power Management framework
* Basic support for Arm TrustZone in Armv8-M

The detailed release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.14.0

I would like to thank all the contributors to this release. In total 250 contributors participated in the development of 1.14. Its taken a lot of hard work from everyone in the Zephyr community!

Thank you again,

Kumar Gala


Re: Board: Adafruit ItsyBitsy M0 Express

Kumar Gala
 

On Apr 13, 2019, at 8:54 AM, ulrich.althoefer@web.de wrote:

Hello everyone,
the board 'Adafruit Trinket M0' is supported by the Zephyr project.
Is it planned to support the board 'Adafruit ItsyBitsy M0 Express' in the future?
Thanks for your answer.
Not aware of anyone working on this, but looks like it would be trivial to add board support for it based on the 'Adafruit Trinket M0’

- k


Re: #bluetoothmesh Help for sending and receiving messages through mesh #bluetoothmesh

paul.leguennec@...
 
Edited

Hi,

I am trying to implement two vendor models : one client and one server. I made a little specification of that model, and it just need two messages handlers : get and status. The client will send a get message to the server to receive a status response from the server.

To send periodically this message, as Johan Hedberg suggested me, I want to use periodic publishing.
Yet, I have trouble to see how I can use it. This is what I have add in my code :
/*
 * Client Configuration Declaration
 */

static struct bt_mesh_cfg_cli cfg_cli = {
};

static struct bt_mesh_cfg_mod_pub mod_periodic_pub = {
    .ttl     = 7,
    .period    = BT_MESH_PUB_PERIOD_SEC(7),

};
I don't believe it should be written like that. Could someone help me ?

EDIT
Also, for my Vendor Models I don't know if i should add a vendor_publish function, I just want to send a get message periodically to the server so it can respond with the status message.

Regards,
Paul.



Re: Web Server

Jukka Rissanen
 

Hi Nicholas,

see https://github.com/zephyrproject-rtos/zephyr/issues/14467 for
discussion about HTTP API support.


Cheers,
Jukka

On Mon, 2019-04-15 at 18:02 +0000, via Lists.Zephyrproject.Org wrote:
Hello,

I see there is an example for a dumb HTTP server for Zephyr in the
samples folder. This example serves a single static web page when
going to that IP address in a web browser. Is it possible to make a
dynamic web page using Zephyr?

My use case is to have my FRDM-K64F board host the server and change
values on the web page every couple seconds. The board will receive
data and put it on the web page essentially. Is this possible?

I also read online that Zephyr removed its HTTP API. Would this
affect me trying to build this application?

Regards, Nick Nicholas Yameen
R&D Engineer

D 978-975-9675 x59675
E Nicholas.Yameen@schneider-electric.com 800 Federal Street
Andover, MA 01810
United States

*Please consider the environment before printing this e-mail



Re: Web Server

Paul Sokolovsky
 

Hello Nicholas,

On Mon, 15 Apr 2019 18:02:46 +0000
" via Lists.Zephyrproject.Org"
<Nicholas.Yameen=se.com@lists.zephyrproject.org> wrote:

I see there is an example for a dumb HTTP server for Zephyr in the
samples folder. This example serves a single static web page when
going to that IP address in a web browser. Is it possible to make a
dynamic web page using Zephyr?

My use case is to have my FRDM-K64F board host the server and change
values on the web page every couple seconds. The board will receive
data and put it on the web page essentially. Is this possible?
Zephyr offers a (sizable subset of) BSD Socket API, which means you can
either implement such a server relatively easily or port an existing
(small) one to Zephyr.

Availability of an HTTP server library in Zephyr tree largely depends
on doing a good research among the existing small HTTP server (also,
client) implementations, choosing the best one, or discarding them all
and embarking on writing our own from scratch. So far, nobody did that
work.

Hasting with adding such a library to Zephyr can only lead to sub-ideal
choice, which later will need to be replaced with something else or
changes substantially, leading to breakage of user applications. In
this regard, starting so far with out-of-tree libraries seems like
good choice (and sharing any experience with them is very welcome and
will be helpful to choose the "official" library to import in-tree).


I also read online that Zephyr removed its HTTP API. Would this
affect me trying to build this application?

Regards,
Nick
Nicholas Yameen
R&D Engineer
[]

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


Is DFU working in Zephyr?

Li, Jun R
 

Hi Zephyr developers:

 

I’m trying to enable the DFU function inside the mcuboot bootloader so that I can use the bootloader to load a custom firmware file. I followed the sample “samples/subsys/usb/dfu/” and enabled the following options in MCUBOOT’s prj.conf:

 

CONFIG_USB_DEVICE_STACK=y

CONFIG_USB_DEVICE_PRODUCT="MCUboot DFU"

CONFIG_USB_DFU_CLASS=y

CONFIG_IMG_MANAGER=y

CONFIG_FLASH_PAGE_LAYOUT=y

 

And I also modified “main.c” to make it always wait for DFU instead of jumping to the slot 0. The bootloader can work normally, and I can see the following “dmesg” on the host computer:

[138144.555652] usb 2-2.1: new full-speed USB device number 29 using uhci_hcd

[138144.662455] usb 2-2.1: New USB device found, idVendor=2fe3, idProduct=0100

[138144.662458] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[138144.662459] usb 2-2.1: Product: MCUBOOT

[138144.662460] usb 2-2.1: Manufacturer: ZEPHYR

[138144.662462] usb 2-2.1: SerialNumber: 0.01

 

It seems everything is ready. So, I ran the following command to try backing up the data in the slot 0:

sudo dfu-util -alt 0 --upload slot0_backup.bin

 

However, the command always fails with the following messages:

dfu-util 0.8

 

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.

Copyright 2010-2014 Tormod Volden and Stefan Schmidt

This program is Free Software and has ABSOLUTELY NO WARRANTY

Please report bugs to dfu-util@...

 

Opening DFU capable USB device...

ID 2fe3:0100

Run-time device DFU version 0110

Claiming USB DFU Runtime Interface...

Determining device status: state = appIDLE, status = 0

Device really in Runtime Mode, send DFU detach request...

Resetting USB...

dfu-util: Lost device after RESET?

 

Any idea how to resolve this issue?  The board I’m using is Nucleo-F429ZI, a ST-Micro eval board.

 

Regards,

Jun

 


Re: Web Server

lairdjm
 

Hi Nick,
HTTP support is set to be dropped soon last I heard yes, this is because it hasn’t been converted to use the new sockets API and has no active maintainer, that may change in the future.

You can do it multiple ways, the easiest would be to have static pages but have the dynamic data on specific URIs like /sensor returning a list of the data in JSON format and then having some AJAX on the webpage which gets this data and puts it where it is needed, it would require a web browser with JavaScript to function, but doesn’t require reloading the whole page to update the values on it.
Thanks,
Jamie


From: devel@... <devel@...> on behalf of via Lists.Zephyrproject.Org <Nicholas.Yameen=se.com@...>
Sent: Monday, April 15, 2019 7:02:46 PM
To: devel@...
Cc: devel@...
Subject: [Zephyr-devel] Web Server
 

EXTERNAL EMAIL: Be careful with attachments and links.

Hello,

 

I see there is an example for a dumb HTTP server for Zephyr in the samples folder. This example serves a single static web page when going to that IP address in a web browser. Is it possible to make a dynamic web page using Zephyr?

 

My use case is to have my FRDM-K64F board host the server and change values on the web page every couple seconds. The board will receive data and put it on the web page essentially. Is this possible?

 

I also read online that Zephyr removed its HTTP API. Would this affect me trying to build this application?

 

Regards,

Nick

Nicholas Yameen
R&D Engineer

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

800 Federal Street
Andover, MA 01810
United States

Blog Blog Blog Blog Blog Blog Blog 

*Please consider the environment before printing this e-mail

 

 


Web Server

Nicholas Yameen <Nicholas.Yameen@...>
 

Hello,

 

I see there is an example for a dumb HTTP server for Zephyr in the samples folder. This example serves a single static web page when going to that IP address in a web browser. Is it possible to make a dynamic web page using Zephyr?

 

My use case is to have my FRDM-K64F board host the server and change values on the web page every couple seconds. The board will receive data and put it on the web page essentially. Is this possible?

 

I also read online that Zephyr removed its HTTP API. Would this affect me trying to build this application?

 

Regards,

Nick

Nicholas Yameen
R&D Engineer

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

800 Federal Street
Andover, MA 01810
United States

Blog Blog Blog Blog Blog Blog Blog 

*Please consider the environment before printing this e-mail

 

 


Re: To bring back RPL to Zephyr project

Thiago Silveira
 

Hello Jian,

We do use the RPL module in our project, and we will keep using it in the future.

Unfortunately, as we are a very small team, we didn't have the resources to step up and maintain it then, and we don't have the resources now. If you do happen to bring it back and take the responsibility, I'd be glad to help in any way I can.

Best regards,
Thiago


On Fri, Apr 5, 2019 at 11:36 PM Jian Zhang <kernel@...> wrote:
Hi All,

I am kind of new to Zephyr dev community. Previously our team was using Zephyr without actively involved in kernel development.

Recently we just noticed that RPL module will be removed in the coming release. Because we are using Zephyr and RPL in the current project and probably will keep using it. I am thinking of bringing it back and take the responsibility to maintain it. 

Just want to check if the RPL module with Zephyr is used anywhere? In case it's not required by anyone else, it probably would be easier for us to maintain our own branch.

Please let me know if you guys have any thoughts.

Thanks and Best Regards,
Jian





Re: Support for Open Supervised Device Protocol (OSDP) in Zephyr

Thea Aldrich
 

Hi Sid,
Thanks so much for reaching out.  Let me do some asking around as to which working group within Zephyr Project can best look into and,  if things align, help with coordination. I'll be back with more specific information on Monday. Thanks so much for your patience!

Best, 
Thea


On Sat, Apr 13, 2019, 1:54 PM Siddharth Chandrasekaran <siddharth@...> wrote:
Hi,

Can anyone comment on this? It'd be helpful to know such information earlier on.

Sid.

 ---- On Sun, 07 Apr 2019 00:39:04 +0530 Siddharth Chandrasekaran <siddharth@...> wrote ----
 > Hello,
 >
 > I'm working on an project that involves Open Supervised Device Protocol (OSDP) [1], an access control communication protocol used in the security industry. I'm working on this as an application at this point but I think this protocol may be useful for others too. So I'm looking at options for upstreaming it.
 >
 > I would like to know if this is something that the upstream is interested at this point. If so, some pointers on where to add such protocol implementations and other references would be of help.
 >
 > Thanks,
 > Sid.
 >
 > [1]: https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/
 >
 >





Re: Support for Open Supervised Device Protocol (OSDP) in Zephyr

Siddharth Chandrasekaran
 

Hi,

Can anyone comment on this? It'd be helpful to know such information earlier on.

Sid.

---- On Sun, 07 Apr 2019 00:39:04 +0530 Siddharth Chandrasekaran <siddharth@embedjournal.com> wrote ----

Hello,
>
> I'm working on an project that involves Open Supervised Device Protocol (OSDP) [1], an access control communication protocol used in the security industry. I'm working on this as an application at this point but I think this protocol may be useful for others too. So I'm looking at options for upstreaming it.
>
> I would like to know if this is something that the upstream is interested at this point. If so, some pointers on where to add such protocol implementations and other references would be of help.
>
> Thanks,
> Sid.
>
> [1]: https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/
>
>

1881 - 1900 of 7815