Date   

RFC Common System logging API Rev. 2

Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
 

This is the second attempt to define a common system logging API,
Original thread can be seen here:

https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject
.org/thread/A6CROK67VKFKFSCENJ6UVQL2IRNHLNW2/#A6CROK67VKFKFSCENJ6UVQL2I
RNHLNW2

Background:
 
Currently several files declare their own logging infrastructure and
sometimes even in the same way, effectively duplicating code, there is
no common logger header or a single interface for logging, this
situation also complicates enhancement of logging functionality.

We want to concentrate logging functionality at a single point to ease
configuration and enhancement while reusing some existing logging
features.

Proposal to implement new logging API:

Create a new header file at include directory, remove all logger macro
definition from .c files and have a single, definition on the new
header. On each .c file that requires logging include the new header
and specify feature/file specific values, such as logging domain (if
any) and per-feature logging switch (view number 7 below).

The surveyed features selected for this logging API are:

1. Kconfig based selection of output backend, these currently being
stdio printf when console is available and printk as fall back.

2. Optional macro expansion, controlled at compile time by Kconfig
files and make menuconfig command. Disabling this helps saving size at
binary images when logging is not needed.

3. Multi category logging, this allows to only enable some of the
logging macros. Previous proposal considered "levels" that are
inherently incremental, i.e., a given level is always a super set of
lower levels. New proposal doesn't force precedence between any of the
four defined macros.

4. Caller thread printing, optionally prints the current thread
pointer.

5. Caller function printing.

New features are added:

6. Labeled log, helps differentiate log categories by using a label at
the beginning.

7. Fine grain per-feature log activation. Allows enabling log at
specific parts of the code through menuconfig.

8. Logging domain, a string optionally specified to be appended to log
messages in order to helps differentiate log output in case several
features are enabled, domain is specified by definition of
SYS_LOG_DOMAIN macro.

Design decisions and rationale:

This API was implemented based on macros instead of run-time functions
(except for thread retrieval) in an attempt to minimize both execution
overhead and binary size increments introduced by logging.

It's important to emphasize that by leaving log activation logic to
preprocessor (at compile time) the binary images size can be
effectively reduced by decreasing the amount of activated log macros,
of course verbosity is reduced as well.

The macros also act as a facade that can be implemented in the
background by different implementations, currently printk and printf
are the only available implementations.

Taking into account feedback from previous RFC version, specifically ht
tps://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.o
rg/message/RKVXWR75XFN3TCXKQV2STRACPMPVSEB4/, a given log macro gets
activated when its category is selected for the current module. Such
combination allows to specify different verbosity at each module.

The macro categories are intended to filter the log according to the
nature of the messages, e.g., ERROR category would report failures
found by the program during execution while DEBUG could record tracing
information relevant to programmer during development and debugging.

Each module needs its own category specified and different modules
might have different categories specified. For example, a new driver
might depend on GPIO, so for debugging this new driver the GPIO related
module gets its log category set to ERROR and the driver has all
categories activated, that way developer can identify when an error was
 encountered by GPIO code, without having to see messages on all the
categories at GPIO code, and could check the DEBUG category of the new
driver to see the details on how was this error handled.

Implementation details:

The macros are defined at include/misc/sys_log.h, they get enabled by
the per-module switch SYS_LOG_LEVEL (specified before header include)
and the global switch (CONFIG_SYS_LOG).
The per-module switch gets relayed at .c file from the Kconfig options
in the following way:
#define SYS_LOG_LEVEL CONFIG_SYS_LOG_GROVE_LEVEL
#include <misc/sys_log.h>

If SYS_LOG_LEVEL is not defined a default is
used: CONFIG_SYS_LOG_DEFAULT_LEVEL. Previous approach was to enforce
the definition by failing compilation if not defined.

The following switches control some optional formatting:

CONFIG_SYS_LOG_ENABLE_PRINTF: specifies printf as backend.
CONFIG_SYS_LOG_ENABLE_PRINTK: specifies printk as backend.
CONFIG_SYS_LOG_SHOW_TAGS: sets category tags on.
SYS_LOG_DOMAIN: sets domain string that will be included at the start
of the messages.
CONFIG_SYS_LOG_THREAD: specifies whether to print thread pointer or
not.

Log categories are selected through a bitmap, each of the 4 least
significant bits of bitmap correspond each of the four defined
categories. Macros get activated when the bit for their category is 1
on the SYS_LOG_LEVEL of including compile unit, e.g.:

When SYS_LOG_LEVEL is 9 (0b1001) for current compile unit SYS_LOG_DBG
and SYS_LOG_ERR, corresponding to ERROR and DEBUG categories, are
active. The macros SYS_LOG_INF and SYS_LOG_WRN instead expand to "{ ;
}"

0b0000 //LOG is off (0)
0b1000 //LOG is ERROR (1)
0b1100 //LOG is ERROR + WARNING (3)
0b1110 //LOG is ERROR + WARNING + INFO (7)
0b1111 //LOG is ERROR + WARNING + INFO + DEBUG (15)

Future work:
Subsequent patches need to define a sanity test, and replace old DBG
macro calls on several files.


RFC: 4/5 Provide a Mechanism to enter SOC to Deep Sleep

Thomas, Ramesh
 

Problem Statement:
Zephyr needs to provide an architecture independent method for power
management application to invoke the SOC Deep Sleep functionality.

Why this is a problem:
-----------------------------
- Entry and Exit of Deep Sleep paths are non-trivial and has
dependencies on kernel
cold boot path
- Resume from deep sleep happens with interrupt stack and needs special
handling
- Different architectures have different ways of handling reset/cold
boot which is the path taken by Deep Sleep resume.
- Method to identify Deep Sleep exit requires understanding of SoC
details.

What should be done:
-----------------------------
- Provide api to save thread context and enter Deep Sleep in
architecture and SoC specific regions
- Provide api to restore thread context and resume at location Deep
Sleep was entered
- Api will safely switch away from interrupt stack
- Provide means to identify Deep Sleep exit which are SoC specific

Key
----
PMA: Power Manager Application
ISR: Interrupt Service Routine

Proposed PMA Deep Sleep Entry Flow:
+-----+ +---------+ +-----+
| ISR | | Kernel | | PMA |
+-----+ +---------+ +-----+
| | ----------\ |
| |-| Compute | |
| | | idle | |
| | | ticks | |
| | |---------| |
| | -----------\ |
| |-| Schedule | |
| | | next | |
| | | event | |
| | |----------| |
| | |
| | _sys_soc_suspend(ticks) |
| |--------------------------->|
| | -----------\ |
| | | Select |-|
| | | policy | |
| | | based on | |
| | | ticks | |
| | |----------| |
| | -----------\ |
| | | Execute |-|
| | | Deep | |
| | | Sleep | |
| | | entry | |
| | | policies | |
| | |----------| |
| | |
| | _sys_soc_push_DS() |
| |<---------------------------|
| | |
| | Deep Sleep |
| |----------- |
| | | |
| |<---------- |
| | |



Proposed PMA Deep Sleep Exit Flow:
+-----+ +---------+ +-----+
| ISR | | Kernel | | PMA |
+-----+ +---------+ +-----+
| --------\ | |
| | AON |-| |
| | event | | |
| |-------| | |
| ---------\ | |
| | start |-| |
| | Kernel | | |
| |--------| | |
| | |
| | _sys_soc_resume() |
| |---------------------->|
| | ----------\ |
| | | detects |-|
| | | DS exit | |
| | |---------| |
| | |
| | _sys_soc_pop_DS() |
| |<----------------------|
| | ----------------\ |
| |-| switch thread | |
| | | context | |
| | |---------------| |
| | |
| | prior call to |
| | _sys_soc_push_DS() |
| | returns |
| |---------------------->|
| | -----------\ |
| | | Execute |-|
| | | Deep | |
| | | Sleep | |
| | | exit | |
| | | policies | |
| | |----------| |
| | -------------\ |
| | | enable |-|
| | | interrupts | |
| | |------------| |
| -------------\ | |
|-| re-compute | | |
| | Tickless | | |
| | timeouts | | |
| |------------| | |
| -----------\ | |
|-| schedule | | |
| | next | | |
| | task | | |
| |----------| | |
| | --------------\ |
| |-| next kernel | |
| | | idle | |
| | |-------------| |
| | |
| | prior call to |
| | _sys_soc_suspend() |
| | returns PM_SOC_DS |
| |<----------------------|
| | |


Proposed Cold Boot flow:
+---------+ +-----+
| Kernel | | PMA |
+---------+ +-----+
| -------\ |
|-| cold | |
| | boot | |
| |------| |
| ---------\ |
|-| start | |
| | Kernel | |
| |--------| |
| |
| _sys_soc_resume() |
|---------------------->|
| ----------\ |
| | detects |-|
| | cold | |
| | boot | |
| |---------| |
| |
| returns immediately |
|<----------------------|
| ------------\ |
|-| kernel | |
| | startup | |
| | continues | |
| |-----------| |
| |


RFC: 3/5 Provide a Mechanism to enter CPU to Low Power State

Thomas, Ramesh
 

Problem Statement:
Zephyr needs to provide an architecture independent method for power
management application to invoke a low power state on the CPU.

Why this is a problem:
-----------------------------
LPS state transition operations impact kernel idle logic e.g. interrupts
need to be atomically enabled before entering CPU low power idle state.
Power Management Application policy enforcement requires that code to be
easily ported/reused across architectures.

What should be done:
-----------------------------
At the arch specific regions in the kernel, provide API to transition to
LPS for each architecture.
Kernel dependent operations like atomically enabling interrupts should
be done in this API.

Key
----
PMA: Power Manager Application
ISR: Interrupt Service Routine

Proposed PMA Low Power State Entry Flow:
+---------+ +-----+ +---------+ +-----+
| Events | | ISR | | Kernel | | PMA |
+---------+ +-----+ +---------+ +-----+
| | | ----------\ |
| | |-| Compute | |
| | | | idle | |
| | | | ticks | |
| | | |---------| |
| | | -----------\ |
| | |-| Schedule | |
| | | | next | |
| | | | event | |
| | | |----------| |
| | | |
| | | _sys_soc_suspend(ticks) |
| | |--------------------------->|
| | | -----------\ |
| | | | Select |-|
| | | | policy | |
| | | | based on | |
| | | | ticks | |
| | | |----------| |
| | | -----------\ |
| | | | Execute |-|
| | | | LPS | |
| | | | entry | |
| | | | policies | |
| | | |----------| |
| | | |
| | | _sys_soc_push_LPS() |
| | |<---------------------------|
| | | |
| | | CPU LPS |
| | | wait |
| | |-------- |
| | | | |
| | |<------- |
| | | |


Proposed PMA Low Power State Exit Flow:
+---------+ +-----+ +---------+ +-----+
| Events | | ISR | | Kernel | | PMA |
+---------+ +-----+ +---------+ +-----+
| | | |
| intr | | |
|-------->| | |
| | | |
| | process interrupt | |
| |----------------------->| |
| | | |
| | | _sys_soc_resume() |
| | |----------------------->|
| | | ----------\ |
| | | | Execute |-|
| | | | LPS | |
| | | | exit | |
| | | | policy | |
| | | |---------| |
| | | |
| | | return to kernel |
| | |<-----------------------|
| | | |
| | return to ISR | |
| |<-----------------------| |
| | -------------\ | |
| |-| re-compute | | |
| | | Tickless | | |
| | | timeouts | | |
| | |------------| | |
| | -----------\ | |
| |-| schedule | | |
| | | next | | |
| | | task | | |
| | |----------| | |
| | | --------------\ |
| | |-| next kernel | |
| | | | idle | |
| | | |-------------| |
| | | |
| | | prior call to |
| | | _sys_soc_push_LPS() |
| | | returns |
| | |----------------------->|
| | | |
| | | prior call to |
| | | _sys_soc_suspend() |
| | | returns PM_SOC_LPS |
| | |<-----------------------|
| | | |


RFC: 2/5 System Device Driver Modifications

Thomas, Ramesh
 

Problem Statement:
Not all Zephyr kernel drivers provide the same interfaces.

Why this is a problem:
-----------------------------
The Zephyr kernel currently has devices that are essential for core OS
functions (such as APICs and timers), but provide no public API means
for accessing them. Without any consistent method to access device
drivers on the platform, it becomes very difficult to achieve power
targets.

What should be done:
-----------------------------
1) Each native Zephyr kernel driver and shim driver (such as QMSI) shall
support:

a) uint32_t suspend() - routine that will move any required device state
data
to RAM* with the following valid return values:
- DEV_OK
- DEV_BUSY
- DEV_FAIL

b) uint32_t resume() - routine that will retrieve any device state data
from
RAM* with the following valid return values:

- DEV_OK
- DEV_FAIL

2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers,
IOAPIC, and LOAPIC.

*The power management process is not expected to power down system RAM
(it will most likely stay in selective suspend).

The size of the device data is dependent upon an individual device, and
therefore the system integrator must be wary of the number of devices
being utilized.

Device suspend flow:
Device Drivers at suspend shall:
- Device state shall be saved to memory and maintained across a PM event
- Turning off the device clock
- Return appropriate error code

Device resume flow:
Device Drivers at resume shall:
- Restore to state saved in memory
- Turn on the device clock
- Return appropriate error code

Device domain experts will be needed to implement the proper methods for
suspending and resuming each device.


RFC: 1/5 Consistent naming of PM Kconfig flags

Thomas, Ramesh
 

Problem Statement:
Power management Kconfig flags are not consistent and hierarchy is not
clear

Why this is a problem:
-----------------------------
The names include terms like “ADVANCED” which are not meaningful to
current implementation. Names do not specifically identify features that
are enabled by the flag. There are redundancies and overlaps in flags
and the hierarchy is not clear.

What should be done:
------------------------------
Change as follows :

ADVANCED_POWER_MANAGEMENT -> SYS_POWER_MANAGEMENT (turn on the basics
of power management)

ADVANCED_IDLE_SUPPORTED -> SYS_POWER_LPS (enables the kernel
for LPS)
-> SYS_POWER_DEEP_SLEEP (enables the kernel for
DS)

ADVANCED_IDLE -> delete
TICKLESS_IDLE -> SYS_POWER_TICKLESS_IDLE
DEVICE_POWER_MGMT -> DEVICE_POWER_MANAGEMENT

The new flags with the dependency hierarchy will be as follows:

SYS_POWER_MANAGEMENT
|
|___SYS_POWER_TICKLESS_IDLE
|
|___SYS_POWER_LPS
|
|___SYS_POWER_DEEP_SLEEP
|
|___DEVICE_POWER_MANAGEMENT


RFC: 0/5 Provide common terminology for Power Management

Thomas, Ramesh
 

Here are the revised RFCs that attempts to state the problems, reasons
and solutions more clearly Thanks to Dan for spending a lot of time
with me in making it right.

(It was a challenge to put things into all-text. There are ascii
diagrams that Linux based email clients would handle correctly when
configured to read as Plain Text. In Outlook, you would need to select
"Rich Text" which will allow selecting a fixed font like Courier.)

Problem Statement:
Create a common set of terminology to use across architectures for
Zephyr discussions on power management.

Why is this a problem:
Different terms used across architectures without clarification of what
it means and how each impacts the system.

What should be done:
Create a common proposed terminology as defined below.

Terminology:
*PMA* - Shortened form for Power Management Application, the system
integrator provided application that maintains any power management
policies and enforces action upon them.

*LPS* - Any of the CPU low power states supported by the processor.
Generally the one saving most power.

Arch Independent Power States:

On X86:

*Active* - The CPU is currently active and running in the hardware defined
C0

*Idle* - The CPU is not currently active, and continues to be powered on.
The CPU may be in one of any lower C-state d(i.e. C1, C2, etc).

*Deep Sleep* - Core voltage rail and system clock turned off. RAM
retained.

On ARM:

*Active* - The CPU is currently active and running

*Idle* - Stops the processor clock. The ARC documentation describes this
as Sleep.

*Deep Sleep* - Stops the system clock and switches off the PLL and flash
memory. RAM retained.

On ARC:

*Active* - The CPU is currently active and running in the SS0 state

*Idle* - Defined as the SS1 state, with the core clock gated.

*Deep Sleep* - Defined as the SS2 state, entered via SLEEP command, gates
timers, clock complex, and peripherals. RAM retained.


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

Boie, Andrew P
 

On Thu, 2016-03-10 at 11:06 +0100, Chény, Yves-Gael wrote:
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 )
The best thing to do if you find code defects is one of two things:

1. Send a patch to Gerrit that fixes it for review.
2. File a bug in JIRA https://jira.zephyrproject.org/ so that the issue
is tracked, eventually someone will get around to fixing it.

Regards,
Andrew


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

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Mar 10, 2016 at 02:46:02PM -0500, Boie, Andrew P wrote:
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.
Question: if they're almost the same, do we really need an extra
directory layer, or simply have different files for the parts that
differ in the same directory ? That would prevent directory
proliferation...

That said, I don't really have a problem with multiple directory layers
if it keeps things clear, and more importantly, if it prevents code
duplication.

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
I don't think we want to go back to variants. We had those at some
point for BSPs, which were the equivalents of SoCs, and the variants
represented the boards really. If we need a variant, that's probably a
sign that we need an extra layer between SoCs and architectures. Like
SoC "family" ?

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


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,

7601 - 7620 of 7909