Date   

Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Boie, Andrew P
 

On Thu, 2016-03-10 at 01:49 +0000, Nashif, Anas wrote:
 
I
share Dan's concerns, I think it may be better to have st_stm32/
SoC and
then subdirectories with variants thereof, with common code at the
toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.
This the design as we have now (and it was proposed and discussed).
Of course, but I don't know if at the time we were thinking about
supporting a bunch of variants of a particular microcontroller that are
almost the same. I think this is an opportunity for iterative
refinement.

Under soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to
change this across the board and not only for STM32.
My train of thought was that if there are closely related variants of a
SoC/MCU, then subdirectories would be appropriate for them. I don't
think another layer would be a requirement for every board. For
something like atmel_sam3 the variant and the soc would be the same
value: SOC=atmel_sam3 SOC_VARIANT=atmel_sam3

It might also be useful to use a diffrent word than "soc" as the term
for the second level under arch, maybe a term that could apply to MCU
or SOC. We shouldn't feel rigidly bound by this hierarchy, just when it
makes sense to do so (i.e. a bunch of variants that are very very
similar which I believe is the case here)

arch/arm/soc/
frdm_k64f/
<code for frdm_k64f>
atmel_sam3/
<code for atmel_sam3>
st_stm32/
<common code for all st_stm32 variants>
st_stm32f1/
<stm32f1-specific bits>
st_stm32f2/
<stm32f2-specific bits>
....


Andrew


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 5:49 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>
Cc: users(a)lists.zephyrproject.org; maciek.borzecki(a)gmail.com;
devel(a)lists.zephyrproject.org; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Subject: Re: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow.
Seems
like an easy fix.
Yes, the only different from what you have right now is having 1 level
less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to create a larger
mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to
enforce maximum sharing between MCUs where possible. For example, the
stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving
this into an upper level "common" area, not only makes it difficult to find, it
just creates confusion as we add in future platforms.

Do we need another layer of abstraction in the build for SoC variants?
Where did you see a new layer in what I said? The current patch and adding
st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture
(just like there is STM8) that has different variants (M0+, M3, M4, …) that
have additional SoCs. st_stm32 is something comparable to Quark from x86.
So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board
You're confusing me now. Please state your objection to the proposed method clearly here.


I
share Dan's concerns, I think it may be better to have st_stm32/ SoC and
then subdirectories with variants thereof, with common code at the
toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.
This the design as we have now (and it was proposed and discussed). Under
soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to change
this across the board and not only for STM32.
Correct. That would be step #2.


Re: [RFC] Sensor API

Vlad Dogaru <vlad.dogaru@...>
 

Hello,

I have uploaded another iteration of the sensor API patches on Gerrit [1].
This addresses some minor issues that have been raised this week and
also ports another driver, the SX9500 SAR proximity.

There is also an API change: previously, there were two functions for
reading a channel. One operated on a sensor_value, in the interest of
avoiding floating point operations, while the other used floating point.
I folded these two functions into a single one and there is now a
SENSOR_TYPE_DOUBLE to indicate that the structure actually contains a
valid floating point value. The sensor_value structure now includes a
union to accomodate this case.

Documentation has also been updated, the most significant change being
that each channel now has a comment specifying the unit of measurement.

At the moment I feel that the API, infrastructure and two drivers are
ready to be merged, unless there are more comments, of course.

If everything is on track, we will start porting the other drivers [2]
to this iteration of the API.

[1]
https://gerrit.zephyrproject.org/r/487 Introduce new sensor API
https://gerrit.zephyrproject.org/r/488 Add infrastructure for sensor drivers
https://gerrit.zephyrproject.org/r/489 sensor: Add driver for MCP9808 temperature sensor
https://gerrit.zephyrproject.org/r/490 samples: Add sample app for MCP9808 sensor
https://gerrit.zephyrproject.org/r/541 sensor: Add threshold trigger support for MCP9808
https://gerrit.zephyrproject.org/r/491 sensor: Add sx9500 SAR proximity driver
https://gerrit.zephyrproject.org/r/492 samples: Add sample app for sx9500 sensor driver

[2] https://gerrit.zephyrproject.org/r/#/q/topic:sensors


Thanks,
Vlad


something wrong into drivers/spi/spi_k64.c line 204.

Chény, Yves-Gael <yves at cheny.fr...>
 

Hi,
i just read the source code of zephyr.

I have found an error into :

drivers/spi/spi_k64.c
line 204, baud_rate_prescaler is use instead of baud_rate_scaler (causes an out of bound )


regards,
Yves-Gael <hurdman> Chény.


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Nashif, Anas
 

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow. Seems
like an easy fix.
Yes, the only different from what you have right now is having 1 level less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to create a larger mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to enforce maximum sharing between MCUs where possible. For example, the stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving this into an upper level "common" area, not only makes it difficult to find, it just creates confusion as we add in future platforms.
Do we need another layer of abstraction in the build for SoC variants?
Where did you see a new layer in what I said? The current patch and adding st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture (just like there is STM8) that has different variants (M0+, M3, M4, …) that have additional SoCs. st_stm32 is something comparable to Quark from x86. So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board

I
share Dan's concerns, I think it may be better to have st_stm32/ SoC and
then subdirectories with variants thereof, with common code at the
toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.
This the design as we have now (and it was proposed and discussed). Under soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-architectures. If you think we need another layer, then we need to change this across the board and not only for STM32.


Anas




--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Boie, Andrew P
 

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow. Seems
like an easy fix.
Yes, the only different from what you have right now is having 1 level less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to create a larger mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to enforce maximum sharing between MCUs where possible. For example, the stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving this into an upper level "common" area, not only makes it difficult to find, it just creates confusion as we add in future platforms.
Do we need another layer of abstraction in the build for SoC variants? I
share Dan's concerns, I think it may be better to have st_stm32/ SoC and
then subdirectories with variants thereof, with common code at the
toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.

--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 1:23 PM
To: Maciek Borzecki <maciek.borzecki(a)gmail.com>
Cc: devel(a)lists.zephyrproject.org; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>; users(a)lists.zephyrproject.org
Subject: Re: [users] Re: [devel] Re: Re: Re: Re: STM32F103x port


Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow. Seems
like an easy fix.
Yes, the only different from what you have right now is having 1 level less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to create a larger mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to enforce maximum sharing between MCUs where possible. For example, the stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving this into an upper level "common" area, not only makes it difficult to find, it just creates confusion as we add in future platforms.


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Nashif, Anas
 

On 09/03/2016, 16:13, "Maciek Borzecki" <maciek.borzecki(a)gmail.com> wrote:

On Wed, Mar 9, 2016 at 6:54 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:
On 9 Mar 2016, at 09:48, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we would need to group all quarks under intel_quark.

Also, the st_ prefix is probably being used because we have ti_ and fsl_ for some of the existing SOCs. Maybe it is the right time now to drop the vendor part completely. (unrelated to this change, but we need to fix this with existing SOCs under arch/arm)

As more SOCs and boards are being added it is important to keep things consistent. The current structure allows adding a new SOC or board by just adding the files and structure and without changing any other files, we should keep it this way.
Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow. Seems
like an easy fix.
Yes, the only different from what you have right now is having 1 level less. I think everything else should stay the same.

Anas


Cheers,
--
Maciek Borzecki


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 9, 2016 at 6:54 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:
On 9 Mar 2016, at 09:48, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we would need to group all quarks under intel_quark.

Also, the st_ prefix is probably being used because we have ti_ and fsl_ for some of the existing SOCs. Maybe it is the right time now to drop the vendor part completely. (unrelated to this change, but we need to fix this with existing SOCs under arch/arm)

As more SOCs and boards are being added it is important to keep things consistent. The current structure allows adding a new SOC or board by just adding the files and structure and without changing any other files, we should keep it this way.
Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow. Seems
like an easy fix.

Cheers,
--
Maciek Borzecki


Re: Change in coding style.

Boie, Andrew P
 

On Wed, 2016-03-09 at 14:35 -0500, Benjamin Walsh wrote:
Not that big of a change for a lot of people, but I pushed a revision to
documentation yesterday that enforces a 8-char tabs/80 column coding
style.
+1 from me

--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center


Change in coding style.

Benjamin Walsh <benjamin.walsh@...>
 

Folks,

Not that big of a change for a lot of people, but I pushed a revision to
documentation yesterday that enforces a 8-char tabs/80 column coding
style. Basically, this makes our coding style the same as for Linux with
the _only_ exception being that we require braces around single-line
code blocks:

ie.

if (blah) {
do_the_blah();
}

and not:

if (blah)
do_the_blah();

Same for for, while, do..while, etc.

The rationale behind that change is that the coding style we had was
kinda impossible to police w.r.t. tabs and columns, since it was
allowing tabs of 4 and 8, and columns of 80 and 100.

And the rationale for the choice of 8 vs 4 tabs is that we think
contributors will be used to that since we expect a non-negligible
amount of them to come from a Linux kernel background.

Cheers,
Ben

--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Nashif, Anas
 

On 9 Mar 2016, at 09:48, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
Maybe I was misunderstood in my email about the structure. I was suggesting to move the SoCs directly under soc/ and ski[ the st_stm32 level. If we are to do things the same way across architecture we would need to group all quarks under intel_quark.

Also, the st_ prefix is probably being used because we have ti_ and fsl_ for some of the existing SOCs. Maybe it is the right time now to drop the vendor part completely. (unrelated to this change, but we need to fix this with existing SOCs under arch/arm)

As more SOCs and boards are being added it is important to keep things consistent. The current structure allows adding a new SOC or board by just adding the files and structure and without changing any other files, we should keep it this way.



Anas


https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO
registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/698 arch: arm: move nmi to common
location
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board

Cheers,


Re: STM32F103x port

Tomasz Bursztyka
 

Hi Daniel,
Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
Depending upon others input, I think this is ready to go.

https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
I'm still toying with the idea that this could be made more generic to work for all STM32 boards. Looking for general mailing list input on this.

Would it be better to accept what Maciek has right now that works on STM32F1 and then submit a follow up patch to make it generic for all STM32 MCUs? Or should we focus on getting a generic interface for all STM32 on the first pass?
Maybe we can move on with current patches yes.

Tomasz


Re: STM32F103x port

Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, March 9, 2016 6:48 AM
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>; Walsh, Benjamin (Wind
River) <benjamin.walsh(a)windriver.com>; Brandewie, Dirk J
<dirk.j.brandewie(a)intel.com>; devel(a)lists.zephyrproject.org;
users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: Re: STM32F103x port

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.
Yeah I saw that this morning and was a little confused until I saw what was going on.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
Depending upon others input, I think this is ready to go.

https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
I'm still toying with the idea that this could be made more generic to work for all STM32 boards. Looking for general mailing list input on this.

Would it be better to accept what Maciek has right now that works on STM32F1 and then submit a follow up patch to make it generic for all STM32 MCUs? Or should we focus on getting a generic interface for all STM32 on the first pass?

https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO
registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
I was mid-review of this yesterday... so I haven't gotten to the lower group yet.

https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/698 arch: arm: move nmi to common
location
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board

Cheers,
--
Maciek Borzecki


Re: STM32F103x port

Maciek Borzecki <maciek.borzecki@...>
 

Hi,

I've pushed another set of updates. Hopefully I have not missed any
comments that were added to the previous versions.

I took the liberty of rebasing Daniel's patch on top of current
master, and so rebasing all of my patches on top of this one.

There are 2 major changes since the previous version.

One is extending of pinmux integration for STM32F1. That includes
structures that define alternate functions for IO pins plus some
helpers for selecting pin's function in a more convenient fashion.

The second change is adding UART_1 and UART_2 ports that map to USART2
and USART3 respectively.

Hopefully it'll be possible to merge at least some of these patches to
master.

Updated Changes:
https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce
STM32F1x SoC family
https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x:
introduce new driver for STM32F10x RCC
https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO
registers mapping
https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common
driver for STM32 pinmux
https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver
for STM32 UART
https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver
for STM32 GPIO
https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add
new board
https://gerrit.zephyrproject.org/r/653 samples/drivers/disco: add
'disco' sample program
https://gerrit.zephyrproject.org/r/698 arch: arm: move nmi to common
location
https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move
quark_se entries to separate file
https://gerrit.zephyrproject.org/r/712 clock_control: extend API
with clock rate query operation
https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement
GPIO support
https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement
STM32 pinmux integration
https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new
board

Cheers,
--
Maciek Borzecki


Re: [RFC] NULL callbacks in driver API

Tomasz Bursztyka
 

Hi,

static inline uint32_t pinmux_pin_input_enable(struct device *dev,
uint32_t pin,
uint8_t func)
{
struct pinmux_driver_api *api;

api = (struct pinmux_driver_api *) dev->driver_api;
__ASSERT(api->input, "%s not implemented", __func__);
return api->input(dev, pin, func);
}
Something like that yes, though I'd put empty lines in between ;)

Tomasz


Re: [RFC] NULL callbacks in driver API

Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 9, 2016 at 11:00 AM, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:
Hi Maciek,

An obligatory example:

<---- code --------->
struct pinmux_driver_api {
pmux_set set;
pmux_get get;
pmux_pullup pullup;
pmux_input input;
};
...

static inline uint32_t pinmux_pin_input_enable(struct device *dev,
uint32_t pin,
uint8_t func)
{
struct pinmux_driver_api *api;

api = (struct pinmux_driver_api *) dev->driver_api;

/* proposed enhacement */
if (!api->input) {
return DEV_NO_SUPPORT;
}

Note that on many API, some calls have a mandatory support (let's say
spi_transceive),
so such test would not have to be generalized.

What about a different approach:

Thing is, Zephyr is an OS for embedded platform thus the developer is really
close to the hw he is using.
Thus, he should know what's available in terms of drivers and, finally, what
features these drivers expose.

So, instead of multiplying such test, which will take some bytes here and
there.
We could do this test through __ASSERT(). The user, while testing its app
could enable the assert checks
and verify he is not using unsupported features. And he could fix his code
accordingly, then disable the asserts.
If I understood correctly what you're suggesting, the example code
could look like this:

static inline uint32_t pinmux_pin_input_enable(struct device *dev,
uint32_t pin,
uint8_t func)
{
struct pinmux_driver_api *api;

api = (struct pinmux_driver_api *) dev->driver_api;
__ASSERT(api->input, "%s not implemented", __func__);
return api->input(dev, pin, func);
}

Cheers,
--
Maciek Borzecki


Re: [RFC] NULL callbacks in driver API

Jesus Sanchez-Palencia <jesus.sanchez-palencia@...>
 

Hi,


On Wed, 9 Mar 2016 11:00:49 +0100
Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> wrote:

Hi Maciek,

An obligatory example:

<---- code --------->
struct pinmux_driver_api {
pmux_set set;
pmux_get get;
pmux_pullup pullup;
pmux_input input;
};
...

static inline uint32_t pinmux_pin_input_enable(struct device *dev,
uint32_t pin,
uint8_t func)
{
struct pinmux_driver_api *api;

api = (struct pinmux_driver_api *) dev->driver_api;

/* proposed enhacement */
if (!api->input) {
return DEV_NO_SUPPORT;
}
There was a thread before [1] about differing between an API not supported and an API not
implemented for a given driver implementation. This would be done by returning DEV_NOT_IMPLEMENTED
instead of DEV_NO_SUPPORT. DEV_NOT_IMPLEMENTED hasn't been added to device.h yet, but the idea got
a green light back then from what I can tell.

This RFC would block that, so we need to keep this in mind and re-visit that discussion.


Note that on many API, some calls have a mandatory support (let's say
spi_transceive),
so such test would not have to be generalized.

What about a different approach:

Thing is, Zephyr is an OS for embedded platform thus the developer is
really close to the hw he is using.
Thus, he should know what's available in terms of drivers and, finally,
what features these drivers expose.

So, instead of multiplying such test, which will take some bytes here
and there.
We could do this test through __ASSERT(). The user, while testing its
app could enable the assert checks
and verify he is not using unsupported features. And he could fix his
code accordingly, then disable the asserts.
+1 for this to be considered.

Cheers,
jesus

[1]
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/thread/ONIGOHXRQWFFEAP2UBURZV7IOSFPQH5F/#ONIGOHXRQWFFEAP2UBURZV7IOSFPQH5F


Re: [RFC] NULL callbacks in driver API

Tomasz Bursztyka
 

Hi Maciek,

An obligatory example:

<---- code --------->
struct pinmux_driver_api {
pmux_set set;
pmux_get get;
pmux_pullup pullup;
pmux_input input;
};
...

static inline uint32_t pinmux_pin_input_enable(struct device *dev,
uint32_t pin,
uint8_t func)
{
struct pinmux_driver_api *api;

api = (struct pinmux_driver_api *) dev->driver_api;

/* proposed enhacement */
if (!api->input) {
return DEV_NO_SUPPORT;
}
Note that on many API, some calls have a mandatory support (let's say
spi_transceive),
so such test would not have to be generalized.

What about a different approach:

Thing is, Zephyr is an OS for embedded platform thus the developer is
really close to the hw he is using.
Thus, he should know what's available in terms of drivers and, finally,
what features these drivers expose.

So, instead of multiplying such test, which will take some bytes here
and there.
We could do this test through __ASSERT(). The user, while testing its
app could enable the assert checks
and verify he is not using unsupported features. And he could fix his
code accordingly, then disable the asserts.

Not sure this would fit all uses case though, I might miss something.

Tomasz


[RFC] NULL callbacks in driver API

Maciek Borzecki <maciek.borzecki@...>
 

Hi,

I'd like to make a proposal for enhancement of driver API
callbacks, but before jumping to code I'd like to get some feedback first.

Right now, whenever a call to an API is made, we directly jump to call
the driver's implementation. This is ok for the general case, when we
know that every driver will implement all callbacks.

However, this approach has some downsides in my opinion and might
become an issue once the number of drivers grows or the APIs become
larger.

First of all, in practice, not every driver will be able to implement all
callbacks. It is my understanding that the API will cover only a subset
of common functionality. However, as an example, the PWM driver for
STM32 may not have an applicable method of setting phase. In such case,
the driver would provide a dummy callback returning DEV_NO_SUPPORT.

Secondly, the current approach requires that whenever an API is
augmented with a new callback, someone must track down all driver
implementations and add this dummy callback.

Once the errno patches hit master, we'll need to make sure that
dummy callbacks (if present) return proper error code.

Given that, I'm proposing to add checks whether the driver implements
given callback in the public API calls. This has some benefits. Firstly,
we'll always have a default code path. Someone working on a driver
does not have add a dummy implementation.

Secondly, this will help to enforce consistent return values for a
case when a device lacks certain feature/functionality. Lack of
callback may return DEV_NO_SUPPORT, or ENOSYS/ENOTSUP.

We can rely on static *_driver_api struct allocation, and just fill in
the blanks. This is important when adding new API calls. IIRC Linux
does that a lot.

Lastly, I believe that this will give a minimal size reduction if one
happens to use drivers with dummy callbacks.

An obligatory example:

<---- code --------->
struct pinmux_driver_api {
pmux_set set;
pmux_get get;
pmux_pullup pullup;
pmux_input input;
};
...

static inline uint32_t pinmux_pin_input_enable(struct device *dev,
uint32_t pin,
uint8_t func)
{
struct pinmux_driver_api *api;

api = (struct pinmux_driver_api *) dev->driver_api;

/* proposed enhacement */
if (!api->input) {
return DEV_NO_SUPPORT;
}

return api->input(dev, pin, func);
}
<------ code ------------->

A similar thing is also a part of clock_control API review:
https://gerrit.zephyrproject.org/r/#/c/712/

Cheers,
--
Maciek Borzecki

7521 - 7540 of 7821