Date   

Re: File system

Thomas, Ramesh
 

On Thu, Jan 26, 2017 at 09:08:37, Fábio Iaione wrote:
Dear Sirs,
I am trying to use the FAT file system in Galileo Gen1 and I have the
following doubts:
1- Does it work on Galileo Gen1?
The file system will work provided a disk access layer and flash driver is
implemented for it. Currently these are only implemented for Winbond
flash on the Arduino 101 boards. (susbs/disk/disk_access_flash.c and
drivers/spi_flash_w25qxxdv.c)

Refer to the following header files for the disk_access and flash interfaces
if you would be interested in implementing them.
include/disk_access.h
include/flash.h

2- The file system will be created in SPI flash or SD card?
The current implementation uses Winbond SPI flash on Arduino 101.


File system

Fábio Iaione <fabio.iaione at gmail.com...>
 

Dear Sirs,

I am trying to use the FAT file system in Galileo Gen1 and I have the following doubts:

1- Does it work on Galileo Gen1?

2- The file system will be created in SPI flash or SD card?

Thank you.


File system

Fábio Iaione <fabio.iaione at gmail.com...>
 

Dear Sirs,
I am trying to use the FAT file system in Galileo Gen1 and I have the following doubts:
1- Does it work on Galileo Gen1?
2- The file system will be created in SPI flash or SD card?
Thank you.


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10513 : net: Make NET_IPV6_ND configurable option
- https://gerrit.zephyrproject.org/r/10510 : net/ieee802154: Modify radio TX function signature
- https://gerrit.zephyrproject.org/r/10486 : boards: arm: mps2: Add pinmuxing
- https://gerrit.zephyrproject.org/r/10515 : Xtensa port: Added support for Xtensa internal timer as system timer.
- https://gerrit.zephyrproject.org/r/10507 : sensor: use SENSOR_CHAN_*_XYZ instead of SENSOR_CHAN_*_ANY
- https://gerrit.zephyrproject.org/r/10516 : sensor: add SENSOR_CHAN_*_XYZ enum values
- https://gerrit.zephyrproject.org/r/10512 : doc: update copyright for documentation
- https://gerrit.zephyrproject.org/r/10514 : net: Make NET_IPV6_DAD depends on NET_IPV6_ND
- https://gerrit.zephyrproject.org/r/10503 : net: dhcpv4: Fix tiny style issues
- https://gerrit.zephyrproject.org/r/10511 : net: echo-client: Add TCP support
- https://gerrit.zephyrproject.org/r/10504 : net: 6lo: Fix tiny style issues
- https://gerrit.zephyrproject.org/r/10509 : i2c/nrf5: Remove r/w to POWER register.
- https://gerrit.zephyrproject.org/r/10505 : doc: update template for nucleo_f401re board
- https://gerrit.zephyrproject.org/r/10506 : tests: kernel: mem_heap: added api and concept tests
- https://gerrit.zephyrproject.org/r/10500 : tests: kernel: port mutex/priority inheritance test to unified
- https://gerrit.zephyrproject.org/r/10488 : frdm_k64f: Add RST board documentation
- https://gerrit.zephyrproject.org/r/10495 : doc: fix broken links in zephyr theme template footer
- https://gerrit.zephyrproject.org/r/10491 : tests: kernel: import pool/heap tests to unified
- https://gerrit.zephyrproject.org/r/10489 : api: dma: dma api update
- https://gerrit.zephyrproject.org/r/10487 : fixed Panther board compilation, added support for BLE, moved winc1500 from drivers/ to ext/
- https://gerrit.zephyrproject.org/r/10484 : arm: cmsis: Convert _ScbIsInThreadMode to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10483 : arm: cmsis: Convert _ScbPendsvSet to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10485 : arm: scb: Move SCB asm defines into cpu_idle.S
- https://gerrit.zephyrproject.org/r/10481 : arm: refactor clearing of exception faults to common code
- https://gerrit.zephyrproject.org/r/10482 : arm: cmsis: Convert _ScbNmiPend to use direct CMSIS register access
- https://gerrit.zephyrproject.org/r/10478 : TEST: DONT MERGE https://gerrit.zephyrproject.org/r/#/c/10359/1 The above line should trigger a warning or an error.
- https://gerrit.zephyrproject.org/r/10479 : Bluetooth: HFP HF: Service level connection completed

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10456 : ext: lib: mbedtls : mbedTLS library modifications
- https://gerrit.zephyrproject.org/r/10075 : net/mqtt: Add the MQTT Publisher sample application
- https://gerrit.zephyrproject.org/r/4872 : DO NOT MERGE: k_poll: asynchronous I/O framework
- https://gerrit.zephyrproject.org/r/10323 : Xtensa port: Added linker script for several Xtensa cores.
- https://gerrit.zephyrproject.org/r/10477 : RFC: bluetooth: hci: Add VS header and new command to retrieve random addrs
- https://gerrit.zephyrproject.org/r/10320 : Xtensa port: Moved XCC specific libraries out of genric Xtensa make file.
- https://gerrit.zephyrproject.org/r/10319 : Xtensa port: Added Xtensa specific code (C + S) files.
- https://gerrit.zephyrproject.org/r/10183 : irq: introduce 'direct' interrupt API definition
- https://gerrit.zephyrproject.org/r/10476 : board: add nucleo_411re board documentation
- https://gerrit.zephyrproject.org/r/10093 : samples/net/http: Add the server sample application
- https://gerrit.zephyrproject.org/r/9517 : samples: net: echo_server .conf for Atmel SMART SAM E70 Xplained board
- https://gerrit.zephyrproject.org/r/8949 : samples: zperf: Correct the include files path to eliminate compile errors
- https://gerrit.zephyrproject.org/r/10369 : ataes132a: Adds a driver to support ATAES132A device
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/9883 : i2c: Adds a functions set that supports 16 bit addressing.
- https://gerrit.zephyrproject.org/r/10178 : samples/net/http: Introduce routines to handle multiple contexts
- https://gerrit.zephyrproject.org/r/10258 : samples/net/http: Add support for multiple URLs
- https://gerrit.zephyrproject.org/r/9854 : http: add server sample
- https://gerrit.zephyrproject.org/r/10436 : net: correct/clarify in*_addr parameter of net_addr_pton()
- https://gerrit.zephyrproject.org/r/10257 : samples: grove: use correct i2c device driver name
- https://gerrit.zephyrproject.org/r/9682 : quark_d2000: Add shared GDT memory to linker
- https://gerrit.zephyrproject.org/r/9681 : quark_se: Add shared GDT in RAM memory to linker
- https://gerrit.zephyrproject.org/r/9680 : quark_se: Fix restore info address
- https://gerrit.zephyrproject.org/r/10475 : Simple PWM driver for nRF5
- https://gerrit.zephyrproject.org/r/10424 : boards: nucleo_l476rg: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10420 : soc: stm32l4xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10422 : board: nucleo_f334r8: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10418 : pwm: update stm32 pwm to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10412 : clock control:stm32: provide STM32Cube LL based driver
- https://gerrit.zephyrproject.org/r/10423 : board: stm32373c_eval: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10471 : soc: stm32f3x: clean up after Cube LL clock control
- https://gerrit.zephyrproject.org/r/10415 : uart: update stm32 uart to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10419 : flash: update stm32 flash_f3x to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10414 : pinmux: update stm32 pinmux to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10417 : i2c: update stm32 i2c_lx to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10473 : drivers: stm32: clean up after stm23cube based clock control
- https://gerrit.zephyrproject.org/r/10470 : soc: stm32l4x: clean up after Cube LL clock control
- https://gerrit.zephyrproject.org/r/10421 : soc: stm32f3xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10472 : clock control: clean up after stm32cube LL driver
- https://gerrit.zephyrproject.org/r/10416 : i2c: stm32: change deprecated constant
- https://gerrit.zephyrproject.org/r/10413 : gpio: update stm32 gpio to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10426 : Bluetooth: HFP HF: Enable extended AG Error Result Code

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10480 : soc: arm: mps2: Fix UART4 base address
- https://gerrit.zephyrproject.org/r/10508 : net: Remove CONFIG_NET_IPV6_NO_ND config option
- https://gerrit.zephyrproject.org/r/10502 : tunslip6: strengthen and defer config to external parties
- https://gerrit.zephyrproject.org/r/10499 : samples: fxos8700: Convert documentation to RST
- https://gerrit.zephyrproject.org/r/10498 : samples: fxos8700: Decimate sensor data before printing to the console
- https://gerrit.zephyrproject.org/r/10497 : fxos8700: Fix broken gpio callback implementation
- https://gerrit.zephyrproject.org/r/10496 : MAINTAINERS: add Andrew to x86
- https://gerrit.zephyrproject.org/r/10493 : Xtensa port: Added support for Xtensa architecture to linker-defs.h.
- https://gerrit.zephyrproject.org/r/10494 : MAINTAINERS: add xtensa arch
- https://gerrit.zephyrproject.org/r/10375 : samples/coaps_client CoAP over DTLS client example app using mbedTLS
- https://gerrit.zephyrproject.org/r/10249 : samples/coaps_server CoAP over DTLS server example app using mbedTLS
- https://gerrit.zephyrproject.org/r/10443 : shell: Fix tiny style issues
- https://gerrit.zephyrproject.org/r/10447 : shell: Make the command queue size configurable via Kconfig
- https://gerrit.zephyrproject.org/r/10438 : drivers/console: Removing non existing Kconfig source
- https://gerrit.zephyrproject.org/r/10440 : net: ip: Add a useful macro to staticaly initialize a struct in_addr
- https://gerrit.zephyrproject.org/r/10445 : drivers/console: Making console input generic
- https://gerrit.zephyrproject.org/r/10449 : shell: If enabled, let's register telnet console as an input
- https://gerrit.zephyrproject.org/r/10444 : drivers/uart_console: Fix tiny style issues
- https://gerrit.zephyrproject.org/r/10446 : console/shell: Switch to generic console input
- https://gerrit.zephyrproject.org/r/10442 : samples/net: Add telnet console support on echo_server with qemu
- https://gerrit.zephyrproject.org/r/10450 : drivers/console/telnet: Add ground support for telnet commands
- https://gerrit.zephyrproject.org/r/10441 : drivers/console: Add a basic telnet console
- https://gerrit.zephyrproject.org/r/10439 : misc/printk: Add a function to get the current hook function.
- https://gerrit.zephyrproject.org/r/10448 : drivers/console/telnet: Provide minimal input handling.
- https://gerrit.zephyrproject.org/r/10435 : Xtensa port: Added support for Xtensa simulator console driver.
- https://gerrit.zephyrproject.org/r/10465 : Xtensa port: Added Xtensa internal timer configuration need by assembly files.
- https://gerrit.zephyrproject.org/r/10324 : Xtensa port: Removed the need to put an empy file soc.c in arch/xtensa/soc dir.
- https://gerrit.zephyrproject.org/r/10453 : xtensa: fix find_msb_set() and find_lsb_set()
- https://gerrit.zephyrproject.org/r/10452 : xtensa: fixup license identifiers
- https://gerrit.zephyrproject.org/r/10469 : pinmux: make pinmux_dev the default pinmux driver for quark
- https://gerrit.zephyrproject.org/r/10474 : pinmux: unify galileo pinmux driver
- https://gerrit.zephyrproject.org/r/10318 : Xtensa port: Added support for Xtensa architecture in zephyr include files.
- https://gerrit.zephyrproject.org/r/6719 : Bluetooth: A2DP: Stream End Point Structure
- https://gerrit.zephyrproject.org/r/10432 : arm: move exception priority to exc.h
- https://gerrit.zephyrproject.org/r/10170 : arm: cmsis: Convert _ScbExcPrioSet to NVIC_SetPriority
- https://gerrit.zephyrproject.org/r/10171 : arm: cmsis: Remove nvic.h and use CMSIS NVIC calls directly
- https://gerrit.zephyrproject.org/r/10359 : commit-message: skip length checks for http/https URLs


Re: I2C compatibility with nrf52

Nicolas Perrenoud <nicolas.perrenoud@...>
 

Hi, Short term, just remove the two lines in question. I'll talk to
Carlesc and the Nordic guys to figure out what the proper solution
should be.
Ok Thanks

Nicolas


Re: I2C compatibility with nrf52

Marcus Shawcroft <marcus.shawcroft@...>
 

On 26 January 2017 at 08:56, Nicolas Perrenoud
<nicolas.perrenoud(a)geo-satis.com> wrote:

Is there some thinks special to do to compile for NRF52 or is it ok to just
comment these two lines ?
Hi, Short term, just remove the two lines in question. I'll talk to
Carlesc and the Nordic guys to figure out what the proper solution
should be.

Cheers
/Marcus


I2C compatibility with nrf52

Nicolas Perrenoud <nicolas.perrenoud@...>
 

Hello,



I tried to use the I2C driver for nRF52. When I compile I have the
followings errors :



/home/nicolas/Desktop/zephyr/drivers/i2c/i2c_nrf5.c:295:5: error:
'NRF_TWI_Type {aka volatile struct <anonymous>}' has no member named 'POWER'

twi->POWER = 0;



/home/nicolas/Desktop/zephyr/drivers/i2c/i2c_nrf5.c:296:5: error:
'NRF_TWI_Type {aka volatile struct <anonymous>}' has no member named 'POWER'

twi->POWER = 1;



The reason is NRF52 TWI module don't have POWER register.



Is there some thinks special to do to compile for NRF52 or is it ok to just
comment these two lines ?



Thanks,



Nicolas


cant debug arduino_due with altera-usb-blaster and openOCD.

曹子龙 <13824125580 at 163.com...>
 

HI:
i encounter a problem with my board Arduino_due running zephyr when i try to install the bare metel debug environment with alter-usb-blaster emulatior and OpenOCD, and


got the error message ouput as below, is any thing i do wrong? or Just alter-usb-blaster cant debug this board? which tools do you debug your arduino_due,thanks for you kindly reply.




root(a)PCcaozilong:/DISK0/WorkSpace/stm32f411-nucleo/openocd# openocd -f ./tcl/interface/altera-usb-blaster.cfg
Open On-Chip Debugger 0.10.0+dev-00001-g0ecee83 (2017-01-25-17:36)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
Info : No lowlevel driver configured, will try them all
Info : usb blaster interface using libftdi
Error: unable to get latency timer
Info : This adapter doesn't support configurable speed
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Info : TAP auto0.tap does not have IDCODE
Info : TAP auto1.tap does not have IDCODE
Warn : Unexpected idcode after end of chain: 130 0xffbfffff
Warn : Unexpected idcode after end of chain: 482 0x0000003f
Warn : Unexpected idcode after end of chain: 514 0xfffffe00
Warn : Unexpected idcode after end of chain: 546 0x0000000f
Warn : Unexpected idcode after end of chain: 578 0xffffff80
Error: double-check your JTAG setup (interface, speed, ...)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x00000000"
Error: auto0.tap: IR capture error; saw 0x0000 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined


Re: License boilerplate on new files

David Brown
 

Perhaps it is a little late, but has anyone sought legal council to
determine if the SPDX header is a sufficient license marker? I'm not aware
of any project using it in lieu of actual license text. I thought SPDX was
more intended to avoid the need to parse license comments, and not to be
used instead of them.

David

On Wed, Jan 25, 2017 at 10:57 AM Nashif, Anas <anas.nashif(a)intel.com> wrote:

Hi,



Probably you have noticed already that we have replaced the APL2.0
boilerplate in all project owned files with SPDX tagging, please see



https://jira.zephyrproject.org/browse/ZEP-1457



for more information.



Any new files submitted to gerrit need to have the new boilerplate:



#

# Copyright (c) 2017 <copyright holder>

# SPDX-License-Identifier: Apache-2.0

#





Or





/*

* Copyright (c) 2017 <copyright holder>

* SPDX-License-Identifier: Apache-2.0

*/





Thanks,

Anas


Zephyr SDK 0.9 released

Nashif, Anas
 

Hi,

Zephyr SDK 0.9 is released and available for download.

Release notes:

https://www.zephyrproject.org/content/zephyr-project-software-development-kit-sdk-09

Download:

https://www.zephyrproject.org/downloads/tools


Regards,
Anas


License boilerplate on new files

Nashif, Anas
 

Hi,

Probably you have noticed already that we have replaced the APL2.0 boilerplate in all project owned files with SPDX tagging, please see

https://jira.zephyrproject.org/browse/ZEP-1457

for more information.

Any new files submitted to gerrit need to have the new boilerplate:

#
# Copyright (c) 2017 <copyright holder>
# SPDX-License-Identifier: Apache-2.0
#


Or



/*

* Copyright (c) 2017 <copyright holder>

* SPDX-License-Identifier: Apache-2.0

*/


Thanks,
Anas


Re: sensor.h API semantics and consistency.

Bogdan Davidoaia
 

On 25 January 2017 at 13:09, Marcus Shawcroft <marcus.shawcroft(a)gmail.com>
wrote:

Hi!

The sensor.h API provides various SENSOR_CHAN_*_ANY channels. The
intent of these, and so far as I can see all current use of these ANY
channels is to represent a the tuple of all of a group of related X,
Y, Z channels. Given that it always refers to *all* of the related
channels rather than any individual one of the related set I wonder
whether it would be less confusing if we rename then as
SENSOR_CHAN_*_ALL or SENSOR_CHAN_*_XYZ ?

Thoughts ?
The initial naming was indeed not the best. Will change it with
SENSOR_CHAN_*_XYZ, as its meaning is evident.



The sensor attributes provide a mechanism to set an OFFSET on any
specific channel. This would appear to be intended as a mechanism to
exploit a hardware capability provided by some devices to configure an
arbitrary measurement offset. We have ~ 2 drivers that support this
attribute in the tree.

Given the current API, an application (or other driver user) who might
want to use the OFFSET mechanism must either:
1) Assume no driver implements OFFSET and post process results itself.
2) Hardwire knowledge that it is using the driver for a specific
device that does, or does not suport the OFFSET feature.
3) Attempt to use OFFSET, detect the ENOTSUP (or other error code used
for the same reason) and fallback to post processing results itself.

Number 1 essentially means the OFFSET mechanism serves no purpose
unless it is ubiquitous.
Number 2 undermines the device abstraction property of a platform OS
Number 3 means increased application logic and to a certain extent
also undermines the device abstraction.

From an applications / device driver users perspective the usability
of the API would be much improved if the OFFSET attribute feature was
either mandatory for a specific channel type across all drivers (or
removed completely). A driver for hardware with no offset feature
can easily emulate the behaviour within the driver itself.

I think we should give consideration to mandating driver support for
OFFSET attributes either for all channels or for specific channels (ie
those where we already have driver support for OFFSET).

I think this argument for consistency applies equally to other attribute
types.

Thoughts ?

I am not sure if enforcing having or not having the OFFSET attribute for
specific channels is necessary the best solution. The OFFSET is used as a
means of manually calibrating sensors that have hardware support for such a
feature. Some sensors may not need calibration, and adding this attribute
to the driver may add little or no benefit to the application.

Also, extending this talk to other attribute types, the answer may not be
as straightforward. SENSOR_ATTR_SAMPLING_FREQUENCY or
SENSOR_ATTR_FULL_SCALE may not be relevant for some drivers (or even have a
fixed value), in which case enforcing support for the attribute doesn't
make sense.

The initial design of the attributes was to offer support for non-generic
sensor features, and not force the drivers to implement any specific
attribute if there is no need for it. So it was though that the application
developers would know beforehand what sensor he will use and what
attributes are supported by it.

So the current attribute model is more close to point 2) which you
mentioned, or an approach similar to 3) if he wants to write a more generic
application.

This talk can be extended to the fact that there is no special rule for
enforcing Kconfig options, as they are not consistent across sensors of the
same type.



The SENSOR_ATTR_CALIB_TARGET, is I believe intended as a mechanism to
allow an application to provide a driver with a "right answer" at the
current point in time, and tell it to calibrate itself such that its
results match the calib target ?

The ATTR_OFFSET mechanism and the ATTR_CALIB_TARGET mechanism have
potential to interact on a channel where both are supported, I think
we should clarify in the API how they are intended to interact.
Notably if an application issues andOFFSET followed by a CALIB_TARGET
for the same channel, we should define how the current offset affects
the behaviour of the CALIB operation. I can imagine two alternatives:
1) CALIB has the effect of zeroing any current OFFSET.
2) Any current OFFSET is added to the CALIB target before calibration
and the current OFFSET remains in force after the CALIB operation.

I think 1) is intuitively more obvious and I can think of no benefits
in choosing 2).

Thoughts?
The point you made for 1) si correct. OFFSET and CALIB shouldn't be used
together as they are a means for manual and automatic calibration, so using
one will invalidate the configurations set by the other.



Cheers
/Marcus
Bogdan


Re: How to overcome timer delay

Benjamin Walsh <benjamin.walsh@...>
 

[..snip..]

void main(void)
{
struct k_timer my_timer;

printk("Hello World! %s\n", CONFIG_ARCH);
k_timer_init(&my_timer, timer_handler, NULL);
t = k_uptime_get_32();
while (1) {
k_timer_start(&my_timer, INTERVAL, K_FOREVER);
k_timer_status_sync(&my_timer);
}
}
[..snip..]

So, although increasing it improves the delay, there is a limit. And
for the TICKS_PER_SEC as high as 10000, there is still 100ms delay
over 1000 counts (10%). I think that in practice a mechanism to
compensate the delay to make it a more precise. Is there any better
way?
For your case, that is what I was saying above: if you set the tick rate
to 1000, and you ask for a delay of 1ms, this means at least 1ms, so the
system will wait for 2 ticks (the partial current one + the next one),
so it will wait for around 2ms. That is with the system clock timer,
which has a finite granularity.

If you want more precision, I would look if your board has a second
timer that your application could take ownership of so that you could
program it to fire periodically every 2ms.
Thank you so much for the explanations, Ben.
Well, that was an in-depth explanation of what is happening internally,
but I focused too much on what your code was doing that I kinda
overlooked a better way of doing what you were trying to do. :-/

Instead of stopping and starting the timer with a <duration> of 1ms and
<period> of 0 every iteration, you should just use the periodic feature
of the timer ! If you want it to fire every 2ms, do this:

k_timer_start(&my_timer, 2, 2);
while (1) {
k_timer_status_sync(&my_timer);
}

The <period> value is not aligned on the next tick boundary, since when
the timer is added back to the timeout queue, this happens in the
timer's timeout's expiration handler, which is called when already
aligned on a tick boundary. Thus, the value for the <duration> parameter
of k_timer_start when converted to ticks _will be_ pushed to the next
tick passed the requested duration, while the value for the <period>
parameter when converted to ticks _will not be_ pushed to the next tick.
Look in timer.c:_timer_expiration_handler():

/*
* if the timer is periodic, start it again; don't add _TICK_ALIGN
* since we're already aligned to a tick boundary
*/
if (timer->period > 0) {
key = irq_lock();
_add_timeout(NULL, &timer->timeout, &timer->wait_q,
timer->period);
irq_unlock(key);
}

So, with my example code above, the timer will thus fire in
2.<something> ms the first time, and at fixed interval every 2ms all
subsequent times. If you want the timer to fire within 2m the first
time, call timer start with a <duration> of 1ms instead, like this:

k_timer_start(&my_timer, 1, 2);

Hope this helps,
Ben


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10476 : board: add nucleo_411re board documentation
- https://gerrit.zephyrproject.org/r/10477 : RFC: bluetooth: hci: Add VS header and new command to retrieve random addrs
- https://gerrit.zephyrproject.org/r/10475 : Simple PWM driver for nRF5
- https://gerrit.zephyrproject.org/r/10469 : pinmux: make pinmux_dev the default pinmux driver for quark
- https://gerrit.zephyrproject.org/r/10474 : pinmux: unify galileo pinmux driver
- https://gerrit.zephyrproject.org/r/10436 : net: correct/clarify in*_addr parameter of net_addr_pton()
- https://gerrit.zephyrproject.org/r/10473 : drivers: stm32: clean up after stm23cube based clock control
- https://gerrit.zephyrproject.org/r/10472 : clock control: clean up after stm32cube LL driver
- https://gerrit.zephyrproject.org/r/10471 : soc: stm32f3x: clean up after Cube LL clock control
- https://gerrit.zephyrproject.org/r/10470 : soc: stm32l4x: clean up after Cube LL clock control
- https://gerrit.zephyrproject.org/r/10450 : drivers/console/telnet: Add ground support for telnet commands
- https://gerrit.zephyrproject.org/r/10446 : console/shell: Switch to generic console input
- https://gerrit.zephyrproject.org/r/10444 : drivers/uart_console: Fix tiny style issues
- https://gerrit.zephyrproject.org/r/10449 : shell: If enabled, let's register telnet console as an input
- https://gerrit.zephyrproject.org/r/10445 : drivers/console: Making console input generic
- https://gerrit.zephyrproject.org/r/10441 : drivers/console: Add a basic telnet console
- https://gerrit.zephyrproject.org/r/10440 : net: ip: Add a useful macro to staticaly initialize a struct in_addr
- https://gerrit.zephyrproject.org/r/10438 : drivers/console: Removing non existing Kconfig source
- https://gerrit.zephyrproject.org/r/10447 : shell: Make the command queue size configurable via Kconfig
- https://gerrit.zephyrproject.org/r/10439 : misc/printk: Add a function to get the current hook function.
- https://gerrit.zephyrproject.org/r/10443 : shell: Fix tiny style issues
- https://gerrit.zephyrproject.org/r/10448 : drivers/console/telnet: Provide minimal input handling.
- https://gerrit.zephyrproject.org/r/10442 : samples/net: Add telnet console support on echo_server with qemu
- https://gerrit.zephyrproject.org/r/10432 : arm: move exception priority to exc.h
- https://gerrit.zephyrproject.org/r/10452 : xtensa: add license identifiers
- https://gerrit.zephyrproject.org/r/10453 : xtensa: fix find_msb_set()
- https://gerrit.zephyrproject.org/r/10465 : Xtensa port: Added Xtensa internal timer configurationi need by assembly files.
- https://gerrit.zephyrproject.org/r/10460 : samples: net: irc_bot: add DHCPv4 support
- https://gerrit.zephyrproject.org/r/10459 : samples: net: irc_bot: add DNS support
- https://gerrit.zephyrproject.org/r/10458 : samples: net: irc_bot: add IPv4 support
- https://gerrit.zephyrproject.org/r/10457 : samples: net: irc_bot: use standard samples IPV6 PEER config
- https://gerrit.zephyrproject.org/r/10456 : ext: lib: mbedtls : Changes to avoid undesired inclusions
- https://gerrit.zephyrproject.org/r/10435 : Xtensa port: Added support for Xtensa simulator console driver.
- https://gerrit.zephyrproject.org/r/10429 : ext: stm32cube: update stm32f4xx cube version
- https://gerrit.zephyrproject.org/r/10430 : ext: stm32cube: update stm32l4xx cube version

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10171 : arm: cmsis: Remove nvic.h and use CMSIS NVIC calls directly
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: add PINMUX config for D2000 board
- https://gerrit.zephyrproject.org/r/10418 : pwm: update stm32 pwm to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10422 : board: nucleo_f334r8: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10423 : board: stm32373c_eval: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10424 : boards: nucleo_l476rg: enable support of LL Cube clock control driver
- https://gerrit.zephyrproject.org/r/10420 : soc: stm32l4xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10419 : flash: update stm32 flash_f3x to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10421 : soc: stm32f3xx: support of Cube LL Clock driver
- https://gerrit.zephyrproject.org/r/10170 : arm: cmsis: Convert _ScbExcPrioSet to NVIC_SetPriority
- https://gerrit.zephyrproject.org/r/10319 : Xtensa port: Added Xtensa specific assembly files.
- https://gerrit.zephyrproject.org/r/10320 : Xtensa port: Added Xtensa specific C files.
- https://gerrit.zephyrproject.org/r/6719 : Bluetooth: A2DP: Stream End Point Structure
- https://gerrit.zephyrproject.org/r/7492 : Bluetooth: A2DP: Added Preset Structure
- https://gerrit.zephyrproject.org/r/6720 : Bluetooth: A2DP: Stream End Point Registration
- https://gerrit.zephyrproject.org/r/9663 : Bluetooth: AVDTP: Add AVDTP Receive Function
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9883 : i2c: Adds a functions set that supports 16 bit addressing.
- https://gerrit.zephyrproject.org/r/10318 : Xtensa port: Added support for Xtensa architecture in zephyr include files.
- https://gerrit.zephyrproject.org/r/4489 : Bluetooth: SDP: Server: Support ServiceAttributeRequest
- https://gerrit.zephyrproject.org/r/10176 : Add support for STM32Cube HAL_PCD USB driver
- https://gerrit.zephyrproject.org/r/10183 : irq: introduce 'direct' interrupt API definition
- https://gerrit.zephyrproject.org/r/10394 : samples: net: irc_bot: handle messages across multiple fragments
- https://gerrit.zephyrproject.org/r/10387 : samples: net: irc_bot: simplify connect path
- https://gerrit.zephyrproject.org/r/10385 : samples: net: irc_bot: use #defines for server and port
- https://gerrit.zephyrproject.org/r/10384 : samples: net: irc_bot: make panic() more accessible
- https://gerrit.zephyrproject.org/r/10383 : samples: net: irc_bot: remove sockaddr globals
- https://gerrit.zephyrproject.org/r/10381 : samples: net: irc_bot: remove unneeded typecasts and extra var
- https://gerrit.zephyrproject.org/r/10396 : samples: net: irc_bot: add FRDM K64F project .conf
- https://gerrit.zephyrproject.org/r/10395 : samples: net: irc_bot: add Linaro copyright
- https://gerrit.zephyrproject.org/r/10393 : samples: net: irc_bot: create semi-unique IRC user names
- https://gerrit.zephyrproject.org/r/10392 : samples: net: irc_bot: !buf in on_context_recv() is disconnected
- https://gerrit.zephyrproject.org/r/10391 : samples: net: irc_bot: dont hardcode NET_SYS_LOG_LEVEL
- https://gerrit.zephyrproject.org/r/10390 : samples: net: irc_bot: use irc parameter's connection
- https://gerrit.zephyrproject.org/r/10389 : samples: net: irc_bot: fix null pointer deref
- https://gerrit.zephyrproject.org/r/10388 : samples: net: irc_bot: expand some char buffers
- https://gerrit.zephyrproject.org/r/10386 : samples: net: irc_bot: make some functions more accessible
- https://gerrit.zephyrproject.org/r/10382 : samples: net: irc_bot: add helper function in_addr_set()
- https://gerrit.zephyrproject.org/r/10380 : samples: net: irc_bot: release net_context reference upon error
- https://gerrit.zephyrproject.org/r/10379 : samples: net: irc_bot: establish privmsg callback typedef
- https://gerrit.zephyrproject.org/r/10378 : samples: net: irc_bot: run sample process as a thread
- https://gerrit.zephyrproject.org/r/10377 : samples: net: irc_bot: fix SYS_LOG_NET_LEVEL in prj_qemu_x86.conf
- https://gerrit.zephyrproject.org/r/10397 : samples: net: Add IRC bot example
- https://gerrit.zephyrproject.org/r/10426 : Bluetooth: HFP HF: Enable extended AG Error Result Code
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/3313 : samples/drivers/crypto: crypto sample app
- https://gerrit.zephyrproject.org/r/3312 : drivers/crypto: TinyCrypt shim driver
- https://gerrit.zephyrproject.org/r/9933 : tests: benchmark: sys_kernel: Porting to unified
- https://gerrit.zephyrproject.org/r/9980 : tests: include: Move timestamp.h into common location
- https://gerrit.zephyrproject.org/r/9967 : arm: Adjust entry point of XIP kernels to the __reset function
- https://gerrit.zephyrproject.org/r/9681 : quark_se: Add shared GDT in RAM memory to linker
- https://gerrit.zephyrproject.org/r/9682 : quark_d2000: Add shared GDT memory to linker
- https://gerrit.zephyrproject.org/r/9680 : quark_se: Fix restore info address
- https://gerrit.zephyrproject.org/r/10323 : Xtensa port: Added linker script for several Xtensa cores.
- https://gerrit.zephyrproject.org/r/10084 : net: buf: Introduce net_buf_save/restore APIs

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10468 : net: 6lo: Verify src and dst link layer addresses
- https://gerrit.zephyrproject.org/r/10467 : net: ip: Check error conditions and return false
- https://gerrit.zephyrproject.org/r/10466 : net: bt: Fix not checking for valid ll addresses
- https://gerrit.zephyrproject.org/r/10461 : drivers: cc2520: Remove unused TI_CC2520 Kconfig option
- https://gerrit.zephyrproject.org/r/10462 : libcoap: Add missing m4 definitions
- https://gerrit.zephyrproject.org/r/10463 : tinydtls: Fix compilation errors
- https://gerrit.zephyrproject.org/r/10464 : Fix compilation warnings
- https://gerrit.zephyrproject.org/r/10431 : build: Use ZEPHYRINCLUDE when building offsets.o
- https://gerrit.zephyrproject.org/r/10428 : net: iface: Fix typo in net_if_down
- https://gerrit.zephyrproject.org/r/10437 : fs: Update external FAT FS source with new rev 0.12b
- https://gerrit.zephyrproject.org/r/10455 : Revert "sanitycheck: add support for risc v boards"
- https://gerrit.zephyrproject.org/r/10451 : ztest: use an aligned stack size
- https://gerrit.zephyrproject.org/r/10434 : Xtensa port: Remove XCC warning about unrecognized CLI option.
- https://gerrit.zephyrproject.org/r/10314 : tests/gpio: fix test GPIO_INT_LEVEL bug
- https://gerrit.zephyrproject.org/r/10335 : tests/gpio: don't call risk function
- https://gerrit.zephyrproject.org/r/10143 : boards/pinmux: fix typo
- https://gerrit.zephyrproject.org/r/9229 : gpio: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/9230 : gpio/nrf5: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/10344 : i2c: Sort Makefile in alphabetical order.
- https://gerrit.zephyrproject.org/r/10346 : boards/bbc_microbit: Enable and configure default I2C_NRF if I2C is enabled.
- https://gerrit.zephyrproject.org/r/10403 : gpio/stm32: Move from the OPEN_DRAIN interface to the DRIVE_STRENGTH interface
- https://gerrit.zephyrproject.org/r/10404 : gpio: Merge the OPEN_DRAIN interface with the DRIVE_STRENGTH interface.
- https://gerrit.zephyrproject.org/r/10345 : i2c/nrf5: Implement NRF5 I2C driver.
- https://gerrit.zephyrproject.org/r/10402 : doc: net: Fix networking documentation
- https://gerrit.zephyrproject.org/r/10405 : net: tcp: Only return -ETIMEDOUT if timeout>0 in connect
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/10410 : boards: arm: mps2_an385: Enable CMSDK Drivers
- https://gerrit.zephyrproject.org/r/10411 : doc: Update mps2_an385 documentation
- https://gerrit.zephyrproject.org/r/10409 : soc: arm: mps2: Add configuration for CMSDK Driver
- https://gerrit.zephyrproject.org/r/10361 : flash: Update mcux shim to new mcux version
- https://gerrit.zephyrproject.org/r/10360 : mcux: Import mcux for kw41z
- https://gerrit.zephyrproject.org/r/10362 : serial: Introduce new mcux lpuart shim driver
- https://gerrit.zephyrproject.org/r/10363 : k64: Rename security_frdm_k64f section
- https://gerrit.zephyrproject.org/r/10364 : kw41z: Add kw41z SoC
- https://gerrit.zephyrproject.org/r/10366 : MAINTAINERS: Add frdm_kw41z board
- https://gerrit.zephyrproject.org/r/10365 : frdm_kw41z: Add frdm_kw41z board
- https://gerrit.zephyrproject.org/r/9093 : sanitycheck: add support for risc v boards
- https://gerrit.zephyrproject.org/r/10321 : Xtensa port: Added Kbuild file for Xtensa arch.
- https://gerrit.zephyrproject.org/r/10288 : Xtensa port: Added fields offset support for kernel and thread structures.
- https://gerrit.zephyrproject.org/r/10310 : tests: kernel: test_mpool_concept: increase STACK_SIZE to 1024 for riscv32
- https://gerrit.zephyrproject.org/r/10311 : tests: kernel: threads_customdata: increase STACK_SIZE to 512 for riscv32
- https://gerrit.zephyrproject.org/r/10286 : Xtensa port: Added support in arch/cpu.h for Xtensa cores.
- https://gerrit.zephyrproject.org/r/10287 : Xtensa port: Added support for Xtensa cores in toolchain/gcc.h.
- https://gerrit.zephyrproject.org/r/10322 : Xtensa port: Added Xtensa specific include files.
- https://gerrit.zephyrproject.org/r/10285 : Xtensa port: Fixed typo in XCC toochain specific make file.
- https://gerrit.zephyrproject.org/r/10427 : Bluetooth: add storage flag for secure connection pairing LTK
- https://gerrit.zephyrproject.org/r/10312 : docs: add Arduino 101 board documentation
- https://gerrit.zephyrproject.org/r/10304 : Bluetooth: Move Bluetooth docs to rst
- https://gerrit.zephyrproject.org/r/10313 : doc: nios2 altera max 10 board documentation


Re: i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, but how can i do this with arduino_due board with the same tools?

曹子龙 <13824125580 at 163.com...>
 

hi:
another question, i have seen the wiki you pasted to me, and i found i did not have the flayswatter device, but i have a altera usb-blaster, so, can i use altera usb-blaster instead of the flyswatter to cooperate with the OpenOCD to finish the debug operation on the arduino_due board? thanks for your reply.

At 2017-01-25 18:06:26, "Erwan Gouriou" <erwan.gouriou(a)linaro.org> wrote:

Hi,


Are you using Nulceo_f411RE?
If this is the case, this board embeds a ST-LINK debugger/programmer that helps you controling your board with USB.
This is specific to ST developpement boards like Nucleo, Disco or Eval.


If you want to debug on Arduino, please refer to dedicated wiki page:
https://wiki.zephyrproject.org/view/Arduino_101



Cheers




On 25 January 2017 at 09:51, 曹子龙 <13824125580(a)163.com> wrote:

Hi all:


i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, the BOARD and the PC host connected directly with the USB wire, i can use this simple things to debug the zephyr flow from _reset.


what puzzle me is that from the document of OpenOCD, we must be connect to the JTAG of the board, but i use the usb of F411re do the same thing, i dont know why?


and if i want to do the debug operation on arduino_due, did this can be done by using the same tools like F411re ? thanks for your kindly reply.


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

On 25 January 2017 at 11:57, Marcus Shawcroft
<marcus.shawcroft(a)gmail.com> wrote:
On 24 January 2017 at 15:57, Anas Nashif <nashif(a)gmail.com> wrote:

The reason why we have minimal libc... it did the job for a basic kernel
implementation and mostly was used only for testing the kernel internals. It
is also a control we have (had), making sure the kernel does not rely on
libc functions and is self-contained. There is lots of history behind that,
probably Ben can add to this :-)

Over the last 2 years I have seen developers implement clones of libc
functions to overcome the lack of support of those functions in the minimal
libc. We have been adding libc function on individual basis, sometimes
pulling those functions from different sources creating a frankenstein libc
implementation that will be difficult to maintain going forward.

Given that the zephyr project now is more than just a kernel and that any
application based on Zephyr will most likely want to use newlib anyways, I
do not think there is a reason why we should continue using minimal libc as
the default, we need however to keep an eye on usage of libc functions
inside the kernel and monitor the footprint (ram and rom) if we follow this
approach.
Newlib has a re-entrancy support/infranstructure that needs porting to
the platform in order to get thread safety, I know that such porting
work for zephyr is not in upstream newlib, have we done that work in
the SDK?
Incidentally, there is work going on in newlib upstream at the moment
to provide more flexible support for re-targeting such locking
mechanisms in pre-built binary toolchains. This was (at least partly)
motivated by the mbed-os team realizing that they could not sensibly
wire up locking/reentrancy support when using the pre-canned newlib
binaries shipped with generic arm-none-eabi toolchains...

https://sourceware.org/ml/newlib/2016/msg01082.html

/Marcus


Re: uint32_t typedef differences causes issues

Marcus Shawcroft <marcus.shawcroft@...>
 

On 24 January 2017 at 15:57, Anas Nashif <nashif(a)gmail.com> wrote:

The reason why we have minimal libc... it did the job for a basic kernel
implementation and mostly was used only for testing the kernel internals. It
is also a control we have (had), making sure the kernel does not rely on
libc functions and is self-contained. There is lots of history behind that,
probably Ben can add to this :-)

Over the last 2 years I have seen developers implement clones of libc
functions to overcome the lack of support of those functions in the minimal
libc. We have been adding libc function on individual basis, sometimes
pulling those functions from different sources creating a frankenstein libc
implementation that will be difficult to maintain going forward.

Given that the zephyr project now is more than just a kernel and that any
application based on Zephyr will most likely want to use newlib anyways, I
do not think there is a reason why we should continue using minimal libc as
the default, we need however to keep an eye on usage of libc functions
inside the kernel and monitor the footprint (ram and rom) if we follow this
approach.
Newlib has a re-entrancy support/infranstructure that needs porting to
the platform in order to get thread safety, I know that such porting
work for zephyr is not in upstream newlib, have we done that work in
the SDK?

Cheers
/Marcus


sensor.h API semantics and consistency.

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi!

The sensor.h API provides various SENSOR_CHAN_*_ANY channels. The
intent of these, and so far as I can see all current use of these ANY
channels is to represent a the tuple of all of a group of related X,
Y, Z channels. Given that it always refers to *all* of the related
channels rather than any individual one of the related set I wonder
whether it would be less confusing if we rename then as
SENSOR_CHAN_*_ALL or SENSOR_CHAN_*_XYZ ?

Thoughts ?

The sensor attributes provide a mechanism to set an OFFSET on any
specific channel. This would appear to be intended as a mechanism to
exploit a hardware capability provided by some devices to configure an
arbitrary measurement offset. We have ~ 2 drivers that support this
attribute in the tree.

Given the current API, an application (or other driver user) who might
want to use the OFFSET mechanism must either:
1) Assume no driver implements OFFSET and post process results itself.
2) Hardwire knowledge that it is using the driver for a specific
device that does, or does not suport the OFFSET feature.
3) Attempt to use OFFSET, detect the ENOTSUP (or other error code used
for the same reason) and fallback to post processing results itself.

Number 1 essentially means the OFFSET mechanism serves no purpose
unless it is ubiquitous.
Number 2 undermines the device abstraction property of a platform OS
Number 3 means increased application logic and to a certain extent
also undermines the device abstraction.

From an applications / device driver users perspective the usability
of the API would be much improved if the OFFSET attribute feature was
either mandatory for a specific channel type across all drivers (or
removed completely). A driver for hardware with no offset feature
can easily emulate the behaviour within the driver itself.

I think we should give consideration to mandating driver support for
OFFSET attributes either for all channels or for specific channels (ie
those where we already have driver support for OFFSET).

I think this argument for consistency applies equally to other attribute types.

Thoughts ?


The SENSOR_ATTR_CALIB_TARGET, is I believe intended as a mechanism to
allow an application to provide a driver with a "right answer" at the
current point in time, and tell it to calibrate itself such that its
results match the calib target ?

The ATTR_OFFSET mechanism and the ATTR_CALIB_TARGET mechanism have
potential to interact on a channel where both are supported, I think
we should clarify in the API how they are intended to interact.
Notably if an application issues andOFFSET followed by a CALIB_TARGET
for the same channel, we should define how the current offset affects
the behaviour of the CALIB operation. I can imagine two alternatives:
1) CALIB has the effect of zeroing any current OFFSET.
2) Any current OFFSET is added to the CALIB target before calibration
and the current OFFSET remains in force after the CALIB operation.

I think 1) is intuitively more obvious and I can think of no benefits
in choosing 2).

Thoughts?

Cheers
/Marcus


Re: i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, but how can i do this with arduino_due board with the same tools?

Erwan Gouriou
 

Hi,

Are you using Nulceo_f411RE?
If this is the case, this board embeds a ST-LINK debugger/programmer that
helps you controling your board with USB.
This is specific to ST developpement boards like Nucleo, Disco or Eval.

If you want to debug on Arduino, please refer to dedicated wiki page:
https://wiki.zephyrproject.org/view/Arduino_101

Cheers

On 25 January 2017 at 09:51, 曹子龙 <13824125580(a)163.com> wrote:

Hi all:

i can debug my STM32-F411RE running zephyr with OpenOCD and
arm-none-eabi-gdb, the BOARD and the PC host connected directly with the
USB wire, i can use this simple things to debug the zephyr flow from _reset.

what puzzle me is that from the document of OpenOCD, we must be connect
to the JTAG of the board, but i use the usb of F411re do the same thing, i
dont know why?

and if i want to do the debug operation on arduino_due, did this can be
done by using the same tools like F411re ? thanks for your kindly reply.


i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, but how can i do this with arduino_due board with the same tools?

曹子龙 <13824125580 at 163.com...>
 

Hi all:


i can debug my STM32-F411RE running zephyr with OpenOCD and arm-none-eabi-gdb, the BOARD and the PC host connected directly with the USB wire, i can use this simple things to debug the zephyr flow from _reset.


what puzzle me is that from the document of OpenOCD, we must be connect to the JTAG of the board, but i use the usb of F411re do the same thing, i dont know why?


and if i want to do the debug operation on arduino_due, did this can be done by using the same tools like F411re ? thanks for your kindly reply.

5661 - 5680 of 8032