Date   

Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1595 : doc: show information about documentation current version
- https://gerrit.zephyrproject.org/r/1594 : Bluetooth: SMP: Make use of sys_timer API
- https://gerrit.zephyrproject.org/r/1593 : misc: Add timer API
- https://gerrit.zephyrproject.org/r/1581 : Task monitor: move to "no_sync" API to feed kernel event logger
- https://gerrit.zephyrproject.org/r/1583 : kernel event profiler: add dynamic enable/disable/configure
- https://gerrit.zephyrproject.org/r/1578 : Add interrupt stub label for profiler (interrupt event)
- https://gerrit.zephyrproject.org/r/1580 : Add support of event logger put/get without sync
- https://gerrit.zephyrproject.org/r/1577 : Set kernel event logger timestamps to HW cycles
- https://gerrit.zephyrproject.org/r/1579 : Add capability to output binary data over console UART
- https://gerrit.zephyrproject.org/r/1591 : Bluetooth: Always use RPA for connection if privacy is enabled
- https://gerrit.zephyrproject.org/r/1590 : Bluetooth: Remove double address comparison
- https://gerrit.zephyrproject.org/r/1589 : Bluetooth: Simplify creation of LE connection
- https://gerrit.zephyrproject.org/r/1588 : Bluetooth: Simplify setting advertising parameters
- https://gerrit.zephyrproject.org/r/1587 : Bluetooth: Simplify setting random address
- https://gerrit.zephyrproject.org/r/1575 : sensors: split lsm9ds0_gyro driver
- https://gerrit.zephyrproject.org/r/1573 : sensor: rename SENSOR_TYPE_* to SENSOR_VALUE_TYPE_*
- https://gerrit.zephyrproject.org/r/1574 : sensors: split bmc150_magn driver
- https://gerrit.zephyrproject.org/r/1582 : qemu: Add possibility to redirect serial port to pseudo TTY
- https://gerrit.zephyrproject.org/r/1584 : Added profiler application
- https://gerrit.zephyrproject.org/r/1570 : Bluetooth: tester: Add Kconfig for nimble stack
- https://gerrit.zephyrproject.org/r/1572 : device: As device names are constants, let's treat them like it
- https://gerrit.zephyrproject.org/r/1571 : gpio: atmel_sam3: Make distinction with configuration and runtime data
- https://gerrit.zephyrproject.org/r/1569 : i2c: add register access API
- https://gerrit.zephyrproject.org/r/1557 : doc: update installation to add PLY library to Python3
- https://gerrit.zephyrproject.org/r/1565 : newlib_2.2.%.bbappend: Upgrade ARC newlib
- https://gerrit.zephyrproject.org/r/1564 : gcc-4.8arc.inc: Upgrade gcc
- https://gerrit.zephyrproject.org/r/1563 : binutils-2.23arc.inc:Upgrade version
- https://gerrit.zephyrproject.org/r/1562 : libgcc_4.8arc.bb: Cleanup
- https://gerrit.zephyrproject.org/r/1561 : make_zephyr_sdk.sh: Fix script compatibility with "dash"
- https://gerrit.zephyrproject.org/r/1560 : binutils: Rename append file
- https://gerrit.zephyrproject.org/r/1559 : script: clone: use poky http clone

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1483 : qmsi: watchdog: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1341 : sensor: add driver for LSM9DS0 accel and magn
- https://gerrit.zephyrproject.org/r/1360 : sensor: fix init driver_api
- https://gerrit.zephyrproject.org/r/1278 : sensor: fix coding style (bmc150 and lsm9ds0)
- https://gerrit.zephyrproject.org/r/1340 : sensor: add the posibility to fetch one data type
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1519 : doc: add step for windows build configuration
- https://gerrit.zephyrproject.org/r/1492 : qmsi: spi: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1550 : Bluetooth: L2CAP: Refactor l2cap_chan_del
- https://gerrit.zephyrproject.org/r/1491 : spi: use global init priority
- https://gerrit.zephyrproject.org/r/1523 : spi: revert changes to API
- https://gerrit.zephyrproject.org/r/1482 : qmsi: rtc: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1500 : qmsi: uart: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1496 : qmsi: gpio: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1537 : net: tcp: Disable client role
- https://gerrit.zephyrproject.org/r/1536 : net: Enable TCP support
- https://gerrit.zephyrproject.org/r/1535 : net: Initial TCP support
- https://gerrit.zephyrproject.org/r/1076 : expr_parser.py: simple expression language
- https://gerrit.zephyrproject.org/r/1077 : sanitycheck: allow for more expressive filtering in testcase.ini
- https://gerrit.zephyrproject.org/r/1078 : test_tickless: improve testcase.ini filter
- https://gerrit.zephyrproject.org/r/1488 : qmsi: i2c: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1098 : drivers: add qmsi files for Quark MCUs
- https://gerrit.zephyrproject.org/r/1522 : doc: add architecture porting guide
- https://gerrit.zephyrproject.org/r/1508 : microkernel: use _thread_essential_set()
- https://gerrit.zephyrproject.org/r/1544 : qmsi: pinmux: use built-in qmsi driver
- https://gerrit.zephyrproject.org/r/1520 : ipm console: Implement flow control between sender and receiver
- https://gerrit.zephyrproject.org/r/1353 : samples: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1354 : cc2520: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1445 : gpio: Deprecate API 1.0 callback function
- https://gerrit.zephyrproject.org/r/914 : gpio: Improve the public API to handle multi callbacks
- https://gerrit.zephyrproject.org/r/1271 : sensors: Using new GPIO API callbacks
- https://gerrit.zephyrproject.org/r/1516 : x86: make GDT setup optional
- https://gerrit.zephyrproject.org/r/1554 : Bluetooth: L2CAP: Make common l2cap_disconn_rsp
- https://gerrit.zephyrproject.org/r/1553 : Bluetooth: L2CAP: Send LE CoC traffic to dedicated handler
- https://gerrit.zephyrproject.org/r/1552 : Bluetooth: L2CAP: Make common l2cap_disconn_req

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1592 : quark_se_devboard: Enable PM for the board
- https://gerrit.zephyrproject.org/r/1586 : drivers/nble: Cleanup Nordic RPC code
- https://gerrit.zephyrproject.org/r/1585 : drivers/nble: Update RPC to 0422 revision
- https://gerrit.zephyrproject.org/r/1576 : Bluetooth: Refactor bt_init
- https://gerrit.zephyrproject.org/r/1568 : Bluetooth: tests: Add DEBUG_DRIVER to automated tests
- https://gerrit.zephyrproject.org/r/1567 : Bluetooth: drivers/h5: Remove redundant BT_DBG()
- https://gerrit.zephyrproject.org/r/1566 : Bluetooth: Fix typo tupe to type
- https://gerrit.zephyrproject.org/r/1558 : vagrant: new python-ply package for build images
- https://gerrit.zephyrproject.org/r/1450 : sensor: bmi160: move sample app to arc subdirectory
- https://gerrit.zephyrproject.org/r/1452 : sensor: bmi160: add x86 app for Arduino101
- https://gerrit.zephyrproject.org/r/1456 : sensor: bmi160: make some read/write functions global
- https://gerrit.zephyrproject.org/r/1457 : sensor: bmi160: add support for triggers
- https://gerrit.zephyrproject.org/r/1455 : sensor: bmi160: fix bmi160_reg_field_update function
- https://gerrit.zephyrproject.org/r/1458 : sensor: bmi160: add trigger tests to the application
- https://gerrit.zephyrproject.org/r/1515 : sensor: bmi160: switch to the new logging API
- https://gerrit.zephyrproject.org/r/1453 : sensor: bmi160: move the printing macro to the header
- https://gerrit.zephyrproject.org/r/1454 : sensor: bmi160: create two wrappers for bmi160_reg_val_to_range
- https://gerrit.zephyrproject.org/r/1451 : sensor: sensor.h: fix typo
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database
- https://gerrit.zephyrproject.org/r/1362 : doc/board: Add documentation file for olimexino_stm32
- https://gerrit.zephyrproject.org/r/1361 : boards/olimexino_stm32: add new board
- https://gerrit.zephyrproject.org/r/1363 : sanitycheck: Add olimexino_stm32 board to sanitycheck
- https://gerrit.zephyrproject.org/r/1530 : samples: ipm: reset kernel binary name to zephyr
- https://gerrit.zephyrproject.org/r/1546 : Bluetooth: Kconfig: Split debug selection into a choice
- https://gerrit.zephyrproject.org/r/1545 : Bluetooth: Add dedicated bt_send() function


Re: [RFC] I2C register access API

Benjamin Walsh <benjamin.walsh@...>
 

On Thu, Apr 21, 2016 at 09:19:56AM +0000, Davidoaia, Bogdan M wrote:
Hello all,

This is a proposal to add an API for reading, writing and updating
internal registers of I2C devices. This API would offer a simpler way of
communicating with I2C devices that have internal registers.

With the current I2C API, if you want to read the value of an internal
device register, you have to do an i2c_transfer call with two messages
(a write of the register address, followed by a read of the register
value).

Just looking at the sensor subsystem, all drivers define their own
register read/write functions which are more or less identical. This is
a case of code duplication that can be avoided if we add an API for
accessing registers.
Always in favour of removing code duplication! :)

I have written a patch that adds the I2C register access functions and
uploaded it to Gerrit [1]. All the new functions are implemented using
the existing I2C driver API.

What are your thoughts on this addition to the I2C API? If you think
this is a good idea, I can start updating the drivers to use the
register access function.

Thanks,
Bogdan

[1] https://gerrit.zephyrproject.org/r/#/c/1569/


Re: [RFCv2 1/2] misc: Add timer API

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Apr 19, 2016 at 05:26:11PM +0300, Luiz Augusto von Dentz wrote:
From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>

This adds a timer fiber which can be used track timeouts removing the
need to use one delayed fiber per timeout.

Change-Id: Id13347fbc69b1e83bca22094fbeb741e045ed516
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>
---
include/misc/timer.h | 106 ++++++++++++++++++++++++
misc/Kconfig | 37 +++++++++
misc/Makefile | 1 +
misc/timer.c | 224 ++++++++++++++++++++++++++++++++++++++++++++++++++
net/bluetooth/Kconfig | 1 +
5 files changed, 369 insertions(+)
create mode 100644 include/misc/timer.h
create mode 100644 misc/timer.c
This is a good functionality to add to the kernel I think. Two things
though:

1. It should probably end up in the kernel directory: I don't think this
is a 'misc' functionality.

2. I am not sure about the naming. This is yet another timer library,
when we already have nano timers and micro timers. What makes it special
is its callback functionality. Can we try to get that into the name ?


diff --git a/include/misc/timer.h b/include/misc/timer.h
new file mode 100644
index 0000000..d3ce695
--- /dev/null
+++ b/include/misc/timer.h
@@ -0,0 +1,106 @@
+/** @file
+ * @brief System timer APIs.
+ */
+
+/*
+ * Copyright (c) 2016 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.
+ */
+
+extern struct sys_timer_queue *__global_tq;
^^
We try not to use double-underscores. Single one is enough, but since
this is a global symbol, it should have a more descriptive name.

+ size_t stack_size;
+
+struct sys_timer_queue {
+ nano_thread_id_t __thread_id;
+ struct sys_timer *__head;
^^^
I'm not sure why you use double-underscores in structure field names...?

+ size_t stack_size;
+ char stack[0];
+};
+
+typedef void (*sys_timer_func)(void *user_data);
+
+struct sys_timer {
+ struct nano_timer __nano_timer;
^^
also here

+ sys_timer_func func;
+ void *user_data;
+ struct sys_timer *__next;
^^
and here

[..snip..]

+static void timer_queue_fiber(struct sys_timer_queue *tq)
+{
+ int32_t ticks;
+
+ SYS_LOG_DBG("tq %p thread_id %d started", tq, tq->__thread_id);
+
+ while ((ticks = timer_queue_ticks_remains(tq))) {
+ fiber_sleep(ticks);
+ }
+
+ SYS_LOG_DBG("tq %p thread_id %d stopped", tq, tq->__thread_id);
+
+ tq->__thread_id = 0;
+ fiber_abort();
^^^^^^^^^^^^^^

Don't do this: it's done automatically by the kernel when the fiber
entry point runs to completion.

I think it looks good, but I should not be doing a code review on the
mailing list. I'll do the full review in gerrit when it ends up there.

Cheers,
Ben

+}
+
+static int timer_queue_start(struct sys_timer_queue *tq)
+{
+ if (tq->__thread_id) {
+ return 0;
+ }
+
+ tq->__thread_id = fiber_start(tq->stack, tq->stack_size,
+ (nano_fiber_entry_t)timer_queue_fiber,
+ (int) tq, 0, 7, 0);
+
+ return 0;
+}
+
+int sys_timer_queue_init(struct sys_timer_queue *tq, size_t stack_size)
+{
+ if (!tq || !stack_size) {
+ return -EINVAL;
+ }
+
+ tq->stack_size = stack_size;
+
+ return 0;
+}
+
+static inline void timer_queue_wakeup(struct sys_timer_queue *tq)
+{
+ if (sys_thread_self_get() != tq->__thread_id) {
+ fiber_wakeup(tq->__thread_id);
+ }
+}
+
+int sys_timer_queue_add(struct sys_timer_queue *tq, struct sys_timer *t, int ticks)
+{
+ struct sys_timer *cur, *prev;
+
+ SYS_LOG_DBG("tq %p t %p ticks %d", tq, t, ticks);
+
+ if (!t || !t->func)
+ return -EINVAL;
+
+ timer_queue_start(tq);
+ nano_timer_start(&t->__nano_timer, ticks);
+
+ /* Sort the list of timers */
+ for (cur = tq->__head, prev = NULL; cur;
+ prev = cur, cur = cur->__next) {
+ if (ticks < nano_timer_ticks_remain(&cur->__nano_timer)) {
+ break;
+ }
+ }
+
+ t->__next = cur;
+
+ if (prev) {
+ prev->__next = t;
+ } else {
+ tq->__head = t;
+ /* Wakeup timer queue fiber since there is a new head */
+ timer_queue_wakeup(tq);
+ }
+
+ return 0;
+}
+
+int sys_timer_queue_cancel(struct sys_timer_queue *tq, struct sys_timer *t)
+{
+ struct sys_timer *cur, *prev;
+
+ SYS_LOG_DBG("tq %p t %p", tq, t);
+
+ if (!t) {
+ return -EINVAL;
+ }
+
+ /* Lookup existing timers */
+ for (cur = tq->__head, prev = NULL; cur;
+ prev = cur, cur = cur->__next) {
+ if (cur == t) {
+ break;
+ }
+ }
+
+ if (!cur) {
+ return -ENOENT;
+ }
+
+ nano_timer_stop(&t->__nano_timer);
+
+ /* Remove timer for the queue */
+ if (prev) {
+ prev->__next = t->__next;
+ } else {
+ tq->__head = t->__next;
+ /* Wakeup timer queue fiber since there is a new head */
+ timer_queue_wakeup(tq);
+ }
+
+ return 0;
+}
+
+int sys_timer_init(struct sys_timer *t, sys_timer_func func, void *user_data)
+{
+ if (!t || !func) {
+ return -EINVAL;
+ }
+
+ t->func = func;
+ t->user_data = user_data;
+ nano_timer_init(&t->__nano_timer, t);
+
+ return 0;
+}
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 2ffb0e0..aa2712b 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -129,6 +129,7 @@ config BLUETOOTH_CENTRAL

config BLUETOOTH_CONN
bool
+ select SYS_TIMER
default n

if BLUETOOTH_CONN
--
2.5.5


Re: [RFC 0/3] Timer Fiber API

Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Apr 19, 2016 at 05:57:50PM +0300, Luiz Augusto von Dentz wrote:
Hi Szymon,

On Tue, Apr 19, 2016 at 11:31 AM, Szymon Janc <ext.szymon.janc(a)tieto.com> wrote:
Hi Luiz,

On Monday 18 of April 2016 18:16:00 Luiz Augusto von Dentz wrote:
From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>

Following the discussion about the Timer API I decided to prototype the
feature in the Bluetooth subsystem:

XX:XX:XX:XX:XX:XX (public)> security 2
bt: bt_timer_queue_add (0x0011a54c): tq 0x00119940 t 0x0011bb1c ticks 3000
XX:XX:XX:XX:XX:XX (public)> bt: timer_queue_fiber (0x0011994c): tq
0x00119940 thread_id 1153356 started bt: timer_queue_ticks_remains
(0x0011994c): tq 0x00119940 ticks 3000 bt: bt_timer_queue_cancel
(0x0011dc60): tq 0x00119940 t 0x0011bb1c bt: bt_timer_queue_add
(0x0011dc60): tq 0x00119940 t 0x0011bb1c ticks 3000 bt:
timer_queue_ticks_remains (0x0011994c): tq 0x00119940 ticks 3000 bt:
bt_timer_queue_cancel (0x0011dc60): tq 0x00119940 t 0x0011bb1c bt:
bt_timer_queue_add (0x0011dc60): tq 0x00119940 t 0x0011bb1c ticks 3000 bt:
timer_queue_ticks_remains (0x0011994c): tq 0x00119940 ticks 2990 Confirm
passkey for XX:XX:XX:XX:XX:XX (public): 775621
bt: timer_expired (0x0011994c): t 0x0011bb1c
bt: smp_timeout: SMP Timeout
bt: timer_queue_ticks_remains (0x0011994c): tq 0x00119940 ticks 0
bt: timer_queue_fiber (0x0011994c): tq 0x00119940 thread_id 1153356 stopped
Disconnected: XX:XX:XX:XX:XX:XX (public) (reason 19)

So at this point it works properly, I tested what could be the minimal stack
necessary in order to run the timer queue and arrive at 512 bytes which is
4 times bigger than what we used to have when using a delayed fiber in SMP
so the timer API only really payoff in terms of memory in case there is 4
or more timer active, which there will be since we will be adding more user
for that in ATT and L2CAP protocols.
I don't get this why you need 512bytes if only 128 was needed by SMP. This
should mostly depend on how heavy is the callback, right? Is overhead for
queue that big?
Should be made configurable.

Actually this is due to printf usage in BT_ERR when smp_timeout is
called, something that perhaps we should not account in the system
wide timer and perhaps just stick with 128 bytes which should work in
most cases where the callback don't require to much stack.


Ive also make the timer queue abort if there is no timers left, this is
something that perhaps is not such a good idea if there is too much
overhead starting the fibers on demand, perhaps by the it cannot be used if
the ticks are low perhaps it is shorter then starting a fiber thus loosing
precision. Anyway the idea here is not to invent a high precision timer, in
fact later on we may introduce a function that takes the timeout in seconds
instead of ticks and then coalesce multiple timers that would happen in the
same second thus reducing the amount of wakeups.

Luiz Augusto von Dentz (3):
Bluetooth: Add timer API
Bluetooth: Kconfig: Add BLUETOOTH_DEBUG_TIMER
Bluetooth: SMP: Make use of bt_timer API

net/bluetooth/Kconfig | 17 ++++
net/bluetooth/Makefile | 1 +
net/bluetooth/smp.c | 40 ++++-----
net/bluetooth/timer.c | 216
+++++++++++++++++++++++++++++++++++++++++++++++++ net/bluetooth/timer.h |
48 +++++++++++
5 files changed, 299 insertions(+), 23 deletions(-)
create mode 100644 net/bluetooth/timer.c
create mode 100644 net/bluetooth/timer.h


Re: Using IC manufacturer header files

Carles Cufi
 

Hi Anas,

-----Original Message-----
From: Nashif, Anas [mailto:anas.nashif(a)intel.com]
Sent: Thursday, April 21, 2016 14:25
To: Maciek Borzecki <maciek.borzecki(a)gmail.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Using IC manufacturer header files

On 20 Apr 2016, at 16:10, Maciek Borzecki <maciek.borzecki(a)gmail.com>
wrote:

<snip>

- I don't trust vendors to have a reasonable release management
(more often than not they prove to have none)
Agreed, see point above. Sometimes there's legitimate reasons to
change the structure of the SDK provided by a vendor, but the OS build
shouldn't be affected by it. Furthermore, relying on a particular
version could potentially then introduce dependency hell into the Zephyr
build for certain architectures, where some users would start to
complain that the OS doesn't build for a particular IC because they have
an older (or newer) IC vendor SDK than the one that Zephyr depends on.

I understand that it's nicer from user's perspective that the CPU
support is integrated into the main codebase. I'm just not sure if it
will be possible to maintain this state in the long run. Integrating
code from a 3rd party into the main codebase means that we've
officially made maintaining compatibility our problem. While, this is
ok to do it with IP stack from contiki, it's just one 3rd party
project after all, it will be hard with the multitude of CPUs out
there.

I know it sounds crazy, but OpenEmbedded BSP layers are not that bad
to work with after all. I can imagine that having similar BSP layers
for Zephyr would not be that complicated. These 'layers', maintained
by community or interested parties, could provide a curated hardware
enablement or support libraries.

This sounds like the mBed approach. Whether you put the files in Zephyr
main source tree or in some other Git repo you are still maintaining the
files the same way, adding the file somewhere else will just create
dependencies on external modules.

Yes, that was my argument in favor of removing dependencies or additional layers of source control and instead keeping the files inside the Zephyr source tree. It's not ideal, but it sounds better to me than the alternatives at this point.

Carles


Re: Using IC manufacturer header files

Nashif, Anas
 

On 20 Apr 2016, at 16:10, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote:

<snip>

- I don't trust vendors to have a reasonable release management (more
often than not they prove to have none)
Agreed, see point above. Sometimes there's legitimate reasons to change the structure of the SDK provided by a vendor, but the OS build shouldn't be affected by it. Furthermore, relying on a particular version could potentially then introduce dependency hell into the Zephyr build for certain architectures, where some users would start to complain that the OS doesn't build for a particular IC because they have an older (or newer) IC vendor SDK than the one that Zephyr depends on.
I understand that it's nicer from user's perspective that the CPU
support is integrated into the main codebase. I'm just not sure if it
will be possible to maintain this state in the long run. Integrating
code from a 3rd party into the main codebase means that we've
officially made maintaining compatibility our problem. While, this is
ok to do it with IP stack from contiki, it's just one 3rd party
project after all, it will be hard with the multitude of CPUs out
there.

I know it sounds crazy, but OpenEmbedded BSP layers are not that bad
to work with after all. I can imagine that having similar BSP layers
for Zephyr would not be that complicated. These 'layers', maintained
by community or interested parties, could provide a curated hardware
enablement or support libraries.

This sounds like the mBed approach. Whether you put the files in Zephyr main source tree or in some other Git repo you are still maintaining the files the same way, adding the file somewhere else will just create dependencies on external modules.


Anas


Re: [RFC] I2C register access API

Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

On Jo, 2016-04-21 at 13:04 +0300, Vlad Dogaru wrote:
On Thu, Apr 21, 2016 at 11:44:45AM +0200, Tomasz Bursztyka wrote:
Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!
Same here.

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)
The sx9500 driver makes a burst write at init to set a bunch of
configuration registers, so that's one user. Not sure about any others,
though.
Good enough for me. Will also add burst write.

Bogdan


Re: [RFC] I2C register access API

Vlad Dogaru <vlad.dogaru@...>
 

On Thu, Apr 21, 2016 at 11:44:45AM +0200, Tomasz Bursztyka wrote:
Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!
Same here.

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)
The sx9500 driver makes a burst write at init to set a bunch of
configuration registers, so that's one user. Not sure about any others,
though.

Vlad


Re: [RFC] I2C register access API

Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

Don't think burst write is that common, but it may be useful if a driver
wants to optimize write operations when configuring the chip.

The functions I wrote are for 8-bit registers/addresses which are the
most common cases. Some drivers can have 16-bit registers in which case
a burst write of 2 bytes can simulate a write of the 16-bit register.
One chip we wrote a driver for (SHT3xD) also has a 16-bit address, but
this is even less common than the 16-bit registers.

But I am not sure if we want to support 16-bit registers/addresses with
these functions, or leave them as exceptions (in which case the driver
will implement it's own register read/write functions).

For the case of symmetry and having the burst write function there if
future drivers will need it, I can add a i2c_reg_burst_write function as
well.

Bogdan

On Jo, 2016-04-21 at 11:44 +0200, Tomasz Bursztyka wrote:
Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)

Tomasz


Re: [RFC] I2C register access API

Tomasz Bursztyka
 

Hi Bogdan,

I like the idea. It would help to factorize code in many places indeed!

Btw, would it make sense to an i2c_reg_burst_write()?
(would there be any use-case for such function actually?)

Tomasz


[RFC] I2C register access API

Davidoaia, Bogdan M <bogdan.m.davidoaia@...>
 

Hello all,

This is a proposal to add an API for reading, writing and updating
internal registers of I2C devices. This API would offer a simpler way of
communicating with I2C devices that have internal registers.

With the current I2C API, if you want to read the value of an internal
device register, you have to do an i2c_transfer call with two messages
(a write of the register address, followed by a read of the register
value).

Just looking at the sensor subsystem, all drivers define their own
register read/write functions which are more or less identical. This is
a case of code duplication that can be avoided if we add an API for
accessing registers.

I have written a patch that adds the I2C register access functions and
uploaded it to Gerrit [1]. All the new functions are implemented using
the existing I2C driver API.

What are your thoughts on this addition to the I2C API? If you think
this is a good idea, I can start updating the drivers to use the
register access function.

Thanks,
Bogdan

[1] https://gerrit.zephyrproject.org/r/#/c/1569/


Re: Using IC manufacturer header files

Carles Cufi
 

Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 22:10
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Wed, Apr 20, 2016 at 9:28 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 19:24
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas
<anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need
to be
kept in sync with upstream can keep their style and formatting to
allow updates in the future. This was the approach taken when we
imported the IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another
repository
at build time, since I don't know what buildroot does with
kernel/toolchains.
However the MDK is not currently available in a repository, instead
it
is released as a .zip file by Nordic every time it gets updated. We
could of course mirror it in a repo, but that would anyway require us
to update it manually every time a new version is available.

What I meant is that you keep the {S,M}DK externally and just
configure a path to it inside Kconfig. You can add a config entry
like CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles
-I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the
build as needed. This has one major advantage, that the 3rd party
code is kept outside of Zephyr repository, so you basically don't
care about the naming/conventions/licenses 3rd party libraries would
use.

I couldn't find the CONFIG_STM32F1_STDLIB_PATH you mentioned, and I
tried to build the "hello_world" sample for STM32 and it worked fine,
even though I have no STM SDK installed at all.

Right, but only because the implementation was done in such way.
Frankly, if I used ST's libraries, it would have saved me a lot of time
during porting. Instead, I followed the example set by other, already
supported, targets and implemented STM32 specific pieces from scratch by
looking at the CPU manuals only.

With that I mean that it looks like, so far, archs are self-contained.
The problem with the "-I$(NORDIC_MDK_PATH)" approach is that, as you
mention later, Nordic might change the folder structure of the .zip file
that it provides, rename some files and change it completely, leaving us
at the mercy of the vendor.

As for mirroring 3rd party SDK in a repo. No matter the vendor's
distribution method I always pull the source code into a git
repository for two main reasons:
By pulling into the repo I assume you mean actually duplicating the
files inside the target repo, instead of "pulling" them from an external
repo.

- I don't trust vendors to have a reasonable release management (more
often than not they prove to have none)
Agreed, see point above. Sometimes there's legitimate reasons to
change the structure of the SDK provided by a vendor, but the OS build
shouldn't be affected by it. Furthermore, relying on a particular
version could potentially then introduce dependency hell into the Zephyr
build for certain architectures, where some users would start to
complain that the OS doesn't build for a particular IC because they have
an older (or newer) IC vendor SDK than the one that Zephyr depends on.

I understand that it's nicer from user's perspective that the CPU
support is integrated into the main codebase. I'm just not sure if it
will be possible to maintain this state in the long run. Integrating
code from a 3rd party into the main codebase means that we've officially
made maintaining compatibility our problem. While, this is ok to do it
with IP stack from contiki, it's just one 3rd party project after all,
it will be hard with the multitude of CPUs out there.
Well the only alternatives to directly integrating IC manufacturer header files into the Zephyr repo that I can conceive are:

1) Maintain the manufacturer files in a separate repository that we somehow (submodule or repo) pull into the build
2) Require the user to pre-install those header files as a dependency to be able to build for a particular architecture
3) Re-implement all the functionality provided by those IC manufacturer header files in our own style and inside the Zephyr repo

I personally dislike 1) and 2) for the reasons I've already exposed in previous emails, so for me the only real alternative is 3). But let's remember that we are talking about header files that describe SoCs here, not specific libraries a version of which we maintain internally. Those header files reflect the register set and the memory map of the SoC, and for that reason they tend to be accurate and well-tested since they have been used to develop the source examples that IC manufacturers already provide in their SDKs. That is yet another reason for me to advocate for the usage of these files unchanged and integrated in our repository. Furthermore, SoCs do not tend to change often (they are hardware descriptions after all) and therefore maintaining them internally should not be too onerous.


I know it sounds crazy, but OpenEmbedded BSP layers are not that bad to
work with after all. I can imagine that having similar BSP layers for
Zephyr would not be that complicated. These 'layers', maintained by
community or interested parties, could provide a curated hardware
enablement or support libraries.
This goes beyond the scope of the work we are trying to do here I believe. For now we want to add support for an architecture, and establishing a layer system for SoC support is not something we have contemplated so far.

Thanks,

Carles


Re: [RFCv2 1/2] misc: Add timer API

Luiz Augusto von Dentz
 

Hi Tomasz,

On Wed, Apr 20, 2016 at 12:05 PM, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com> wrote:
Hi Luiz,



+
+struct sys_timer_queue {
+ nano_thread_id_t __thread_id;
+ struct sys_timer *__head;
+ size_t stack_size;
+ char stack[0];
+};
+
+typedef void (*sys_timer_func)(void *user_data);

Giving the pointer on current sys_timer instead you could:

+
+struct sys_timer {
+ struct nano_timer __nano_timer;
+ sys_timer_func func;
+ void *user_data;

remove that pointer, and up to user to use CONTAINER_OF() if he wants to.
(yes I am reusing ideas from Johan ;) )
Yep, this actually saves a pointer and in fact is something I thought
about but for some reason did not implement, anyway I will change to
make use of CONTAINER_OF.

+ struct sys_timer *__next;
+};
+
+/**
+ * @brief Init timer queue
+ *
+ * @param tq Timer queue object that should be initialized
+ * @param stack_size The stack size in bytes
+ */
+int sys_timer_queue_init(struct sys_timer_queue *tq, size_t stack_size);

Are you ever going to use another queue besides the system's one (the global
one)?
It could simplify a lot the API then. Unless I miss to see some use case for
custom queue
Well a private/custom one could be useful in case the stack needs to
different, and I was actually thinking to include a priority later on.
But yes it could be simplified in the first version so later on we can
check for actual use cases.

+
+/**
+ * @brief Add timer to a timer queue
+ *
+ * Both timer and timer queue must be initialized.
+ *
+ * @param tq Timer queue object to add the timer

And continuing on that idea, is it then worth asking to which queue you want
to add a timer?

+ * @param t Timer object to be added
+ * @param ticks Amount of time in ticks to wait
+ *
+ * @return Zero on success or (negative) error code otherwise.
+ */
+int sys_timer_queue_add(struct sys_timer_queue *tq, struct sys_timer *t,
+ int ticks);

so you could remove tq parameter.

+
+/**
+ * @brief Cancel timer
+ *
+ * Remove timer from timer queue and stop it so its callback is not
called.
+ *
+ * @param tq Timer queue object where the timer was added
+ * @param t Timer object to be canceled
+ *
+ * @return Zero on success or (negative) error code otherwise.
+ */
+int sys_timer_queue_cancel(struct sys_timer_queue *tq, struct sys_timer
*t);

here as well.


+
+/**
+ * @brief Init timer
+ *
+ * @param t Timer object to be initialized
+ * @param func Function callback to be called when timer expires
+ * @param user_data Data to be passed in the callback
+ *
+ * @return Zero on success or (negative) error code otherwise.
+ */
+int sys_timer_init(struct sys_timer *t, sys_timer_func func, void
*user_data);
+
+/**
+ * @brief Add timer to the global timer queue
+ *
+ * Timer must be initialized.
+ *
+ * @param _t Timer object to be added
+ * @param _ticks Amount of time in ticks to wait
+ *
+ * @return Zero on success or (negative) error code otherwise.
+ */
+#define sys_timer_add(_t, _ticks) sys_timer_queue_add(__global_tq, _t,
_ticks)
+
+/**
+ * @brief Cancel global timer
+ *
+ * Remove timer from the global timer queue and stop it so its callback
is not
+ * called.
+ *
+ * @param _t Timer object to be canceled
+ *
+ * @return Zero on success or (negative) error code otherwise.
+ */
+#define sys_timer_cancel(_t) sys_timer_queue_cancel(__global_tq, _t)

And these 2 defines would also go away.

And struct sys_timer_queue could also be private.

Tomasz


--
Luiz Augusto von Dentz


Re: remove zephyr-env.sh

Carles Cufi
 


By the way, and as a side comment, paths containing "~" do not seem to
work in ZEPHYR_BASE and <toolchain>_TOOLCHAIN_PATH. Instead one has to
explicitly set "/home/me".
Mind filing a ticket for it, please?
https://jira.zephyrproject.org/browse/ZEP-212

Carles


Re: [RFC] Zephyr IoT Protocols

Flavio Santes <flavio.santes@...>
 

Hello Joakim,

Your feedback is really appreciated.

-----Original Message-----
From: Joakim Eriksson [mailto:joakime(a)sics.se]
Sent: Wednesday, April 20, 2016 2:01 AM
To: Santes, Flavio <flavio.santes(a)intel.com>
Cc: Joakim Eriksson <joakime(a)sics.se>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC] Zephyr IoT Protocols

I fully agree with your plan of implementing the IoT protocols but have a few
questions related to the planned implementation.

What is the minimal SoC required for the implementation of let’s say DTLS +
CoAP + LWM2M + Application (assumed to be small)?

There are a lot of SoC out there in real IoT products already that probably could
replace whatever codebase they currently run (Zigbee, or other 802.15.4, RIOT,
Contiki, mbed OS, etc) so this is very interesting for me at least.
Our target SoC's are the same as Zephyr's. This is a new feature to be
added to Zephyr.


In Contiki we have a stack that can run on STM32W108 which has 16 KB of RAM
and 256 KB of flash that we used for IPSO Interop last year and had the
following:
- Full Yanzi Application Layer Stack
- DTLS + CoAP + LWM2M + IPSO Objects

Running in Yanzi LED Lamps and Yanzi Smart Plugs and they was interop tested
with Wakaama and Leshan plus other implementations at the event. This
codebase is already in upstream Contiki.

Thread + Nest’s application layer seems to need more than Thread/6LoWPAN +
LWM2M and therefore requires larger devices - I am very interested in seeing
which is your target for IoT devices that needs connectivity and a full IP +
Application stack.
Thank you for sharing the specs of your demos. It could be interesting
to compare your results with Zephyr. Can you describe your setup
(number or nodes, networking technology, average response time
node <-> server)?

Personally i would also vote for calling these IoT protocols rather than M2M
protocols. All of them are Internet protocols and M2M sounds more M-Bus,
modbus, and the likes to me. So the title “Zephyr IoT protocols” i do like, but I
suggest having them in something that is IP-network related rather than in a
lib/m2m folder.
Regarding the naming convention, I do prefer "IoT Protocols" than "M2M".
However, "m2m" is shorter than "iot_proto", perhaps just "iot" would
also work.
Let's see what others say in the coming days!


Also, there are plenty of reference implementations out there. I think you should
at least also have Leshan (LWM2M server/client library) in the list also, and
possibly the Contiki implementations of MQTT/LWM2M that might not be
reference implementations but would match an implementation that would fit
constrained IoT devices (which will be a part of the future as long as RAM costs
energy to retain and money to buy).
So far, we didn't consider Leshan because is written in Java. However,
we could use it in the server side during tests.

Cheers,
Flavio


Best regards,
— Joakim Eriksson, SICS


On 19 Apr 2016, at 23:22, Santes, Flavio <flavio.santes(a)intel.com> wrote:

[RFC] Zephyr IoT Protocols


Problem definition

Currently, Zephyr does not support any machine-to-machine protocol
(M2M). These protocols were defined for inter-communication between
devices or nodes in a constrained networking environment [1].


Aim and scope

This document proposes the integration of M2M protocols to Zephyr.
Specifically, we are interested in the following protocols:
CoAP [3], LightweightM2M (LWM2M) [2], MQTT [4] and MQTT-SN [5].


State of the art

LWM2M is a device-management protocol frequently used on the top of
CoAP. CoAP requires UDP as a transport protocol. Optionally, CoAP may
use DTLS (on the top of UDP) for securing communications between
devices.

On the other hand, MQTT, a publish-subscribe messaging protocol,
requires TCP as a transport protocol and may use TLS to create a secure
channel.

A lightweight version of MQTT for sensor networks (MQTT-SN) can be
deployed in almost any kind of network and it doesn't require any
specific transport protocol. MQTT-SN was created with short-range
wireless networks in mind. However, MQTT-SN can be used with wired or
wireless networks.

Support for short-range wireless communications in Zephyr is present
via Bluetooth. Furthermore, the Zephyr's TCP/IP stack only offers UDP.
So far, TCP is work in progress. Zephyr offers a networking security
layer by means of DTLS.


Reference implementations

LWM2M + CoAP (wakaama)
A plain C BSD-licensed implementation of LWM2M is available at [6].

MQTT client library
A client-side plain C implementation, licensed under the Eclipse
Public License [7].

MQTT client full implementation
Project Paho provides a full implementation in C++ licensed under
the Eclipse Public License [8].

MQTT-SN
C library licensed under the Eclipse Public License [9].


Integrating M2M protocols with Zephyr

MQTT relies on TCP as a transport protocol, and this could be an
stopper. So far, there is no evidence of any other inconvenience for
integrating LWM2M, CoAP and MQTT-SN.

Proposed roadmap

The integration of the M2M protocols could fit into the lib/m2m
directory (to be created), generating a directory per protocol:

lib/
|-- m2m
|-- coap
|-- lwm2m
|-- mqtt
|-- mqtt_sn

MQTT-SN can be the first protocol added to Zephyr, given the few
dependencies involved in its development and testing. We can continue
with CoAP/LWM2M and finally with MQTT. However, it's not clear if the
Zephyr's licenses are compatible with the Eclipse Public License, so
this could be a stopper (we can always write the code from scratch if
this license is incompatible with Zephyr's).

References

[1] Terminology for Constrained-Node Networks
C. Bormann, et al.
May, 2014
<https://www.rfc-editor.org/rfc/rfc7228.txt>

[2] OMA Lightweight M2M (LWM2M) protocol
Open Mobile Alliance
December, 2013
<http://openmobilealliance.hs-sites.com/
lightweight-m2m-specification-from-oma>

[3] The Constrained Application Protocol (CoAP)
Z. Shelby, et al.
June, 2014
<https://tools.ietf.org/html/rfc7252>

[4] MQTT Version 3.1.1
Andrew Banks and Rahul Gupta
October 2014
<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf>

[5] MQTT For Sensor Networks Protocol Specification Version 1.2
Andy Stanford-Clark and Hong Linh Truong
November, 2014
<http://mqtt.org/new/wp-content/uploads/2009/06/
MQTT-SN_spec_v1.2.pdf>

[6] LWM2M implementation - Wakaama Project
Eclipse Foundation
<https://github.com/eclipse/wakaama>

[7] MQTT C client - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/>
GIT repo:
<https://github.com/eclipse/paho.mqtt.c>

[8] MQTT C/C++ Embedded clients - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt.embedded-c.git>

[9] MQTT-SN - Eclipse Paho
Eclipse Foundation
<https://www.eclipse.org/paho/clients/c/embedded-sn/>
GIT repo:
<http://git.eclipse.org/c/paho/
org.eclipse.paho.mqtt-sn.embedded-c.git/>


Re: remove zephyr-env.sh

Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

On Wed, 2016-04-20 at 15:58 -0400, Benjamin Walsh wrote:
On Wed, Apr 20, 2016 at 07:53:56PM +0000, Boie, Andrew P wrote:


From: Perez-Gonzalez, Inaky [mailto:inaky.perez-gonzalez(a)intel.co
m]
Currently we require the user to source the zephyr-env.sh
environment to
set up the build environment. This is awkward; things build fine
without
it and the user still has to manually setup ZEPHYR_BASE,
ZEPHYR_GCC_VARIANT and ZEPHYR_SDK_INSTALL_DIR. zephyr-env.sh has
grown to
I don't believe this is the case.

Thanks for all the feedback -- it definitely looks that it is staying
as people very actively rely on it, so I'll close the ticket but first
I'll add the feedback to it for future reference in case anyone has the
same idea :)


Re: remove zephyr-env.sh

Boie, Andrew P
 

-----Original Message-----
From: Perez-Gonzalez, Inaky
Certainly, ZEPHYR_BASE is tree-specific (so could be the other in certain
cases, but uncommon). I also do set it manually (in fact, as I said
somewhere, I feed it to make's command line)
I feel that is rather cumbersome.
I'm not sure if we can just migrate this to the build system, since the application Makefile has to find the main Zephyr Makefile somehow...it could be out-of-tree.

Can we fold a 'make sanitycheck'-like solution? After all, if we can
figure out access to the Makefile, we can use it for accessing the scripts
too?
Given the plethora of command line options to sanitycheck, a nontrivial subset of which are used fairly often, I don't see a path to success with this approach.

Andrew


Re: Using IC manufacturer header files

Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Apr 20, 2016 at 9:28 PM, Cufi, Carles <Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 19:24
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need to
be
kept in sync with upstream can keep their style and formatting to
allow updates in the future. This was the approach taken when we
imported the IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another repository
at build time, since I don't know what buildroot does with
kernel/toolchains.
However the MDK is not currently available in a repository, instead it
is released as a .zip file by Nordic every time it gets updated. We
could of course mirror it in a repo, but that would anyway require us to
update it manually every time a new version is available.

What I meant is that you keep the {S,M}DK externally and just configure
a path to it inside Kconfig. You can add a config entry like
CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles
-I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the
build as needed. This has one major advantage, that the 3rd party code
is kept outside of Zephyr repository, so you basically don't care about
the naming/conventions/licenses 3rd party libraries would use.
I couldn't find the CONFIG_STM32F1_STDLIB_PATH you mentioned, and I tried to build the "hello_world" sample for STM32 and it worked fine, even though I have no STM SDK installed at all.
Right, but only because the implementation was done in such way.
Frankly, if I used ST's libraries, it would have saved me a lot of
time during porting. Instead, I followed the example set by other,
already supported, targets and implemented STM32 specific pieces from
scratch by looking at the CPU manuals only.

With that I mean that it looks like, so far, archs are self-contained. The problem with the "-I$(NORDIC_MDK_PATH)" approach is that, as you mention later, Nordic might change the folder structure of the .zip file that it provides, rename some files and change it completely, leaving us at the mercy of the vendor.

As for mirroring 3rd party SDK in a repo. No matter the vendor's
distribution method I always pull the source code into a git repository
for two main reasons:
By pulling into the repo I assume you mean actually duplicating the files inside the target repo, instead of "pulling" them from an external repo.

- I don't trust vendors to have a reasonable release management (more
often than not they prove to have none)
Agreed, see point above. Sometimes there's legitimate reasons to change the structure of the SDK provided by a vendor, but the OS build shouldn't be affected by it. Furthermore, relying on a particular version could potentially then introduce dependency hell into the Zephyr build for certain architectures, where some users would start to complain that the OS doesn't build for a particular IC because they have an older (or newer) IC vendor SDK than the one that Zephyr depends on.
I understand that it's nicer from user's perspective that the CPU
support is integrated into the main codebase. I'm just not sure if it
will be possible to maintain this state in the long run. Integrating
code from a 3rd party into the main codebase means that we've
officially made maintaining compatibility our problem. While, this is
ok to do it with IP stack from contiki, it's just one 3rd party
project after all, it will be hard with the multitude of CPUs out
there.

I know it sounds crazy, but OpenEmbedded BSP layers are not that bad
to work with after all. I can imagine that having similar BSP layers
for Zephyr would not be that complicated. These 'layers', maintained
by community or interested parties, could provide a curated hardware
enablement or support libraries.


- you cannot rely on developers putting/extracting SDK's at proper
locations and setting their dev environment
Yes, this is especially troublesome in this case. The MDK is delivered as a .zip file for Linux and there is no installer or standardized path for it.


The multi repository projects can be easily remedied by using `repo`
tool or git submodules.
Although that is true, it would break the current seemingly desirable feature of the Zephyr codebase, and that is it being self-contained. Git submodules or repo add an additional layer of complexity to users, and that is not something I envision introducing at this point.

So far we have a nice, self-contained repo with a subset of (almost) untouched Nordic MDK files in the arch folder. We'll start with that and see how that works in the future.

Thanks,

Carles


--
Maciek Borzecki


Re: remove zephyr-env.sh

Nashif, Anas
 

On 20/04/2016, 15:58, "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez(a)intel.com> wrote:

On Wed, 2016-04-20 at 19:53 +0000, Boie, Andrew P wrote:

From: Perez-Gonzalez, Inaky [mailto:inaky.perez-gonzalez(a)intel.com]
Currently we require the user to source the zephyr-env.sh
environment to
set up the build environment. This is awkward; things build fine
without
it and the user still has to manually setup ZEPHYR_BASE,
ZEPHYR_GCC_VARIANT and ZEPHYR_SDK_INSTALL_DIR. zephyr-env.sh has
grown to
I don't believe this is the case.

You do have to set ZEPHYR_GCC_VARIANT and ZEPHYR_SDK_INSTALL_DIR. I
put them in my .bashrc:

export ZEPHYR_GCC_VARIANT=zephyr
export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk/

However, ZEPHYR_BASE is specific to what Zephyr tree you are working
in. I personally have several that I work in. This is not something I
would want to globally set in my .bashrc. At minimum we would need to
transplant this logic to the Makefiles.
Certainly, ZEPHYR_BASE is tree-specific (so could be the other in
certain cases, but uncommon). I also do set it manually (in fact, as I
said somewhere, I feed it to make's command line)

if you think doing this

# make ZEPHYR_BASE=/path/to/source/tree BOARD=blah blah

hundreds of times per day is more convenient than doing 'source zephyr-env.sh’ once a day per shell then we have a different definition of convenience :-)



From looking at the script it additionally:

1. Appends the ZEPHYR_BASE/scripts directory to the PATH
This is the only one that might have some use--however, it still forces
you to work on the same session; if you fly through windows and tabs,
like I do, it's not as useful.

2. Sources ~/.zephyrrc if it exists (not sure what the use-case for
this is, I don't personally use it).
I haven't heard of anyone ever using this (hopefully they'll come up in
this thread).

I use it and it is also documented in the getting started guide.



Both of these seem optional, but to run stuff like sanitycheck from
the command line you'd have to include a full path.
Can we fold a 'make sanitycheck'-like solution? After all, if we can
figure out access to the Makefile, we can use it for accessing the
scripts too?

then you have to support all the nice options of sanity checks using make, do not know how user-friendly this will be.


Anas


Re: remove zephyr-env.sh

Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

On Wed, 2016-04-20 at 19:53 +0000, Boie, Andrew P wrote:

From: Perez-Gonzalez, Inaky [mailto:inaky.perez-gonzalez(a)intel.com]
Currently we require the user to source the zephyr-env.sh
environment to
set up the build environment. This is awkward; things build fine
without
it and the user still has to manually setup ZEPHYR_BASE,
ZEPHYR_GCC_VARIANT and ZEPHYR_SDK_INSTALL_DIR. zephyr-env.sh has
grown to
I don't believe this is the case.

You do have to set ZEPHYR_GCC_VARIANT and ZEPHYR_SDK_INSTALL_DIR. I
put them in my .bashrc:

export ZEPHYR_GCC_VARIANT=zephyr
export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk/

However, ZEPHYR_BASE is specific to what Zephyr tree you are working
in. I personally have several that I work in. This is not something I
would want to globally set in my .bashrc. At minimum we would need to
transplant this logic to the Makefiles.
Certainly, ZEPHYR_BASE is tree-specific (so could be the other in
certain cases, but uncommon). I also do set it manually (in fact, as I
said somewhere, I feed it to make's command line)

From looking at the script it additionally:

1. Appends the ZEPHYR_BASE/scripts directory to the PATH
This is the only one that might have some use--however, it still forces
you to work on the same session; if you fly through windows and tabs,
like I do, it's not as useful.

2. Sources ~/.zephyrrc if it exists (not sure what the use-case for
this is, I don't personally use it).
I haven't heard of anyone ever using this (hopefully they'll come up in
this thread).

Both of these seem optional, but to run stuff like sanitycheck from
the command line you'd have to include a full path.
Can we fold a 'make sanitycheck'-like solution? After all, if we can
figure out access to the Makefile, we can use it for accessing the
scripts too?

7241 - 7260 of 7811