Date   

Building project

Corey Williamson <corey.bailey.williamson@...>
 

Hi,

I'm currently trying to build the hello world example in a directory
outside the zephyr SDK and I keep getting this make error:

corey(a)corey-H97M-D3H:~/ZephyrWorkspace/eclipse_workspace/hello_world$ make
Using
/home/corey/ZephyrWorkspace/zephyr-project/boards/frdm_k64f/frdm_k64f_defconfig
as base
Merging
/home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config
The merge file
'/home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config'
does not exist. Exit.
make: ***
[/home/corey/ZephyrWorkspace/eclipse_workspace/hello_world/outdir/.config]
Error 1

I thought I might be environment variables but I echoed ZEPHYR_BASE and it
was correct.

Any help is much appreciated,

Thanks!

Corey


Re: Counter driver API

Tseng, Kuo-Lang
 

Just to add missing sub-folder name in the hardware specific driver path:

-----Original Message-----
From: Tseng, Kuo-Lang [mailto:kuo-lang.tseng(a)intel.com]
Sent: Friday, February 26, 2016 12:29 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] RFC: Counter driver API

Hi,

As per suggestion from Gerrit comment, moving the discussion to mailing list.

Background
--------------

On Quark (SE and D2000), there are Always On Counter (free running) and
Always ON Periodic Timer devices. A counter|timer driver is to be added for
supporting these devices. At same time, the goal is to create an API that is
generic enough for not just these two specific devices.

Proposal:
-----------

Generic counter driver API:
-------------------------------
We will have 3 routines - start, stop, and read, which takes in the device pointer
- which identifies the timer. The driver header, counter.h, is under /include
folder:

/**
* @brief Set up counter configuration and start it.
* @param dev Pointer to the device structure for the driver instance.
* @param config Pointer to counter configuration structure
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_start(struct device *dev, counter_input *config);

/**
* @brief Stop the counter.
* @param dev Pointer to the device structure for the driver instance.
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_stop(struct device *dev);

/**
* @brief Read current counter value
* @param dev Pointer to the device structure for the driver instance.
*
* @return 32-bit value
*/
uint32_t counter_read(struct device *dev)

The counter_input structure can be something like below:

/**
* @brief Counter configuration.
*
* Acceptable setting in the configuration structure is hardware-specific.
*
* initial_value - Initial value to load to the counter or timer.
* callback - Callback function when timer expires.
*/
struct counter_input {
uint32_t initial_value;
void (*callback)(void);
};

Note - Using structure, tomorrow we can add more fields for a counter with
more features.
For the Free Running counter in Quark, these fields would be null as it does not
support interrupt or callback notification.

The hardware-specific driver implementation:
-----------------------------------

This can be implemented in /drivers directory. For example, for Quark SE and
D2000, we can have below file which implements the API functionality using the
AON Counter and AON Periodic Timer:

drivers/quark_aon_counter.c
I missed sub-folder name here. It should be drivers/counter/quark_aon_counter.c


Comment, feedback welcome.


[RFC] Docker-based development environment for Windows

LeMay, Michael <michael.lemay@...>
 

Problem: Setting up a Zephyr development environment on Microsoft Windows involves many steps.

Proposal: Use Docker to automate the setup procedure.

Docker Toolbox (https://www.docker.com/products/docker-toolbox) can be installed on Windows. It automates the installation of a VMM and a Linux VM suitable for running Docker containers. It also installs associated tools.

A Dockerfile is a sort of script for creating a Linux container (https://docs.docker.com/engine/reference/builder/). I wrote one that automates the creation of a Zephyr development environment based on Ubuntu 15.10. It's fairly short, so I pasted it at the end of this message in its entirety. It would be placed in a new, empty directory, e.g. $ZEPHYR_BASE/scripts/docker.

To build the container, the developer would execute "docker build -t zephyr-build ." in that directory from the "Docker Quickstart Terminal".

To run the container, the developer would execute "docker run -t -i -v /c/Users/<username>/<zephyr_src_dir>:/zephyr zephyr-build", where <zephyr_src_dir> is a Zephyr source tree. This would present the developer with a command prompt in the Zephyr development environment with the root of the Zephyr source tree as the initial working directory.

To build an app, the developer would navigate to the desired app source directory and execute the same commands that would be used in any other Ubuntu Linux environment. The output binary can be accessed from Windows after being built.

This environment is also suitable for building GRUB for the Intel Galileo using the scripts/build_grub.sh script. However, the script must first be copied to /tmp within the Linux container and executed from there, since the GRUB build process is incompatible with the virtual filesystem for the Zephyr source tree.

I think that this environment would only be suitable for building Zephyr binaries. Installing the binaries to the target is an orthogonal procedure. The files simply need to be copied to a USB-connected flash device for a board like the Intel Galileo, but the installation procedure is more complicated for some other boards.

I can submit this Dockerfile as a patch with associated documentation if it seems potentially useful.

This could potentially be useful on other platforms besides Windows, but I have only tested it on Windows 10 so far.

--
Dockerfile:

FROM ubuntu:15.10

RUN apt-get update \
&& apt-get install -y \
autoconf automake bison bzip2 file flex gcc-multilib git make python \
&& rm -rf /var/lib/apt/lists/*

WORKDIR /tmp
ENV SDK_VER 0.7.2
ENV SDK_ARCHIVE zephyr-sdk-$SDK_VER-i686-setup.run
ADD https://nexus.zephyrproject.org/content/repositories/releases/org/zephyrproject/zephyr-sdk/$SDK_VER-i686/$SDK_ARCHIVE ./
RUN chmod u+x $SDK_ARCHIVE
ENV ZEPHYR_SDK_INSTALL_DIR /opt/zephyr-sdk
RUN ./$SDK_ARCHIVE --nox11 -- -d $ZEPHYR_SDK_INSTALL_DIR
RUN rm $SDK_ARCHIVE

RUN echo export ZEPHYR_GCC_VARIANT=zephyr >> ~/.bashrc
RUN echo export ZEPHYR_SDK_INSTALL_DIR=$ZEPHYR_SDK_INSTALL_DIR >> ~/.bashrc
RUN echo source /zephyr/zephyr-env.sh >> ~/.bashrc

WORKDIR /zephyr
CMD ["/bin/bash", "-l"]


Re: STM32F103x port

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


Re: RFC[1/2] Common logging infrastructure and API

Nashif, Anas
 

Hi,




On 24/02/2016, 17:13, "Saucedo Tejada, Genaro" <genaro.saucedo.tejada(a)intel.com> wrote:

Hello, please review this proposal and provide feedback if possible.
This email should be followed by a patch containing a prototype
implementation for reference but not meant to be applied.

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 retaining (and reusing) all
existing logging features when decided by developers.

Additional features are proposed anticipating possibly desired
functionality.
This is a much needed enhancement, thanks for making this proposal.



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, compatible 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 2.1 below).

The retained features surveyed on existing implementations of logging
are:

1. Make based identification of output appender, these currently being
stdio printf when console is available and printk as fall back.

2. Optional macro expansion, controlled by Kconfig files and make
menuconfig command. Disabling this helps saving memory on production
when logging is not needed.

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

3. Multilevel log formatting.

3.1 Colored log, when console is active it helps differentiate three
existing log levels. currently in use only on Bluetooth files.

4. Caller thread printing, currently Bluetooth files print the current
thread pointer.

5. Caller function printing, some logging macros print the function
that called them.

All above features are kept by this proposal and most become
configurable. The following new ones are added:

6. Labeled log, helps differentiate log levels by using a tag, useful
if color is not available.

7. Incremental per-level log activation. Orthogonal to existing per-
feature filter, this filter allows to set one logging level out of:
INFO, ERROR, WARNING and DEBUG. The higher the level the more verbose
the log becomes. Also as levels are hidden by preprocessor decreasing
level also helps reducing footprint. This is set at menuconfig as well.
We need to make sure we support logging for more than debugging and during development. In most cases logging will be used during development to assist with debugging and printing information on the console, however, we need to make sure this design also addresses cases where logging is part of the application, for example you might want to write to a file-system, send messages to a remote endpoint or write messages to a connected display. This basically means we also need to support different backends, the most immediate and straightforward backend would be printing to the console using printk and printf.

An application should be able to configure the domains and levels it wants to log, for example, if I am debugging an issue with I2C and I am only interested in I2C, I want to be able to select this domain and the logging level, so for example:

the defaults:
CONFIG_LOG=y
CONFIG_LOG_BACKEND=“printk”
CONFIG_LOG_DOMAINS=“*”

CONFIG_LOG_LEVEL=“INFO”


would enable logging (INFO) for everything using printk

For the case above I would change the following in my application .config:

CONFIG_LOG_DOMAINS=“I2C”
CONFIG_LOG_LEVEL=“DEBUG”






Design decisions and rationale:

It was decided to implement this API preferring macros instead of run-
time functions (except for thread retrieval) in an attempt to minimize
overhead introduced by logging.

Also, within this macro implementation, two extreme sides can be
discerned, these are concatenate compile time values with preprocessor
## versus using printf format arguments (%s). Preferring formatting
slightly impacts run-time overhead while preferring preprocessor
concatenation produces longer strings that duplicate substrings. In
this case none of the extremes was reached, instead something closer to
formatting was picked seeking to keep the prototype code simpler. Final
patch can be tuned likewise or one of the two extreme approaches can be
taken.

Implementation details:

The patch following this email is meant as proof-of-concept prototype.
It might compile but has not been thoughtfully tested and it only
covers Bluetooth and lcd_rgb.c files.

In this example path configuration is done through menuconfig, new
options need to be enabled in addition to existing ones, for modified
files CONFIG_BLUETOOTH_CONN, CONFIG_BLUETOOTH_DEBUG,
CONFIG_BLUETOOTH_DEBUG_HCI_CORE and CONFIG_GROVE_DEBUG.

A "logging domain" can be specified, it helps filter a log output in
case several features are enabled, domain is specified by:
LOG_DMN: short for log domain.

Example:
#define LOG_DMN "bt"
Just use LOG_DOMAIN, no need to abbreviate this



The macros at logging.h get enabled by two definitions:
CONFIG_USE_COMPILE_LOG: This is the global Kconfig switch for logging.
Keep it simple, CONFIG_LOG, the COMPILE wording can be misleading, In Kconfig we compile almost everything that is enabled, i.e. y means USE_COMPILE...


LOG_THIS_MODULE: This is an additional switch intended to bridge the
generic definitions on the header to a feature-specific logging switch
from Kconfig.

Example usage of LOG_THIS_MODULE:
#define LOG_THIS_MODULE CONFIG_BLUETOOTH_DEBUG_HCI_CORE
#include <logging.h>
I think this is were things will get confusing, we do need to change all of those existing DEBUG variables and make them work with the new model instead of keeping them in the code. See my example above, using the right domains and level, the same will be achieved.



That way logging.h will know that if CONFIG_BLUETOOTH_DEBUG_HCI_CORE
was not set by menuconfig it should not log at all (at current
compilation unit).

This requires an additional line to be included by files that use
logging but could be made optional, doing so requires deciding default
behavior between having unfiltered features (on 2.1 filter mentioned
above) or allowing developer to included logging.h file with no effect.
On current prototype this line requirement is enforced by #error
directive.

Future work:

* Final patch needs to unify system wide the macro naming and such
naming should be less likely to collide.
* An alternative run-time implementation could be later developed to
provide more features.
* Compare footprint between different degrees of ## usage over printf
format.

We should implement backends and clean up all the custom DEBUG usage in Kconfig and move everything to the new model reducing complexity and making things more consistent.

Please make sure we have a JIRA story to track this and add the final proposal to that JIRA once we have reached consensus.

Anas



Example macro expansions:

printf("" "%s%s\t%p: %s" "Grove LCD: background set to white\n" "%s\n",
"DBG ", __func__, sys_thread_self_get(), "", "");
(messages were left unchaged so domain is still repeated as part of the
message)
printf("bt" ":\t" "%s%s\t%p: %s" "Unable to allocate new HCI command"
"%s\n", "", __func__, sys_thread_self_get(), "\x1B[0;31m", "\x1B[0m");
(domain is defined through macro, color and thread are in use)
printf("bt" ":\t" "%s%s\t: %s" "No HCI driver registered" "%s\n", "",
__func__, "\x1B[0;31m", "\x1B[0m");
(same but without thread)


Re: RFC[2/2] Common logging infrastructure and API

Nashif, Anas
 

Hi

On 24/02/2016, 17:13, "Saucedo Tejada, Genaro" <genaro.saucedo.tejada(a)intel.com> wrote:

From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001
From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com>
Date: Fri, 19 Feb 2016 17:10:28 -0600
Subject: [PATCH] Log macros unified in a common API

Introduces a header to concentrate logging macro definitions for all
code to
reuse, change aims to provide all currently existing logging
functionality so
every C file can replace it's compile-unit definitions by common code.

Later enhancements to log can now be performed in a single file.

Features:
* Optional printing of thread pointer
* Optional printing of colored messages
* Optional printing of a label to indicate logging level (info, error,
warning, debug)
* Caller function name printing
* Incremental log levels
* One point log disable

See my comments on the first email..

- we need to make all existing code use this feature and how it was defined and avoid designing it to match EVERY existing custom logging and debugging implementation we currently have.
- support multiple logging backends

- split this patch, add the feature and testcases then add a sample that can be used for as a reference by developers
- need to work on better variable names, avoid extreme abbreviations (LV -> LEVEL, DMN -> DOMAIN,...)

few comments below..


Change-Id: Ibe542d69912778703bb43c7afef0889f0591ba6a
Signed-off-by: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com>
---
drivers/grove/lcd_rgb.c | 14 +---
include/bluetooth/log.h | 28 +++----
include/logging.h | 166
++++++++++++++++++++++++++++++++++++++++
misc/debug/Kconfig | 66 ++++++++++++++++
net/bluetooth/Kconfig | 3 +-
net/bluetooth/hci_core.c | 5 --
tests/bluetooth/tester/prj.conf | 2 +
7 files changed, 250 insertions(+), 34 deletions(-)
create mode 100644 include/logging.h

diff --git a/drivers/grove/lcd_rgb.c b/drivers/grove/lcd_rgb.c
index 58b86c5..7ef6a78 100644
--- a/drivers/grove/lcd_rgb.c
+++ b/drivers/grove/lcd_rgb.c
@@ -29,17 +29,9 @@
#define GROVE_LCD_DISPLAY_ADDR (0x3E)
#define GROVE_RGB_BACKLIGHT_ADDR (0x62)

-#ifndef CONFIG_GROVE_DEBUG
-#define DBG(...) { ; }
-#else
-#if defined(CONFIG_STDOUT_CONSOLE)
-#include <stdio.h>
-#define DBG printf
-#else
-#include <misc/printk.h>
-#define DBG printk
-#endif /* CONFIG_STDOUT_CONSOLE */
-#endif /* CONFIG_GROVE_DEBUG */
+/* module specific logging check */
+#define LOG_THIS_MODULE CONFIG_GROVE_DEBUG
+#include <logging.h>

struct command {
uint8_t control;
diff --git a/include/bluetooth/log.h b/include/bluetooth/log.h
index e47453a..e5abbab 100644
--- a/include/bluetooth/log.h
+++ b/include/bluetooth/log.h
@@ -26,25 +26,19 @@
extern "C" {
#endif

-#if defined(CONFIG_BLUETOOTH_DEBUG_COLOR)
-#define BT_COLOR_OFF "\x1B[0m"
-#define BT_COLOR_RED "\x1B[0;31m"
-#define BT_COLOR_YELLOW "\x1B[0;33m"
-#else
-#define BT_COLOR_OFF ""
-#define BT_COLOR_RED ""
-#define BT_COLOR_YELLOW ""
-#endif
-
#if defined(CONFIG_BLUETOOTH_DEBUG)
+
+/* module specific logging check */
+#define LOG_THIS_MODULE CONFIG_BLUETOOTH_DEBUG_HCI_CORE
+/* specify logging domain */
+#define LOG_DMN "bt"
+#include <logging.h>
+
#include <nanokernel.h>
-#define BT_DBG(fmt, ...) printf("bt: %s (%p): " fmt "\n", __func__, \
- sys_thread_self_get(), ##__VA_ARGS__)
-#define BT_ERR(fmt, ...) printf("bt: %s: %s" fmt "%s\n", __func__, \
- BT_COLOR_RED, ##__VA_ARGS__,
BT_COLOR_OFF)
-#define BT_WARN(fmt, ...) printf("bt: %s: %s" fmt "%s\n", __func__, \
- BT_COLOR_YELLOW, ##__VA_ARGS__,
BT_COLOR_OFF)
-#define BT_INFO(fmt, ...) printf("bt: " fmt "\n", ##__VA_ARGS__)
+#define BT_DBG(fmt, ...) DBG(fmt, ##__VA_ARGS__)
+#define BT_ERR(fmt, ...) ERR(fmt, ##__VA_ARGS__)
+#define BT_WARN(fmt, ...) WRN(fmt, ##__VA_ARGS__)
+#define BT_INFO(fmt, ...) INF(fmt, ##__VA_ARGS__)
#define BT_ASSERT(cond) if (!(cond)) { \
BT_ERR("assert: '" #cond "' failed");
\
}
diff --git a/include/logging.h b/include/logging.h
new file mode 100644
index 0000000..d778da9
--- /dev/null
+++ b/include/logging.h
@@ -0,0 +1,166 @@
+/*
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/** @file logging.h
+ * @brief Logging macros.
+ */
+#ifndef __LOGGING_H
+#define __LOGGING_H
+
+#if !defined LOG_THIS_MODULE
+#error DO NOT include this header without defining LOG_THIS_MODULE
+#endif
+
+#if defined CONFIG_USE_COMPILE_LOG && (1 == LOG_THIS_MODULE)
+
+#define IS_LOGGING_ACTIVE 1
+#define THREAD_FN_CALL sys_thread_self_get()
+
+/* decide print func */
+#if defined(CONFIG_STDOUT_CONSOLE)
+#include <stdio.h>
+#define LOG_FN printf
+#else
+#include <misc/printk.h>
+#define LOG_FN printk
+#endif /* CONFIG_STDOUT_CONSOLE */
+
The above should be defined using backend support.


+/* Should use color? */
+#if defined(CONFIG_USE_LOG_COLOR)
+#define LOG_COLOR_OFF "\x1B[0m"
+#define LOG_COLOR_RED "\x1B[0;31m"
+#define LOG_COLOR_YELLOW "\x1B[0;33m"
+#else
+#define LOG_COLOR_OFF ""
+#define LOG_COLOR_RED ""
+#define LOG_COLOR_YELLOW ""
+#endif /* CONFIG_BLUETOOTH_DEBUG_COLOR */
+
+/* Should use log lv labels? */
+#if defined(CONFIG_USE_LOG_LV_TAGS)
+#define LOG_LV_ERR "ERR "
+#define LOG_LV_WRN "WRN "
+#define LOG_LV_INF "INF "
+#define LOG_LV_DBG "DBG "
+#else
+#define LOG_LV_ERR ""
+#define LOG_LV_WRN ""
+#define LOG_LV_INF ""
+#define LOG_LV_DBG ""
+#endif /* CONFIG_USE_LOG_LV_TAGS */

Use LEVEL instead of LV


+
+/* Log domain name */
+#if defined LOG_DMN
+#define LOG_DMN_TAG LOG_DMN ":\t"
+#else
+#define LOG_DMN_TAG ""
+#endif /* LOG_DMN */

DOMAIN

+
+/* Should thread be printed on log? */
+#if defined CONFIG_PRINT_THREAD_LOG
+#define LOG_LAYOUT LOG_DMN_TAG "%s%s\t%p: %s" /* label func thread */
+#define LOG_FN_CALL(log_lv, log_color, log_format, color_off, ...)
\
+ LOG_FN(LOG_LAYOUT log_format "%s\n",
\
+ log_lv, __func__, THREAD_FN_CALL, log_color, ##__VA_ARGS__,
color_off)
+#else
+#define LOG_LAYOUT LOG_DMN_TAG "%s%s\t: %s" /* label func */
+#define LOG_FN_CALL(log_lv, log_color, log_format, color_off, ...)
\
+ LOG_FN(LOG_LAYOUT log_format "%s\n",
\
+ log_lv, __func__, log_color, ##__VA_ARGS__, color_off)
+#endif /* CONFIG_PRINT_THREAD_LOG */
+
+#define LOG_NO_COLOR(log_lv, log_format, ...)
\
+ LOG_FN_CALL(log_lv, "", log_format, "", ##__VA_ARGS__)
+#define LOG_COLOR(log_lv, log_color, log_format, ...)
\
+ LOG_FN_CALL(log_lv, log_color, log_format, LOG_COLOR_OFF,
\
+ ##__VA_ARGS__)
+
+/**
+ * @def INF
+ *
+ * @brief Writes information to log
+ *
+ * @details Lowest logging lv, these messages are not disabled unless
whole
+ * logging gets disabled.
+ *
+ * @param A kprint valid format string and optinally, kprint
formateable
+ * arguments.
+ */
+#define INF(...) LOG_NO_COLOR(LOG_LV_INF, ##__VA_ARGS__)
+
+#if defined(CONFIG_LOG_LV_ERR) || defined(CONFIG_LOG_LV_WRN) \
+ || defined(CONFIG_LOG_LV_DBG)
+/**
+ * @def ERR
+ *
+ * @brief Writes Errors to log
+ *
+ * @details available if CONFIG_USE_COMPILE_LOG is CONFIG_LOG_LV_ERR
or higiher,
+ * it's meant to report fatal errors that can't be recovered from.
+ *
+ * @param A kprint valid format string and optinally, kprint
formateable
+ * arguments.
+ */
+#define ERR(...) LOG_COLOR(LOG_LV_ERR, LOG_COLOR_RED, ##__VA_ARGS__)
+#else
+#define ERR(...) { ; }
+#endif
+
+#if defined(CONFIG_LOG_LV_WRN) || defined(CONFIG_LOG_LV_DBG)
+/**
+ * @def WRN
+ *
+ * @brief Writes warnings to log
+ *
+ * @details available if CONFIG_USE_COMPILE_LOG is CONFIG_LOG_LV_WRN
or higiher,
+ * it's meant to print unexpedted situations that are not necesarily
an error.
+ *
+ * @param A kprint valid format string and optinally, kprint
formateable
+ * arguments.
+ */
+#define WRN(...) LOG_COLOR(LOG_LV_WRN, LOG_COLOR_YELLOW,
##__VA_ARGS__)
+#else
+#define WRN(...) { ; }
+#endif
+
+#if defined(CONFIG_LOG_LV_DBG)
+/**
+ * @def DBG
+ *
+ * @brief Writes debugging information to log
+ *
+ * @details highest logging level, available if CONFIG_USE_COMPILE_LOG
is
+ * CONFIG_LOG_LV_DBG, it's meant to print developer information.
+ *
+ * @param A kprint valid format string and optinally, kprint
formateable
+ * arguments.
+ */
+#define DBG(...) LOG_NO_COLOR(LOG_LV_DBG, ##__VA_ARGS__)
+#else
+#define DBG(...) { ; }
+#endif
+
+#else
+#define IS_LOGGING_ACTIVE 0
+/* create dummy macros */
+#define DBG(...) { ; }
+#define ERR(...) { ; }
+#define WRN(...) { ; }
+#define INF(...) { ; }
+
+#endif /*USE_COMPILE_LOG*/
+
+#endif /* __LOGGING_H */
diff --git a/misc/debug/Kconfig b/misc/debug/Kconfig
index 51a3d3f..716a361 100644
--- a/misc/debug/Kconfig
+++ b/misc/debug/Kconfig
@@ -16,6 +16,72 @@
# limitations under the License.
#

+config USE_COMPILE_LOG
+ bool
+ prompt "Enable Logging"
+ default n
+ help
+ Global switch for logging.
+
+config USE_LOG_LV_TAGS
+ bool
+ prompt "Prepend level tags to logs"
+ depends on USE_COMPILE_LOG
+ default y
+ help
+ Log lines will beging with one of INF, ERR, WRN or DBG,
depending on the
+ macro used at C code.
+
+config USE_LOG_COLOR
+ bool
+ prompt "Use colored logs"
+ depends on USE_COMPILE_LOG
+ default n
+ help
+ Use color in the logs. This requires an ANSI capable
terminal.
+
+config PRINT_THREAD_LOG
+ bool
+ prompt "Include thread on log messages"
+ depends on USE_COMPILE_LOG
+ default n
+ help
+ Each log line will include the pointer of the thread that
printed it
+
+choice
+depends on USE_COMPILE_LOG
+prompt "Log level"
+
+config LOG_LV_INF
+ bool
+ prompt "Info"
+ help
+ Print just unfiltered logging.
+
+config LOG_LV_ERR
+ bool
+ prompt "Error"
+ help
+ Do not filter printing of ERR logging macro, it is meant to
report fatal
+ errors.
+
+config LOG_LV_WRN
+ bool
+ prompt "Warning"
+ help
+ Do not filter printing of WRN and above logging macros, WRN
marcro is
+ meant to print messages generated under unexpedted
circumstances, not
+ necesarily errors.
+
+config LOG_LV_DBG
+ bool
+ prompt "Debug"
+ help
+ Enable printing of all logging macros, DBG is meant to print
developer
+ information.
+
+endchoice
+

menu "Safe memory access"

diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 8dcbbcf..222199d 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -218,7 +218,8 @@ config BLUETOOTH_DEBUG
serial console.

if BLUETOOTH_DEBUG
-config BLUETOOTH_DEBUG_COLOR
+config BLUETOOTH_DEBUG_COLOR
+ select USE_LOG_COLOR
bool "Use colored logs"
default y
help
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d5b6d24..00ad8d2 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -50,11 +50,6 @@
#include "smp.h"
#endif /* CONFIG_BLUETOOTH_SMP */

-#if !defined(CONFIG_BLUETOOTH_DEBUG_HCI_CORE)
-#undef BT_DBG
-#define BT_DBG(fmt, ...)
-#endif
-
/* Stacks for the fibers */
static BT_STACK_NOINIT(rx_fiber_stack,
CONFIG_BLUETOOTH_RX_STACK_SIZE);
static BT_STACK_NOINIT(rx_prio_fiber_stack, 256);
diff --git a/tests/bluetooth/tester/prj.conf
b/tests/bluetooth/tester/prj.conf
index 617e07c..af53ace 100644
--- a/tests/bluetooth/tester/prj.conf
+++ b/tests/bluetooth/tester/prj.conf
@@ -1,5 +1,7 @@
CONFIG_UART_PIPE=y
CONFIG_CONSOLE_HANDLER=y
+CONFIG_USE_COMPILE_LOG=y
+CONFIG_LOG_LV_DBG=y
CONFIG_BLUETOOTH=y
CONFIG_BLUETOOTH_LE=y
CONFIG_BLUETOOTH_CENTRAL=y
--
2.5.0


Re: STM32F103x port

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


Re: STM32F103x port

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


RFC [0/3] - SoC, CPU LPS, Tickless idle and Device power management

Thomas, Ramesh
 

Migrating this RFC from the old server for reference. This is updated
with the feedbacks that were incorporated. This consists of the
following parts:

[0/3] - This overview
[1/3] - SoC, CPU and Tickless Idle power management (merged)
[2/3] - Device power management (under review)
[3/3] - Areas to be implemented next including open feedbacks

Following are the main areas to address for power management support in
Zephyr:
1. Kernel SoC power management hook infrastructure in Zephyr
2. Kernel CPU low power state and Tickless idle power management hook
infrastructure.
3. Device driver power management hook infrastructure

Goal:
This support in Zephyr kernel is added to assist system integrator's
implementation of Power Management policy and service.

Non-goal - Zephyr kernel will not:
a) Implement any Power Management policy - The integrator's power
management service app would implement power policy
b) Implement any code to save/restore registers or SoC or device states.
- The integrator's power management service app and device drivers
should take care of that.


RFC [1/3] - SoC, CPU LPS, Tickless idle and Device power management

Thomas, Ramesh
 

***This part is merged***
https://gerrit.zephyrproject.org/r/#/c/148/
https://gerrit.zephyrproject.org/r/#/c/149/
https://gerrit.zephyrproject.org/r/#/c/150/
https://gerrit.zephyrproject.org/r/#/c/151/

Kernel SOC power management hook infrastructure in Zephyr
-----------------------------------------------------------------------
This infrastructure provides hooks at locations where the kernel goes to
idle to enable the PM service application to do suspend operations
around them.

This infrastructure can be used by power manager app to implement PM
policy and to put system to various power states. A sample PM
application is provided as an example to demonstrate how to use these
hooks and the states it uses (listed below) are for demonstration
purpose. It is up to the implementer of the PM service app to design their own.

1. LPS:
CPU is put in low power states like C2. The CPU states are not lost.
Woken up by any interrupt.

2. Deep Sleep:
The SoC is put in deep sleep state saving most power. In this state, CPU
power is off while SRAM contents are retained. Woken up by deep
sleep wake up events of SoC. On wake up, execution will resume from
reset vector.

3. Tickless Idle power saving:
Zephyr kernel has its own idling called Tickless idle. PM service can
take advantage of this by turning off peripherals to save more power
when the hook infrastructure notifies it before going to idle. It will
be notified again when kernel exits the tickless idle state when it can
restore states it altered.

The hook functions:
These functions must be implemented by the power management service app.

a) int _sys_soc_suspend(int32_t ticks)
param ticks:
- the upcoming kernel idle time

return:
- non-zero value if it uses its own idle or deep sleep. If a zero value
is returned, then kernel will enter its own idle.

Details:
This is called immediately before the kernel prepares to go into its
idle state. The PM service, based on the amount of idle time available,
chooses an appropriate power policy comparing the wake latencies involved.

For CPU low power states it would put the CPU in states like C2. For
SoC deep sleep states, it would do the required SoC specific operation.
In these, it would return a non-zero value indicating it has fully
handled the idle and the kernel will not enter its own idle.

For tickless idle power saving, the PM service app can turn off as many
peripherals it requires and then returns a zero value. The zero return
value would indicate to the kernel that it should do its own idle.

This function is entered with interrupts disabled. It should re-enable
interrupts if it does its own idle or deep sleep. If it returns zero
then it should not enable interrupts so the kernel can go to idle state
without interruption.

b) void _sys_soc_resume(void)

Details:
The main purpose of this hook is to notify PM service of exit from SoC
deep sleep state, CPU low power and tickless idle exit. Any states
altered at _sys_soc_suspend() should be restored in this function.

This hook function is called from 2 different locations in the kernel.
PM service will check its internal states to determine which state the
system recovering from.

Following are the 2 different locations where it called from:
1. At kernel start recovering from deep sleep or entering cold boot.
Deep sleep causes all CPU states to be lost so the system resumes at the
reset vector taking the same path as cold boot. Since kernel does not
save any state to identify whether it is recovering from cold boot or
deep sleep, it would call this function in both cases. PM service can
use SoC specific sticky registers that can retain values across deep
sleep to identify whether it is resuming from deep sleep. In the case
of cold boot, these registers would get reset.

If it is cold boot then this function should return immediately doing
nothing.

If it is recovering from deep sleep then it should restore states
including CPU registers and stack stored in _sys_soc_suspend().
Execution context should then switch to execution inside
_sys_soc_suspend() at the location where it put the system to deep sleep.

In this location, this function is called using a temporary stack that
is also used by interrupts. It is important that this function switches
to the stack that was saved during _sys_soc_suspend before interrupts
are enabled when returning from _sys_soc_suspend() to avoid interfering
with interrupt handlers use of this stack.

2. After the exit of tickless idle or a low power CPU state from the
context of the ISR that caused the exit. In this case, PM service will
restore altered states and return.


RFC [2/3] - SoC, CPU LPS, Tickless idle and Device power management

Thomas, Ramesh
 

***These are implemented and under review***
https://gerrit.zephyrproject.org/r/#/c/532/
https://gerrit.zephyrproject.org/r/#/c/528/
https://gerrit.zephyrproject.org/r/#/c/525/

Device driver power management hook infrastructure
------------------------------------------------------
When the _sys_soc_suspend() and _sys_soc_resume() hook functions are
called, the PM service app may want to do some device specific
operations. Zephyr kernel provides this infrastructure to enable device
drivers to define suspend and resume hook functions that can be called
by the PM service app.

Following are the goals for providing this infrastructure:
1. A framework for drivers to implement generic suspend/resume hook
functions.
2. Provide means for PM app service to call the suspend and resume
functions of all devices in the system. This is necessary especially to
do suspend and resume operations on system devices like the APIC device
which do not export device binding interface.
3. Since not all devices need to implement suspend and resume hook
functions, provide a no-op function by default for such devices. By
default all devices would be setup with the no-op function for their
hooks. The device drivers who need specific handling would assign the
addresses of the functions they implement to these hooks during
initialization.

Non-goals:
The implementation of the hook functions by the device drivers is up to
each driver, the integrator and the system power management policies.

All device power management infrastructure implementations is enclosed
inside CONFIG_DEVICE_POWER flag.

The hook functions for the PM service app:
a) int device_suspend(struct device *port)
param port:
Device structure of the driver instance

return:
DEV_OK for success, error code otherwise

Details - calls the suspend hook of the device associated with the
device structure parameter.

b) int device_resume(struct device *port)
param port:
Device structure of the driver instance

return:
DEV_OK for success, error code otherwise

Details - calls the resume hook of the device associated with the device
structure parameter.

c) void device_suspend_all(bool system_devices)
param system_devices
Boolean true for only the system devices; else all devices

Details:
Kernel holds a list of all devices in the system. This function will
iterate through that list and call the suspend hook function of each
device in the list. It will do this in the reverse order in which the
devices were initialized.

If the <system_devices> parameter is false then it would call all
devices. If it is true then it would call the suspend/resume of only
system devices. This parameter is provided because it is mandatory for
the PM service app to call this function for system devices. This is
because it cannot bind to them and call their suspend/resume functions
directly. For non-system devices, the PM service app can bind to thm
and has the flexibility to call whichever device it requires to call and
in the order it chooses to. If it chooses to call the suspend/resume
functions of non-system devices individually, then it would call this
function passing true for the <system_devices> parameter.

d) void device_resume_all(bool system_devices)
param system_devices
Boolean true for only the system devices; else all devices

Details:
The description is same as for device_suspend_all() except, this would
call the resume hook functions of devices and they would be called in
the same order as the devices were initialized.

API for device drivers:
Structure storing the hook functions. This structure is stored in the
device's "device" structure.
struct device_power_ops {
device_op_t suspend;
device_op_t resume;
}

The NO-OP function:
int device_pm_noop(struct device *unused)
return - always returns DEV_OK.

Details:
No-op function that does nothing and returns DEV_OK immediately. This
can be used to initialize hooks for which the device has no operation to do.

The hooks inside device_power_ops structure are by default initialized
with this function by the kernel. Device drivers which have specific
operations for the hooks would overwrite with a suspend and resume
functions during driver initialization.

a) void device_power_ops_configure(struct device *port,
device_op_t suspend_fn, device_op_t resume_fn)
param port
- device structure of driver instance
param suspend_fn
- Address of suspend function
param resume_fn
- Address of resume function

Details:
Initializes the hook functions in device_power_ops with the functions
passed as parameters. This function should be called by devices during
the time of initialization if they have a specific suspend or resume
function implementation. Drivers can also pass the no-op function as
parameter for any of the hooks it does not have an operation. If it
does not have any operation for both suspend and resume then it need not
call this function at all. This is because the hooks for the devices are
by default initialized with the no-op function by the kernel.


RFC [3/3] - SoC, CPU LPS, Tickless idle and Device power management

Thomas, Ramesh
 

Areas to be implemented next:
1. ARC deep sleep support:
- Currently ARC in quark_se would be reset upon deep sleep initiated
from x86 core. It needs something like _sys_soc_resume() called at boot
time so it can restore states and resume at the point it suspended.

Suspend would be invoked from the x86 side so there is no need for a
suspend function.

2. Nanokernel tickless idle PM support:
- Currently tickless idle PM hooks are called only in microkernel idle
task. The same hook functions should also be called from nanokernel
tickless idle. Microkernel and Nanokernel implementations would
be consolidated. This consolidation would also make names of functions
uniform.


3. The naming of CONFIG flags and functions:
- The CONFIG flag names would be made consistent with the new power
management implementation. Also the dependencies between the flags
would be improved and unnecessary fags removed.

Feedbacks/Suggestions:
1. Provide arch specific helper functions used in the PM service app to
do state transitions and save/restore CPU thread contexts.
- Zephyr has arch specific code in arch folders. The suggestion is to
add functions in these locations and abstract them to the PM service app.


Re: Building project

Nashif, Anas
 

You have a typo in your makefile? mico instead of micro?

Anas

From: Corey Williamson <corey.bailey.williamson(a)gmail.com<mailto:corey.bailey.williamson(a)gmail.com>>
Date: To: "devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>" <devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>>
Subject: [devel] Building project

Hi,

I'm currently trying to build the hello world example in a directory outside the zephyr SDK and I keep getting this make error:

corey(a)corey-H97M-D3H:~/ZephyrWorkspace/eclipse_workspace/hello_world$ make
Using /home/corey/ZephyrWorkspace/zephyr-project/boards/frdm_k64f/frdm_k64f_defconfig as base
Merging /home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config
The merge file '/home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config' does not exist. Exit.
make: *** [/home/corey/ZephyrWorkspace/eclipse_workspace/hello_world/outdir/.config] Error 1

I thought I might be environment variables but I echoed ZEPHYR_BASE and it was correct.

Any help is much appreciated,

Thanks!

Corey


RFC - arm-gcc-embedded Toolchain Support

Hugo Vincent
 

Hi,

One of the complications of setting up a Zephyr development environment,
especially on OS X, is having to get and build CrossTool-NG. ARM maintains
an official distro and build of gcc and family for Cortex-M and Cortex-R at
https://launchpad.net/gcc-arm-embedded, which provides pre-built binaries
for Windows, Linux and Mac OS X.

I created a simple, minimal Makefile.toolchain.gcc-arm-embedded that adds
support for this toolchain to Zephyr, see attached patch. If there is
interest in accepting this, I can add qemu and OpenOCD to this, as well as
update the documentation, as well as generalising/parameterising the paths
etc. Please advise how to proceed.

I tested on the frdm_k64f board, with versions 4.9-2015-q2-update and
5.0-2015-q4-major of the toolchain, and with several of the example
applications, and they all functioned correctly.

(There is also another hunk in the patch that adds .DS_Store to gitignore
-- it's a metadata file generated by the OS X Finder, and can be safely
ignored).

Regards,
Hugo

(Disclaimer: I work at ARM, but this is a personal contribution).


Re: RFC - arm-gcc-embedded Toolchain Support

Nashif, Anas
 

Hugo,

Looks good to me. You can also do that by specifying CROSS_COMPILE at the command line, for example:

CROSS_COMPILE=arm-none-eabi- make BOARD=qemu_cortex_m3

will build using the installed ARM toolchain on my host. You do not need to specify the VARIANT.


Thanks,
Anas

From: Hugo Vincent <hugo.vincent(a)gmail.com<mailto:hugo.vincent(a)gmail.com>>
Date: To: "devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>" <devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>>
Subject: [devel] RFC - arm-gcc-embedded Toolchain Support

Hi,

One of the complications of setting up a Zephyr development environment, especially on OS X, is having to get and build CrossTool-NG. ARM maintains an official distro and build of gcc and family for Cortex-M and Cortex-R at https://launchpad.net/gcc-arm-embedded, which provides pre-built binaries for Windows, Linux and Mac OS X.

I created a simple, minimal Makefile.toolchain.gcc-arm-embedded that adds support for this toolchain to Zephyr, see attached patch. If there is interest in accepting this, I can add qemu and OpenOCD to this, as well as update the documentation, as well as generalising/parameterising the paths etc. Please advise how to proceed.

I tested on the frdm_k64f board, with versions 4.9-2015-q2-update and 5.0-2015-q4-major of the toolchain, and with several of the example applications, and they all functioned correctly.

(There is also another hunk in the patch that adds .DS_Store to gitignore -- it's a metadata file generated by the OS X Finder, and can be safely ignored).

Regards,
Hugo

(Disclaimer: I work at ARM, but this is a personal contribution).


Re: RFC: Counter driver API

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

On 02/26/2016 12:29 PM, Tseng, Kuo-Lang wrote:
Hi,

As per suggestion from Gerrit comment, moving the discussion to mailing list.

Background
--------------

On Quark (SE and D2000), there are Always On Counter (free running) and Always ON Periodic Timer devices. A counter|timer driver is to be added for supporting these devices. At same time, the goal is to create an API that is generic enough for not just these two specific devices.

Proposal:
-----------

Generic counter driver API:
-------------------------------
We will have 3 routines - start, stop, and read, which takes in the device pointer - which identifies the timer. The driver header, counter.h, is under /include folder:

/**
* @brief Set up counter configuration and start it.
* @param dev Pointer to the device structure for the driver instance.
* @param config Pointer to counter configuration structure
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_start(struct device *dev, counter_input *config);

/**
* @brief Stop the counter.
* @param dev Pointer to the device structure for the driver instance.
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_stop(struct device *dev);

/**
* @brief Read current counter value
* @param dev Pointer to the device structure for the driver instance.
*
* @return 32-bit value
*/
uint32_t counter_read(struct device *dev)

The counter_input structure can be something like below:

/**
* @brief Counter configuration.
*
* Acceptable setting in the configuration structure is hardware-specific.
*
* initial_value - Initial value to load to the counter or timer.
* callback - Callback function when timer expires.
*/
struct counter_input {
uint32_t initial_value;
end_count/expiration_count something like like that so the reader knows
how the value is used.

void (*callback)(void);
};

Note - Using structure, tomorrow we can add more fields for a counter with more features.
For the Free Running counter in Quark, these fields would be null as it does not support interrupt or callback notification.
Confused by this note. The always on counter does have an interrupt
it the only way for the device to signal counter expiration.

The hardware-specific driver implementation:
-----------------------------------

This can be implemented in /drivers directory. For example, for Quark SE and D2000, we can have below file which implements the API functionality using the AON Counter and AON Periodic Timer:

drivers/quark_aon_counter.c

Comment, feedback welcome.


Re: RFC: Counter driver API

D'alton, Alexandre <alexandre.dalton@...>
 

There are 2 aon counters:

Aon counter => monotinic counter without interrupt
Aon periodic timer => periodic timer with interrupt support

Regards,
Alex.

-----Original Message-----
From: Dirk Brandewie [mailto:dirk.j.brandewie(a)intel.com]
Sent: Monday, February 29, 2016 16:09
To: Tseng, Kuo-Lang <kuo-lang.tseng(a)intel.com>;
devel(a)lists.zephyrproject.org
Cc: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Subject: [devel] Re: RFC: Counter driver API



On 02/26/2016 12:29 PM, Tseng, Kuo-Lang wrote:
Hi,

As per suggestion from Gerrit comment, moving the discussion to mailing
list.

Background
--------------

On Quark (SE and D2000), there are Always On Counter (free running) and
Always ON Periodic Timer devices. A counter|timer driver is to be added for
supporting these devices. At same time, the goal is to create an API that is
generic enough for not just these two specific devices.

Proposal:
-----------

Generic counter driver API:
-------------------------------
We will have 3 routines - start, stop, and read, which takes in the device
pointer - which identifies the timer. The driver header, counter.h, is under
/include folder:

/**
* @brief Set up counter configuration and start it.
* @param dev Pointer to the device structure for the driver instance.
* @param config Pointer to counter configuration structure
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_start(struct device *dev, counter_input *config);

/**
* @brief Stop the counter.
* @param dev Pointer to the device structure for the driver instance.
*
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
*/
int counter_stop(struct device *dev);

/**
* @brief Read current counter value
* @param dev Pointer to the device structure for the driver instance.
*
* @return 32-bit value
*/
uint32_t counter_read(struct device *dev)

The counter_input structure can be something like below:

/**
* @brief Counter configuration.
*
* Acceptable setting in the configuration structure is hardware-
specific.
*
* initial_value - Initial value to load to the counter or timer.
* callback - Callback function when timer expires.
*/
struct counter_input {
uint32_t initial_value;
end_count/expiration_count something like like that so the reader knows how
the value is used.

void (*callback)(void);
};

Note - Using structure, tomorrow we can add more fields for a counter with
more features.
For the Free Running counter in Quark, these fields would be null as it
does not support interrupt or callback notification.
Confused by this note. The always on counter does have an interrupt it the
only way for the device to signal counter expiration.

The hardware-specific driver implementation:
-----------------------------------

This can be implemented in /drivers directory. For example, for Quark SE
and D2000, we can have below file which implements the API functionality
using the AON Counter and AON Periodic Timer:

drivers/quark_aon_counter.c

Comment, feedback welcome.
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


[PATCH 0/8] Adding generic suspend/resume infrasturcture.

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Since this change set was loosely based on my RFC on the subject prior
to release it is worth bringing the orginal design into this thread.

Given that most/all platforms we are targeting will care deeply about
power consumption this patch set changes the device model to *require*
that every driver do something about suspend/resume even it is just
providing a null implementation if there is nothing the device needs
to do during a suspend/resume cycle.

This patch does the following things:
Adds suspend/resume to *all* devices.

Provides a null suspend/resume implementation that can be used by
*all* drivers.

Provides an interface for the power management infrastrcuture (PMI) to
call suspend/resume on the device without needing to know the type
of the device.

Provides an interface where the PMI can register callbacks with the
driver to be called when suspend has completed and resume has
started. These call backs allow the PMI to do any processing
required to complete the suspend/resume of the device. e.g. clock
control, power to IP block. This is needed since there may be
multiple devices attached to a single clock or power island which
can only be disabled once all attached devices are suspended and
must be turned on prior to the first device resuming.

This keeps *all* the information about a device in one place. Forces
all drivers to support the suspend/resume interface.

This will require that all the current drivers be updated to support
the new interface. Now is the right time to do this before we get a
*bunch* more drivers added to the tree.

Patch 1 adds a PM enabled version of DEVICE_INIT() which is only there
to keep things building while the drivers are being updated. Once all
the drivers have been updated we can remove the extra macro with a
single tree wide change.

The API to suspend/resume all devices in the system was meant to show
how the PMI might want to suspend all devices and is not complete
since there is no error handling. After thinking about it more it is
not clear to me that we should provide this convienence API.

The changes to the GPIO interface and driver are meant to illustrate
the changes that will need to be applied to all the drivers in the
system.

Dirk Brandewie (8):
device: Add suspend/resume api functions to device structure
device: Add _null_suspend_resume() function
device: Add generic device_{suspend, resume}() API
device: Add API to suspend/resume all devices in the system.
device: pm: Add API for power management entity to register pm
callbacks
gpio: Remove suspend/resume from GPIO API
gpio: gpio_dw: Use generic suspend suspend/resume API
gpio: gpio_dw: Add suport for device_register_pm_ops()

drivers/gpio/gpio_dw.c | 48 ++++++++++++++++----
drivers/gpio/gpio_dw.h | 2 +
include/device.h | 109 +++++++++++++++++++++++++++++++++++++++++++++
include/gpio.h | 27 -----------
include/pm.h | 25 +++++++++++
kernel/nanokernel/device.c | 40 +++++++++++++++++
6 files changed, 216 insertions(+), 35 deletions(-)
create mode 100644 include/pm.h

--
2.4.3


[PATCH 1/7] device: Add _null_suspend_resume() function

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Some devices may have no work to do in suspend/resume, but every
device is required to provided a suspend/resume function to the power
management subsystem. Provide generic noop suspend/resume functions
to be reused by devices saving the code space for every device
defining their own noop functions.

Change-Id: Ia1c2edd97fc9cdaff36967f2e4901fadbaca65bf
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/include/device.h b/include/device.h
index 64b1e6f..5dbb52f 100644
--- a/include/device.h
+++ b/include/device.h
@@ -261,6 +261,11 @@ struct device {
void _sys_device_do_config_level(int level);
struct device* device_get_binding(char *name);

+static inline int _null_suspend_resume(struct device *device)
+{
+ return 0;
+};
+
/**
* Synchronous calls API
*/
--
2.4.3


[PATCH 1/8] device: Add suspend/resume api functions to device structure

dirk.brandewie@...
 

From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Suspend and resume are generic functions that each device should
support. Move the suspend/resume API functions to the top level
device structure. This change allows for the application to call
suspend/resume without needing to know device type.

Change-Id: I2fa7b13f75faeb83106ced83cd07ddbae4c915d6
Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
---
include/device.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 74 insertions(+)

diff --git a/include/device.h b/include/device.h
index e2e657d..64b1e6f 100644
--- a/include/device.h
+++ b/include/device.h
@@ -147,6 +147,70 @@ extern "C" {
*/
#define DEVICE_DECLARE(name) extern struct device DEVICE_NAME_GET(name)

+/**
+ * @def DEVICE_INIT_PM
+ *
+ * @brief create device object and set it up for boot time initialization
+ *
+ * @details This macro defines a device object that is automatically
+ * configured by the kernel during system initialization.
+ *
+ * @param dev_name Device name.
+ *
+ * @param drv_name The name this instance of the driver exposes to
+ * the system.
+ *
+ * @param init_fn Address to the init function of the driver.
+ *
+ * @param device_fn Address of device_ops structure for device.
+ *
+ * @param data Pointer to the device's configuration data.
+ *
+ * @param cfg_info The address to the structure containing the
+ * configuration information for this instance of the driver.
+ *
+ * @param level The initialization level at which configuration occurs.
+ * Must be one of the following symbols, which are listed in the order
+ * they are performed by the kernel:
+ *
+ * PRIMARY: Used for devices that have no dependencies, such as those
+ * that rely solely on hardware present in the processor/SOC. These devices
+ * cannot use any kernel services during configuration, since they are not
+ * yet available.
+ *
+ * SECONDARY: Used for devices that rely on the initialization of devices
+ * initialized as part of the PRIMARY level. These devices cannot use any
+ * kernel services during configuration, since they are not yet available.
+ *
+ * NANOKERNEL: Used for devices that require nanokernel services during
+ * configuration.
+ *
+ * MICROKERNEL: Used for devices that require microkernel services during
+ * configuration.
+ *
+ * APPLICATION: Used for application components (i.e. non-kernel components)
+ * that need automatic configuration. These devices can use all services
+ * provided by the kernel during configuration.
+ *
+ * @param prio The initialization priority of the device, relative to
+ * other devices of the same initialization level. Specified as an integer
+ * value in the range 0 to 99; lower values indicate earlier initialization.
+ * Must be a decimal integer literal without leading zeroes or sign (e.g. 32),
+ * or an equivalent symbolic name (e.g. #define MY_INIT_PRIO 32); symbolic
+ * expressions are *not* permitted
+ * (e.g. CONFIG_KERNEL_INIT_PRIORITY_DEFAULT + 5).
+ */
+
+#define DECLARE_INIT_PM(cfg_name, drv_name, init_fn, \
+ device_fn, config)\
+ static struct device_config config_##cfg_name __used \
+ __attribute__((__section__(".devconfig.init"))) = { \
+ .name = drv_name, .init = (init_fn), \
+ .dev_ops = device_fn, \
+ .config_info = (config) \
+ }
+
+
/* Common Error Codes devices can provide */
#define DEV_OK 0 /* No error */
#define DEV_FAIL 1 /* General operation failure */
@@ -160,6 +224,15 @@ extern "C" {
struct device;

/**
+ * @brief Specify the operations common across all devices
+ * @param init init function for the driver
+ */
+struct device_ops {
+ int (*suspend)(struct device *device);
+ int (*resume)(struct device *device);
+};
+
+/**
* @brief Static device information (In ROM) Per driver instance
* @param name name of the device
* @param init init function for the driver
@@ -168,6 +241,7 @@ struct device;
struct device_config {
char *name;
int (*init)(struct device *device);
+ struct device_ops *dev_ops;
void *config_info;
};

--
2.4.3

121 - 140 of 7731