Date   

Re: Trying Nucleo-64 STM32F411RE

jack ma
 

if someone can write some document for how to use hal drivers(eg,stm32
cube) to write drivers or give an example for that ?
I really want use Zephyr for new project, but not familiar with the driver
develop. after browse the code tree, I did not find a method, so
temporarily abandoned.

2017-01-16 17:42 GMT+08:00 Erwan Gouriou <erwan.gouriou(a)linaro.org>:

Hi Piotr,

You should indeed first look at Zephyr documentation, and particularly i2c
API.
Then, regarding STM32 driver/IP, there are several sources that could help
you to develop I2C driver for STM32F4xx family
(as your driver should benefit to other SoCs from the F4 family):
-Zephyr native implementation of stm32lx i2c driver:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=
tree;f=drivers/i2c
-HAL implementation from STM32Cube SDK (that you could get here
http://www.st.com/en/embedded-software/stm32cubef4.html)
Inside SDK, you'll find i2c code examples using HAL
(Projects/xx/Examples/I2C/)
-stm32f411re Refence Manual for information about stm32f411re I2C (
http://www.st.com/en/microcontrollers/stm32f411re.html)

Then, you have two options:
-based on STM32Cube HAL, develop a generic STM32 driver that will benefit
to all STM32 based boards.
-develop a Zephyr "native" STM32F4 I2C API that will benefit to STM32F4
family devices (similar to stm32lx.c driver)

Either ways, note that you could use STM32Cube SDK (ext/hal/st/stm32cube/stm32f4xx/soc/stm32f411xe.h)
to benefit from
useful structures, macros and defines that provide abstraction capability
so you don't have to deal with subtle differences between
similar SoCs (such as stm32f401re and stm32f411re).

Good luck with your project
Erwan


On 14 January 2017 at 23:26, Piotr Król <piotr.krol(a)3mdeb.com> wrote:

On Mon, Jan 02, 2017 at 03:03:58PM +0100, Erwan Gouriou wrote:
Hi Piotr,
Hi Erwan,


There was an issue on F411RE clock initialisation steps.
I've submitted following change to correct it:
https://gerrit.zephyrproject.org/r/9571

Hope it helps.
This helps sample code works correctly. With that I can continue with my
target project, which is i2c driver for F411RE.

Can you point me to information how I should approach adding i2c driver
for this board ?

I assume first I should familiarize myself with Zephyr documentation and
contribution guidelines, but have you got any reference code for i2c
driver ?

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-1582] How to create a Zephyr ROM library
https://jira.zephyrproject.org/browse/ZEP-1582

[ZEP-1581] [nRF52832] Blinky hangs after some minutes
https://jira.zephyrproject.org/browse/ZEP-1581


UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Re: [RFC]DMA API Update

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

On Sat, 2017-01-14 at 00:31 +0000, Liu, Baohong wrote:
Thanks for the feedback. See my reply inline.
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]

But finally, the big elephant in the room is: how are DMA APIs actually
expected to used? And how should the system be configured?
The same way as other device drivers. There will be a driver to implement
the APIs for each SoC. App does the config, and initiate the transfer by
calling the APIs.
As far as I can see there is no documentation or examples in Zephyr that
give a clue as to how DMA can be used with device drivers. So it's very
difficult to review a DMA API without some more explanation on it's
expected use.

Let me try some more specific questions...

Say I have a system which has:
A) a driver for a DMA Controller (it implement struct dma_driver_api) 
B) a driver for some interface, e.g. SPI
C) an app which wants to talk to a device attached to that interface
e.g. and LCD controller
D) other things

Which of the above will call

- dma_channel_config
- dma_transfer_config
- dma_transfer_start
- dma_transfer_stop

?

The SPI subsystem interface doesn't have anything DMA related in it, so
I can only assume that DMA use will have to be hidden inside the SPI
driver, and for each spi_transceive request made made of it will setup
and operate on an appropriate struct dma_transfer_config? (Or use
scatter-gather lists when API's get that ;-)

If so, every device driver in zephyr that anyone wants to use with DMA
will need to add DMA support to it and make it configurable to
(optionally) use the generic DMA API. Or is it expected that all APIs
like SPI grow new functions for use with DMA specifically?

That still leaves the question as to who calls dma_channel_config and
how the parameters for that get into the system. Is each driver that
implements DMA support going to have a bunch of KConfig entries to
dma_slot, hankshake_polarity etc? Or will the SoC have a bunch of
#defines (like we currently have for IRQ numbers) for setting these DMA
attributes (assuming they are fixed in hardware).

There's also the question as to how channel numbers are allocated. Is
this more per-driver KConfig options or should we have a DMA channel
allocator function so they can just be assigned at runtime?

I'm also thinking about the fact that there are likely to be more
devices capable of DMA than channels available so how about an API to
free a channel? E.g. dma_channel_config claims a channel for use and
dma_channel_free releases for someone else. That way even with static
allocation of channels we have the option of allocating the same channel
to two different devices if we know they can't be active at the same
time.

--
Tixy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10083 : tests/context: fix Coverity warning about array overrun
- https://gerrit.zephyrproject.org/r/10067 : doc: make build process quiet
- https://gerrit.zephyrproject.org/r/10082 : net: doc: add section about networking with qemu
- https://gerrit.zephyrproject.org/r/10077 : net: buf: fix user_data_size initialization.
- https://gerrit.zephyrproject.org/r/10073 : net/mqtt: Simplify the MQTT high-level API
- https://gerrit.zephyrproject.org/r/10074 : net/mqtt: Add the "malformed" callback to the MQTT ctx structure
- https://gerrit.zephyrproject.org/r/10072 : net/mqtt: Move upwards buffer size validation
- https://gerrit.zephyrproject.org/r/10058 : doc: update doc building README instructions
- https://gerrit.zephyrproject.org/r/10057 : samples/net: Improve text indentation and clarify some instructions

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/10052 : kernel: doc: Add deprecation notice to legacy.h
- https://gerrit.zephyrproject.org/r/9805 : ext: mcux: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/10002 : boards: categorize boards by architecture
- https://gerrit.zephyrproject.org/r/10004 : samples: doc: remove 'make pristine', it is not needed
- https://gerrit.zephyrproject.org/r/9998 : boards: add qemu_x86 board documentation
- https://gerrit.zephyrproject.org/r/10003 : boards: add em_starterkit board documentation
- https://gerrit.zephyrproject.org/r/10001 : boards: add arduino_due board documentation
- https://gerrit.zephyrproject.org/r/10000 : doc: application porting guide to the unified kernel
- https://gerrit.zephyrproject.org/r/9997 : samples: dtls: Fixed layout and titles in documentation
- https://gerrit.zephyrproject.org/r/10051 : doc: add a doxygen group for the Kernel API
- https://gerrit.zephyrproject.org/r/9999 : boards: add qemu_cortex_m3 board documentation
- https://gerrit.zephyrproject.org/r/9996 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/10050 : boards: quark_d2000_crb: add board image to documentation
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9446 : Bluetooth: AVDTP: Added params to AVDTP Request structure
- https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level
- https://gerrit.zephyrproject.org/r/9859 : Bluetooth: Kconfig: Specify stack size for Bluetooth SPI
- https://gerrit.zephyrproject.org/r/9857 : Bluetooth: Add HCI SPI driver
- https://gerrit.zephyrproject.org/r/9904 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9905 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9858 : Bluetooth: samples/beacon: Print message at start of sample
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/9660 : Bluetooth: Controller: Conditional compile roles
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission
- https://gerrit.zephyrproject.org/r/9573 : Bluetooth: Controller: conditional compile advertiser only
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/9894 : net: ipv6: fix link address handling in handle_ns_neighbor
- https://gerrit.zephyrproject.org/r/9663 : Bluetooth: AVDTP: Add AVDTP Receive Function
- https://gerrit.zephyrproject.org/r/9928 : net: tcp: Also signal EOF with a negative status code
- https://gerrit.zephyrproject.org/r/9977 : samples: net: "Mini HTTP" example & validator for TCP layer
- https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/4457 : DONT: MERGE - cause checkpatch warnings
- https://gerrit.zephyrproject.org/r/7664 : second: test
- https://gerrit.zephyrproject.org/r/5137 : DONT_MERGE: - add changes to two different branches
- https://gerrit.zephyrproject.org/r/5445 : DONT_MERGE: - break sanity
- https://gerrit.zephyrproject.org/r/3114 : DONT MERGE: - break doc
- https://gerrit.zephyrproject.org/r/9968 : ext: hal: qmsi: implement I2C Fast Plus Mode
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9713 : Bluetooth: SDP: Add API to get ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9715 : Bluetooth: SDP: Add API to get SupportedFeature attribute
- https://gerrit.zephyrproject.org/r/9716 : Bluetooth: SDP: Use SupportedFeature attr API in BTshell
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9710 : Bluetooth: SDP: Add SDP client interface to BTshell app
- https://gerrit.zephyrproject.org/r/9995 : samples/philosophers: enable demo to run in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9993 : kernel/mutex: prevent priority inheritance from lowering owner's prio
- https://gerrit.zephyrproject.org/r/9992 : kernel: fix main/work_q prios in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9994 : kernel: fix total number of coop prios in coop-only mode
- https://gerrit.zephyrproject.org/r/9991 : kernel: use PREEMPT_ENABLED instead of NUM_PREEMPT_PRIORITIES > 0
- https://gerrit.zephyrproject.org/r/9990 : kernel: correct the highest priority in coop-only modes
- https://gerrit.zephyrproject.org/r/10053 : ztest: enable coop/preempt configurations

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10080 : Bluetooth: L2CAP: Fix using CONFIG_BLUETOOTH_RX_BUF_LEN as MTU
- https://gerrit.zephyrproject.org/r/10056 : samples/net: Remove legacy configuation variables
- https://gerrit.zephyrproject.org/r/10078 : samples: thermometer: use convert to double function from sensor.h
- https://gerrit.zephyrproject.org/r/10081 : MAINTAINERS: fix email address typo in sensor drivers section
- https://gerrit.zephyrproject.org/r/10079 : Bluetooth: Add documentation for connection callbacks
- https://gerrit.zephyrproject.org/r/10048 : samples/net: Remove redundant configuration variable
- https://gerrit.zephyrproject.org/r/10049 : drivers/ethernet: Update default GPIO pin for the ENC28J60 module
- https://gerrit.zephyrproject.org/r/9895 : net: route: remove extra variable use in net_route_add()
- https://gerrit.zephyrproject.org/r/9893 : net: ipv6: fix NULL reference in handle_ra_neighbor
- https://gerrit.zephyrproject.org/r/9892 : net: linkaddr: introduce net_linkaddr_set function
- https://gerrit.zephyrproject.org/r/9940 : net: tcp: Destroy net_tcp struct at the same time as the context
- https://gerrit.zephyrproject.org/r/9935 : net: tcp: Pass correct user_data pointers
- https://gerrit.zephyrproject.org/r/9891 : net: linkaddr: calculate linkaddr storage addr size via config
- https://gerrit.zephyrproject.org/r/9953 : Bluetooth: RFCOMM: Implement Aggregate Flow Control
- https://gerrit.zephyrproject.org/r/9983 : bluetooth: hci_core: Fix conn params validity check


Re: Consistency in Kconfig organization, depends / select

Jukka Rissanen
 

Hi Marcus,

On Mon, 2017-01-16 at 10:46 +0000, Marcus Shawcroft wrote:
Hi!

I noticed this review fly by:

https://gerrit.zephyrproject.org/r/#/c/9982/

Which essentially adjusts a Kconfig to have an SPI driver Kconfig
explicitly select a GPIO driver when it needs the GPIO driver.

Many, perhaps most of the dependence relationships between drivers
are
currently expressed using a Kconfig "depends" model rather than the
"select" model.

Over the last few months I've pondered the use of the "depends" model
rather than a "select" model.  Superficially the "select" model has a
number of user facing advantages over the "depends" model, ones that
spring to mind are:
- As a user I can just enable the high level components/drivers I
need
to solve the applications problem, all the dependencies get dragged
in
automatically.
If you use "select", then the dependencies of that select are not
selected by default. This makes "select" a bit cumbersome and error
prone to use IMHO. 

- As a user I don;t need to dig around in Kconfig to figure out which
config options I need  to first enable in order to get the actual
option I'm looking for to appear in the config menus (I've often
found
myself having to do this :-(.

Looking in the drivers tree, there are many driver dependencies that
IMHO would give a better user config experience if we adopted a
selects model instead of the current depend model, for example:
- *sensor* -> I2C.
- console -> serial
- flash -> spi
- spi -> gpio
- ethernet -> random

What do folks think about adopting a more aggressive use of 'select'
?

Cheers
/Marcus

Cheers,
Jukka


Re: reg: Routing SPI signals connected from x86 core to the Arc core

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

Hi Liu

We have finalized zephyr 1.6 version for our project

there is any patch available for zephyr 1.6 , which I can install and use ARC to directly access GPIO including AON_GPIO and SPI ?

Please help and reply

Best regards
Mahendra




From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Saturday, January 14, 2017 12:16 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: Routing SPI signals connected from x86 core to the Arc core

Post 1.6. You need to use master. You do not need x86 at all.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Friday, January 13, 2017 4:16 AM
To: Liu, Baohong <baohong.liu(a)intel.com<mailto:baohong.liu(a)intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: reg: Routing SPI signals connected from x86 core to the Arc core

Hi Liu

As you have stated below

"Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all"

Is this done in zephyr 1.6 ? Even AON_GPIO can I declare and use directly at ARC ?

Please Note we have connected bma255 at SPI lines of x86.


Best regards

Mahendravarman Rajarao

Mobil +919952921253
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 03, 2017 11:36 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: Routing SPI signals connected from x86 core to the Arc core

Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all.

Please see the updated driver and sample app for BMI160 (top of the free, master).

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, January 3, 2017 4:24 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: Routing SPI signals connected from x86 core to the Arc core

Hi

We have connected an Accelerometer to the x86 core of C1000 (Quark_se) through SPI interface.
Interrupt line of accelerometer is also connected to the AON_GPIO_3

Now I need to route the SPI connection of x86 to Arc core. Is that possible ?

Any sample code in zephyr I can refer for this activity ?

Best regards
Mahendra


Consistency in Kconfig organization, depends / select

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi!

I noticed this review fly by:

https://gerrit.zephyrproject.org/r/#/c/9982/

Which essentially adjusts a Kconfig to have an SPI driver Kconfig
explicitly select a GPIO driver when it needs the GPIO driver.

Many, perhaps most of the dependence relationships between drivers are
currently expressed using a Kconfig "depends" model rather than the
"select" model.

Over the last few months I've pondered the use of the "depends" model
rather than a "select" model. Superficially the "select" model has a
number of user facing advantages over the "depends" model, ones that
spring to mind are:
- As a user I can just enable the high level components/drivers I need
to solve the applications problem, all the dependencies get dragged in
automatically.
- As a user I don;t need to dig around in Kconfig to figure out which
config options I need to first enable in order to get the actual
option I'm looking for to appear in the config menus (I've often found
myself having to do this :-(.

Looking in the drivers tree, there are many driver dependencies that
IMHO would give a better user config experience if we adopted a
selects model instead of the current depend model, for example:
- *sensor* -> I2C.
- console -> serial
- flash -> spi
- spi -> gpio
- ethernet -> random

What do folks think about adopting a more aggressive use of 'select'
instead of 'depend' above and beyond 9982

?

Cheers
/Marcus


Re: Zephyr on STM32F042/072/405 with USB?

Erwan Gouriou
 

Hi Christer,

Thanks in advance for these tasks.

For USB support on STM32, it would be great that this work could benefit
to the whole STM32 family.
STM32Cube SDK could help you in implementing a single driver common to
STM32 SoCs thanks to HAL.
Should you prefer to implement a zephyr native driver, please note that
Cube SDKs
provides CMSIS defines, structures and macros that are useful for
abstracting
differences between SoC and keep genericity in your driver.

Good luck with this work
Erwan

On 15 January 2017 at 17:13, Christer Weinigel <christer(a)weinigel.se> wrote:

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer


Re: Trying Nucleo-64 STM32F411RE

Erwan Gouriou
 

Hi Piotr,

You should indeed first look at Zephyr documentation, and particularly i2c
API.
Then, regarding STM32 driver/IP, there are several sources that could help
you to develop I2C driver for STM32F4xx family
(as your driver should benefit to other SoCs from the F4 family):
-Zephyr native implementation of stm32lx i2c driver:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=tree;f=drivers/i2c
-HAL implementation from STM32Cube SDK (that you could get here
http://www.st.com/en/embedded-software/stm32cubef4.html)
Inside SDK, you'll find i2c code examples using HAL
(Projects/xx/Examples/I2C/)
-stm32f411re Refence Manual for information about stm32f411re I2C (
http://www.st.com/en/microcontrollers/stm32f411re.html)

Then, you have two options:
-based on STM32Cube HAL, develop a generic STM32 driver that will benefit
to all STM32 based boards.
-develop a Zephyr "native" STM32F4 I2C API that will benefit to STM32F4
family devices (similar to stm32lx.c driver)

Either ways, note that you could use STM32Cube SDK
(ext/hal/st/stm32cube/stm32f4xx/soc/stm32f411xe.h) to benefit from
useful structures, macros and defines that provide abstraction capability
so you don't have to deal with subtle differences between
similar SoCs (such as stm32f401re and stm32f411re).

Good luck with your project
Erwan

On 14 January 2017 at 23:26, Piotr Król <piotr.krol(a)3mdeb.com> wrote:

On Mon, Jan 02, 2017 at 03:03:58PM +0100, Erwan Gouriou wrote:
Hi Piotr,
Hi Erwan,


There was an issue on F411RE clock initialisation steps.
I've submitted following change to correct it:
https://gerrit.zephyrproject.org/r/9571

Hope it helps.
This helps sample code works correctly. With that I can continue with my
target project, which is i2c driver for F411RE.

Can you point me to information how I should approach adding i2c driver
for this board ?

I assume first I should familiarize myself with Zephyr documentation and
contribution guidelines, but have you got any reference code for i2c
driver ?

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com


How to generate .hex image

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

Hello,

When building, some BOARDs will generate both .bin and .hex, but others only .bin.
Is there a build switch to control this ?

My current stupid method is that, enter the directory where zephyr.elf is located, and then type:
/opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-eabi/arm-poky-eabi-objcopy -S -O ihex -R .note -R .comment -R COMMON -R .eh_frame zephyr.elf zephyr.hex

Thanks.


Re: Zephyr on STM32F042/072/405 with USB?

Joseph, Jithu
 

Hi Christer,

We have a bunch of USB device stuff under "subsys/usb/*".

In brief we have support for the following device classes :
CDC ACM - uart over usb
Mass storage
Webusb

You can exercise them via the samples under :
"samples/usb/*"

I am poking around a bit on USB Ethernet related stuff.

Coming onto the lower layer(driver) stuff, currently our only support is for the QuarkC1000 SOC's usb device controller. You can find it under "drivers/usb/device/*". So the USB samples currently run on arduino_101 and quark_se_c1000_devboard board configurations.

The first step for the STM usb stuff would be to implement the device controller driver which expose the
include/usb/usb_device.h API . Once this is done I expect the device class implementations and samples to plug in directly.

We look forward for your contributions .

Thanks
Jithu

-----Original Message-----
From: Christer Weinigel [mailto:christer(a)weinigel.se]
Sent: Saturday, January 14, 2017 10:36 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Zephyr on STM32F042/072/405 with USB?

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently running
ChibiOS on. I'm thinking about porting Zephyr to these boards and also try
to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working on
support for those MCUs or on the USB device? It would be kind of silly of
I someone else has already done that and I would duplicate their work.

/Christer

--
Have laptop, will travel. I'm a consultant looking for interesting jobs
anywhere in the world. I'm an experienced software engineer with a solid
understanding of hardware. Specialities: Linux, device drivers and
embedded systems in general. Find me at www.weinigel.se.


[RFC] STM32 pinmux - simplify pinmux logic

Christer Weinigel
 

Hi all,

BTW, for RFC patches like this that break the build, should
I submit them to Gerrit instead or do you prefer to see them
on the list?

I've just managed to port Zephyr to my STM32F405 based board.
One thing that I stumbled on and took me a few hours to figure
out is that I'm using UART2 on PD5/PD6 as my serial port and
for some reason I did not get any UART output. It turns out
that in addition to adding a few lines to pinmux_stm32f4.h
defining the UART2 alternate functions on PD5/PD6 I also had
to add mappings for PD5/PD6 to soc_pinmux.c. Without the
second change everything compiles nicely but the alternate
functions won't be activated anyway.

After thinking about this a bit I feel that the indirection
through stm32_get_pin_config in soc_pinmux.c is a bit, well,
overcomplicated. It also limits what I can do from my board
file, what if I acutally want to have a UART where RX is
pulled down (I want to see continuous breaks if nothing is
connected to the port)? Right now I can't do that without
modifying the Zephyr core.

Can't we just simplify this so that we encode the conf part
directly in the table? This allows us to remove all the
code in soc_pinmux.c and this way it's kind of obvious that
if you add a line in pinmux_stm32f4.h you have to specify
both the conf part and the altf part.

This is only a RFC, the patch as is breaks the stm32f1 and
stm32l4 ports. I can fix those up if you think this way of
doing things is a good idea.

/Christer

---
arch/arm/soc/st_stm32/stm32f4/Makefile | 1 -
arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c | 112 -----------------------------
drivers/pinmux/stm32/pinmux_stm32.c | 9 +--
drivers/pinmux/stm32/pinmux_stm32f4.h | 24 ++++---
4 files changed, 20 insertions(+), 126 deletions(-)
delete mode 100644 arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c

diff --git a/arch/arm/soc/st_stm32/stm32f4/Makefile b/arch/arm/soc/st_stm32/stm32f4/Makefile
index 6ae6e19..1ef7b4a 100644
--- a/arch/arm/soc/st_stm32/stm32f4/Makefile
+++ b/arch/arm/soc/st_stm32/stm32f4/Makefile
@@ -1,7 +1,6 @@
obj-y += soc.o

obj-$(CONFIG_GPIO) += soc_gpio.o
-obj-$(CONFIG_PINMUX) += soc_pinmux.o

zephyr: $(KERNEL_HEX_NAME)
all: $(KERNEL_HEX_NAME)
diff --git a/arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c b/arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c
deleted file mode 100644
index ef79ef4..0000000
--- a/arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c
+++ /dev/null
@@ -1,112 +0,0 @@
-/*
- * Copyright (c) 2016 Linaro Limited.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-#include <errno.h>
-
-#include "soc.h"
-#include <device.h>
-#include <misc/util.h>
-#include <pinmux/stm32/pinmux_stm32.h>
-#include <drivers/clock_control/stm32_clock_control.h>
-
-static const stm32_pin_func_t pin_pa9_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA9_USART1_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa10_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA10_USART1_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pb6_funcs[] = {
- [STM32F4_PINMUX_FUNC_PB6_USART1_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pb7_funcs[] = {
- [STM32F4_PINMUX_FUNC_PB7_USART1_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa2_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA2_USART2_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa3_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA3_USART2_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa0_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA0_PWM2_CH1 - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pd5_funcs[] = {
- [STM32F4_PINMUX_FUNC_PD5_USART2_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pd6_funcs[] = {
- [STM32F4_PINMUX_FUNC_PD6_USART2_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-/**
- * @brief pin configuration
- */
-static const struct stm32_pinmux_conf pins[] = {
- STM32_PIN_CONF(STM32_PIN_PA9, pin_pa9_funcs),
- STM32_PIN_CONF(STM32_PIN_PA10, pin_pa10_funcs),
- STM32_PIN_CONF(STM32_PIN_PB6, pin_pb6_funcs),
- STM32_PIN_CONF(STM32_PIN_PB7, pin_pb7_funcs),
- STM32_PIN_CONF(STM32_PIN_PA2, pin_pa2_funcs),
- STM32_PIN_CONF(STM32_PIN_PA3, pin_pa3_funcs),
- STM32_PIN_CONF(STM32_PIN_PA0, pin_pa0_funcs),
- STM32_PIN_CONF(STM32_PIN_PD5, pin_pa2_funcs),
- STM32_PIN_CONF(STM32_PIN_PD6, pin_pa3_funcs),
-};
-
-int stm32_get_pin_config(int pin, int func)
-{
- /* GPIO function is always available, to save space it is not
- * listed in alternate functions array
- */
- if (func == STM32_PINMUX_FUNC_GPIO) {
- return STM32F4X_PIN_CONFIG_BIAS_HIGH_IMPEDANCE;
- }
-
- /* analog function is another 'known' setting */
- if (func == STM32_PINMUX_FUNC_ANALOG) {
- return STM32F4X_PIN_CONFIG_ANALOG;
- }
-
- func -= 1;
-
- for (int i = 0; i < ARRAY_SIZE(pins); i++) {
- if (pins[i].pin == pin) {
- if (func > pins[i].nfuncs) {
- return -EINVAL;
- }
-
- return pins[i].funcs[func];
- }
- }
-
- return -EINVAL;
-}
diff --git a/drivers/pinmux/stm32/pinmux_stm32.c b/drivers/pinmux/stm32/pinmux_stm32.c
index dfc13b4..9a9d94a 100644
--- a/drivers/pinmux/stm32/pinmux_stm32.c
+++ b/drivers/pinmux/stm32/pinmux_stm32.c
@@ -102,17 +102,18 @@ static int stm32_pin_configure(int pin, int func, int altf)
int _pinmux_stm32_set(uint32_t pin, uint32_t func,
struct device *clk)
{
- int config;
+ int conf;
+ int altf;

/* make sure to enable port clock first */
if (enable_port(STM32_PORT(pin), clk)) {
return -EIO;
}

- /* determine config for alternate function */
- config = stm32_get_pin_config(pin, func);
+ conf = STM32F4_PINMUX_CONF(func);
+ altf = STM32F4_PINMUX_ALTF(func);

- return stm32_pin_configure(pin, config, func);
+ return stm32_pin_configure(pin, conf, altf);
}

/**
diff --git a/drivers/pinmux/stm32/pinmux_stm32f4.h b/drivers/pinmux/stm32/pinmux_stm32f4.h
index 8ec7f25..79c97d6 100644
--- a/drivers/pinmux/stm32/pinmux_stm32f4.h
+++ b/drivers/pinmux/stm32/pinmux_stm32f4.h
@@ -21,18 +21,24 @@
* @file Header for STM32F4 pin multiplexing helper
*/

-#define STM32F4_PINMUX_FUNC_PA9_USART1_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PA10_USART1_RX STM32_PINMUX_FUNC_ALT_7
+#include "soc.h"

-#define STM32F4_PINMUX_FUNC_PB6_USART1_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PB7_USART1_RX STM32_PINMUX_FUNC_ALT_7
+#define STM32F4_PINMUX_ENCODE(conf, altf) (((conf)<<8) | (altf))
+#define STM32F4_PINMUX_CONF(func) ((func) >> 8)
+#define STM32F4_PINMUX_ALTF(func) ((func) & 0xff)

-#define STM32F4_PINMUX_FUNC_PA2_USART2_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PA3_USART2_RX STM32_PINMUX_FUNC_ALT_7
+#define STM32F4_PINMUX_FUNC_PA9_USART1_TX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PA10_USART1_RX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7

-#define STM32F4_PINMUX_FUNC_PD5_USART2_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PD6_USART2_RX STM32_PINMUX_FUNC_ALT_7
+#define STM32F4_PINMUX_FUNC_PB6_USART1_TX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PB7_USART1_RX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)

-#define STM32F4_PINMUX_FUNC_PA0_PWM2_CH1 STM32_PINMUX_FUNC_ALT_1
+#define STM32F4_PINMUX_FUNC_PA2_USART2_TX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PA3_USART2_RX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+
+#define STM32F4_PINMUX_FUNC_PD5_USART2_TX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PD6_USART2_RX STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+
+#define STM32F4_PINMUX_FUNC_PA0_PWM2_CH1 STM32F4_PINMUX_ENCODE(STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_1)

#endif /* _STM32F4_PINMUX_H_ */
--
1.9.1


Zephyr on STM32F042/072/405 with USB?

Christer Weinigel
 

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 7
[ZEP-1103] Propose and implement synchronization flow for multicore power management
https://jira.zephyrproject.org/browse/ZEP-1103

[ZEP-1572] Update QMSI to 1.4
https://jira.zephyrproject.org/browse/ZEP-1572

[ZEP-1321] Glossary of Terms needs updating
https://jira.zephyrproject.org/browse/ZEP-1321

[ZEP-1389] Add support for KW41 SoC
https://jira.zephyrproject.org/browse/ZEP-1389

[ZEP-1558] Support of user private data pointer in Timer expiry function
https://jira.zephyrproject.org/browse/ZEP-1558

[ZEP-1374] Add ksdk spi shim driver
https://jira.zephyrproject.org/browse/ZEP-1374

[ZEP-1549] k_cpu_sleep_mode unaligned byte address
https://jira.zephyrproject.org/browse/ZEP-1549


CLOSED JIRA items within last 24 hours: 2
[ZEP-1404] (Won't Do) Move documentation to kernel-doc
https://jira.zephyrproject.org/browse/ZEP-1404

[ZEP-1578] (Duplicate) Kernel documentation still has TBD section
https://jira.zephyrproject.org/browse/ZEP-1578


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10052 : kernel: doc: Add deprecation notice to legacy.h
- https://gerrit.zephyrproject.org/r/9990 : kernel: correct the highest priority in coop-only modes
- https://gerrit.zephyrproject.org/r/10053 : ztest: enable coop/preempt configurations
- https://gerrit.zephyrproject.org/r/10051 : doc: add a doxygen group for the Kernel API
- https://gerrit.zephyrproject.org/r/9983 : bluetooth: hci_core: Fix conn params validity check
- https://gerrit.zephyrproject.org/r/10050 : boards: quark_d2000_crb: add board image to documentation
- https://gerrit.zephyrproject.org/r/9997 : samples: dtls: Fixed layout and titles in documentation
- https://gerrit.zephyrproject.org/r/9998 : boards: add qemu_x86 board documentation
- https://gerrit.zephyrproject.org/r/9996 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/10002 : boards: categorize boards by architecture
- https://gerrit.zephyrproject.org/r/10000 : doc: application porting guide to the unified kernel
- https://gerrit.zephyrproject.org/r/9999 : boards: add qemu_cortex_m3 board documentation
- https://gerrit.zephyrproject.org/r/10004 : samples: doc: remove 'make pristine', it is not needed
- https://gerrit.zephyrproject.org/r/10003 : boards: add em_starterkit board documentation
- https://gerrit.zephyrproject.org/r/10001 : boards: add arduino_due board documentation
- https://gerrit.zephyrproject.org/r/10049 : drivers/ethernet: Update default GPIO pin for the ENC28J60 module
- https://gerrit.zephyrproject.org/r/10048 : samples/net: Remove redundant configuration variable
- https://gerrit.zephyrproject.org/r/9995 : samples: allow demo to run in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9991 : kernel: use PREEMPT_ENABLED instead of NUM_PREEMPT_PRIORITIES > 0
- https://gerrit.zephyrproject.org/r/9993 : kernel/mutex: prevent priority inheritance from lowering owner's prio
- https://gerrit.zephyrproject.org/r/9994 : kernel: fix total number of coop prios in coop-only mode
- https://gerrit.zephyrproject.org/r/9992 : kernel: fix main/work_q prios in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9989 : spi: k64: Remove the k64 spi driver
- https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level
- https://gerrit.zephyrproject.org/r/9987 : tests: Update spi driver test for mcux
- https://gerrit.zephyrproject.org/r/9986 : k64: Change the default spi driver to the mcux shim
- https://gerrit.zephyrproject.org/r/9985 : spi: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9984 : spi: Add shared default configs

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback
- https://gerrit.zephyrproject.org/r/9968 : ext: hal: qmsi: implement I2C Fast Plus Mode
- https://gerrit.zephyrproject.org/r/9953 : Bluetooth: RFCOMM: Implement Aggregate Flow Control

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9943 : sensor: remove sensor value type


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Appala Raju <raju.ga@...>
 

Hi Luiz Augusto von Dentz,

Thanks for the patch. I have update the same and build for zoap_server.

LE SCAN output:
LE Scan ...
CA:2E:39:48:00:77 (unknown)
CA:2E:39:48:00:77 Test IPSP node

This is the debug output on UART:
[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [INF] show_dev_info: Identity: ca:2e:39:48:00:77 (random)
[bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x0000, manufacturer 0xffff
[bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0xffff
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20005020) CID 0x0004
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20005020) CID 0x0006
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20005020) CID 0x0005

Then I am trying to connect to this server using following command. But it .is not connecting. What could be the reason?

echo "connect ca:2e:39:48:00:77 1" | tee /sys/kernel/debug/bluetooth/6lowpan_control


Zephyr on STM32F042/072/405 with USB?

Christer Weinigel
 

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer

--
Have laptop, will travel. I'm a consultant looking for interesting
jobs anywhere in the world. I'm an experienced software engineer with
a solid understanding of hardware. Specialities: Linux, device
drivers and embedded systems in general. Find me at www.weinigel.se.


Re: Trying Nucleo-64 STM32F411RE

Piotr Król <piotr.krol at 3mdeb.com...>
 

On Mon, Jan 02, 2017 at 03:03:58PM +0100, Erwan Gouriou wrote:
Hi Piotr,
Hi Erwan,


There was an issue on F411RE clock initialisation steps.
I've submitted following change to correct it:
https://gerrit.zephyrproject.org/r/9571

Hope it helps.
This helps sample code works correctly. With that I can continue with my
target project, which is i2c driver for F411RE.

Can you point me to information how I should approach adding i2c driver
for this board ?

I assume first I should familiarize myself with Zephyr documentation and
contribution guidelines, but have you got any reference code for i2c
driver ?

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com


Re: Any plan for OTA support?

Carles Cufi
 

Hi Linh,

I was actually asking myself the same question recently. I think Linaro has started working on making the Mynewt bootloader usable with Zephyr, but that is only the first step I assume.

Also, to add a bit to your question, are there plans for IP-based OTA only, or is “regular” BLE OTA support also planned? By regular I mean similar to the proprietary solutions that vendors offer today, where one can update the firmware using only GATT, without requiring IPSP or LE Connection-Oriented Channels.

Thanks,

Carles

From: nvl1109(a)gmail.com [mailto:nvl1109(a)gmail.com]
Sent: Saturday, January 14, 2017 15:43
To: devel(a)lists.zephyrproject.org <devel(a)lists.zephyrproject.org>
Subject: [devel] Any plan for OTA support?

Hi all,

Do you have any plans to support OTA framework on Zephyr?

Thank & Regards,
Linh Nguyen


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 7
[ZEP-1577] Add support for the Arduino Ethernet Shield V2
https://jira.zephyrproject.org/browse/ZEP-1577

[ZEP-1576] Simple Network Time Protocol support
https://jira.zephyrproject.org/browse/ZEP-1576

[ZEP-1578] Kernel documentation still has TBD section
https://jira.zephyrproject.org/browse/ZEP-1578

[ZEP-1579] external links to zephyr technical docs are broken
https://jira.zephyrproject.org/browse/ZEP-1579

[ZEP-1575] Getting warning messages due to Macro SYS_LOG_DOMAIN defined in bmi160.h file
https://jira.zephyrproject.org/browse/ZEP-1575

[ZEP-1573] net/tcp: User provided data in net_context_recv is not passed to callback
https://jira.zephyrproject.org/browse/ZEP-1573

[ZEP-1580] broken links on zephyrproject.org/doc need a nice 404 error page response
https://jira.zephyrproject.org/browse/ZEP-1580


UPDATED JIRA items within last 24 hours: 12
[ZEP-1457] Add SPDX Tags to Zephyr licence boilerplate
https://jira.zephyrproject.org/browse/ZEP-1457

[ZEP-1474] BLE Connection Parameter Request/Response Processing
https://jira.zephyrproject.org/browse/ZEP-1474

[ZEP-810] Network Time Protocol v4
https://jira.zephyrproject.org/browse/ZEP-810

[ZEP-820] HTTP v1.1 Server Sample
https://jira.zephyrproject.org/browse/ZEP-820

[ZEP-795] Path MTU Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-795

[ZEP-1554] Xtensa integration
https://jira.zephyrproject.org/browse/ZEP-1554

[ZEP-1557] RISC V Port
https://jira.zephyrproject.org/browse/ZEP-1557

[ZEP-1571] Update "Changes from Version 1 Kernel" to include a "How-To Port Apps" section
https://jira.zephyrproject.org/browse/ZEP-1571

[ZEP-852] SPI API Update
https://jira.zephyrproject.org/browse/ZEP-852

[ZEP-1558] Support of user private data pointer in Timer expiry function
https://jira.zephyrproject.org/browse/ZEP-1558

[ZEP-1532] Wrong accelerometer readings
https://jira.zephyrproject.org/browse/ZEP-1532

[ZEP-1574] Samples/net/dhcpv4_client: Build fail as undefined reference to `net_mgmt_add_event_callback'
https://jira.zephyrproject.org/browse/ZEP-1574


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0

5801 - 5820 of 8032