Date   

Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 19, 2017, at 8:57 AM, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> wrote:

On 19 January 2017 at 14:52, Johan Hedberg <johan.hedberg(a)intel.com> wrote:
Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus
Not having much luck there, but its possible I’m missing something obvious because of lack of sleep:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:24:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:388:33: error: expected ')' before 'PRIu32'
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
^

Here’s what BT_ERR looks like:
BT_ERR("Required RAM size: %" PRIu32 ", supplied: %u.", err,
sizeof(_radio));


- k


Re: uint32_t typedef differences causes issues

Johan Hedberg
 

Hi Marcus,

On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.

Johan


Re: uint32_t typedef differences causes issues

Kumar Gala
 

On Jan 19, 2017, at 8:52 AM, Johan Hedberg <johan.hedberg(a)intel.com> wrote:

Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
away.

Johan
Thought that myself, but with %u you get:

In file included from /home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:23:0:
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]
BT_ERR("Required RAM size: %u, supplied: %u.", err,


- k


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

On 19 January 2017 at 14:52, Johan Hedberg <johan.hedberg(a)intel.com> wrote:
Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct specifier is:
PRIu32

e.g.
#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);

Cheers
/Marcus


Re: uint32_t typedef differences causes issues

Johan Hedberg
 

Hi Kumar,

On Thu, Jan 19, 2017, Kumar Gala wrote:
It looks like newlib and our mini libc define uint32_t differently and
this causes issues with the printf format warning from gcc. We get
things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the
build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd
party pre-built toolchains
The right format specifier for unsigned integers is %u and not %d, so as
far as I see that's the issue and using %u should make the error go
away.

Johan


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi,

[Second attempt at responding, my arm email address seems to have
triggered a moderator approval, sorry about the duplication for those
of you that got a direct reply.]

This is because the code is using the wrong format specifier, see
JIRA-1181 https://jira.zephyrproject.org/browse/ZEP-1181

Cheers
/Marcus

On 19 January 2017 at 14:41, Kumar Gala <kumar.gala(a)linaro.org> wrote:
It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd party pre-built toolchains

- k


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <Marcus.Shawcroft@...>
 

On 19 Jan 2017, at 14:41, Kumar Gala <kumar.gala(a)linaro.org> wrote:

It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned intuint32_t;

Mini libc:

typedef unsigned intuint32_t;

So wondering if we should change mini-libc to match and fix up all the build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd party pre-built toolchains

- k
Hi, This is because the code is using the wrong format specifier, see JIRA-1181

Cheers
/Marcus
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


uint32_t typedef differences causes issues

Kumar Gala
 

It looks like newlib and our mini libc define uint32_t differently and this causes issues with the printf format warning from gcc. We get things like:

/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c: In function 'hci_driver_open':
/home/galak/git/zephyr-project/subsys/bluetooth/controller/hci/hci_driver.c:387:10: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t {aka long unsigned int}' [-Werror=format=]

As newlib

typedef long unsigned int uint32_t;

Mini libc:

typedef unsigned int uint32_t;

So wondering if we should change mini-libc to match and fix up all the build issues associated with this?

Other ideas? Concern that fixing newlib will have issues w/other 3rd party pre-built toolchains

- k


Re: Any plan for OTA support?

Carles Cufi
 

Hi David,

If I’m not mistaken the Mynewt bootloader includes support for serial “DFU” (more like app image management and transfer). Are you planning to port that as well as part of the mcuboot project? The reason I ask is that there have been some conversations regarding the future protocol that will be used to provide DFU over the different transports (serial, USB, BLE, 15.4, etc) and it would be good to know if you have taken any sort of decision in this regard.
If I’m not mistaken the serial code in the Mynewt bootloader uses parts of what’s called the Newt management protocol currently, so it’d be interesting to know if you plan to incorporate that into the project.
Also could you confirm that the mcuboot image will only be able to be overwritten using debug pins? (i.e. no DFU, OTA or otherwise of the bootloader itself).

Thanks,

Carles

From: David Brown [mailto:david.brown(a)linaro.org]
Sent: Wednesday, January 18, 2017 19:32
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>; nvl1109(a)gmail.com; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Any plan for OTA support?

We are working on the Mynewt bootloader (which is going to be its own project, called mcuboot). I have the OTA update as something that needs to be done, but I'm not aware of currently plans to implement anything.

David

On Sat, Jan 14, 2017 at 12:10 PM Cufi, Carles <Carles.Cufi(a)nordicsemi.no<mailto:Carles.Cufi(a)nordicsemi.no>> wrote:
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> [mailto:nvl1109(a)gmail.com<mailto:nvl1109(a)gmail.com>]
Sent: Saturday, January 14, 2017 15:43
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org> <devel(a)lists.zephyrproject.org<mailto: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


Re: [RFC]DMA API Update

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

On Wed, 2017-01-18 at 23:15 +0000, Liu, Baohong wrote:
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]

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).
The DMA driver should have configuration entries for setting these parameters and
the values of these configurations should be determined and set by an app level
prj.conf, not by the SPI or DMA driver
So, when I add DMA support to my uart, everyone project that uses a
UART, or device attached through a UART, needs know the magic device
specific configuration required and add it their prj.conf?

E.g, to run the Zephyr UART tests I edit tests/drivers/uart/prj.conf
to add the DMA slot, handshaking polarity, etc., that are used for the
UART + DMA driver combination on the device I'm interested in?

Does prj.conf support #includes? That way we could at least provide an
include files per SoC for people to include to get all this config. Then
again, if we did that, why not just add the config direct to the SoC
defconfig? Or even better, just add it to SoC headers files like IRQ
assignments and device addresses? At least that way this SoC specific
knowledge is more together in one place. Currently it's spread between
SoC and board files, and leaking into device drivers, and now starting
to push some of it into project files as well seems like completely the
wrong direction to take.

--
Tixy


[USB] composite device

Alexey Belyaev <BeliaevAV@...>
 

Hello, is anybody tried to realize composite USB-device? Any hints? Examples?
Thank you.


Re: Suggestions for getting started

Kumar Gala
 

On Jan 18, 2017, at 12:29 PM, Abhinav Misra <abhitheextremeeng(a)gmail.com> wrote:

Hi All,

Hope everybody is doing well.

I recently joined the zephyr devel mailing list and going through the documentation and other starters stuffs as being new to open source development.

I want to contribute to the project.Please suggest me some ways how to get started and on to which things to focus on.

I have following boards - :
1. Beagle bone black
2. STM32 discovery board
3. TI's MSP432

Any type of suggestion and help would be much appreciated.

Regards,
Abhinav
Which STM32 discovery board do you have, this is possibly the best starting point to try and get zephyr up and running.

What kinda of work or code have you developed in the past? Any particular area of interest?

- k


Re: [RFC]DMA API Update

Liu, Baohong
 

From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Monday, January 16, 2017 7:16 AM
Subject: Re: [devel] [RFC]DMA API Update

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.
The DMA API can be used by drivers for DMA operations


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

?
IMO, ideally the SPI driver should call the DMA API to implement the DMA support.
However, I think this is up to the driver to decide to use the DMA API or to utilize a
HAL driver it depends on


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?
Either one is fine.


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).
The DMA driver should have configuration entries for setting these parameters and
the values of these configurations should be determined and set by an app level
prj.conf, not by the SPI or DMA driver


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.
The current API dma_channel_config can support this; when the channel is being used by
a driver, if another driver calls the dma_channel_config API, the API should return an
specific error code indicating the channel is not ready to be used.

--
Tixy


Re: [RFC]DMA API Update

Liu, Baohong
 

From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Wednesday, January 18, 2017 3:31 AM
Subject: Re: [devel] [RFC]DMA API Update

On Wed, 2017-01-18 at 01:14 +0000, Liu, Baohong wrote:
-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]
?

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?
What you said is the scenario of driver over driver. There are
existing examples In Zephyr.
Just to clarify my previous answer which is meant to say that there are existing
usage cases a driver use API from another driver. (e.g some sensor drivers uses
I2C driver API)

For the channel assignment, I think this should be decided and set by an app level
Prj.conf, not by driver Kconfig.


Where? I can only assume you have in mind the things in
ext/hal/qmsi/drivers which is only occurrence of DMA in the Zephyr tree I
can find. Those drivers look hard coded for use on a single SoC and have
driver specific APIs for DMA, and nothing in-tree uses those APIs.

Also, there is no app in-tree that actually uses DMA apart from
test_loop_transfer which just does a simple memory-to-memory DMA test.

If the idea is that people should follow the Quark example, then it looks to
me that your saying DMA support in drivers is something everyone has to
design for themselves on a per-driver basis? If so, there'll be no API
consistency between drivers and every app will be hard coded to a particular
set of drivers.

But I can't believe that is what is intended, so I must have mis- understood
something fundamental.
The DMA API is designed to solve that; ideally app or drivers should all use the DMA
API to implement DMA support

--
Tixy


Re: [RFC]DMA API Update

Tseng, Kuo-Lang
 

Baohong,

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 17, 2017 4:52 PM


Hi everyone,

Based on the feedbacks, I updated the RFC.
[...]

/**
* @brief DMA channel configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW
specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-memory to
peripheral,
* 2-peripheral to memory ...
* complete_int_en [ 10 ] --completion interrupt enable
* block_int_en [ 11 ] --block completion interrupt enable
* source_int_en [ 12 ] --source completion interrupt enable
* dest_int_en [ 13 ] --destination completion interrupt
enable
* error_int_en [ 14 ] --error interrupt enable
* source_handshake [ 15 ] --HW or SW
* dest_handshake [ 16 ] --HW or SW
I thought the original idea (from ZEP-873) was to minimize the dma_channel_config
structure by removing SoC or driver specific entries like the handshake interface
above which may not be common in other DMA engines. IMO, those should be kept
inside the driver and not to be exposed in API.

Kuo


SSH on Galileo

Fábio Iaione <fabio.iaione at gmail.com...>
 

Dear Sirs,
Does Zephyr have SSH support?
Thank you.


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

Christer Weinigel
 

Hi Erwan,

well, it wasn't too hard. Almost everything is already implemented in
the STM Cube drivers and only a little bit of glue code was needed.

I've only implemented the functions needed by the cdc_acm driver so
other higher level drivers such as mass storage will probably not work.
It's not very heavily tested and might contain race conditions that will
show up under load. But it's a start.

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

Even if this driver doesn't break down under load, performance will suck
due to the way I've implemented the usb_dc_ep_read function. The upper
layers expect the usb_dc_read function to return data immediately while
the STM32 Cube HAL_PCD_EP_Receive function only starts a read and data
will not be available until HAL_PCD_DataOutStageCallback is called by
the HAL. The way I have worked around this for the moment is to have an
extra packet buffer in the usb_dc_stm driver that HAL_PCD_EP_Receive
reads into, and then when usb_dc_ep_read is called data from this buffer
is copied to higher level driver. In the case of cdc_acm driver, this
will be done 4 bytes at a time, and then the data in the cdc_acm buffer
is copied to yet another buffer one byte at a time and when data is read
from the serial buffer it's copied again.

To get decent performance out of the STM32 Cube drivers all higher level
drivers ought to split usb_dc_ep_read into a usb_dc_ep_start_read and a
usb_dc_ep_get_read_count function so that it matches what the HAL layer
does. It's a bit painful, but shouldn't be that hard.

If the higher level driver is also aware of USB packet boundaries and
alighment this could also allow DMA directly into the driver buffers for
hardware (such as the STM32F4xx) that supports it.

/Christer

On 2017-01-16 11:31, Erwan Gouriou wrote:
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
<mailto: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: Any plan for OTA support?

David Brown
 

We are working on the Mynewt bootloader (which is going to be its own
project, called mcuboot). I have the OTA update as something that needs to
be done, but I'm not aware of currently plans to implement anything.

David

On Sat, Jan 14, 2017 at 12:10 PM Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
wrote:

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



Suggestions for getting started

Abhinav Misra
 

Hi All,

Hope everybody is doing well.

I recently joined the zephyr devel mailing list and going through the
documentation and other starters stuffs as being new to open source
development.

I want to contribute to the project.Please suggest me some ways how to get
started and on to which things to focus on.

I have following boards - :
1. Beagle bone black
2. STM32 discovery board
3. TI's MSP432

Any type of suggestion and help would be much appreciated.

Regards,
Abhinav


Re: RFC: ieee802154 radio api

Tomasz Bursztyka
 

Hi Johann,


int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
What's the use case for it?
It would be turned off by default (return -ENOTSUPP). It is useful for
commissioning the hardware and is required for the test during the CE
or FCC certification. Of course, there are tools from the
manufacturers for it, but they are usually not so nice and they are
almost always bound to an OS, which I do not want to use. Natively
implemented, it is also useful in driver development, e.g. to check
whether PLL was set correctly after the channel was switched or to
test CCA :-). Mostly only four modes are useful: Idle, continues RX,
carrier wave, PRBS9. It must be clearly marked that it is only for
testing.
Isn't this kind of test made out of any 15.4 network? (i.e.: does it
require L2? I don't think so).
No, it just for the PHY (RF Testing, simular to BT DTM, e.g.
DTM_PKT_PRBS9 or CARRIER_TEST ...). It would also needs a shell command.
Ok sound like it could use the actual RAW use of the driver.

So you would need 2 function:

- one returning the supported modes

- one running the test with requested mode as you proposed.

this would be exposed only on Kconfig option condition.


Br

Tomasz

5541 - 5560 of 7817