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.

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

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

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

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

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

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

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

Baohong,

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

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

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

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

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

Hi Erwan,

On 2017-01-17 13:38, Erwan Gouriou wrote:

I agree with the observation that gpio/pinmux configuration is
overcomplicated.
Your proposal is interesting and look rather easy to use.
Maybe you can also have a look to Adam's porting of STM32F3x family, in
which
he's trying to by pass pin configuration this in another way:
https://gerrit.zephyrproject.org/r/#/c/9701

It looks quite similar, if I understood this correctly, he's also added
some macros to combine the pull up/pull down/function with the alternate
function in one word:

https://gerrit.zephyrproject.org/r/#/c/9325/19/drivers/pinmux/stm32/pinmux_stm32.h

Although I think it's nicer to do what I did and put the pin information
in drivers/pinmux/stm32/pinmux_stm32f4.h since it puts everything in one
file.

Other than that it looks like a nice patchset to add support for the
STM32F3xx family.

After thinking a bit more about this, I'm actually not too fond of magic
macros like my STM32F4_PINMUX_ENCODE. Sometimes abstractions can be
nice, but in this case I actually thinks that it obscures more than it
helps. I would actually prefer to change the defines to have the a
shift built in, that is change the stm32f4x_pin_config_mode enum to defines:

#define STM32F4X_PIN_CONFIG_AF_PUSH_MASK (15 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_PULL (0 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_UP (1 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_DOWN (2 << 8)
...
STM32F4X_PIN_CONFIG_ANALOG (15 << 8)

so that the defines in pinmux_stm32.h can be a bit more explicit not
have to use the STM32F4_PINMUX_ENCODE macro:

#define STM32F4_PINMUX_FUNC_PA9_USART1_TX
(STM32F4X_PIN_CONFIG_AF_PUSH_UP | STM32_PINMUX_FUNC_ALT_7)

this also allows more flexibility, we're no longer limited to just two
axes of parameters. For example AF_PUSH_UP actually combines three
different settings. We can split that into MODE_AF, PULL_UP and
OTYPE_PUSH_PULL:

#define STM32F4X_PIN_MODE_MASK (3 << 8)
#define STM32F4X_PIN_MODE_INPUT (0 << 8)
#define STM32F4X_PIN_MODE_OUTPUT (1 << 8)
#define STM32F4X_PIN_MODE_AF (2 << 8)
#define STM32F4X_PIN_MODE_ANALOG (3 << 8)

#define STM32F4X_PIN_PULL_MASK (3 << 10)
#define STM32F4X_PIN_PULL_NONE (0 << 10)
#define STM32F4X_PIN_PULL_UP (1 << 10)
#define STM32F4X_PIN_PULL_DOWN (2 << 10)

#define STM32F4X_PIN_OTYPE_MASK (1 << 12)
#define STM32F4X_PIN_OTYPE_PUSH_PULL (0 << 12)
#define STM32F4X_PIN_OTYPE_OPEN_DRAIN (1 << 12)

and for completeness we could also expose the speed settings:

#define STM32F4X_PIN_SPEED_MASK (3 << 13)
#define STM32F4X_PIN_SPEED_LOW (0 << 13)
#define STM32F4X_PIN_SPEED_MEDIUM (1 << 13)
#define STM32F4X_PIN_SPEED_FAST (2 << 13)
#define STM32F4X_PIN_SPEED_HIGH (3 << 13)

The above pin definition would look like this:

#define STM32F4_PINMUX_FUNC_PA9_USART1_TX (STM32F4X_PIN_FUNC_AF |
STM32F4X_PIN_PULL_UP | STM32_PINMUX_FUNC_ALT_7)

It's a bit more verbose, but it's obvious what it does, especially if
you look at the corresponding definitions in the data sheet since this
is how the hardware registers look.

If we do this we can rip out stm32_get_pin_config completely and also
simplify the __func_to_foo functions in soc_gpio.c

It might also be a good idea to unify these defines between STM32
families. If I recall correctly many STM32F1xx, STM32F2xx and STMF4xx
packages are mostly pin compatible. The same PCB could have a STM32Fxx
or STM32F4xx MCU mounted on it (with a zero ohm resistor or capacitor to
account for any differences between them) and it would be nice if they
could use the same board file.

Some functions might not be supported on all families, for example, I
don't think the STM32F1xx can have a pull-up/pull-down at the same tie
as a pin is an output or alternate function, but that shouldn't be problem.

Btw, I think that you could submit your RFC as a patch in Gerrit, so we can
better appreciate the differences and comment easily.

I'll see if I can clean up my ideas and push a few patches for review in
gerrit.

/Christer

Hi Tomasz,

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.

--
Best Regards,
Johann Fischer

Hi Oliver,

On Wed, Jan 18, 2017 at 09:57:15AM +0100, Tomasz Bursztyka wrote:

For example, if the hardware can automatically perform CCA before the TX
sequence (IEEE802154_HW_LBT is set), the linklayer does not have to call
the API function int (*cca)(struct device *dev);

No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time, it's
cost-less.

<snip>

- IEEE802154_HW_LBT (listen before transmit or CCA before TX)

Always enable it if the hw supports it, at built time.

Not sure, I understand you correctly here, but some transceivers (e.g. the
at86rf2xx) does not allow you to perform manual CCA if automatic CCA is
enabled.

Good to know. Does it behave like that because it can do some/all of the
CSMA job directly?
For now I'd say disable auto-CCA in driver by default, then.

Basically manual CCA is meant for the fully soft-CSMA radio strategy,
as it is right now.
If only auto-cca does not mess up with the manual one, then keep it enabled.

But soon, we'll have to figure out a way to hand-over CSMA parts to
relevant hw that can
do it.

- IEEE802154_HW_FRAME_RETRIES

Up to the driver to handle it. L2 does not have to care about it.

What if the MAC needs full control over L2 retransmissions (e.g. in a TDMA
MAC).

Hum, MAC and L2 in our case is the same. What I call L2 here is
ieee802.15.4 soft-MAC L2 stack.
See subsys/net/ip/l2/ieee802154/

Anyway, TDMA is not part of IEEE 802.15.4 <= 2011, so we can put it aside.

In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)

Always enable it if the hw supports it.

Same as above. For some MAC protocols (e.g. IEEE 802.15.4 TSCH mode) this is
not a viable solution.

TSCH is for IEEE 802.15.4 >= 2012. So at this point we can put it aside.

Or is your point only about setting these capabilities at runtime? Is it still
possible to disable these flags at compile time?

We had autoack, and crc and all being disabled at compile time for a
while. But at this stage
it was just useless, so it got removed.


Br,

Tomasz

Hi Tomasz!

On Wed, Jan 18, 2017 at 09:57:15AM +0100, Tomasz Bursztyka wrote:

For example, if the hardware can automatically perform CCA before the TX
sequence (IEEE802154_HW_LBT is set), the linklayer does not have to call
the API function int (*cca)(struct device *dev);

No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time, it's
cost-less.

<snip>

- IEEE802154_HW_LBT (listen before transmit or CCA before TX)

Always enable it if the hw supports it, at built time.

Not sure, I understand you correctly here, but some transceivers (e.g. the
at86rf2xx) does not allow you to perform manual CCA if automatic CCA is
enabled.

- IEEE802154_HW_FRAME_RETRIES

Up to the driver to handle it. L2 does not have to care about it.

What if the MAC needs full control over L2 retransmissions (e.g. in a TDMA
MAC).

In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)

Always enable it if the hw supports it.

Same as above. For some MAC protocols (e.g. IEEE 802.15.4 TSCH mode) this is
not a viable solution.

Or is your point only about setting these capabilities at runtime? Is it still
possible to disable these flags at compile time?

Cheers,
Oleg

Hi Johann,

The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
- IEEE802154_HW_TX_OMIT_CKSUM

Is there any hw which is unable to do the chksum?
I made a patch on my local tree, to support software chksum on tx, and
rx. But as long as
there is no hw supporting it: I won't post it.

ok I agree. What bothers me is the IEEE802154_MTU of 127, the frame
length is 127 octets (including FCS field), should it not be 125?

It's a left-over. Just keep it that way. Drivers are setting the MTU to
125 mostly due to net buf. (it's possible to reserve header part, not
tail part, and that was generating issuse)
Up to the driver to not write the fcs into buffer's data. (L2 does not
care about it anyway).
And anyway driver don't push bigger frames than what they are supposed
to, so the check in frame is really superfluous.

int (*set_cca_mode)(struct device *dev, ...),

int (*set_cca_threshold)(struct device *dev, int32_t level),

Not convinced to expose these 2.

It makes a difference what CCA mode the HW uses. It should be
prescribed somewhere or the L2 sets it to runtime.
For the threshold, the default value of the PHY may be ok.

int (*set_promiscuous_mode)(struct device *dev, bool on),

Ok on that one. But it should be built time set feature.

You mean the timestamps should be inserted by the driver?

No I mean the promiscuous feature should be Kconfig set, and disabled by
default.

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


Br,

Tomasz

Hi Tomasz,

For example, if the hardware can automatically perform CCA before the
TX sequence (IEEE802154_HW_LBT is set), the linklayer does not have to
call the API function int (*cca)(struct device *dev);

No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time,
it's cost-less.

Ok, then I will implement the cca function, which then execute a
standalone CCA.

The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
- IEEE802154_HW_TX_OMIT_CKSUM

Is there any hw which is unable to do the chksum?
I made a patch on my local tree, to support software chksum on tx, and
rx. But as long as
there is no hw supporting it: I won't post it.

ok I agree. What bothers me is the IEEE802154_MTU of 127, the frame
length is 127 octets (including FCS field), should it not be 125?

- IEEE802154_HW_LBT (listen before transmit or CCA before TX)

Always enable it if the hw supports it, at built time.

> ...

ok

int (*set_cca_mode)(struct device *dev, ...),

int (*set_cca_threshold)(struct device *dev, int32_t level),

Not convinced to expose these 2.

It makes a difference what CCA mode the HW uses. It should be prescribed
somewhere or the L2 sets it to runtime.
For the threshold, the default value of the PHY may be ok.

int (*set_promiscuous_mode)(struct device *dev, bool on),

Ok on that one. But it should be built time set feature.

You mean the timestamps should be inserted by the driver?

int (*set_hw_addr_filt)(struct device *dev, ...),

That one we are missing yes. So it could be used once neighbors are
detected etc...
But it means improving nbr management also. It's really not the biggest
feature missing
right now.

ok

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.

For now I don't see much point for exposing capabilities, besides maybe
the autoack one but I want
a real hw example that does not support it first. (pushing awai the
newer specs for now).

Point is, all drivers are exposing the same API. For instance, if it
does not support promiscuous mode, then
it sets the relevant api function pointer to NULL. If the user asks "set
promiscuous" (let's say through the 15.4 shell),
l2 verify that and return -ENOTSUPP accordingly. No need of any flag here.
Same for hw filtering etc etc... There is no need of checking any flag
at anytime.

ok, got it :-)

Br,

Tomasz

--
Best Regards,
Johann Fischer