Topics

STM32F103x port


Maciek Borzecki <maciek.borzecki@...>
 

Hi list,

I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is
hardcoded. The MCU is configured to use internal HSI clock source, with
PLL feeding a 36MHz clock to SYSCLK and AHB/APB (tried to make it board
agnostic). The minimal UART driver assumes that USART1 will be used with
a fixed speed of 9600kbps. The the best of my knowledge, this should be
enough as a starting point for porting to other boards.

The source code lives here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103 in
bboozzoo/stm32f103 branch.

Obligatory video: https://goo.gl/photos/AGhfXYvv8CswjRRu7 (sorry for the
background sound and overall potato quality). In the vide I flash the
firmware through STLink, the board resets and starts the hello world
sample. The output is received via a USB RS232 adapter. The sample
program has been also modified to print an increasing loop counter, just
to make sure we're not looping the same content.

If anyone feels like this is worth working on I might be able to try and
clean it up a little bit and push out to Gerrit (once I get my access
issues resolved). I also have a couple of boards with STM32F3xx and
STM32L4xx MCUs so I might give these a try, unfortunately all of these
are Cortex-M4 based.

Has anyone looked at ports to Cortex-M0?

Cheers,
--
Maciek Borzecki


Benjamin Walsh <benjamin.walsh@...>
 

Hi Maciek,

I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is
hardcoded. The MCU is configured to use internal HSI clock source, with
PLL feeding a 36MHz clock to SYSCLK and AHB/APB (tried to make it board
agnostic). The minimal UART driver assumes that USART1 will be used with
a fixed speed of 9600kbps. The the best of my knowledge, this should be
enough as a starting point for porting to other boards.

The source code lives here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103 in
bboozzoo/stm32f103 branch.

Obligatory video: https://goo.gl/photos/AGhfXYvv8CswjRRu7 (sorry for the
background sound and overall potato quality). In the vide I flash the
firmware through STLink, the board resets and starts the hello world
sample. The output is received via a USB RS232 adapter. The sample
program has been also modified to print an increasing loop counter, just
to make sure we're not looping the same content.

If anyone feels like this is worth working on I might be able to try and
clean it up a little bit and push out to Gerrit (once I get my access
issues resolved). I also have a couple of boards with STM32F3xx and
STM32L4xx MCUs so I might give these a try, unfortunately all of these
are Cortex-M4 based.
Very cool!

Cortex-M4 should work as well, since the M4 is a superset of the M3. The
first board we supported is the Freescale FRDM-K64F, which is an M4.

Has anyone looked at ports to Cortex-M0?
For M0, you have to do an arch port as well. The M3 arch port was done
by using a couple of features that are not available on M0, basically
BASEPRI for interrupt locking instead of PRIMASK and some Thumb2
instructions that are not available on M0.

That said, it might not be too hard to make the M3 arch M0-capable, we
just haven't had the time to look very deep into it.

Cheers,
Ben

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


Tomasz Bursztyka
 

Hi Maciek,

This is great stuff, it's totally worth working on porting Zephyr for STM32.

I actually recently got the Nucleo boards F103, F030 and F334 as I was
planning to
play with Zephyr on it. I'll try your branch on it and I'll take some
time to review it.
(as soon as I get some time)

M0, M0+, M4... all these are relevant for Zephyr I would say. I don't
know if anybody
is already working around though.

Br,

Tomasz

Hi list,

I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is
hardcoded. The MCU is configured to use internal HSI clock source, with
PLL feeding a 36MHz clock to SYSCLK and AHB/APB (tried to make it board
agnostic). The minimal UART driver assumes that USART1 will be used with
a fixed speed of 9600kbps. The the best of my knowledge, this should be
enough as a starting point for porting to other boards.

The source code lives here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103 in
bboozzoo/stm32f103 branch.

Obligatory video: https://goo.gl/photos/AGhfXYvv8CswjRRu7 (sorry for the
background sound and overall potato quality). In the vide I flash the
firmware through STLink, the board resets and starts the hello world
sample. The output is received via a USB RS232 adapter. The sample
program has been also modified to print an increasing loop counter, just
to make sure we're not looping the same content.

If anyone feels like this is worth working on I might be able to try and
clean it up a little bit and push out to Gerrit (once I get my access
issues resolved). I also have a couple of boards with STM32F3xx and
STM32L4xx MCUs so I might give these a try, unfortunately all of these
are Cortex-M4 based.

Has anyone looked at ports to Cortex-M0?

Cheers,


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

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Friday, February 26, 2016 8:07 AM
To: devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: [devel] STM32F103x port

Hi list,

I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is hardcoded.
The MCU is configured to use internal HSI clock source, with PLL feeding a
36MHz clock to SYSCLK and AHB/APB (tried to make it board agnostic). The
minimal UART driver assumes that USART1 will be used with a fixed speed of
9600kbps. The the best of my knowledge, this should be enough as a starting
point for porting to other boards.

Looks like you beat me to some of it. I have been slowly working on an STM32F2xx support. If you clean up your patches and submit to gerrit, much of the STM32F2xx patches can be easily integrated.


The source code lives here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103 in
bboozzoo/stm32f103 branch.

Obligatory video: https://goo.gl/photos/AGhfXYvv8CswjRRu7 (sorry for the
background sound and overall potato quality). In the vide I flash the firmware
through STLink, the board resets and starts the hello world sample. The
output is received via a USB RS232 adapter. The sample program has been
also modified to print an increasing loop counter, just to make sure we're not
looping the same content.

If anyone feels like this is worth working on I might be able to try and clean it
up a little bit and push out to Gerrit (once I get my access issues resolved). I
also have a couple of boards with STM32F3xx and STM32L4xx MCUs so I
might give these a try, unfortunately all of these are Cortex-M4 based.

Has anyone looked at ports to Cortex-M0?

Cheers,
--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

On Fri, Feb 26, 2016 at 5:39 PM, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:
Hi Maciek,

This is great stuff, it's totally worth working on porting Zephyr for STM32.

I actually recently got the Nucleo boards F103, F030 and F334 as I was
planning to
play with Zephyr on it. I'll try your branch on it and I'll take some time
to review it.
(as soon as I get some time)
The problem with the dev board that I used is that it's not really
available anymore. To the best of my knowledge, the unit I have is an
older version of this one:
https://kamami.pl/zestawy-uruchomieniowe-stm32/187712-eb-stm3206.html?search_query=stm32f103vet6&results=3
However, since there are some apparent differences in the pinout and
since I don't really have the schematics, I'll have to replace it with
something more usable. We have some Discovery (STM32F3, STM32F4) and
Nucleo (F030R8, maybe one F103) kits at the office, I guess one of
these will be my next target.

As for the code, there's really not much of it. I've typed in the
structs for RCC (Reset & Clock Control), GPIOs and UART register
mappings and wired that up.

BR,
--
Maciek Borzecki


Nashif, Anas
 

On Feb 26, 2016, at 11:08, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi list,

I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is
hardcoded. The MCU is configured to use internal HSI clock source, with
PLL feeding a 36MHz clock to SYSCLK and AHB/APB (tried to make it board
agnostic). The minimal UART driver assumes that USART1 will be used with
a fixed speed of 9600kbps. The the best of my knowledge, this should be
enough as a starting point for porting to other boards.

The source code lives here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103 in
bboozzoo/stm32f103 branch.

Obligatory video: https://goo.gl/photos/AGhfXYvv8CswjRRu7 (sorry for the
background sound and overall potato quality). In the vide I flash the
firmware through STLink, the board resets and starts the hello world
sample. The output is received via a USB RS232 adapter. The sample
program has been also modified to print an increasing loop counter, just
to make sure we're not looping the same content.

If anyone feels like this is worth working on I might be able to try and
clean it up a little bit and push out to Gerrit (once I get my access
issues resolved). I also have a couple of boards with STM32F3xx and
STM32L4xx MCUs so I might give these a try, unfortunately all of these
are Cortex-M4 based.

Has anyone looked at ports to Cortex-M0?

There is an effort going on right now, details will be provided soon.

Anas



Cheers,
--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

Hi list,

It has been a slow weekend, as part of my self-doubt recovery after a
bad Codility experience I've started writing drivers for RCC, UART and
pinmux for STM32F10x chips. The changes are pushed to
bboozzoo/stm32f103-next branch here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next/ Beware,
I'm treating this branch as a backup of my local work, so there might be
force pushes from time to time.

The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up and
push for review. I'd be glad if someone took a look at the code and
shared their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver
API. The problem comes form the fact that some chips may a more
elaborate clock distribution within the SoC itself. For instance, inside
the STM32F103x chip, there are at least 2 clock domains driving the
peripherals (low speed clock PCLK1 and high speed PCLK2). When setting
up UARTx baud rate one needs to know the clock rate in order to
calculate the timings for the peripheral. Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven by
PLCK1. Finding out the rate of the clock driving particular peripheral
is useful if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is returned
in `*rate` field.

Since this might be a more general problem, I think the functionality
can be added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly
delivers the CC part of the name. I have intentionally specified a low
priority (1) in DEVICE_INIT() call. The RCC has to be initialized early
in the startup process, otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header. I
did not feel like these belonged to the SoC specific part as the mappings
are shared by the whole family of SoCs.

The pinmux driver contains only the parts essential for getting the UART
to work. Again, this is not part of the board specific code, neither the
SoC specific one, as the driver is shared by a family of MCUs. I have
looked at the pinmux driver for Galileo and I understand the the API has
been shaped having this board in mind. While the API methods are
sufficient, I have only implemented the *_get() and *_set() calls. The
pin config on STM32F10x is a bit elaborate so I reused the `func`
parameter in *_get()/*_set() calls to pass driver specific function
mappings. The function mapping names are currently shaped after
pinconf-generic Linux driver. Perhaps I'm being too pragmatic here, but
I'd like to avoid replication of STM32Cube's functionality and typing in
all possible pin mappings.

The UART driver is still using polling, however drive init has been
reworked to use the pinmux and clock_control APIs. The baud rate is not
hardcoded anymore and is calculated based on configuration. The fixed
point arithmetic should be correct for low speeds and close enough for
higher speeds.

Depending the amount of Yocto/OE work things might be a bit slower next
week, but I'll do some testing and push updates when
possible. Eventually I'd like to hook up a BMP180 pressure sensor over
I2C and get that working.

Cheers,
--
Maciek Borzecki


Liu, Sharron <sharron.liu@...>
 

Really glad to see Zephyr upon chips of STM, my former employer :)

-----Original Message-----
From: Nashif, Anas [mailto:anas.nashif(a)intel.com]
Sent: Saturday, February 27, 2016 4:52 AM
To: Maciek Borzecki <maciek.borzecki(a)gmail.com>
Cc: devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: [devel] Re: STM32F103x port



On Feb 26, 2016, at 11:08, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

Hi list,

I've done a PoC port of Zephyr to STM32F103VE MCU on a EB-STM_06 dev
board. The port is rather minimal, most of the configuration is
hardcoded. The MCU is configured to use internal HSI clock source,
with PLL feeding a 36MHz clock to SYSCLK and AHB/APB (tried to make it
board agnostic). The minimal UART driver assumes that USART1 will be
used with a fixed speed of 9600kbps. The the best of my knowledge,
this should be enough as a starting point for porting to other boards.

The source code lives here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103 in
bboozzoo/stm32f103 branch.

Obligatory video: https://goo.gl/photos/AGhfXYvv8CswjRRu7 (sorry for
the background sound and overall potato quality). In the vide I flash
the firmware through STLink, the board resets and starts the hello
world sample. The output is received via a USB RS232 adapter. The
sample program has been also modified to print an increasing loop
counter, just to make sure we're not looping the same content.

If anyone feels like this is worth working on I might be able to try
and clean it up a little bit and push out to Gerrit (once I get my
access issues resolved). I also have a couple of boards with STM32F3xx
and STM32L4xx MCUs so I might give these a try, unfortunately all of
these are Cortex-M4 based.

Has anyone looked at ports to Cortex-M0?

There is an effort going on right now, details will be provided soon.

Anas



Cheers,
--
Maciek Borzecki


Piyush Pangtey <ppang.cse13@...>
 

Hi Maciek,
i'm inspired by your work and i would like to make port for other
boards too , can you guide me from where can I start ?

Regards,
Piyush Pangtey


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

General feedback inline below.

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Sunday, February 28, 2016 2:27 AM
To: devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: [devel] Re: STM32F103x port

Hi list,

It has been a slow weekend, as part of my self-doubt recovery after a bad
Codility experience I've started writing drivers for RCC, UART and pinmux for
STM32F10x chips. The changes are pushed to bboozzoo/stm32f103-next
branch here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next/
Beware, I'm treating this branch as a backup of my local work, so there might
be force pushes from time to time.
As said before, I've also been working on an STM32F2xx port. Looking at your changes, it might make sense to do something a little different for both of us, and try to re-use portions of code from each.

First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to allow selecting of the various flavors of the STM32 chip. This would be similar to what you've already got with the Kconfig.soc.stm32f103ve file, merged with the values from your Kconfig.soc. Then keeping the Kconfig to the pieces generic to all the STM32 portions (i.e. flash size, base address, etc).

Thoughts?

Second thing to add, in your use of addresses, please add a comment where these values were originally sourced from (aka the DataSheet document to be used for cross-referencing). Specifically looking at your soc.h.

Third, I like your rcc.h, using the union for structs. In my opinion this makes things a lot cleaner. This is also has been a bit of a contention for the project between several of us. :-) Two things on this. 1) rename val to raw, it keeps it consistent with other locations where this has been in use. 2) you may also need to add #define register definitions for these. I've got a bunch already typed up that I can share with you off-list to save some typing (if you want it).


The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up and
push for review. I'd be glad if someone took a look at the code and shared
their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver API. The
problem comes form the fact that some chips may a more elaborate clock
distribution within the SoC itself. For instance, inside the STM32F103x chip,
there are at least 2 clock domains driving the peripherals (low speed clock
PCLK1 and high speed PCLK2). When setting up UARTx baud rate one needs
to know the clock rate in order to calculate the timings for the peripheral.
Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven by
PLCK1. Finding out the rate of the clock driving particular peripheral is useful
if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is returned
in `*rate` field.

Since this might be a more general problem, I think the functionality can be
added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly delivers the
CC part of the name. I have intentionally specified a low priority (1) in
DEVICE_INIT() call. The RCC has to be initialized early in the startup process,
otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header. I did
not feel like these belonged to the SoC specific part as the mappings are
shared by the whole family of SoCs.
I need to look more at this, as in my own port for STM32F2xx I've left the RCC in the SOC section. Not saying that is right, just have left it there for now.

The pinmux driver contains only the parts essential for getting the UART to
work. Again, this is not part of the board specific code, neither the SoC
specific one, as the driver is shared by a family of MCUs. I have looked at the
pinmux driver for Galileo and I understand the the API has been shaped
having this board in mind. While the API methods are sufficient, I have only
implemented the *_get() and *_set() calls. The pin config on STM32F10x is a
bit elaborate so I reused the `func` parameter in *_get()/*_set() calls to pass
driver specific function mappings. The function mapping names are currently
shaped after pinconf-generic Linux driver. Perhaps I'm being too pragmatic
here, but I'd like to avoid replication of STM32Cube's functionality and typing
in all possible pin mappings.
I'm 90% sure that the pinmux can probably be renamed to something like pinmux_stm32, as I believe the functions are the same for the F1xx and F2xx series of chips. I would strongly encourage you to read some just recently posted messages on the mailing list for changes that are coming to the pinmux. It would be best to utilize those early on.

The pinmux you're providing is very SOC specific, which is good.

The UART driver is still using polling, however drive init has been reworked to
use the pinmux and clock_control APIs. The baud rate is not hardcoded
anymore and is calculated based on configuration. The fixed point arithmetic
should be correct for low speeds and close enough for higher speeds.
The UART is looking like it is coming along nicely. Again I think this is code that can be re-used on many of the STM32 chips.


Benjamin Walsh <benjamin.walsh@...>
 

Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this.
1) rename val to raw, it keeps it consistent with other locations
where this has been in use.
I think he got that from scs.h, which uses 'val' and 'bit'. Maybe we
should rename 'val' to 'raw' there as well.


Maciek Borzecki <maciek.borzecki@...>
 

On 02/29 14:06, Benjamin Walsh wrote:
Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this.
1) rename val to raw, it keeps it consistent with other locations
where this has been in use.
I think he got that from scs.h, which uses 'val' and 'bit'. Maybe we
should rename 'val' to 'raw' there as well.
Yes, I tried to be consistent with scs.h. I agree with Daniel, 'raw' is
more meaningful.

--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

On 02/29 18:53, Kalowsky, Daniel wrote:
General feedback inline below.

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Sunday, February 28, 2016 2:27 AM
To: devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: [devel] Re: STM32F103x port

Hi list,

It has been a slow weekend, as part of my self-doubt recovery after a bad
Codility experience I've started writing drivers for RCC, UART and pinmux for
STM32F10x chips. The changes are pushed to bboozzoo/stm32f103-next
branch here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next/
Beware, I'm treating this branch as a backup of my local work, so there might
be force pushes from time to time.
As said before, I've also been working on an STM32F2xx port. Looking
at your changes, it might make sense to do something a little
different for both of us, and try to re-use portions of code from
each.

First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>

IMO having a soc specific defconfig would be great too. Right now there
are only arch and board defconfigs. A soc defconfig would save a lot of
typing and if'ing in Kconfigs, what happens to be really error prone by
the way.


Second thing to add, in your use of addresses, please add a comment
where these values were originally sourced from (aka the DataSheet
document to be used for cross-referencing). Specifically looking at
your soc.h.
Ok.


Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this. 1) rename val to raw, it keeps it consistent with other
locations where this has been in use. 2) you may also need to add
#define register definitions for these. I've got a bunch already
typed up that I can share with you off-list to save some typing (if
you want it).
Sure, I'd be glad to take a look.



The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up and
push for review. I'd be glad if someone took a look at the code and shared
their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver API. The
problem comes form the fact that some chips may a more elaborate clock
distribution within the SoC itself. For instance, inside the STM32F103x chip,
there are at least 2 clock domains driving the peripherals (low speed clock
PCLK1 and high speed PCLK2). When setting up UARTx baud rate one needs
to know the clock rate in order to calculate the timings for the peripheral.
Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven by
PLCK1. Finding out the rate of the clock driving particular peripheral is useful
if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is returned
in `*rate` field.

Since this might be a more general problem, I think the functionality can be
added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly delivers the
CC part of the name. I have intentionally specified a low priority (1) in
DEVICE_INIT() call. The RCC has to be initialized early in the startup process,
otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header. I did
not feel like these belonged to the SoC specific part as the mappings are
shared by the whole family of SoCs.
I need to look more at this, as in my own port for STM32F2xx I've left
the RCC in the SOC section. Not saying that is right, just have left
it there for now.

The pinmux driver contains only the parts essential for getting the UART to
work. Again, this is not part of the board specific code, neither the SoC
specific one, as the driver is shared by a family of MCUs. I have looked at the
pinmux driver for Galileo and I understand the the API has been shaped
having this board in mind. While the API methods are sufficient, I have only
implemented the *_get() and *_set() calls. The pin config on STM32F10x is a
bit elaborate so I reused the `func` parameter in *_get()/*_set() calls to pass
driver specific function mappings. The function mapping names are currently
shaped after pinconf-generic Linux driver. Perhaps I'm being too pragmatic
here, but I'd like to avoid replication of STM32Cube's functionality and typing
in all possible pin mappings.
I'm 90% sure that the pinmux can probably be renamed to something like
pinmux_stm32, as I believe the functions are the same for the F1xx and
F2xx series of chips. I would strongly encourage you to read some
just recently posted messages on the mailing list for changes that are
coming to the pinmux. It would be best to utilize those early on.

The pinmux you're providing is very SOC specific, which is good.
Are you referring to this discussion?
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/message/P6HMQUTHVAL4PZXSNRJCYTEBDGXFQWKH/


The UART driver is still using polling, however drive init has been reworked to
use the pinmux and clock_control APIs. The baud rate is not hardcoded
anymore and is calculated based on configuration. The fixed point arithmetic
should be correct for low speeds and close enough for higher speeds.
The UART is looking like it is coming along nicely. Again I think
this is code that can be re-used on many of the STM32 chips.
Agreed. I've just briefly looked at STM32F4xxxx Reference Manual. The
register map looks the same. Specific registers (CR1, CR3) use a couple
of bits more, but nothing that cannot be handled by #ifdefs. I expect
that the lower families (2xxx, 3xxx) are also very much identical.

Cheers,
--
Maciek Borzecki


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

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Monday, February 29, 2016 12:03 PM
To: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>
Cc: devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: STM32F103x port

On 02/29 18:53, Kalowsky, Daniel wrote:
General feedback inline below.

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Sunday, February 28, 2016 2:27 AM
To: devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: [devel] Re: STM32F103x port

Hi list,

It has been a slow weekend, as part of my self-doubt recovery after
a bad Codility experience I've started writing drivers for RCC, UART
and pinmux for STM32F10x chips. The changes are pushed to
bboozzoo/stm32f103-next branch here:
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next/
Beware, I'm treating this branch as a backup of my local work, so
there might be force pushes from time to time.
As said before, I've also been working on an STM32F2xx port. Looking
at your changes, it might make sense to do something a little
different for both of us, and try to re-use portions of code from
each.

First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?

IMO having a soc specific defconfig would be great too. Right now there are
only arch and board defconfigs. A soc defconfig would save a lot of typing
and if'ing in Kconfigs, what happens to be really error prone by the way.
Depending upon what you see going into such a file, this is a relatively reasonable idea.

Second thing to add, in your use of addresses, please add a comment
where these values were originally sourced from (aka the DataSheet
document to be used for cross-referencing). Specifically looking at
your soc.h.
Ok.


Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this. 1) rename val to raw, it keeps it consistent with other
locations where this has been in use. 2) you may also need to add
#define register definitions for these. I've got a bunch already
typed up that I can share with you off-list to save some typing (if
you want it).
Sure, I'd be glad to take a look.



The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up
and push for review. I'd be glad if someone took a look at the code
and shared their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver
API. The problem comes form the fact that some chips may a more
elaborate clock distribution within the SoC itself. For instance,
inside the STM32F103x chip, there are at least 2 clock domains
driving the peripherals (low speed clock
PCLK1 and high speed PCLK2). When setting up UARTx baud rate one
needs to know the clock rate in order to calculate the timings for the
peripheral.
Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven
by PLCK1. Finding out the rate of the clock driving particular
peripheral is useful if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is
returned in `*rate` field.

Since this might be a more general problem, I think the
functionality can be added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly
delivers the CC part of the name. I have intentionally specified a
low priority (1) in
DEVICE_INIT() call. The RCC has to be initialized early in the
startup process, otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header.
I did not feel like these belonged to the SoC specific part as the
mappings are shared by the whole family of SoCs.
I need to look more at this, as in my own port for STM32F2xx I've left
the RCC in the SOC section. Not saying that is right, just have left
it there for now.

The pinmux driver contains only the parts essential for getting the
UART to work. Again, this is not part of the board specific code,
neither the SoC specific one, as the driver is shared by a family of
MCUs. I have looked at the pinmux driver for Galileo and I
understand the the API has been shaped having this board in mind.
While the API methods are sufficient, I have only implemented the
*_get() and *_set() calls. The pin config on STM32F10x is a bit
elaborate so I reused the `func` parameter in *_get()/*_set() calls
to pass driver specific function mappings. The function mapping
names are currently shaped after pinconf-generic Linux driver.
Perhaps I'm being too pragmatic here, but I'd like to avoid replication of
STM32Cube's functionality and typing in all possible pin mappings.

I'm 90% sure that the pinmux can probably be renamed to something like
pinmux_stm32, as I believe the functions are the same for the F1xx and
F2xx series of chips. I would strongly encourage you to read some
just recently posted messages on the mailing list for changes that are
coming to the pinmux. It would be best to utilize those early on.

The pinmux you're providing is very SOC specific, which is good.
Are you referring to this discussion?
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/P6HMQUTHVAL4PZXSNRJCYTEBDGXFQWKH/
That would be the very specific discussion. :-)

The UART driver is still using polling, however drive init has been
reworked to use the pinmux and clock_control APIs. The baud rate is
not hardcoded anymore and is calculated based on configuration. The
fixed point arithmetic should be correct for low speeds and close enough
for higher speeds.

The UART is looking like it is coming along nicely. Again I think
this is code that can be re-used on many of the STM32 chips.
Agreed. I've just briefly looked at STM32F4xxxx Reference Manual. The
register map looks the same. Specific registers (CR1, CR3) use a couple of bits
more, but nothing that cannot be handled by #ifdefs. I expect that the lower
families (2xxx, 3xxx) are also very much identical.


Pawel Wodnicki <root@...>
 

Hi,

I have been working with Dan's stm32 patch to add support for stm32f4xx and just wanted to share couple of thoughts.
https://gerrit.zephyrproject.org/r/#/c/209/

I would second the idea of adding additional level of hierarchy under st_stm32 soc for functionality specific to the line of ST MCU's.
Just looking at the STM32F chips there is 6 variants not even including STM32L. Organizing soc folders to reflect that hierarchy would help dealing with the variability within the STM32 line of mcu's without cluttering arch/arm/soc/ folder.

arch/arm/soc/st_stm32/
arch/arm/soc/st_stm32/stm32f0xx/
arch/arm/soc/st_stm32/stm32f1xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f4xx/
arch/arm/soc/st_stm32/stm32f7xx/

Common functionality could be implemented at the arch/arm/soc/st_stm32/ level, ie:

arch/arm/soc/st_stm32/soc.c:static int st_stm32_init(struct device *arg)

But when needed SOC api could be structured in a hierarchical way, ie:

arch/arm/soc/st_stm32/soc.c:void clock_init(void)

arch/arm/soc/st_stm32/stm32f1xx/soc.c:void clock_init_stm32f1xx(void)
..
arch/arm/soc/st_stm32/stm32f4xx/soc.c:void clock_init_stm32f4xx(void)

As for drivers for specific stm32 peripherals some like the RCC (Reset & Clock Control)
could be handled at the st_stm32 soc top level with #ifdefs but there are some peripherals that use different versions of the hardware IP (GPIO is a good example) and would be easier to handle at the level specific to the MCU soc.

Cheers,
Pawel Wodnicki


Dirk Brandewie <dirk.j.brandewie@...>
 

On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.


If it turns out to painful we can "move the deck chairs around later" (tm)
IMO having a soc specific defconfig would be great too. Right now there are
only arch and board defconfigs. A soc defconfig would save a lot of typing
and if'ing in Kconfigs, what happens to be really error prone by the way.
Depending upon what you see going into such a file, this is a relatively reasonable idea.

Second thing to add, in your use of addresses, please add a comment
where these values were originally sourced from (aka the DataSheet
document to be used for cross-referencing). Specifically looking at
your soc.h.
Ok.


Third, I like your rcc.h, using the union for structs. In my opinion
this makes things a lot cleaner. This is also has been a bit of a
contention for the project between several of us. :-) Two things on
this. 1) rename val to raw, it keeps it consistent with other
locations where this has been in use. 2) you may also need to add
#define register definitions for these. I've got a bunch already
typed up that I can share with you off-list to save some typing (if
you want it).
Sure, I'd be glad to take a look.



The demo code has been archived in bboozzoo/stm32f103-demo branch.

Once I deem the work somewhat feature complete, I'll clean that up
and push for review. I'd be glad if someone took a look at the code
and shared their opinion on whether the path I took seems reasonable.

I think there might be some room for extending clock control driver
API. The problem comes form the fact that some chips may a more
elaborate clock distribution within the SoC itself. For instance,
inside the STM32F103x chip, there are at least 2 clock domains
driving the peripherals (low speed clock
PCLK1 and high speed PCLK2). When setting up UARTx baud rate one
needs to know the clock rate in order to calculate the timings for the
peripheral.
Also, on this particular chip
USART1 is driven by PCLK2, while the remaining for UARTx are driven
by PLCK1. Finding out the rate of the clock driving particular
peripheral is useful if we want to keep things generic to some extent.

I've added the following call to driver specific part of the API:

void stm32f10x_clock_control_get_subsys_rate(struct device *clock,
clock_control_subsys_t subsys,
uint32_t *rate);

where `subsys` is the regular clock subsystem and the clock rate is
returned in `*rate` field.

Since this might be a more general problem, I think the
functionality can be added to the clock_control API:

typedef void (*clock_control_get_clock)(struct device *dev,
clock_control_subsys_t sys,
uint32_t *rate);

struct clock_control_driver_api {
...
clock_control_get_clock get_clock;
}

As for the drivers. The RCC (Reset & Clock Control) driver mostly
delivers the CC part of the name. I have intentionally specified a
low priority (1) in
DEVICE_INIT() call. The RCC has to be initialized early in the
startup process, otherwise no peripherals will work.

RCC subsytem mapping enums have been put in driver specific header.
I did not feel like these belonged to the SoC specific part as the
mappings are shared by the whole family of SoCs.
I need to look more at this, as in my own port for STM32F2xx I've left
the RCC in the SOC section. Not saying that is right, just have left
it there for now.

The pinmux driver contains only the parts essential for getting the
UART to work. Again, this is not part of the board specific code,
neither the SoC specific one, as the driver is shared by a family of
MCUs. I have looked at the pinmux driver for Galileo and I
understand the the API has been shaped having this board in mind.
While the API methods are sufficient, I have only implemented the
*_get() and *_set() calls. The pin config on STM32F10x is a bit
elaborate so I reused the `func` parameter in *_get()/*_set() calls
to pass driver specific function mappings. The function mapping
names are currently shaped after pinconf-generic Linux driver.
Perhaps I'm being too pragmatic here, but I'd like to avoid replication of
STM32Cube's functionality and typing in all possible pin mappings.

I'm 90% sure that the pinmux can probably be renamed to something like
pinmux_stm32, as I believe the functions are the same for the F1xx and
F2xx series of chips. I would strongly encourage you to read some
just recently posted messages on the mailing list for changes that are
coming to the pinmux. It would be best to utilize those early on.

The pinmux you're providing is very SOC specific, which is good.
Are you referring to this discussion?
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/
message/P6HMQUTHVAL4PZXSNRJCYTEBDGXFQWKH/
That would be the very specific discussion. :-)

The UART driver is still using polling, however drive init has been
reworked to use the pinmux and clock_control APIs. The baud rate is
not hardcoded anymore and is calculated based on configuration. The
fixed point arithmetic should be correct for low speeds and close enough
for higher speeds.

The UART is looking like it is coming along nicely. Again I think
this is code that can be re-used on many of the STM32 chips.
Agreed. I've just briefly looked at STM32F4xxxx Reference Manual. The
register map looks the same. Specific registers (CR1, CR3) use a couple of bits
more, but nothing that cannot be handled by #ifdefs. I expect that the lower
families (2xxx, 3xxx) are also very much identical.


Maciek Borzecki <maciek.borzecki@...>
 

On 03/01 10:17, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
Do you mind taking a look here
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-layout-change
and sending some feedback?

The branch implements this layout:
arch/
arm/
soc/
stm32/
Kconfig <-- includes family specific Kconfigs
Kconfig.soc <-- SOC family selection under 'General platform..'
stm32f1x/
Makefile
Kconfig.soc.family <-- list of possible MCUs in this family
general defaults
Kconfig.soc.stm32f103ve <-- STM32F103VE specific settings
...
Kconfig.soc.stm32f103rb <-- xxRB model if we had
NUCLEO-FRB103 board
soc.{c,h} <-- MCU specifi headers & code
stm32f2x/
<soc specific>
stm32f4x/
<soc specific>

There's a little trick in Kconfig under stm32/<MCU-specific>, CONFIG_SOC
is set to have a default of pointing to MCU specific directory. For
example, for stm32f1x, the SOC defaults to stm32/stm32f1x, this ensures
that MCU specific path is included in CFLAGS.

Then under menuconfig we have:
------
Location:
-> ARM architecture
-> General Platform Configuration
-> SoC Selection (<choice> [=y]) <-- STM32F1x
-----

and MCU selection:

-----
Location:
-> ARM architecture
-> STM32F1x MCU Selection (<choice> [=y]) <-- STM32F103VE
-----

Cheers,
--
Maciek Borzecki


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

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, March 1, 2016 11:19 AM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Cc: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>;
devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: STM32F103x port

On 03/01 10:17, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
Do you mind taking a look here
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-
layout-change
and sending some feedback?

The branch implements this layout:
arch/
arm/
soc/
stm32/
Kconfig <-- includes family specific Kconfigs
Kconfig.soc <-- SOC family selection under 'General platform..'
stm32f1x/
Only one x? I'll admit to being relatively new to the STM32 family so it's not clear to me if 10x and 1xx will make any difference. Same goes for other STM32F models. I'm not sure the sub-directories are needed yet. Still digesting this one.

Makefile
Kconfig.soc.family <-- list of possible MCUs in this family
general defaults
Having done some minor toying around with Kconfig today, I decided to use Kconfig.soc to just declare the generic STM32 family. From there, the Kconfig is used to better tune to which family type, but that most likely isn't enough granularity. Looks like you and I had done some similar work, as I just uploaded my minor tinkering from today.

Kconfig.soc.stm32f103ve <-- STM32F103VE specific settings
...
Kconfig.soc.stm32f103rb <-- xxRB model if we had
NUCLEO-FRB103 board
soc.{c,h} <-- MCU specifi headers & code
stm32f2x/
<soc specific>
stm32f4x/
<soc specific>

There's a little trick in Kconfig under stm32/<MCU-specific>, CONFIG_SOC
is set to have a default of pointing to MCU specific directory. For
example, for stm32f1x, the SOC defaults to stm32/stm32f1x, this ensures
that MCU specific path is included in CFLAGS.

Then under menuconfig we have:
------
Location:
-> ARM architecture
-> General Platform Configuration
-> SoC Selection (<choice> [=y]) <-- STM32F1x
-----

and MCU selection:

-----
Location:
-> ARM architecture
-> STM32F1x MCU Selection (<choice> [=y]) <-- STM32F103VE
-----

Cheers,
--
Maciek Borzecki


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

Hey Pawel,

-----Original Message-----
From: Pawel Wodnicki [mailto:root(a)32bitmicro.com]
Sent: Tuesday, March 1, 2016 8:26 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: STM32F103x port

Hi,

I have been working with Dan's stm32 patch to add support for stm32f4xx
and just wanted to share couple of thoughts.
https://gerrit.zephyrproject.org/r/#/c/209/
Oh wow, didn't realize that DRAFTS were visible to the world. Guess this means I'll need to be more careful about what I put in there. Sorry for the large amount of broken code that was in the patches before.


I would second the idea of adding additional level of hierarchy under
st_stm32 soc for functionality specific to the line of ST MCU's.
Just looking at the STM32F chips there is 6 variants not even including
STM32L. Organizing soc folders to reflect that hierarchy would help dealing
with the variability within the STM32 line of mcu's without cluttering
arch/arm/soc/ folder.

arch/arm/soc/st_stm32/
arch/arm/soc/st_stm32/stm32f0xx/
arch/arm/soc/st_stm32/stm32f1xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f2xx/
arch/arm/soc/st_stm32/stm32f4xx/
arch/arm/soc/st_stm32/stm32f7xx/

Common functionality could be implemented at the arch/arm/soc/st_stm32/
level, ie:

arch/arm/soc/st_stm32/soc.c:static int st_stm32_init(struct device *arg)

But when needed SOC api could be structured in a hierarchical way, ie:

arch/arm/soc/st_stm32/soc.c:void clock_init(void)

arch/arm/soc/st_stm32/stm32f1xx/soc.c:void clock_init_stm32f1xx(void)
..
arch/arm/soc/st_stm32/stm32f4xx/soc.c:void clock_init_stm32f4xx(void)
A lot of this sounds like what Maciek is suggesting as the layout.

As for drivers for specific stm32 peripherals some like the RCC (Reset & Clock
Control)
could be handled at the st_stm32 soc top level with #ifdefs but there are
some peripherals that use different versions of the hardware IP (GPIO is a
good example) and would be easier to handle at the level specific to the
MCU soc.
Wind River just submitted a series of drivers for the FRDM-K64F. It might be worth looking at and modeling the STM32 after something similar.


Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 2, 2016 at 2:49 AM, Kalowsky, Daniel
<daniel.kalowsky(a)intel.com> wrote:


-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, March 1, 2016 11:19 AM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Cc: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>;
devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: STM32F103x port

On 03/01 10:17, Dirk Brandewie wrote:


On 02/29/2016 02:26 PM, Kalowsky, Daniel wrote:
-----Original Message-----
First suggestion, create an arch/arm/soc/stm32, and use the Kconfig to
allow selecting of the various flavors of the STM32 chip. This would
be similar to what you've already got with the Kconfig.soc.stm32f103ve
file, merged with the values from your Kconfig.soc. Then keeping the
Kconfig to the pieces generic to all the STM32 portions (i.e. flash
size, base address, etc).

Thoughts?
Makes sense. I think we should also add another 'MCU family' level of
hierarchy. We would have then:

arch/
arm/
soc/
stm32/
stm32f1xx/
<soc specific>
stm32f2xx/
<soc specific>
stm32f4xx/
<soc specific>
I'm not opposed to this.

Ben/Dirk any commentary?
Having thought about it for 10 seconds it seems reasonable :-) To the
greatest extent reasonable please avoid link time binding of SOC specifc
code into the generic stm32 code. We don't want to the next guy to
wonder which init() function is called.
Do you mind taking a look here
https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-
layout-change
and sending some feedback?

The branch implements this layout:
arch/
arm/
soc/
stm32/
Kconfig <-- includes family specific Kconfigs
Kconfig.soc <-- SOC family selection under 'General platform..'
stm32f1x/
Only one x? I'll admit to being relatively new to the STM32 family so it's not clear to me if 10x and 1xx will make any difference. Same goes for other STM32F models. I'm not sure the sub-directories are needed yet. Still digesting this one.
Single 'x' as in 'everything that comes after the i-1 character' :)

As for the models, I'm not aware of any non STF32F10x MCUs, however
all of these are collectively referred to as STM32F1
series/family. The core is different between F[0-4] families, F1 are
all Cortex-M3, F0 are Cortex-M0[+], F3/4 are Cortex-M4.

Within a family, the MCUs differ wrt. to clock and peripherals
present. Then within a subfamily (?), ex. STM32F103xx, the MCUs differ
again, for instance there's no DAC in STM32F103xB, but there are 2
DACs in STM32F103x[CDEFG]. Again, the xB line only has 3 UARTs, while
other variants have 5 ports.

The last letter indicates the amount of flash and SRAM (dubbed as
high- low- medium- density int the specs).

The one but last letter, ex. STM32F103VE - V indicates the pin
count. This will influence pin remapping and in the case of packages
with very few pins, it will indicate that certain peripherals may have
been left out.

A quite elaborate part number coding scheme. That's why I included per
family subdirectories and Kconfig.soc.<mcumodel> in my proposal.


Makefile
Kconfig.soc.family <-- list of possible MCUs in this family
general defaults
Having done some minor toying around with Kconfig today, I decided to use Kconfig.soc to just declare the generic STM32 family. From there, the Kconfig is used to better tune to which family type, but that most likely isn't enough granularity. Looks like you and I had done some similar work, as I just uploaded my minor tinkering from today.
Cheers,
--
Maciek Borzecki