Date   

Re: CMSIS, ksdk and nrf52 integration

Carles Cufi
 

On 24/05/16 16:47, "Cufi, Carles" <Carles.Cufi(a)nordicsemi.no> wrote:

Hi Anas,


On 24/05/16 16:44, "Nashif, Anas" <anas.nashif(a)intel.com> wrote:

Hi Maureen, Carles:

In the interest of moving forward with CMSIS and related pending changes,
I am proposing the following:

- merge CMSIS+ksdk patches from Maureen
- add basic support in Kconfig and the Makefile to allow inclusion of
CMSIS headers by SoCs.
- change nrf52 port to use new location of cmsis headers. Carles, will
you be ok doing this?
Should be done now, as long as the path to the new location is provided to
the compiler. We now simply include the cmsis file directly assuming it¹s
in the include path:

#include <core_m4.h>

Carles


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/2203 : sensor: add driver for HTS221 sensor
- https://gerrit.zephyrproject.org/r/2215 : eth: Fix spurious interrupt issues
- https://gerrit.zephyrproject.org/r/2202 : Bluetooth: tester: Fix invalid type cast
- https://gerrit.zephyrproject.org/r/2199 : flash: update API documentation
- https://gerrit.zephyrproject.org/r/2214 : Bluetooth: Add delay before sending Connection Update
- https://gerrit.zephyrproject.org/r/2212 : drivers/nble: Check connection before unref
- https://gerrit.zephyrproject.org/r/2213 : Bluetooth/peripheral_csc: Add configuration for nble
- https://gerrit.zephyrproject.org/r/2209 : slip: Helper script to setup tap0 interface
- https://gerrit.zephyrproject.org/r/2210 : slip: Fix IP address and route setup for tap0
- https://gerrit.zephyrproject.org/r/2207 : net: apps: Add DHCP client sample application
- https://gerrit.zephyrproject.org/r/2206 : net: dhcp: Add DHCP client support.
- https://gerrit.zephyrproject.org/r/2205 : Bluetooth: Offload ECC calculations to task
- https://gerrit.zephyrproject.org/r/2200 : sample/flash: update sample usage for flash erase operation
- https://gerrit.zephyrproject.org/r/2197 : test: test CI build
- https://gerrit.zephyrproject.org/r/2195 : net: ipv6: Fix net_set_mac function

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1903 : arm: Add support for Nordic Semiconductor's nRF52 series of ICs
- https://gerrit.zephyrproject.org/r/2039 : nano_work: Add delayed version
- https://gerrit.zephyrproject.org/r/2187 : nanokernel: Add callback to _nano_timeout once again
- https://gerrit.zephyrproject.org/r/2063 : Bluetooth: conn: Make use of nano_delayed_work API
- https://gerrit.zephyrproject.org/r/2041 : Bluetooth: SMP: Make use of nano_delayed_work API
- https://gerrit.zephyrproject.org/r/2040 : tests: Add tests for delayed workqueue
- https://gerrit.zephyrproject.org/r/2010 : samples: gpio: lcd: sample app for HD44780 LCD controller
- https://gerrit.zephyrproject.org/r/2086 : net: apps: zperf - add TCP client
- https://gerrit.zephyrproject.org/r/2130 : pinmux: remove pinmux.h and define structs where needed
- https://gerrit.zephyrproject.org/r/2114 : debug: allow easier stack frame debug
- https://gerrit.zephyrproject.org/r/2007 : cmsis: Import CMSIS-Core header files
- https://gerrit.zephyrproject.org/r/2128 : quark: move pinmux files to board/
- https://gerrit.zephyrproject.org/r/2081 : drivers: Add basic GPIO and UART support for nRF52
- https://gerrit.zephyrproject.org/r/2169 : scripts: Add the ISA to the path of included libraries for GCC ARM Embedded
- https://gerrit.zephyrproject.org/r/1614 : gpio: add device config helpers
- https://gerrit.zephyrproject.org/r/2082 : boards: Add support for the nRF52 DK board (PCA10040)
- https://gerrit.zephyrproject.org/r/1616 : samples: mcp9808: support two devices
- https://gerrit.zephyrproject.org/r/1615 : sensor: mcp9808: support multiple devices
- https://gerrit.zephyrproject.org/r/1613 : i2c: add device config helpers
- https://gerrit.zephyrproject.org/r/1904 : arm: Add CMSIS-CORE v4.50 include header files
- https://gerrit.zephyrproject.org/r/2133 : galileo: merge pinmux code into one file
- https://gerrit.zephyrproject.org/r/1612 : sensor: add device config helpers
- https://gerrit.zephyrproject.org/r/2134 : pinmux: fix naming inconsistency
- https://gerrit.zephyrproject.org/r/2132 : galileo: Remove pinmux kconfigs for the board and reuse existing
- https://gerrit.zephyrproject.org/r/2131 : pinmux: move galileo pinmuxing to board/galileo
- https://gerrit.zephyrproject.org/r/2135 : arduino due: move pinmux code to board definition
- https://gerrit.zephyrproject.org/r/2129 : remove custom pinmux for quark and use qmsi

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2211 : drivers/nble: Improve logging for long characteristic
- https://gerrit.zephyrproject.org/r/2204 : sensor: fix typo resulting in compile error
- https://gerrit.zephyrproject.org/r/2201 : adc: some symbols didn't have depends on ADC and should
- https://gerrit.zephyrproject.org/r/2196 : arc: disable i-cache in early init because ARC CPUs start with it on
- https://gerrit.zephyrproject.org/r/2192 : Bluetooth/shell: Add test vendor service support
- https://gerrit.zephyrproject.org/r/2165 : quark_se_devboard: do not configure uart0 by default
- https://gerrit.zephyrproject.org/r/2193 : net: Clear the connection pointer when net_buf is allocated
- https://gerrit.zephyrproject.org/r/1899 : pm/loapic: suspend/resume support for LOAPIC
- https://gerrit.zephyrproject.org/r/1896 : apic : Refactor some macros into a header
- https://gerrit.zephyrproject.org/r/1897 : pm/apic: Keep irq to vector table in RAM when needed by PM
- https://gerrit.zephyrproject.org/r/1898 : pm/ioapic: Add suspend/resume support for IOAPIC
- https://gerrit.zephyrproject.org/r/2179 : arc: Adding EM11D SOC
- https://gerrit.zephyrproject.org/r/2182 : arc: linker.ld modified to handle DRAM configuration as well
- https://gerrit.zephyrproject.org/r/2181 : arc: Adding ARC EM Starter Kit board support
- https://gerrit.zephyrproject.org/r/2093 : gpio: quark se: Add QMSI 1.1-based GPIO shim driver
- https://gerrit.zephyrproject.org/r/2094 : quark_se: gpio: use qmsi gpio driver
- https://gerrit.zephyrproject.org/r/2091 : spi: quark se: Add QMSI 1.1-based SPI shim driver
- https://gerrit.zephyrproject.org/r/2188 : samples/task_profiler: fix #if to #ifdef
- https://gerrit.zephyrproject.org/r/2107 : samples/task_profiler: disable UART0 on galileo to fix crash
- https://gerrit.zephyrproject.org/r/2178 : arc: Adding EM9D SOC
- https://gerrit.zephyrproject.org/r/2095 : i2c: quark se: Add QMSI 1.1-based I2C shim driver
- https://gerrit.zephyrproject.org/r/2067 : samples/task_profiler: add RTC/counter support as timestamp
- https://gerrit.zephyrproject.org/r/2090 : quark se: build sensor subsystem files
- https://gerrit.zephyrproject.org/r/2100 : uart: qmsi: do not include ioapic.h on non x86 systems
- https://gerrit.zephyrproject.org/r/2171 : uart: use qmsi driver for quark_se sensor subsystem
- https://gerrit.zephyrproject.org/r/2096 : quark_se: i2c: use qmsi i2c driver
- https://gerrit.zephyrproject.org/r/2097 : adc: quark se: Add QMSI 1.1-based ADC shim driver
- https://gerrit.zephyrproject.org/r/2173 : qmsi: move drivers and hal to ext/hal
- https://gerrit.zephyrproject.org/r/2092 : quark_se: spi: use qmsi spi driver on sensor sub-system
- https://gerrit.zephyrproject.org/r/2066 : kernel event logger: add possibility to use custom timestamp
- https://gerrit.zephyrproject.org/r/2099 : apds9960: Fix reference to i2c driver
- https://gerrit.zephyrproject.org/r/2089 : qmsi: update qmsi to 1.1 alpha
- https://gerrit.zephyrproject.org/r/2164 : build: use export to pass CFLAGS to zephyrmake
- https://gerrit.zephyrproject.org/r/2118 : Upgrade Zephyr SDK to v0.8
- https://gerrit.zephyrproject.org/r/2183 : tests: remove duplicate kernel configs and usage of ARCH
- https://gerrit.zephyrproject.org/r/2174 : checkpatch: add option for excluding directories
- https://gerrit.zephyrproject.org/r/2175 : checkpatch: exclude ext/ from checks
- https://gerrit.zephyrproject.org/r/2194 : drivers/nble: Update service db attributes handle


Re: CMSIS, ksdk and nrf52 integration

Carles Cufi
 

Hi Anas,


On 24/05/16 16:44, "Nashif, Anas" <anas.nashif(a)intel.com> wrote:

Hi Maureen, Carles:

In the interest of moving forward with CMSIS and related pending changes,
I am proposing the following:

- merge CMSIS+ksdk patches from Maureen
- add basic support in Kconfig and the Makefile to allow inclusion of
CMSIS headers by SoCs.
- change nrf52 port to use new location of cmsis headers. Carles, will
you be ok doing this?
Of course, in fact there should not be any work at all there as long as
the INCLUDE path points to the new location in a similar format:
<cmsis/file.h>. If we decide to drop the ³cmsis² namespace then it¹s a
simple change, I will make it of course.


we had a discussion about header namespace for CMSIS. I see both points
here, the goal is to avoid changes to existing SDKs including such
headers, a quick look reveals directly inclusion is used without
namespaces in many vendor SDKs.

Goal is to have everything reviewed and merged by tomorrow, is this Ok
with everyone? :-)
Got it, will push the change to include directly without the cmsis/ path.


Thanks,

Carles


CMSIS, ksdk and nrf52 integration

Nashif, Anas
 

Hi Maureen, Carles:

In the interest of moving forward with CMSIS and related pending changes, I am proposing the following:

- merge CMSIS+ksdk patches from Maureen
- add basic support in Kconfig and the Makefile to allow inclusion of CMSIS headers by SoCs.
- change nrf52 port to use new location of cmsis headers. Carles, will you be ok doing this?

we had a discussion about header namespace for CMSIS. I see both points here, the goal is to avoid changes to existing SDKs including such headers, a quick look reveals directly inclusion is used without namespaces in many vendor SDKs.

Goal is to have everything reviewed and merged by tomorrow, is this Ok with everyone? :-)


Anas


Re: Power Management

Matt Heins <heinsmatt@...>
 

Thank you. This is very helpful information. I will give it a try.

Thanks again,

Matt

On Mon, May 23, 2016 at 10:48 PM, Ramesh Thomas <ramesh.thomas(a)intel.com>
wrote:



On 05/23/2016 12:27 PM, Matt Heins wrote:

I'm trying to understand the power management API and figure out what is
and isn't possible at this time. The clearest information about the API
I've found in the samples directory. In there, it suggests that power
management is not presently supported for the ARC processor on the Arduino
101. I believe I can get power management working on the x86 with the
sample, but I'd like to also get it working on the ARC processor. Could
someone point me to any code to get that working?


As of now, PM in ARC can be done using IPM (inter processor messaging)
from the x86 side. You can refer to samples/ipm to see how x86 and ARC can
communicate. When x86 side gets notified via _sys_soc_suspend() , it can
tell ARC to put CPU in low power state. You can refer to ARC data sheet or
arch/arc/core/cpu_idle.S to see how ARC can be put to low power states.
Sending ipm message during _sys_soc_resume() would cause ARC to come out of
low power state. You would need to setup some kind of handshaking between
ARC and x86 apps.


Also, it appears that any interrupt will bring the processor out of low
power, but the sample doesn't indicate how you might go about figuring out
what interrupt triggered. Is there a reference available for that too?


You can probably do what the kernel event logger does - call
_sys_current_irq_key_get(). In x86, this function calls
_loapic_isr_vector_get() to get the current vector number.


Thanks

Matt



Re: spi_sam3x/cc2520 of zephyr

david.dai@...
 

Hi Tomasz,

Sorry, that is my wrong, I just test and validate the cc2520 driver, it can
transmit and receive 802.15.4 mac frame.
Thank you!


Best Regards
David Dai(戴卫彬)
Position:上海



|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|devel(a)lists.zephyrproject.org, |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|2016/05/24 18:23 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[devel] Re: spi_sam3x/cc2520 of zephyr |
>--------------------------------------------------------------------------------------------------------------------------------------------------|





Hi,

Meanwhile, I also find that, cc2520 driver is submitted, but it is
never validated.
What do you mean by "validated"?


SPI:
==> spi_sam3x_transceive can not return, and result in system exception
==================================================================
GPIO and SPI configured
verify_osc_stabilization enter
***** BUS FAULT *****
Executing thread ID (thread): 0x20080d04
Faulting instruction address: 0x80480488
Instruction bus error
Fatal fault in essential task ! Spinning...
===================================================================
==> Receiving data cannot occur without transmitting data.
SAM3X[DATASHEET]->32.7.3 Master Mode Operations
==> spi internal nCS may be unusable, instead of it with gpio.
==> it is better to transmit and receive data in fiber context.
Well, I can't find any driver about sam3's SPI on latest master tree.
Are you working with some patches not up-streamed or?
I really would like to take a look at such SPI driver.
cc2520 relies at 90% on SPI. Most of the time, bugs have been found on
SPI side.

And something tells me spi_sam3x_transceivec is not properly implemented.

cc2520:
==>fifop(gpio2) triggers rx processing at rising edge, sfd(gpio4)
triggers tx completion notification, should it be falling edge?
That's all about arduino_due GPIO specifics. In quark_se_devboard that's
rising edge.

==>linux cc2520 driver is very concise and clear, why don't port it to
zephyr?
Sure, because a driver from a totally different OS will just do the trick?

==>cc2520 driver defines macro
"CONFIG_NETWORKING_LEGACY_RADIO_DRIVER", if this means how to
interface cc2520 to zephyr 6lowpan stack still is a uncompleted task,
or the interface will be changed in future.
You don't have to care about that. That's internal stuff, which
application will never ever have to deal with.


Here I greatly appreciate huge contribution from Intel colleagues.
I specially care for spi_sam3x <==> cc2520 driver <==>
6lowpan/ieee802154 <==> ipv6.
To achieve this target, Would you have any information about its, plan
or schedule?
We don't have plans ourselves in porting cc2520 to arduino_due.
It seems to me you are actually doing that yourself right?
cc2520 has been, for now, ported to quark_se_devboard and works well there.

However: this means providing the proper GPIO and SPI configuration.
This all goes through boards/arduino_due/<bfoard.h/board.c and Kconfig>
in your case.
Have you done that? Take a look at same files in boards/quark_se_devboard/

Do you have any patch to show so I can help you with the porting process?

Tomasz


*********************************************************
This message contains information that may be confidential and/or privileged and is intended only for the individual or entity named in the body of email above. If this message has been received in error, your receipt of this message is not intended to waive any applicable privilege. No one else may disclose, copy, distribute or use the contents of this message. Unauthorized use, dissemination and duplication is strictly prohibited, and may be unlawful.


Re: spi_sam3x/cc2520 of zephyr

Tomasz Bursztyka
 

Hi,

Meanwhile, I also find that, cc2520 driver is submitted, but it is
never validated.
What do you mean by "validated"?


SPI:
==> spi_sam3x_transceive can not return, and result in system exception
==================================================================
GPIO and SPI configured
verify_osc_stabilization enter
***** BUS FAULT *****
Executing thread ID (thread): 0x20080d04
Faulting instruction address: 0x80480488
Instruction bus error
Fatal fault in essential task ! Spinning...
===================================================================
==> Receiving data cannot occur without transmitting data.
SAM3X[DATASHEET]->32.7.3 Master Mode Operations
==> spi internal nCS may be unusable, instead of it with gpio.
==> it is better to transmit and receive data in fiber context.
Well, I can't find any driver about sam3's SPI on latest master tree.
Are you working with some patches not up-streamed or?
I really would like to take a look at such SPI driver.
cc2520 relies at 90% on SPI. Most of the time, bugs have been found on
SPI side.

And something tells me spi_sam3x_transceivec is not properly implemented.

cc2520:
==>fifop(gpio2) triggers rx processing at rising edge, sfd(gpio4)
triggers tx completion notification, should it be falling edge?
That's all about arduino_due GPIO specifics. In quark_se_devboard that's
rising edge.

==>linux cc2520 driver is very concise and clear, why don't port it to
zephyr?
Sure, because a driver from a totally different OS will just do the trick?

==>cc2520 driver defines macro
"CONFIG_NETWORKING_LEGACY_RADIO_DRIVER", if this means how to
interface cc2520 to zephyr 6lowpan stack still is a uncompleted task,
or the interface will be changed in future.
You don't have to care about that. That's internal stuff, which
application will never ever have to deal with.


Here I greatly appreciate huge contribution from Intel colleagues.
I specially care for spi_sam3x <==> cc2520 driver <==>
6lowpan/ieee802154 <==> ipv6.
To achieve this target, Would you have any information about its, plan
or schedule?
We don't have plans ourselves in porting cc2520 to arduino_due.
It seems to me you are actually doing that yourself right?
cc2520 has been, for now, ported to quark_se_devboard and works well there.

However: this means providing the proper GPIO and SPI configuration.
This all goes through boards/arduino_due/<bfoard.h/board.c and Kconfig>
in your case.
Have you done that? Take a look at same files in boards/quark_se_devboard/

Do you have any patch to show so I can help you with the porting process?

Tomasz


Re: Power Management

Thomas, Ramesh
 

On 05/23/2016 12:27 PM, Matt Heins wrote:
I'm trying to understand the power management API and figure out what
is and isn't possible at this time. The clearest information about the
API I've found in the samples directory. In there, it suggests that
power management is not presently supported for the ARC processor on
the Arduino 101. I believe I can get power management working on the
x86 with the sample, but I'd like to also get it working on the ARC
processor. Could someone point me to any code to get that working?
As of now, PM in ARC can be done using IPM (inter processor messaging)
from the x86 side. You can refer to samples/ipm to see how x86 and ARC
can communicate. When x86 side gets notified via _sys_soc_suspend() ,
it can tell ARC to put CPU in low power state. You can refer to ARC data
sheet or arch/arc/core/cpu_idle.S to see how ARC can be put to low power
states. Sending ipm message during _sys_soc_resume() would cause ARC to
come out of low power state. You would need to setup some kind of
handshaking between ARC and x86 apps.


Also, it appears that any interrupt will bring the processor out of
low power, but the sample doesn't indicate how you might go about
figuring out what interrupt triggered. Is there a reference available
for that too?
You can probably do what the kernel event logger does - call
_sys_current_irq_key_get(). In x86, this function calls
_loapic_isr_vector_get() to get the current vector number.


Thanks

Matt


Power Management

Matt Heins <heinsmatt@...>
 

I'm trying to understand the power management API and figure out what is
and isn't possible at this time. The clearest information about the API
I've found in the samples directory. In there, it suggests that power
management is not presently supported for the ARC processor on the Arduino
101. I believe I can get power management working on the x86 with the
sample, but I'd like to also get it working on the ARC processor. Could
someone point me to any code to get that working?

Also, it appears that any interrupt will bring the processor out of low
power, but the sample doesn't indicate how you might go about figuring out
what interrupt triggered. Is there a reference available for that too?

Thanks

Matt


[RFC PATCH v2 5/5] samples: mcp9808: support two devices

Vlad Dogaru <vlad.dogaru@...>
 

Update the sample app to describe and support two MCP9808 devices. This
is meant to illustrate the new style device configuration.

Change-Id: I850c7ac307a6a3932bc02c7586e3d0fc03475152
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
samples/sensor/mcp9808/Makefile | 1 +
samples/sensor/mcp9808/prj.conf | 4 ++-
samples/sensor/mcp9808/src/Makefile | 2 +-
samples/sensor/mcp9808/src/devices.c | 35 +++++++++++++++++++
samples/sensor/mcp9808/src/main.c | 66 +++++++++++++++++++++++-------------
5 files changed, 83 insertions(+), 25 deletions(-)
create mode 100644 samples/sensor/mcp9808/src/devices.c

diff --git a/samples/sensor/mcp9808/Makefile b/samples/sensor/mcp9808/Makefile
index 65b4d36..8f40c04 100644
--- a/samples/sensor/mcp9808/Makefile
+++ b/samples/sensor/mcp9808/Makefile
@@ -1,5 +1,6 @@
KERNEL_TYPE = nano
BOARD ?= arduino_101_sss
CONF_FILE = prj.conf
+CFLAGS += -I${ZEPHYR_BASE}

include ${ZEPHYR_BASE}/Makefile.inc
diff --git a/samples/sensor/mcp9808/prj.conf b/samples/sensor/mcp9808/prj.conf
index 28abc67..e56ec14 100644
--- a/samples/sensor/mcp9808/prj.conf
+++ b/samples/sensor/mcp9808/prj.conf
@@ -3,8 +3,10 @@ CONFIG_STDOUT_CONSOLE=y
CONFIG_I2C=y
CONFIG_GPIO=y

+CONFIG_NANO_WORKQUEUE=y
+CONFIG_SYSTEM_WORKQUEUE=y
CONFIG_NANO_TIMEOUTS=y

CONFIG_SENSOR=y
CONFIG_MCP9808=y
-CONFIG_MCP9808_TRIGGER_GLOBAL=y
+CONFIG_MCP9808_TRIGGER=y
diff --git a/samples/sensor/mcp9808/src/Makefile b/samples/sensor/mcp9808/src/Makefile
index b666967..7fdc3fe 100644
--- a/samples/sensor/mcp9808/src/Makefile
+++ b/samples/sensor/mcp9808/src/Makefile
@@ -1 +1 @@
-obj-y += main.o
+obj-y += main.o devices.o
diff --git a/samples/sensor/mcp9808/src/devices.c b/samples/sensor/mcp9808/src/devices.c
new file mode 100644
index 0000000..3f373c0
--- /dev/null
+++ b/samples/sensor/mcp9808/src/devices.c
@@ -0,0 +1,35 @@
+#include <i2c.h>
+#include <gpio.h>
+#include <device.h>
+
+#include "drivers/sensor/sensor_mcp9808.h"
+
+#ifdef CONFIG_MCP9808_TRIGGER
+static __stack char mcp9808_fiber_stack[1024];
+#endif
+
+static struct mcp9808_data mcp9808_0_data;
+
+static struct mcp9808_config mcp9808_0_config = {
+ I2C_CLIENT("I2C_0", 0x18),
+#ifdef CONFIG_MCP9808_TRIGGER
+ GPIO_PIN("GPIO_0", 8),
+ SENSOR_TRIG_WQ_OWN(mcp9808_fiber_stack, 10),
+#endif
+};
+
+DEVICE_INIT(mcp9808_0, "MCP9808_0", mcp9808_init, &mcp9808_0_data,
+ &mcp9808_0_config, SECONDARY, 70);
+
+static struct mcp9808_data mcp9808_1_data;
+
+static struct mcp9808_config mcp9808_1_config = {
+ I2C_CLIENT("I2C_0", 0x19),
+#ifdef CONFIG_MCP9808_TRIGGER
+ GPIO_PIN("GPIO_0", 9),
+ SENSOR_TRIG_WQ_GLOBAL,
+#endif
+};
+
+DEVICE_INIT(mcp9808_1, "MCP9808_1", mcp9808_init, &mcp9808_1_data,
+ &mcp9808_1_config, SECONDARY, 70);
diff --git a/samples/sensor/mcp9808/src/main.c b/samples/sensor/mcp9808/src/main.c
index 6736cdd..77d7a8c 100644
--- a/samples/sensor/mcp9808/src/main.c
+++ b/samples/sensor/mcp9808/src/main.c
@@ -28,6 +28,8 @@
#define PRINT printk
#endif

+#define DEBUG
+
#ifdef CONFIG_MCP9808_TRIGGER
static void trigger_handler(struct device *dev, struct sensor_trigger *trig)
{
@@ -36,47 +38,65 @@ static void trigger_handler(struct device *dev, struct sensor_trigger *trig)
sensor_sample_fetch(dev);
sensor_channel_get(dev, SENSOR_CHAN_TEMP, &temp);

- PRINT("trigger fired, temp %d.%06d\n", temp.val1, temp.val2);
+ PRINT("trigger fired on %s, temp %d.%06d\n", dev->config->name,
+ temp.val1, temp.val2);
}
-#endif

-void main(void)
+static void trigger_setup(struct device *dev, int thresh_temp)
{
- struct device *dev = device_get_binding("MCP9808");
-
- if (dev == NULL) {
- printk("device not found. aborting test.\n");
- return;
- }
-
-#ifdef DEBUG
- PRINT("dev %p\n", dev);
- PRINT("dev %p name %s\n", dev, dev->config->name);
-#endif
-
-#ifdef CONFIG_MCP9808_TRIGGER
struct sensor_value val;
struct sensor_trigger trig;
+ int ret;

val.type = SENSOR_VALUE_TYPE_INT;
- val.val1 = 26;
+ val.val1 = thresh_temp;

- sensor_attr_set(dev, SENSOR_CHAN_TEMP,
- SENSOR_ATTR_UPPER_THRESH, &val);
+ ret = sensor_attr_set(dev, SENSOR_CHAN_TEMP,
+ SENSOR_ATTR_UPPER_THRESH, &val);
+ if (ret < 0) {
+ PRINT("failed to set threshold attribute on %s\n",
+ dev->config->name);
+ return;
+ }

trig.type = SENSOR_TRIG_THRESHOLD;
trig.chan = SENSOR_CHAN_TEMP;

sensor_trigger_set(dev, &trig, trigger_handler);
+}
+#endif
+
+void main(void)
+{
+ struct device *dev0 = device_get_binding("MCP9808_0");
+ struct device *dev1 = device_get_binding("MCP9808_1");
+
+ if (!dev0) {
+ printk("device 0 not found. aborting test.\n");
+ return;
+ }
+
+ if (!dev1) {
+ printk("device 1 not found. aborting test.\n");
+ return;
+ }
+
+#ifdef CONFIG_MCP9808_TRIGGER
+ trigger_setup(dev0, 26);
+ trigger_setup(dev1, 27);
#endif

while (1) {
- struct sensor_value temp;
+ struct sensor_value temp0, temp1;
+
+ sensor_sample_fetch(dev0);
+ sensor_channel_get(dev0, SENSOR_CHAN_TEMP, &temp0);

- sensor_sample_fetch(dev);
- sensor_channel_get(dev, SENSOR_CHAN_TEMP, &temp);
+ sensor_sample_fetch(dev1);
+ sensor_channel_get(dev1, SENSOR_CHAN_TEMP, &temp1);

- PRINT("temp: %d.%06d\n", temp.val1, temp.val2);
+ PRINT("temp: %d.%06d %d.%06d\n",
+ temp0.val1, temp0.val2, temp1.val1, temp1.val2);

task_sleep(sys_clock_ticks_per_sec);
}
--
1.9.1


[RFC PATCH v2 4/5] sensor: mcp9808: support multiple devices

Vlad Dogaru <vlad.dogaru@...>
 

Until now, MCP9808 device configuration was done in Kconfig. This
imposed a limit on the number of identical devices the driver could
handle (1, in this case). Also, Kconfig snippets could not be reliably
generated by an external tool.

Move the MCP9808 driver to a configuration language based on C
structures that are easier to generate externally and impose no
limitations on the number of devices. Application code is now expected
to define its own device, device_config and device_data structures and
fill them in with relevant information.

Trigger support is still conditionally compiled. If no triggers are
needed, the driver is reduced to a bare minimum. This also has the
secondary benefit that trigger code is now ifdef-free, because the
decision of how to handle an interrupt is taken at runtime.

Change-Id: I80a9f015199e8e2ae91253103e25df64d93afc0c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
drivers/sensor/Kconfig.mcp9808 | 77 ++-------------------------------
drivers/sensor/sensor_mcp9808.c | 15 +++----
drivers/sensor/sensor_mcp9808.h | 29 ++++++++-----
drivers/sensor/sensor_mcp9808_trigger.c | 73 +++++++++----------------------
4 files changed, 48 insertions(+), 146 deletions(-)

diff --git a/drivers/sensor/Kconfig.mcp9808 b/drivers/sensor/Kconfig.mcp9808
index 01be91c..7bee8d8 100644
--- a/drivers/sensor/Kconfig.mcp9808
+++ b/drivers/sensor/Kconfig.mcp9808
@@ -16,7 +16,7 @@
# limitations under the License.
#

-menuconfig MCP9808
+config MCP9808
bool "MCP9808 temperature sensor"
depends on SENSOR && I2C
default n
@@ -37,78 +37,9 @@ config MCP9808_SYS_LOG_LEVEL
3 INFO, write SYS_LOG_INF in addition to previous levels
4 DEBUG, write SYS_LOG_DBG in addition to previous levels

-config MCP9808_DEV_NAME
- string "MCP9808 device name"
- depends on MCP9808
- default "MCP9808"
-
-config MCP9808_INIT_PRIORITY
- int
- depends on MCP9808
- default 70
- prompt "Init priority"
- help
- Device driver initialization priority.
-
-config MCP9808_I2C_ADDR
- hex "MCP9808 I2C slave address"
- depends on MCP9808
- default 0x18
- help
- Specify the I2C slave address for the MCP9808.
-
-config MCP9808_I2C_DEV_NAME
- string "I2C master where MCP9808 is connected"
- depends on MCP9808
- default "I2C_0"
- help
- Specify the device name of the I2C master device to which MCP9808 is
- connected.
-
-choice
- prompt "MCP9808 trigger mode"
- depends on MCP9808
- default MCP9808_TRIGGER_NONE
-
-config MCP9808_TRIGGER_NONE
- bool "No trigger"
-
-config MCP9808_TRIGGER_GLOBAL_FIBER
- depends on GPIO && SYSTEM_WORKQUEUE
- select MCP9808_TRIGGER
- bool "Use global fiber"
-
-config MCP9808_TRIGGER_OWN_FIBER
- depends on GPIO
- select MCP9808_TRIGGER
- bool "Use own fiber"
-
-endchoice
-
config MCP9808_TRIGGER
- bool
+ bool "MCP9808 trigger support"
depends on MCP9808
-
-config MCP9808_GPIO_CONTROLLER
- string "GPIO controller for MCP9808 interrupt"
- depends on MCP9808 && MCP9808_TRIGGER
- default "GPIO_0"
- help
- The GPIO controller the MCP9808 interrupt is connected to.
-
-config MCP9808_GPIO_PIN
- int "GPIO pin for MCP9808 interrupt"
- depends on MCP9808 && MCP9808_TRIGGER
- default 3
+ default n
help
- The GPIO pin the MCP9808 interrupt is connected to.
-
-config MCP9808_FIBER_STACK_SIZE
- int "Sensor delayed work fiber stack size"
- depends on MCP9808 && MCP9808_TRIGGER_OWN_FIBER
- default 1024
-
-config MCP9808_FIBER_PRIORITY
- int "MCP9808 fiber priority"
- depends on MCP9808 && MCP9808_TRIGGER_OWN_FIBER
- default 10
+ Enable trigger support for MCP9808.
diff --git a/drivers/sensor/sensor_mcp9808.c b/drivers/sensor/sensor_mcp9808.c
index 4baf743..db8ab84 100644
--- a/drivers/sensor/sensor_mcp9808.c
+++ b/drivers/sensor/sensor_mcp9808.c
@@ -26,7 +26,6 @@

#include "sensor_mcp9808.h"

-
int mcp9808_reg_read(struct mcp9808_data *data, uint8_t reg, uint16_t *val)
{
struct i2c_msg msgs[2] = {
@@ -92,15 +91,16 @@ static struct sensor_driver_api mcp9808_api_funcs = {
int mcp9808_init(struct device *dev)
{
struct mcp9808_data *data = dev->driver_data;
+ struct mcp9808_config *config = dev->config->config_info;

- data->i2c_master = device_get_binding(CONFIG_MCP9808_I2C_DEV_NAME);
+ data->i2c_master = device_get_binding(I2C_GET_MASTER(config));
if (!data->i2c_master) {
- SYS_LOG_DBG("mcp9808: i2c master not found: %s",
- CONFIG_MCP9808_I2C_DEV_NAME);
+ SYS_LOG_ERR("i2c master not found: %s\n",
+ I2C_GET_MASTER(config));
return -EINVAL;
}

- data->i2c_slave_addr = CONFIG_MCP9808_I2C_ADDR;
+ data->i2c_slave_addr = I2C_GET_ADDR(config);

mcp9808_setup_interrupt(dev);

@@ -108,8 +108,3 @@ int mcp9808_init(struct device *dev)

return 0;
}
-
-struct mcp9808_data mcp9808_data;
-
-DEVICE_INIT(mcp9808, CONFIG_MCP9808_DEV_NAME, mcp9808_init, &mcp9808_data,
- NULL, SECONDARY, CONFIG_MCP9808_INIT_PRIORITY);
diff --git a/drivers/sensor/sensor_mcp9808.h b/drivers/sensor/sensor_mcp9808.h
index 43c3f52..007b6d2 100644
--- a/drivers/sensor/sensor_mcp9808.h
+++ b/drivers/sensor/sensor_mcp9808.h
@@ -22,8 +22,9 @@
#include <stdint.h>
#include <device.h>
#include <sensor.h>
-#include <misc/util.h>
#include <gpio.h>
+#include <i2c.h>
+#include <misc/util.h>
#include <misc/nano_work.h>

#define MCP9808_REG_CONFIG 0x01
@@ -43,26 +44,29 @@

#define MCP9808_TEMP_MAX 0xffc

+struct mcp9808_config {
+ I2C_DECLARE_CLIENT_CONFIG;
+#ifdef CONFIG_MCP9808_TRIGGER
+ SENSOR_DECLARE_TRIG_CONFIG;
+ GPIO_DECLARE_PIN_CONFIG;
+#endif
+};
+
struct mcp9808_data {
struct device *i2c_master;
uint16_t i2c_slave_addr;

uint16_t reg_val;

- struct gpio_callback gpio_cb;
-
-#ifdef CONFIG_MCP9808_TRIGGER_OWN_FIBER
- struct nano_sem sem;
-#endif
-
-#ifdef CONFIG_MCP9808_TRIGGER_GLOBAL_FIBER
+#ifdef CONFIG_MCP9808_TRIGGER
struct nano_work work;
struct device *dev;
-#endif
+ struct nano_workqueue wq;

-#ifdef CONFIG_MCP9808_TRIGGER
+ enum sensor_trigger_mode trig_mode;
struct sensor_trigger trig;
sensor_trigger_handler_t trigger_handler;
+ struct gpio_callback gpio_cb;
#endif
};

@@ -92,7 +96,7 @@ static inline int mcp9808_trigger_set(struct device *dev,
return -ENOTSUP;
}

-static void mcp9808_setup_interrupt(struct device *dev)
+static inline void mcp9808_setup_interrupt(struct device *dev)
{
}
#endif /* CONFIG_MCP9808_TRIGGER */
@@ -100,4 +104,7 @@ static void mcp9808_setup_interrupt(struct device *dev)
#define SYS_LOG_DOMAIN "MCP9808"
#define SYS_LOG_LEVEL CONFIG_MCP9808_SYS_LOG_LEVEL
#include <misc/sys_log.h>
+
+extern int mcp9808_init(struct device *dev);
+
#endif /* __SENSOR_MCP9808_H__ */
diff --git a/drivers/sensor/sensor_mcp9808_trigger.c b/drivers/sensor/sensor_mcp9808_trigger.c
index bd26218..719af7a 100644
--- a/drivers/sensor/sensor_mcp9808_trigger.c
+++ b/drivers/sensor/sensor_mcp9808_trigger.c
@@ -116,8 +116,6 @@ int mcp9808_trigger_set(struct device *dev,
handler == NULL ? 0 : MCP9808_ALERT_CNT);
}

-#ifdef CONFIG_MCP9808_TRIGGER_OWN_FIBER
-
static void mcp9808_gpio_cb(struct device *dev,
struct gpio_callback *cb, uint32_t pins)
{
@@ -126,40 +124,14 @@ static void mcp9808_gpio_cb(struct device *dev,

ARG_UNUSED(pins);

- nano_isr_sem_give(&data->sem);
-}
-
-static void mcp9808_fiber_main(int arg1, int arg2)
-{
- struct device *dev = INT_TO_POINTER(arg1);
- struct mcp9808_data *data = dev->driver_data;
-
- ARG_UNUSED(arg2);
-
- while (1) {
- nano_fiber_sem_take(&data->sem, TICKS_UNLIMITED);
- data->trigger_handler(dev, &data->trig);
- mcp9808_reg_update(data, MCP9808_REG_CONFIG,
- MCP9808_INT_CLEAR, MCP9808_INT_CLEAR);
+ if (data->trig_mode == SENSOR_TRIG_MODE_OWN_WQ) {
+ nano_work_submit_to_queue(&data->wq, &data->work);
+ } else if (data->trig_mode == SENSOR_TRIG_MODE_GLOBAL_WQ) {
+ nano_work_submit(&data->work);
}
}

-static char __stack mcp9808_fiber_stack[CONFIG_MCP9808_FIBER_STACK_SIZE];
-
-#else /* CONFIG_MCP9808_TRIGGER_GLOBAL_FIBER */
-
-static void mcp9808_gpio_cb(struct device *dev,
- struct gpio_callback *cb, uint32_t pins)
-{
- struct mcp9808_data *data =
- CONTAINER_OF(cb, struct mcp9808_data, gpio_cb);
-
- ARG_UNUSED(pins);
-
- nano_work_submit(&data->work);
-}
-
-static void mcp9808_gpio_fiber_cb(struct nano_work *work)
+static void mcp9808_work_handler(struct nano_work *work)
{
struct mcp9808_data *data =
CONTAINER_OF(work, struct mcp9808_data, work);
@@ -170,40 +142,37 @@ static void mcp9808_gpio_fiber_cb(struct nano_work *work)
MCP9808_INT_CLEAR, MCP9808_INT_CLEAR);
}

-#endif /* CONFIG_MCP9808_TRIGGER_GLOBAL_FIBER */
-
void mcp9808_setup_interrupt(struct device *dev)
{
struct mcp9808_data *data = dev->driver_data;
+ struct mcp9808_config *config = dev->config->config_info;
+ uint32_t gpio_pin = GPIO_GET_PIN(config);
struct device *gpio;

+ data->dev = dev;
+ data->trig_mode = SENSOR_GET_TRIG_MODE(config);
+ if (data->trig_mode == SENSOR_TRIG_MODE_NONE) {
+ return;
+ }
+
mcp9808_reg_update(data, MCP9808_REG_CONFIG, MCP9808_ALERT_INT,
MCP9808_ALERT_INT);
mcp9808_reg_write(data, MCP9808_REG_CRITICAL, MCP9808_TEMP_MAX);
mcp9808_reg_update(data, MCP9808_REG_CONFIG, MCP9808_INT_CLEAR,
MCP9808_INT_CLEAR);

-#ifdef CONFIG_MCP9808_TRIGGER_OWN_FIBER
- nano_sem_init(&data->sem);
+ data->work.handler = mcp9808_work_handler;

- fiber_fiber_start(mcp9808_fiber_stack,
- CONFIG_MCP9808_FIBER_STACK_SIZE,
- mcp9808_fiber_main, POINTER_TO_INT(dev), 0,
- CONFIG_MCP9808_FIBER_PRIORITY, 0);
-#else /* CONFIG_MCP9808_TRIGGER_GLOBAL_FIBER */
- data->work.handler = mcp9808_gpio_fiber_cb;
- data->dev = dev;
-#endif
+ if (data->trig_mode == SENSOR_TRIG_MODE_OWN_WQ) {
+ nano_workqueue_start(&data->wq, &SENSOR_GET_WQ_CONFIG(config));
+ }

- gpio = device_get_binding(CONFIG_MCP9808_GPIO_CONTROLLER);
- gpio_pin_configure(gpio, CONFIG_MCP9808_GPIO_PIN,
+ gpio = device_get_binding(GPIO_GET_CONTROLLER(config));
+ gpio_pin_configure(gpio, gpio_pin,
GPIO_DIR_IN | GPIO_INT | GPIO_INT_EDGE |
GPIO_INT_ACTIVE_LOW | GPIO_INT_DEBOUNCE);

- gpio_init_callback(&data->gpio_cb,
- mcp9808_gpio_cb,
- BIT(CONFIG_MCP9808_GPIO_PIN));
-
+ gpio_init_callback(&data->gpio_cb, mcp9808_gpio_cb, BIT(gpio_pin));
gpio_add_callback(gpio, &data->gpio_cb);
- gpio_pin_enable_callback(gpio, CONFIG_MCP9808_GPIO_PIN);
+ gpio_pin_enable_callback(gpio, gpio_pin);
}
--
1.9.1


[RFC PATCH v2 3/5] gpio: add device config helpers

Vlad Dogaru <vlad.dogaru@...>
 

Change-Id: I8af573484934a02893a395bb0d19551b5c9d0291
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/gpio.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)

diff --git a/include/gpio.h b/include/gpio.h
index 1d1205a..4823881 100644
--- a/include/gpio.h
+++ b/include/gpio.h
@@ -433,6 +433,32 @@ static inline int gpio_port_disable_callback(struct device *port)
return api->disable_callback(port, GPIO_ACCESS_BY_PORT, 0);
}

+struct gpio_pin_config {
+ char *gpio_controller;
+ uint32_t gpio_pin;
+};
+
+#define GPIO_DECLARE_PIN_CONFIG_IDX(_idx) \
+ struct gpio_pin_config gpio_pin_ ##_idx
+#define GPIO_DECLARE_PIN_CONFIG \
+ GPIO_DECLARE_PIN_CONFIG_IDX()
+
+#define GPIO_PIN_IDX(_idx, _controller, _pin) \
+ .gpio_pin_ ##_idx = { \
+ .gpio_controller = (_controller),\
+ .gpio_pin = (_pin), \
+ }
+#define GPIO_PIN(_controller, _pin) \
+ GPIO_PIN_IDX(, _controller, _pin)
+
+#define GPIO_GET_CONTROLLER_IDX(_idx, _conf) \
+ ((_conf)->gpio_pin_ ##_idx.gpio_controller)
+#define GPIO_GET_PIN_IDX(_idx, _conf) \
+ ((_conf)->gpio_pin_ ##_idx.gpio_pin)
+
+#define GPIO_GET_CONTROLLER(_conf) GPIO_GET_CONTROLLER_IDX(, _conf)
+#define GPIO_GET_PIN(_conf) GPIO_GET_PIN_IDX(, _conf)
+
#ifdef __cplusplus
}
#endif
--
1.9.1


[RFC PATCH v2 2/5] i2c: add device config helpers

Vlad Dogaru <vlad.dogaru@...>
 

Add some macros that drivers and applications can use in describing I2C
clients.

Change-Id: Ic7af97804e88ed3b9d4f68f9ac358a425f4cc17c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/i2c.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

diff --git a/include/i2c.h b/include/i2c.h
index b772871..1f22363 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -411,6 +411,22 @@ static inline int i2c_resume(struct device *dev)
return api->resume(dev);
}

+struct i2c_client_config {
+ char *i2c_master;
+ uint16_t i2c_addr;
+};
+
+#define I2C_DECLARE_CLIENT_CONFIG struct i2c_client_config i2c_client
+
+#define I2C_CLIENT(_master, _addr) \
+ .i2c_client = { \
+ .i2c_master = (_master), \
+ .i2c_addr = (_addr), \
+ }
+
+#define I2C_GET_MASTER(_conf) ((_conf)->i2c_client.i2c_master)
+#define I2C_GET_ADDR(_conf) ((_conf)->i2c_client.i2c_addr)
+
#ifdef __cplusplus
}
#endif
--
1.9.1


[RFC PATCH v2 1/5] sensor: add device config helpers

Vlad Dogaru <vlad.dogaru@...>
 

Define some configuration structures and macros that can be used in
device configuration. These usage scenarios are as follows:

* device drivers will use SENSOR_DECLARE_* macros in their device
configuration structures and SENSOR_GET_* macros in the init
functions;

* application code will use SENSOR_TRIG_* to fill in the device
configuration structures.

Change-Id: I3a897999175b14a4cd1111da4c26434741294e52
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/sensor.h | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 73 insertions(+), 4 deletions(-)

diff --git a/include/sensor.h b/include/sensor.h
index 29faf15..228dca8 100644
--- a/include/sensor.h
+++ b/include/sensor.h
@@ -33,10 +33,6 @@ extern "C" {
#include <device.h>
#include <errno.h>

-#ifdef CONFIG_SENSOR_WORKQUEUE
-#include <misc/nano_work.h>
-#endif
-
/** @brief Sensor value types. */
enum sensor_value_type {
/** val1 contains an integer value, val2 is unused. */
@@ -436,6 +432,79 @@ static inline void sensor_degrees_to_rad(int32_t d, struct sensor_value *rad)
rad->val2 = ((int64_t)d * SENSOR_PI / 180LL) % 1000000LL;
}

+/**
+ * @brief configuration parameters for sensor triggers.
+ */
+enum sensor_trigger_mode {
+ /** Do not use triggering. */
+ SENSOR_TRIG_MODE_NONE,
+ /**
+ * Driver should start a workqueue specifically for this
+ * device. See @ref sensor_trig_or_wq_config for instruction on
+ * how to specify the parameters of the workqueue.
+ */
+ SENSOR_TRIG_MODE_OWN_WQ,
+ /** Use the system workqueue. */
+ SENSOR_TRIG_MODE_GLOBAL_WQ,
+};
+
+struct sensor_trigger_config {
+ /**
+ * This is always set to NULL when using a @ref
+ * sensor_trigger_config. See the comment in @ref
+ * sensor_trig_or_wq_config.
+ */
+ void *always_null;
+ enum sensor_trigger_mode mode;
+};
+
+/**
+ * @brief Structure used for sensor trigger configuration.
+ *
+ * If @ref fiber_config.stack is non-NULL, the driver should start its
+ * on fiber based on @fiber_config. Otherwise, use @ref
+ * trig_config.mode to decide if and how to use triggering.
+ */
+union sensor_trig_or_wq_config {
+ struct fiber_config fiber_config;
+ struct sensor_trigger_config trig_config;
+};
+
+#define SENSOR_DECLARE_TRIG_CONFIG \
+ union sensor_trig_or_wq_config trig_or_wq_config
+
+#define SENSOR_TRIG_WQ_OWN(_stack, _prio) \
+ .trig_or_wq_config = { \
+ .fiber_config = { \
+ .stack = (_stack), \
+ .stack_size = sizeof(_stack), \
+ .prio = (_prio), \
+ } \
+ }
+
+#define SENSOR_TRIG_WQ_GLOBAL \
+ .trig_or_wq_config = { \
+ .trig_config = { \
+ .always_null = NULL, \
+ .mode = SENSOR_TRIG_MODE_GLOBAL_WQ, \
+ } \
+ }
+
+#define SENSOR_TRIG_NONE \
+ .trig_or_wq_config = { \
+ .trig_config = { \
+ .always_null = NULL, \
+ .mode = SENSOR_TRIG_MODE_NONE, \
+ } \
+ }
+
+#define SENSOR_GET_TRIG_MODE(_conf) \
+ (!(_conf)->trig_or_wq_config.fiber_config.stack \
+ ? SENSOR_TRIG_MODE_OWN_WQ : \
+ (_conf)->trig_or_wq_config.trig_config.mode)
+#define SENSOR_GET_WQ_CONFIG(_conf) \
+ ((_conf)->trig_or_wq_config.fiber_config)
+
#ifdef __cplusplus
}
#endif
--
1.9.1


[RFC PATCH v2 0/5] Refactor device configuration

Vlad Dogaru <vlad.dogaru@...>
 

Hi everyone,

This is version 2 of the device configuration proposal. In the long
run, I hope to make all drivers configurable similarly to how mcp9808 is
configured in the last patch of the series. The final step, after every
driver is converted, is doing away with device names and using explicit
pointers to connect devices between each other.

News since v1:
- workqueue support is now system-wide, no more using our own
implementation;
- GPIO patches have been merged, so you can apply this to current
master without issues;
- addressed (hopefully) all feedback;
- rebased to newest master.

Patches on Gerrit: https://gerrit.zephyrproject.org/r/#/q/topic:dev_config+status:open

Link to v1: https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/thread/OXTZ3RK7WDLDS66R76HTMPEXYRKHAIDS/


Vlad Dogaru (5):
sensor: add device config helpers
i2c: add device config helpers
gpio: add device config helpers
sensor: mcp9808: support multiple devices
samples: mcp9808: support two devices

drivers/sensor/Kconfig.mcp9808 | 77 ++-------------------------------
drivers/sensor/sensor_mcp9808.c | 15 +++----
drivers/sensor/sensor_mcp9808.h | 29 ++++++++-----
drivers/sensor/sensor_mcp9808_trigger.c | 73 +++++++++----------------------
include/gpio.h | 26 +++++++++++
include/i2c.h | 16 +++++++
include/sensor.h | 77 +++++++++++++++++++++++++++++++--
samples/sensor/mcp9808/Makefile | 1 +
samples/sensor/mcp9808/prj.conf | 4 +-
samples/sensor/mcp9808/src/Makefile | 2 +-
samples/sensor/mcp9808/src/devices.c | 35 +++++++++++++++
samples/sensor/mcp9808/src/main.c | 66 ++++++++++++++++++----------
12 files changed, 246 insertions(+), 175 deletions(-)
create mode 100644 samples/sensor/mcp9808/src/devices.c

--
1.9.1


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-398] i2c FRAM sample not working
https://jira.zephyrproject.org/browse/ZEP-398


UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/2194 : drivers/nble: Update service db attributes handle
- https://gerrit.zephyrproject.org/r/2186 : scripts: add a script to report RAM/ROM usage
- https://gerrit.zephyrproject.org/r/2193 : net: Clear the connection pointer when net_buf is allocated
- https://gerrit.zephyrproject.org/r/2192 : Bluetooth/shell: Add test vendor service support
- https://gerrit.zephyrproject.org/r/2191 : Revert "drivers/nble: Check that attribute is withing range"
- https://gerrit.zephyrproject.org/r/2188 : samples/task_profiler: fix #if to #ifdef
- https://gerrit.zephyrproject.org/r/2187 : nanokernel: Add callback to _nano_timeout once again

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2164 : build: properly quote CFLAGS in zephyrmake
- https://gerrit.zephyrproject.org/r/2106 : sensor: add driver for LSM6DS0
- https://gerrit.zephyrproject.org/r/2170 : Bluetooth: L2CAP: Refactor bt_l2cap_chan type
- https://gerrit.zephyrproject.org/r/2107 : samples/task_profiler: disable UART0 on galileo to fix crash
- https://gerrit.zephyrproject.org/r/2067 : samples/task_profiler: add RTC/counter support as timestamp
- https://gerrit.zephyrproject.org/r/2086 : net: apps: zperf - add TCP client
- https://gerrit.zephyrproject.org/r/2079 : Bluetooth: L2CAP: Set basic BR/EDR CoC state tracker
- https://gerrit.zephyrproject.org/r/2039 : nano_work: Add delayed version
- https://gerrit.zephyrproject.org/r/1903 : arm: Add support for Nordic Semiconductor's nRF52 series of ICs
- https://gerrit.zephyrproject.org/r/2081 : drivers: Add basic GPIO and UART support for nRF52
- https://gerrit.zephyrproject.org/r/2082 : boards: Add support for the nRF52 DK board (PCA10040)
- https://gerrit.zephyrproject.org/r/1896 : apic : Refactor some macros into a header
- https://gerrit.zephyrproject.org/r/2066 : kernel event logger: add possibility to use custom timestamp
- https://gerrit.zephyrproject.org/r/1899 : pm/loapic: suspend/resume support for LOAPIC
- https://gerrit.zephyrproject.org/r/1898 : pm/ioapic: Add suspend/resume support for IOAPIC
- https://gerrit.zephyrproject.org/r/1997 : nios2: set initial stack pointer to the interrupt stack
- https://gerrit.zephyrproject.org/r/1996 : nios2: crt0: split into __start and __text_start
- https://gerrit.zephyrproject.org/r/1995 : nios2: add arch/nios2/soc/<soc>/include to linker include path
- https://gerrit.zephyrproject.org/r/2184 : arc: support microkernel on ARC

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2190 : Bluetooth: nble: Extend BTP with Identity Resolved event
- https://gerrit.zephyrproject.org/r/2189 : Bluetooth: tester: Correct flushed data length
- https://gerrit.zephyrproject.org/r/2110 : console: shell: Add return to command callback


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 1
[ZEP-397] Undeclared functions when building kernel_event_logger for ARC microkernel
https://jira.zephyrproject.org/browse/ZEP-397


UPDATED JIRA items within last 24 hours: 1
[ZEP-396] Enable Microkernel on ARC platforms
https://jira.zephyrproject.org/browse/ZEP-396


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2178 : arc: Adding EM9D SOC
- https://gerrit.zephyrproject.org/r/2179 : arc: Adding EM11D SOC
- https://gerrit.zephyrproject.org/r/2010 : samples: gpio: lcd: sample app for HD44780 LCD controller
- https://gerrit.zephyrproject.org/r/2184 : arc: support microkernel on ARC
- https://gerrit.zephyrproject.org/r/2171 : uart: use qmsi driver for quark_se sensor subsystem
- https://gerrit.zephyrproject.org/r/2173 : qmsi: move drivers and hal to ext/hal
- https://gerrit.zephyrproject.org/r/2095 : i2c: quark se: Add QMSI 1.1-based I2C shim driver
- https://gerrit.zephyrproject.org/r/2175 : checkpatch: exclude ext/ from checks
- https://gerrit.zephyrproject.org/r/2100 : uart: qmsi: do not include ioapic.h on non x86 systems
- https://gerrit.zephyrproject.org/r/2174 : checkpatch: add option for excluding directories
- https://gerrit.zephyrproject.org/r/2097 : adc: quark se: Add QMSI 1.1-based ADC shim driver
- https://gerrit.zephyrproject.org/r/2092 : quark_se: spi: use qmsi spi driver on sensor sub-system
- https://gerrit.zephyrproject.org/r/2093 : gpio: quark se: Add QMSI 1.1-based GPIO shim driver
- https://gerrit.zephyrproject.org/r/2091 : spi: quark se: Add QMSI 1.1-based SPI shim driver
- https://gerrit.zephyrproject.org/r/2096 : quark_se: i2c: use qmsi i2c driver
- https://gerrit.zephyrproject.org/r/2099 : apds9960: Fix reference to i2c driver
- https://gerrit.zephyrproject.org/r/2094 : quark_se: gpio: use qmsi gpio driver
- https://gerrit.zephyrproject.org/r/2090 : quark se: build sensor subsystem files
- https://gerrit.zephyrproject.org/r/2089 : qmsi: update qmsi to 1.1 alpha

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/2185 : Revert "nanokernel: Add callback to _nano_timeout"
- https://gerrit.zephyrproject.org/r/2045 : doc: Restructure top level sections.
- https://gerrit.zephyrproject.org/r/2077 : sensor: remove CONFIG_SENSOR_DEBUG


Re: Structure for external libraries, HAL

Nashif, Anas
 

On 21 May 2016, at 10:53, Kumar Gala <kumar.gala(a)linaro.org> wrote:


On May 19, 2016, at 11:48 AM, Nashif, Anas <anas.nashif(a)intel.com> wrote:

Hi,
As you are probably already aware, we have a few changes in review that add external components to Zephyr, especially the CMSIS headers needed for porting more Cortex-M MCUs and board.
Zephyr already has some external components. Some will need to move to the new proposed location outlined below.

Proposal:

create a top level directory for all external components and headers with the following structure (slightly modified):

ext/
hal/
cmsis
qmsi
ksdk
...
lib/
tinycrypt
matt-bar
lwm2m-foo
foo-tls
….

we should be able to add more 2nd level categories under ext/, we might consider having drivers for example for drivers from vendor SDKs that are well tested and verified.

The advantages of having all the code in one place:
- easy to update and maintain
- files of the same license and from the same source all in one location
- can be excluded from zephyr style checks easily (to make CI happy)
- no contamination with original zephyr code

disadvantages:
- the code will be in a location different from where it is being used and referenced
- need to create cross references across the tree
- …

We plan to make this final by next week. If you have any concerns or other suggestions please raise them now.


Anas
We should probably document rules on import in ext/README. Mostly around documenting to origins of the code import (i.e., what should be in a commit message, what meta file that documents the source of the code, what version or SHA/tag, etc).

Also, probably having a READMEs in ext/hal & ext/lib that has a one liner or two about what things are:

kext - NXP Kinetis SDK drivers
qmsi - Intel Quark Microcontroller Software Interface
cmsis - ARM Cortex Microcontroller Software Interface Standard

(etc)
Yeah, README is fine here, I would also add this to the documentation, including usage and policies etc for external modules.



The other option would be a file kinda structured like MAINTAINERS in top level ext/hal & ext/lib that gets updated on imports:

ext/hal/README:

D: directory
T: (source tree repo)
V: (repo version/tag info)

CMSIS - ARM Cortex Microcontroller Software Interface Standard
D: cmsis
T: https://github.com/ARM-software/CMSIS
V: v4.5.0

NXP Kinetis SDK drivers
D: kext
T: http://kex.nxp.com/
V: v2

QMSI - Intel Quark Microcontroller Software Interface
D: qmsi
T: https://github.com/01org/qmsi
V: v1.0.1
I would add those to the top level MAINTAINERS file we are planning to add. I do not thing we need another MAINTAINERS file.

Anas


(Needs some hashing out on the details related to how to handle version info/tags/SHAs)

- k

7561 - 7580 of 8335