NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 4
[ZEP-178] Port Zephyr to Altera Max10 (Nios 2 CPU)
https://jira.zephyrproject.org/browse/ZEP-178
[ZEP-53] enable kernel_event_logger on ARC
https://jira.zephyrproject.org/browse/ZEP-53
[ZEP-186] ISSM - ARC support
https://jira.zephyrproject.org/browse/ZEP-186
[ZEP-100] Test bug for Gerrit
https://jira.zephyrproject.org/browse/ZEP-100

CLOSED JIRA items within last 24 hours: 4
[ZEP-171] (Cannot Reproduce) tests/kernel/test_timer/nanokernel/test FAILED: timeout in QEMU
https://jira.zephyrproject.org/browse/ZEP-171
[ZEP-170] (Won't Do) tests/kernel/test_sleep/test FAILED in QEMU CI
https://jira.zephyrproject.org/browse/ZEP-170
[ZEP-190] (Fixed) [regression] Failed to receive loopback packet.
https://jira.zephyrproject.org/browse/ZEP-190
[ZEP-172] (Cannot Reproduce) tests/kernel/test_task_priv/test FAILED in QEMU
https://jira.zephyrproject.org/browse/ZEP-172

RESOLVED JIRA items within last 24 hours: 1
[ZEP-185] (Fixed) Nanokernel FIFO does not handle timeouts correctly
https://jira.zephyrproject.org/browse/ZEP-185

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1383 : Bluetooth: Add support for confirming incoming JustWorks pairing
- https://gerrit.zephyrproject.org/r/1393 : gcc: add __weak for shorter __attribute((weak))
- https://gerrit.zephyrproject.org/r/1400 : debug: add target GDB server
- https://gerrit.zephyrproject.org/r/1401 : x86: if GDB_SERVER is enabled, set the needed number of exception stubs
- https://gerrit.zephyrproject.org/r/1387 : Bluetooth: gatt: include service api definition proposal
- https://gerrit.zephyrproject.org/r/1402 : docs: adding details for the D2000 board
- https://gerrit.zephyrproject.org/r/1384 : Bluetooth: shell: Add confirming incoming JustWorks pairing
- https://gerrit.zephyrproject.org/r/1403 : doc: add porting guide
- https://gerrit.zephyrproject.org/r/1389 : doc: merge coding conventions into one document
- https://gerrit.zephyrproject.org/r/1392 : debug: interrupt event logger sample for arc
- https://gerrit.zephyrproject.org/r/1388 : doc: move code contribution guidelines one level up
- https://gerrit.zephyrproject.org/r/1394 : console: add hook for debug server to handle outgoing characters
- https://gerrit.zephyrproject.org/r/1399 : debug/x86: add runtime info needed by target debuggers
- https://gerrit.zephyrproject.org/r/1397 : debug: fit Kconfig lines in 80 columns
- https://gerrit.zephyrproject.org/r/1398 : debug: add missing MEM_SAFE dependency
- https://gerrit.zephyrproject.org/r/1395 : x86: add debug hook in _NanoFatalErrorHandler()
- https://gerrit.zephyrproject.org/r/1396 : libc: add strncat() to minimal libc
- https://gerrit.zephyrproject.org/r/1391 : debug: interrupt event logger support for arc
- https://gerrit.zephyrproject.org/r/1390 : nios2: Add support for Altera Nios2 CPU
- https://gerrit.zephyrproject.org/r/1386 : pinmux: include errno.h
- https://gerrit.zephyrproject.org/r/1385 : Bluetooth: include errno.h

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1370 : arduino_101: Do not duplicate GPIO select
- https://gerrit.zephyrproject.org/r/1373 : Bluetooth: L2CAP: l2cap_chan_get() can get BR/EDR L2CAP SIG channel
- https://gerrit.zephyrproject.org/r/1372 : Bluetooth: L2CAP: l2cap_send_reject() can use BR/EDR L2CAP SIG channel
- https://gerrit.zephyrproject.org/r/1341 : sensor: add driver for LSM9DS0 accel and magn
- https://gerrit.zephyrproject.org/r/1340 : sensor: add the posibility to fetch one data type
- https://gerrit.zephyrproject.org/r/1303 : sensors: add driver for TMP007 infrared thermopile sensor
- https://gerrit.zephyrproject.org/r/1361 : boards/olimexino_stm32: add new board
- https://gerrit.zephyrproject.org/r/1381 : tests: Pend microkernel tasks on nanokernel objects
- https://gerrit.zephyrproject.org/r/1380 : nanokernel: [un]block tasks on nanokernel objects infrastructure
- https://gerrit.zephyrproject.org/r/1135 : boards: nucleo: Adding flash support
- https://gerrit.zephyrproject.org/r/1263 : build: support icx llvm compiler
- https://gerrit.zephyrproject.org/r/1325 : power_mgmt: Provide APIs for devices to signal busy to PM policy mgr
- https://gerrit.zephyrproject.org/r/1029 : device: Remove DEV_* codes
- https://gerrit.zephyrproject.org/r/1093 : doc: index config variable only once
- https://gerrit.zephyrproject.org/r/1374 : microkernel: Add TF_NANO wait flag reason
- https://gerrit.zephyrproject.org/r/1216 : kinetis: reorganise soc directory using soc family
- https://gerrit.zephyrproject.org/r/1378 : kernel: Add thread parameter to _nano_wait_q_put()
- https://gerrit.zephyrproject.org/r/1377 : nanokernel: Add thread parameter to _NANO_TIMEOUT_ADD()
- https://gerrit.zephyrproject.org/r/1376 : kernel: Init back pointer to microkernel task
- https://gerrit.zephyrproject.org/r/1375 : nanokernel: Add back pointer to microkernel task
- https://gerrit.zephyrproject.org/r/1379 : microkernel: [un]block tasks on nanokernel objects infrastructure
- https://gerrit.zephyrproject.org/r/1363 : sanitycheck: Add olimexino_stm32 board to sanitycheck
- https://gerrit.zephyrproject.org/r/1362 : doc/board: Add documentation file for olimexino_stm32

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1382 : Bluetooth: SMP: Refactor pairing request handling
- https://gerrit.zephyrproject.org/r/1407 : Bluetooth: drivers/nble: Fix returning included service handle
- https://gerrit.zephyrproject.org/r/1405 : drivers/nble: Fix compare logic in on_nble_gattc_read_rsp
- https://gerrit.zephyrproject.org/r/1406 : drivers/nble: Fix handling read errors
- https://gerrit.zephyrproject.org/r/1404 : cc2520: Properly start and stop the device
- https://gerrit.zephyrproject.org/r/1356 : drivers/nble: Fix spelling typo
- https://gerrit.zephyrproject.org/r/1304 : net: Test random is necessary to use CC2520 as radio driver
- https://gerrit.zephyrproject.org/r/1342 : cc2520: Enable hardware filtering all the time
- https://gerrit.zephyrproject.org/r/1305 : cc2520: Set short address and ieee address from the driver
- https://gerrit.zephyrproject.org/r/1364 : doc: sphinx conf: use env var in sphinx doc version
- https://gerrit.zephyrproject.org/r/1357 : sensors: use SENSOR_G constant in all accelerometer drivers
- https://gerrit.zephyrproject.org/r/1358 : sensors: bma280: fix slope threshold measurement unit
- https://gerrit.zephyrproject.org/r/1195 : meta-zephyr-sdk-clone-0.7.5.sh: Use Gerrit repo
- https://gerrit.zephyrproject.org/r/1235 : hosttools-tarball.bb: Integrate Python 3 into SDK
- https://gerrit.zephyrproject.org/r/1365 : template_dir: More sanity checks deleting files
- https://gerrit.zephyrproject.org/r/1105 : doc: Edit microkernel API links

Hi Daniel,

I didn't catch this at first, but the patch causes a problem for the
Grove LCD driver (not sure if this problem is also present for other
drivers).

The way it was written, the Grove LCD driver doesn't use the driver_api
pointer at all (there is no LCD API). As such, it is NULL by default and
the call to device_get_binding will return NULL even though the device
was correctly initialized.

Bogdan

Hi,
To establish relationships between Jira items and gerrit requests and to enhance traceability of changes we have a system in place that handles the cross-reference and creates the necessary links both in Jira and Gerrit.

For code submitted to Gerrit that is based on an issue in Jira please add the Jira number to the commit message using the following format:

Jira: ZEP-100 Change-Id: Idb24bb28d5f4b5f31f1cc32d9a9ec2b8c622543e Signed-off-by: ….

This is optional right now and will help track progress of code changes and issues.

Regards,
Anas

Hey Jason,

NEW JIRA items within last 24 hours: 1
[ZEP-199] Zephyr driver model is undocumented
https://jira.zephyrproject.org/browse/ZEP-199

UPDATED JIRA items within last 24 hours: 2
[ZEP-70] Users should be able to use bossa tool for the Arduino Due from the SDK
https://jira.zephyrproject.org/browse/ZEP-70
[ZEP-178] Port Zephyr to Altera Max10 (Nios 2 CPU)
https://jira.zephyrproject.org/browse/ZEP-178

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0

On Wed, 13 Apr 2016, Luiz Augusto von Dentz wrote:

Hi Dmitriy,

On Wed, Apr 13, 2016 at 1:18 AM, Dmitriy Korovkin
<dmitriy.korovkin(a)windriver.com> wrote:

On Tue, 12 Apr 2016, Luiz Augusto von Dentz wrote:

Hi Dmitriy,

On Mon, Apr 11, 2016 at 9:32 PM, Dmitriy Korovkin
<dmitriy.korovkin(a)windriver.com> wrote:

On Fri, 8 Apr 2016, Luiz Augusto von Dentz wrote:

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.

I am not quite sure I understand the problem. Kernel keeps the track of
nanokernel timers and timeouts. If needed, each fiber can wait on a
timer (one fiber per timer). Not sure, what is the need for a separate
fiber
that runs through the timers.

By kernel I guess you mean that each fiber has a capability to run
timers, which is not useful in case of net subsystem since that
requires each and every timeout to have a dedicated stack.

In other words, the idea of several fibers does not work for you, I see.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.

Depends on what is needed. If this is a global change (apility for
multiple
fibers to wait on one timer, for instance), this should be global.

I never said we want the ability for multiple fibers to wait on one
timer, it is actually the opposite that we are doing in IP since there
is a single fiber managing multiple nano_timers calling a callback
when they expire. Anyway I starting to think we would be better off
prototyping this under net so we get the ball rolling.

- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?

As the kernel keeps track of the timers, there may be something else is
needed.

As I understand the kernel has APIs to put a fiber/task to sleep for
an x amount of ticks, blocking them, it doesn't have any API that the
user provide a callback which gets called when the timer expire
without blocking or requiring a new fiber for each call.

Ok, now it gets clearer. You are asking for a nanokernel timer API that
executes a registered callback when it expires. I do not think it is a good
idea to execute callbacks in ISR context, which brings us to an idea
of a fiber that executes these callbacks. Is this what you are asking for?
For this we need to make sure that a fiber can sleep on multiple timers.
The stack size for this fiber should be configurable.
Does it look good?

Yes, it is actually what we already have in IP which maintain a fiber
to execute the callbacks but the API is based on contiki etimers which
is something we would not like to use in Bluetooth. We have actually
discussed about using ISR context and came to the same conclusion that
it is perhaps not a good idea, although the callback should not block
either since that would block other callbacks to be executed. This
concept in fact is very similar to Linux Workqueues, but in Linux it
is possible to create dedicated workqueues which perhaps is useful for
drivers, etc. Anyway I started prototyping for Bluetooth first to see
how it works in practice.

I would suggest starting with RFC, as it may be good to have it
implemented in the Zephyr OS kernel:
If we enable NANO_TIMER_CALLBACK config option, we start a fiber that
sleeps on all the nanokernel timers that have registered a callback
function. When this fiber starts, it may probably just call
_nano_fiber_swap() and wait. When we register a nano_timer callback,
we add the "callback fiber" tcs to the timer, as if the fiber is
waiting for this timer to expire. And do same things with all the other
timers when register a callback for them. When the timer expires, it
wakes up the callback fiber, fiber walks through the expired timers
(somehow) and executes their callbacks. Then it calls _nano_fiber_swap()
and waits for another timer to expire.
This is just a rough idea and it opens several questions:
- do we need both timer with a callback and a fiber (not the "callback
fiber") waiting for it.
- do we need an argument for the callback? Should the argument be the user
data pointer that we have for the nano timer?
- how is it better to keep the callback pointer? For each nanokernel
timer or within the "callback fiber" list?
- how to get the list of expired timers without walking through the list
of all the registered ones?

Regards,
/Dmitriy.

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1364 : doc: sphinx conf: use env var in sphinx doc version
- https://gerrit.zephyrproject.org/r/1381 : tests: Pend microkernel tasks on nanokernel objects
- https://gerrit.zephyrproject.org/r/1380 : nanokernel: [un]block tasks on nanokernel objects infrastructure
- https://gerrit.zephyrproject.org/r/1379 : microkernel: [un]block tasks on nanokernel objects infrastructure
- https://gerrit.zephyrproject.org/r/1378 : kernel: Add thread parameter to _nano_wait_q_put()
- https://gerrit.zephyrproject.org/r/1377 : nanokernel: Add thread parameter to _NANO_TIMEOUT_ADD()
- https://gerrit.zephyrproject.org/r/1376 : kernel: Init back pointer to microkernel task
- https://gerrit.zephyrproject.org/r/1375 : nanokernel: Add back pointer to microkernel task
- https://gerrit.zephyrproject.org/r/1374 : microkernel: Add TF_NANO wait flag reason
- https://gerrit.zephyrproject.org/r/1373 : Bluetooth: L2CAP: Make common l2cap_chan_get
- https://gerrit.zephyrproject.org/r/1372 : Bluetooth: L2CAP: Make common l2cap_send_reject
- https://gerrit.zephyrproject.org/r/1367 : device: add macro to assign driver_api at compile time
- https://gerrit.zephyrproject.org/r/1368 : pinmux/dev: convert to use DEVICE_AND_API_INIT()
- 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/1370 : arduino_101: Do not duplicate GPIO select
- https://gerrit.zephyrproject.org/r/1371 : quark_se_devboard: Do not select GPIO
- https://gerrit.zephyrproject.org/r/1365 : template_dir: More sanity checks deleting files

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1105 : doc: Edit microkernel API links
- https://gerrit.zephyrproject.org/r/1341 : sensor: add driver for LSM9DS0 accel and magn
- https://gerrit.zephyrproject.org/r/1340 : sensor: add the posibility to fetch one data type
- https://gerrit.zephyrproject.org/r/1303 : sensors: add driver for TMP007 infrared thermopile sensor
- https://gerrit.zephyrproject.org/r/1278 : sensor: fix coding style (bmc150 and lsm9ds0)
- https://gerrit.zephyrproject.org/r/1356 : drivers/nble: Fix spelling typo
- https://gerrit.zephyrproject.org/r/1342 : cc2520: Enable hardware filtering all the time
- https://gerrit.zephyrproject.org/r/1304 : net: Test random is necessary to use CC2520 as radio driver
- https://gerrit.zephyrproject.org/r/1305 : cc2520: Set short address and ieee address from the driver
- https://gerrit.zephyrproject.org/r/932 : drivers: Quark flash support
- https://gerrit.zephyrproject.org/r/1325 : power_mgmt: Provide APIs for devices to signal busy to PM policy mgr
- https://gerrit.zephyrproject.org/r/1360 : sensor: fix init driver_api
- https://gerrit.zephyrproject.org/r/1112 : microkernel: deprecate task IRQs
- https://gerrit.zephyrproject.org/r/1113 : nanokernel: deprecate dynamic IRQs
- https://gerrit.zephyrproject.org/r/1235 : hosttools-tarball.bb: Integrate Python 3 into SDK
- https://gerrit.zephyrproject.org/r/1217 : stm32: reorganise soc directory and use family/series
- https://gerrit.zephyrproject.org/r/914 : gpio: Improve the public API to handle multi callbacks
- https://gerrit.zephyrproject.org/r/1201 : Bluetooth: tester: Add support for seqence gatt database

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1366 : flash/spi_flash_w25qxxdv: do not set driver_api if init fails
- https://gerrit.zephyrproject.org/r/1320 : doc: move device driver to a new section
- https://gerrit.zephyrproject.org/r/1322 : doc: Fixed structure in collab guide
- https://gerrit.zephyrproject.org/r/1327 : doc: fix wording in device documentation
- https://gerrit.zephyrproject.org/r/1323 : docs: remove notes from bluetooth document
- https://gerrit.zephyrproject.org/r/1321 : doc: create subsystem section
- https://gerrit.zephyrproject.org/r/1328 : doc: make naming conventions apply to none kernel functions
- https://gerrit.zephyrproject.org/r/1346 : doc: remove networking configuration section
- https://gerrit.zephyrproject.org/r/1345 : docs: Getting Started overhaul
- https://gerrit.zephyrproject.org/r/1347 : doc: remove usage of sudo and reduce notes
- https://gerrit.zephyrproject.org/r/1255 : relocate_sdk.patch: Fix file sections overwrites
- https://gerrit.zephyrproject.org/r/1205 : gcc-4.sc.iamcu.inc: Enable LTO

Hi Dmitriy,

On Wed, Apr 13, 2016 at 1:18 AM, Dmitriy Korovkin
<dmitriy.korovkin(a)windriver.com> wrote:

On Tue, 12 Apr 2016, Luiz Augusto von Dentz wrote:

Hi Dmitriy,

On Mon, Apr 11, 2016 at 9:32 PM, Dmitriy Korovkin
<dmitriy.korovkin(a)windriver.com> wrote:

On Fri, 8 Apr 2016, Luiz Augusto von Dentz wrote:

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.

I am not quite sure I understand the problem. Kernel keeps the track of
nanokernel timers and timeouts. If needed, each fiber can wait on a
timer (one fiber per timer). Not sure, what is the need for a separate
fiber
that runs through the timers.

By kernel I guess you mean that each fiber has a capability to run
timers, which is not useful in case of net subsystem since that
requires each and every timeout to have a dedicated stack.

In other words, the idea of several fibers does not work for you, I see.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.

Depends on what is needed. If this is a global change (apility for
multiple
fibers to wait on one timer, for instance), this should be global.

I never said we want the ability for multiple fibers to wait on one
timer, it is actually the opposite that we are doing in IP since there
is a single fiber managing multiple nano_timers calling a callback
when they expire. Anyway I starting to think we would be better off
prototyping this under net so we get the ball rolling.

- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?

As the kernel keeps track of the timers, there may be something else is
needed.

As I understand the kernel has APIs to put a fiber/task to sleep for
an x amount of ticks, blocking them, it doesn't have any API that the
user provide a callback which gets called when the timer expire
without blocking or requiring a new fiber for each call.

Ok, now it gets clearer. You are asking for a nanokernel timer API that
executes a registered callback when it expires. I do not think it is a good
idea to execute callbacks in ISR context, which brings us to an idea
of a fiber that executes these callbacks. Is this what you are asking for?
For this we need to make sure that a fiber can sleep on multiple timers.
The stack size for this fiber should be configurable.
Does it look good?

Yes, it is actually what we already have in IP which maintain a fiber
to execute the callbacks but the API is based on contiki etimers which
is something we would not like to use in Bluetooth. We have actually
discussed about using ISR context and came to the same conclusion that
it is perhaps not a good idea, although the callback should not block
either since that would block other callbacks to be executed. This
concept in fact is very similar to Linux Workqueues, but in Linux it
is possible to create dedicated workqueues which perhaps is useful for
drivers, etc. Anyway I started prototyping for Bluetooth first to see
how it works in practice.

--
Luiz Augusto von Dentz

Hi Maureen,

NXP is a founding member of the Zephyr project, so yes we will
definitely continue working on it. We're still in the early stages
though and will be ramping up in the coming months.

I'm very glad to hear this.

Otherwise I'd like start to develop a little more for my K64, but
looking at those amount of daily changes, especially at the core
api - is it wiser to wait a few months? I really would like to
contribute a litte bit in my sparse spare time to get this board
a little bit more usable :)

I'd encourage you to submit such patches. The APIs should no
longer be bouncing around. If they are, please call us out on when
it is happening.

What APIs are you most interested in using with the K64?

First I was interested for the onboard peripherals, like the RGB-LED and the
accelerometer. But these were only for tests.
Originally I bought this board for the combination of i2c-uart/data-logging and
processing(handy FPU) as well as communiction over the ethernet port.
So, uart and I2C(Not tested yet - maybe it is implemented?) and the SDHC would
be my VIA - very importand APIs :) Ethernet a nice-to-have.

Idups


PS: the Hardware-RNG - found it later in the manual; but I'ld like to add some
gaussian noise to the data-processing+filtering - so this would also be very
nice, if implemented.

Hi Daniel,

Are there plans for Zephyr OS to run on STM32F401 (Nucleo-64) boards?


Thanks,
Jason

Problem Statement:
Shrink binary size by doing driver_api assignment at compile/link time.

Problem Description:
For some drivers, the assignment of driver_api is unconditionally done.
This is especially true for drivers that will never fail initialization,
hence there is no need to set NULL. Therefore, the assignment of
driver_api can be statically done at compile/link time, and skips
the code to do the assignment at runtime.

Proposal:
To achieve this, a new API is proposed to do the extra work of
assignment when the driver instance is declared. The current
mechanism of declaring a driver instance (via DEVICE_INIT())
remains the same, which still requires the driver init function
to do the assignment.

The code can be seen at [1]. The changes to the pinmux/dev drivers
can be seen at [2], where similar changes can be applied to other
drivers. Here is the results from sanitycheck after [2]:

galileo : tests/drivers/pinmux/test_pinmux_dev
ram_size -10, is now 33255 -0.03%
rom_size -10, is now 27075 -0.04%

quark_se_devboard : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 13278 -0.05%

arduino_due : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 5732 -0.14%

stm32_mini_a15 : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7712 -0.10%

frdm_k64f : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7992 -0.10%

nucleo_f103rb : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7696 -0.10%

arduino_101 : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 13291 -0.05%

quark_d2000_crb : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 5219 -0.13%


[1] https://gerrit.zephyrproject.org/r/1367
[2] https://gerrit.zephyrproject.org/r/1368

On Tue, 12 Apr 2016, Luiz Augusto von Dentz wrote:

Hi Dmitriy,

On Mon, Apr 11, 2016 at 9:32 PM, Dmitriy Korovkin
<dmitriy.korovkin(a)windriver.com> wrote:

On Fri, 8 Apr 2016, Luiz Augusto von Dentz wrote:

Hi,

For the network protocols is quite common to have timers/timeouts for
retrying, etc, and these cold be many in parallel depending on how
many protocols and connections are involved, for that reason the IP
stack actually contains a Timer Fiber to keep track of every timer, it
does basically something like this:

net/ip/net_core.c:666:
while (1) {
/* Run various timers */
next_wakeup = etimer_request_poll();
if (next_wakeup == 0) {
/* There was no timers, wait for fiber_wakeup */
next_wakeup = TICKS_UNLIMITED;
} else {
if (next_wakeup > MAX_TIMER_WAKEUP) {
next_wakeup = MAX_TIMER_WAKEUP;
}
...
fiber_sleep(next_wakeup);
}

This actually uses contiki etimer infra but that in the end is using
nano_timer as a backend.

In the other hand in the Bluetooth stack we actually use delayed
fibers, but that requires each and every timeout to create its own
stack to be run separately which adds more footprint to the stack, so
we would like to use the same approach of IP stack and share the same
fiber/stack but without having to resort to any contiki API.

I am not quite sure I understand the problem. Kernel keeps the track of
nanokernel timers and timeouts. If needed, each fiber can wait on a
timer (one fiber per timer). Not sure, what is the need for a separate fiber
that runs through the timers.

By kernel I guess you mean that each fiber has a capability to run
timers, which is not useful in case of net subsystem since that
requires each and every timeout to have a dedicated stack.

In other words, the idea of several fibers does not work for you, I see.

With this in mind Id like to get some opinions regarding the design of
a Timer/Timeout API:

- Shall this be global/system wide or net specific? I think it could
be global enabled with a Kconfig option and perhaps make _nano_timeout
API public.

Depends on what is needed. If this is a global change (apility for multiple
fibers to wait on one timer, for instance), this should be global.

I never said we want the ability for multiple fibers to wait on one
timer, it is actually the opposite that we are doing in IP since there
is a single fiber managing multiple nano_timers calling a callback
when they expire. Anyway I starting to think we would be better off
prototyping this under net so we get the ball rolling.

- Perhaps have the API flexible enough so private fiber could be used
instead in case one don't want to use the global one?

As the kernel keeps track of the timers, there may be something else is
needed.

As I understand the kernel has APIs to put a fiber/task to sleep for
an x amount of ticks, blocking them, it doesn't have any API that the
user provide a callback which gets called when the timer expire
without blocking or requiring a new fiber for each call.

Ok, now it gets clearer. You are asking for a nanokernel timer API that
executes a registered callback when it expires. I do not think it is a
good idea to execute callbacks in ISR context, which brings us to an idea
of a fiber that executes these callbacks. Is this what you are asking for?
For this we need to make sure that a fiber can sleep on multiple timers.
The stack size for this fiber should be configurable.
Does it look good?
Regards,
/Dmitriy.

On Tue, Apr 12, 2016 at 08:58:34PM +0000, Boie, Andrew P wrote:

I already got feedback from people developing either drivers or sample
application for Rocket, basically playing to role of customers of
Zephyr, and I can already say that, for people used to writing software
against APIs that experience a very minimal amount of changes (i.e.

I'm not advocating anything w.r.t. a policiy for changing APIs right
now, but this is a data point.

I think we shouldn't change our existing APIs at all. They should be
treated as a contract. Someone who builds code against 1.0 should be
able to do so against later versions until we make a conscious
decision otherwise.

I think if we want to change something, we mark the old APIs with
__attribute__((deprecated)) so that it's clear that the old API is
going away at some point by generating a warning. But they should
still be *usable*.

Then, in the fullness of time, remove the APIs that were previously
deprecated. Whether that is Zephyr 1.5, 2.0, doesn't matter to me.

VxWorks), they did _not_ like the fact that even a small amount of
our APIs is in flux. It basically causes lost time and frustration.

What specifically changed that caused consternation?

I don't remember exactly. One of the them was some renaming of either
pinmux or gpio functions/structures.

I already got feedback from people developing either drivers or sample
application for Rocket, basically playing to role of customers of
Zephyr, and I can already say that, for people used to writing software
against APIs that experience a very minimal amount of changes (i.e.

I'm not advocating anything w.r.t. a policiy for changing APIs right
now, but this is a data point.

I think we shouldn't change our existing APIs at all. They should be treated as a contract. Someone who builds code against 1.0 should be able to do so against later versions until we make a conscious decision otherwise.

I think if we want to change something, we mark the old APIs with __attribute__((deprecated)) so that it's clear that the old API is going away at some point by generating a warning. But they should still be *usable*.

Then, in the fullness of time, remove the APIs that were previously deprecated. Whether that is Zephyr 1.5, 2.0, doesn't matter to me.

VxWorks), they did _not_ like the fact that even a small amount of our
APIs is in flux. It basically causes lost time and frustration.

What specifically changed that caused consternation?

Andrew

On Tue, Apr 12, 2016 at 10:27:20, Leung, Daniel wrote:

On Tue, Apr 12, 2016 at 09:07:00AM +0200, Tomasz Bursztyka wrote:

Hi Ramesh,

> > > The idea was that the kernel could not really do
> > > anything when a driver failed initialization, so why not getting rid

of returns

> > > to save a few bytes. The burden of determining whether it is a

critical error

> > > during init is up to the driver. If there is a critical error, the driver
> > > should assert (and setting driver_api to NULL).
> > >
> > > There are situations where there are non-critical erros during

initialization.

> > > For example, the I2C driver, failure to set default configuration is

not

> > > critical. As long as the developer sets it later, the driver can still

function.

> > > However, with the above code, this non-critical error will cause

driver_api

> > > to be NULL, which prevents its usage at all. The driver writer

should know

> > > whether an error prevents the device from functioning at all. So

it should be

> > > up to driver writer to set driver_api to NULL. One can argue that a

non-critical

> > > error should not return anything other than 0. But then it is not

passing on

> > > the information that there is a non-critical error (though the

kernel does not

Not sure how the method in the RFC differentiates between critical

and

non-critical errors. Isn't the driver also *not* passing on the
non-critical error status to the app by not setting device_api = NULL in
those cases? Then how will the app know that it needs to do

something to

correct such non-critical errors?

If this is merely a way to indicate that the driver is in an unusable
error state, then how is it different from critical error? - which is
not expected to happen in production releases.

The idea is to let the driver decide whether it is still functioning or
not.
Unusable state is a critical error to me.
A non critical error, means it is still ok to work, thus the driver API
will be set.
If the driver stops at non-critical error and do not set the API, it's not
really a non-critical error then.
(or it's a bug)

I don't see much trouble with that. Up to drivers to decide

And anyway, in 99.9% of the drivers: there will be critical errors only I
guess (unable to get
a device binding, to configure some register...).

Tomasz

Ramesh, in a production release, there should not be any non-critical
errors
at device initialization (hence "production"). In a production
environment,
the null-returning can be used as a mechanism to signify a major
problem,
for example, a peripheral breaks down in the field. Notification then can
be
made to replace the faulty hardware, if so desired.

I see. So the method in the RFC is to assist in diagnosis or notification of critical
errors.

----------
Daniel Leung

On Tue, Apr 12, 2016 at 10:22:21AM -0700, Daniel Leung wrote:

On Tue, Apr 12, 2016 at 10:22:13AM -0400, Benjamin Walsh wrote:

On Tue, Apr 12, 2016 at 09:12:19AM +0200, Tomasz Bursztyka wrote:

Hi Daniel and Anas,

and all the existing drivers in one go as well.
I hope we don't consider Kernel device API (init and stuff) as part of
"API 1.0".

The init change will be in another RFC. I am testing locally to see how much
space we can actually save. If it is minimal or non-existent, there is no need
to do that.

Saving even a minimal amount of bytes is good to consider, as long
as it does not reduce
features etc... and that RFC is actually fixing things.

AFAIK, the device init interface is not API from my understanding. Application
should not be using these in their code. They are internal to the kernel and
drivers.

IMO the driver interface is still considered public APIs.
Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers.

How long are we supposed to support this API 1.0? Can't we drop some
of its specifics in, let's say, 1.5?
The more we will have to support all of it, the less we will be able
to proceed on some interesting changes. :(

I already got feedback from people developing either drivers or sample
application for Rocket, basically playing to role of customers of
Zephyr, and I can already say that, for people used to writing software
against APIs that experience a very minimal amount of changes (i.e.
VxWorks), they did _not_ like the fact that even a small amount of our
APIs is in flux. It basically causes lost time and frustration.

I'm not advocating anything w.r.t. a policiy for changing APIs right
now, but this is a data point.

Is this only about changing the APIs (like adding parameters, etc)?
How about adding APIs (but still keep the existing API unmodified)?

Changing APIs.

On Tue, Apr 12, 2016 at 09:07:00AM +0200, Tomasz Bursztyka wrote:

Hi Ramesh,

> > > The idea was that the kernel could not really do
> > > anything when a driver failed initialization, so why not getting rid of returns
> > > to save a few bytes. The burden of determining whether it is a critical error
> > > during init is up to the driver. If there is a critical error, the driver
> > > should assert (and setting driver_api to NULL).
> > >
> > > There are situations where there are non-critical erros during initialization.
> > > For example, the I2C driver, failure to set default configuration is not
> > > critical. As long as the developer sets it later, the driver can still function.
> > > However, with the above code, this non-critical error will cause driver_api
> > > to be NULL, which prevents its usage at all. The driver writer should know
> > > whether an error prevents the device from functioning at all. So it should be
> > > up to driver writer to set driver_api to NULL. One can argue that a non-critical
> > > error should not return anything other than 0. But then it is not passing on
> > > the information that there is a non-critical error (though the kernel does not

Not sure how the method in the RFC differentiates between critical and
non-critical errors. Isn't the driver also *not* passing on the
non-critical error status to the app by not setting device_api = NULL in
those cases? Then how will the app know that it needs to do something to
correct such non-critical errors?

If this is merely a way to indicate that the driver is in an unusable
error state, then how is it different from critical error? - which is
not expected to happen in production releases.

The idea is to let the driver decide whether it is still functioning or
not.
Unusable state is a critical error to me.
A non critical error, means it is still ok to work, thus the driver API
will be set.
If the driver stops at non-critical error and do not set the API, it's not
really a non-critical error then.
(or it's a bug)

I don't see much trouble with that. Up to drivers to decide

And anyway, in 99.9% of the drivers: there will be critical errors only I
guess (unable to get
a device binding, to configure some register...).

Tomasz

Ramesh, in a production release, there should not be any non-critical errors
at device initialization (hence "production"). In a production environment,
the null-returning can be used as a mechanism to signify a major problem,
for example, a peripheral breaks down in the field. Notification then can be
made to replace the faulty hardware, if so desired.


----------
Daniel Leung

On Tue, Apr 12, 2016 at 10:22:13AM -0400, Benjamin Walsh wrote:

On Tue, Apr 12, 2016 at 09:12:19AM +0200, Tomasz Bursztyka wrote:

Hi Daniel and Anas,

and all the existing drivers in one go as well.
I hope we don't consider Kernel device API (init and stuff) as part of
"API 1.0".

The init change will be in another RFC. I am testing locally to see how much
space we can actually save. If it is minimal or non-existent, there is no need
to do that.

Saving even a minimal amount of bytes is good to consider, as long
as it does not reduce
features etc... and that RFC is actually fixing things.

AFAIK, the device init interface is not API from my understanding. Application
should not be using these in their code. They are internal to the kernel and
drivers.

IMO the driver interface is still considered public APIs.
Someone might be using those to write drivers external to Zephyr, changing the signatures will break such drivers.

How long are we supposed to support this API 1.0? Can't we drop some
of its specifics in, let's say, 1.5?
The more we will have to support all of it, the less we will be able
to proceed on some interesting changes. :(

I already got feedback from people developing either drivers or sample
application for Rocket, basically playing to role of customers of
Zephyr, and I can already say that, for people used to writing software
against APIs that experience a very minimal amount of changes (i.e.
VxWorks), they did _not_ like the fact that even a small amount of our
APIs is in flux. It basically causes lost time and frustration.

I'm not advocating anything w.r.t. a policiy for changing APIs right
now, but this is a data point.

Is this only about changing the APIs (like adding parameters, etc)?
How about adding APIs (but still keep the existing API unmodified)?


----------
Daniel Leung

When: Saturday, April 16, 8AM - 10AM PDT (15:00-17:00 UTC)
What: Zephyr environment
Why: OS security updates and reboots

Impact
Services will be unavailable briefly as the systems are rebooted.

Jenkins will be paused to avoid having jobs fail due to missing
resources prior to the outage.

NOTE: Since upgrading to Gerrit 2.12.x Gerrit now takes a significant
amount of time to restart (anywhere form 5 - 20 minutes).

If you have any concerns, please contact helpdesk(a)zephyrproject.org

A notice will be sent out prior too and again after the maintenance as
well as a note in #zephyrproject on Freenode

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation