Date   

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.


Re: samples/net/zoap_server - blockwise transfers?

Bober, Wojciech <Wojciech.Bober@...>
 

Hi Vinicius,

Thanks for the reply. Sure, feel free to add me to the review.

Kind regards,
Wojtek

-----Original Message-----
From: Vinicius Costa Gomes [mailto:vinicius.gomes(a)intel.com]
Sent: 24 January 2017 19:43
To: Bober, Wojciech <Wojciech.Bober(a)nordicsemi.no>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: samples/net/zoap_server - blockwise transfers?

Hi Wojtek,

"Bober, Wojciech" <Wojciech.Bober(a)nordicsemi.no> writes:

Hi,

I'm playing around with zoap_server on nrf52_pca10040 but I can't get the blockwise transfers to work.
There are still some bugs in the implementation, I am working on solving them, I just noticed it when I was running a CoAP test suite
(californium) against zoap-server. Seems that my previous tests were incomplete.

When I do GET to /large I get "[zoap-server] [ERR] udp_receive: No handler for such request (-22)" in the log. The large_get handler fails at zoap_update_from_block() function. It doesn't matter if the block2 option is present in the request or not.

I also have issue with PUT to /large-update. The behaviour is inconsistent: sometimes I get the same error as above other times I get a reply to the request but I've also seen ACK Continue with Block2 (I think it should be Block1).

Any ideas what might be wrong?
In short, there was a stupid bug in parsing of integer options (this was already merged into the net branch), but I am still working on it, I can add you as reviewer as I propose the changes, if you are interested.


Kind regards,
Wojtek

Cheers,
--
Vinicius


Re: How to overcome timer delay

Dinh, Kien T
 

Thank you so much for the explanations, Ben.

Kien

On 2017/01/25 1:23, "Benjamin Walsh" <benjamin.walsh(a)windriver.com> wrote:

> > > I’m developing an app which requires fast sampling rate (~500 times
> > > per sec) via the ADC on the Arduino 101. It was alright using
> > > nano_timer_init/start/test APIs up version 1.5. However, after
> > > upgrading to version 1.6, noticeable time delay has been observed. To
> > > remove possible effects from other drivers, I’ve used the following
> > > code to test the time delay and got the below results.
> > >
> > > It seems that the amount of delay is inversely proportional to the
> > > interval. For interval = 1000 ms, the delay is just 10 ms. But for
> > > interval as high as 10 ms, the delay becomes 1000 ms, making it
> > > impossible to use for high sampling rate app. Is there any Kconfig
> > > needs to be set or any way to minimize such delay?
> >
> > When we changed the new API to take ms instead of kernel ticks for
> > timeouts, we also decided the timeouts mean "wait for at least this
> > time" instead of "wait for at most this time".
> >
> > The system is still tick-based though. So we convert ms to ticks
> > internally.
> >
> > If you want to wait "at most" an amount of time, you have to ask for
> > one tick less. So if you know your tick rate is 100Hz, and you want to
> > wait at most 20ms, you have to ask for 10ms (that would give you two
> > ticks).
> >
> > Now, you say your sampling rate is 500Hz: however, the default tick rate
> > is 100Hz. You have to change CONFIG_SYS_CLOCK_TICKS_PER_SEC to 500.
> > However (again), since with a tick freq of 500Hz, if you wait for 2ms
> > you'll wait for "at least" 2ms, you might wait for 4ms. So what you
> > probably want is a CONFIG_SYS_CLOCK_TICKS_PER_SEC of 1000, and wait for
> > 1ms, which will make you wait at most for 2ms.
> >
> > I'm starting to wonder if we should have macros for this in the API,
> > e.g. AT_MOST()/AT_LEAST(), where you could do:
> >
> > k_timer_start(&my_timer, AT_MOST(INTERVAL), 0);
> >
> > This is all because the kernel is still tick-based. We would like to
> > move to a tickless kernel, where these would not be an issue anymore.
> >
> > > =====
> > >
> > > #include <zephyr.h>
> > > #include <misc/printk.h>
> > >
> > > #define INTERVAL 1
> > >
> > > static int count;
> > > static int t;
> > >
> > > void timer_handler(struct k_timer *a_timer)
> > > {
> > > count += INTERVAL;
> > > if (count % 1000 == 0) {
> > > printk("Count %d, delta = %d\n", count,
> > > k_uptime_get_32() - t);
> > > t = k_uptime_get_32();
> > > }
> > > }
> > >
> > > 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);
> > ^^^^^^^^^
> > You cannot use K_FOREVER in this API: if you do not want periodic
> > repetition, you have to use 0.
> >
> > I'm surprised this did not blow up. Actually, if you ran with
> > CONFIG_ASSERT=y, you would have hit the one at the top of
> > _add_timeout():
> >
> > __ASSERT(timeout_in_ticks > 0, "");
> >
> >
> > > k_timer_status_sync(&my_timer);
> > > }
> > > }
> > > ====
> > >
> > > I got the same following outputs for both x86 qemu and Arduino 101 (x86):
> > >
> > > * INTERVAL = 1000 (one second)
> > > Count 1000, delta = 1010
> > > Count 2000, delta = 1010
> > > Count 3000, delta = 1010
> > > …
> > >
> > > * INTERVAL = 100 (one hundred millisecs)
> > > Count 1000, delta = 1100
> > > Count 2000, delta = 1100
> > > Count 3000, delta = 1100
> > > …
> > >
> > > * INTERVAL = 10 (ten millisecs)
> > > Count 1000, delta = 2000
> > > Count 2000, delta = 2000
> > > Count 3000, delta = 2000
> > > …
> > >
> > > * INTERVAL = 1 (one millisec)
> > > Count 1000, delta = 20000
> > > Count 2000, delta = 20000
> > > Count 3000, delta = 20000
> >
> > You're getting these numbers because your tick rate is probably 100.
> > With 1000 you would probably get:
> >
> > * INTERVAL = 1000 (one second)
> > Count 1000, delta = 1001
> > Count 2000, delta = 1001
> > Count 3000, delta = 1001
> > …
> >
> > * INTERVAL = 100 (one hundred millisecs)
> > Count 1000, delta = 1010
> > Count 2000, delta = 1010
> > Count 3000, delta = 1010
> > …
> >
> > * INTERVAL = 10 (ten millisecs)
> > Count 1000, delta = 1100
> > Count 2000, delta = 1100
> > Count 3000, delta = 1100
> > …
> >
> > * INTERVAL = 1 (one millisec)
> > Count 1000, delta = 2000
> > Count 2000, delta = 2000
> > Count 3000, delta = 2000
>
> Thank you for your reply and advices. Setting
> CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 does improve the results like you
> said. Increasing the parameter also shortens the delay:
>
> With interval=1ms:
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000
> Count 1000, delta = 2000
> Count 2000, delta = 2000
> Count 3000, delta = 2000
> …
>
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=2000
> Count 1000, delta = 1500
> Count 2000, delta = 1500
> Count 3000, delta = 1500
> …
>
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=10000
> Count 1000, delta = 1100
> Count 2000, delta = 1100
> Count 3000, delta = 1100
> …
>
> * CONFIG_SYS_CLOCK_TICKS_PER_SEC=100000
> Count 1000, delta = 1010
> Count 2000, delta = 1010
> Count 3000, delta = 1010
> main-loop: WARNING: I/O thread spun for 1000 iterations

You probably should not use tick rates that are that high, or you'll
spend all time in the timer interrupt handler (unless you also enable
tickless idle). :)

> 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.

Cheers,
Ben


[RFC]DMA API Update

Liu, Baohong
 

Hi everyone,

I made minor update, the following is the final format.

Data Structure Definitions
-------

/**
* @brief DMA block configuration structure.
*
* source_address is block starting address at source
* source_gather_interval is the address adjustment at gather boundary
* dest_address is block starting address at destination
* dest_scatter_interval is the address adjustment at scatter boundary
* dest_scatter_count is the continuous transfer count between scatter boundaries
* source_gather_count is the continuous transfer count between gather boundaries
* block_size is the number of bytes to be transferred for this block.
* config is a bit field with the following parts:
* source_gather_en [ 0 ] --0-disable, 1-enable
* dest_scatter_en [ 1 ] --0-disable, 1-enable
* source_addr_adj [ 2 : 3 ] --00-increment, 01-decrement, 10-no change
* dest_addr_adj [ 4 : 5 ] --00-increment, 01-decrement, 10-no change
* source_reload_en [ 6 ] --reload source address at the end of block transfer
* 0-disable, 1-enable
* dest_reload_en [ 7 ] --reload destination address at the end of block transfer
* 0-disable, 1-enable
* fifo_mode_control [ 8 : 11 ] --How full of the fifo before transfer start. HW specific.
* flow_control_mode [ 12 ] --0-source request served upon data availability
* 1-wait until destination request happens
* RESERVED [ 13 : 15 ]
*/
struct dma_block_config {
uint32_t source_address;
uint32_t source_gather_interval;
uint32_t dest_address;
uint32_t dest_scatter_interval;
uint16_t dest_scatter_count;
uint16_t source_gather_count;
uint32_t block_size;
struct dma_block_config *next_block;
uint16_t config;
}

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW specific)
* channel_direction [ 6 : 8 ] --000-memory to memory, 001-memory to peripheral,
* 010-peripheral to memory ...
* complete_callback_en [ 9 ] --0-callback invoked at completion only
* 1-callback invoked at completion of each block
* error_callback_en [ 10 ] --0-err callback enabled
* 1-err callback disabled
* source_handshake [ 11 ] --0-HW, 1-SW
* dest_handshake [ 12 ] --0-HW, 1-SW
* channel_priority [ 13 : 16 ] --DMA channel priority
* source_chaining_en [ 17 ] --enable/disable source block chaining
* 0-disable, 1-enable
* dest_chaining_en [ 18 ] --enable/disable destination block chaining
* 0-disable, 1-enable
* RESERVED [ 19 : 31 ]
* config_size is a bit field with the following parts:
* source_data_size [ 0 : 7 ] --number of bytes
* dest_data_size [ 8 : 15 ] -- number of bytes
* source_burst_length [ 16 : 23 ] -- number of source data units
* dest_burst_length [ 24 : 31 ] -- number of destination data units
* dma_callback is the callback function pointer. If enabled, callback function will be invoked
* at transfer completion or when error happens (non zero error_code).
*/
struct dma_config {
uint32_t config;
uint32_t config_size;
uint32_t block_count;
struct dma_block_config *head_block;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code); }

API Interfaces
-------

/**
* @brief Configure individual channel for DMA transfer.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel to configure
* @param config Data structure containing the intended configuration for the
* selected channel
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_config(struct device *dev, uint32_t channel,
struct dma_config *config)
{
}

/**
* @brief Enables DMA channel and starts the transfer, the channel must be
* configured beforehand.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer will
* be processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_start(struct device *dev, uint32_t channel)
{
}

/**
* @brief Stops the DMA transfer and disables the channel.
*
* @param dev Pointer to the device structure for the driver instance.
* @param channel Numeric identification of the channel where the transfer was
* being processed
*
* @retval 0 If successful.
* @retval Negative errno code if failure.
*/
static inline int dma_stop(struct device *dev, uint32_t channel)
{
}

All existing data structure definitions and APIs will be deprecated.

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Wednesday, January 11, 2017 11:50 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] [RFC]DMA API Update


Hi everyone,

I would like to propose the update for DMA API.
(https://jira.zephyrproject.org/browse/ZEP-873).

Known Problems
--------

Struct dma_channel_config consists of quite a few variables of enum types,
two callback function pointers, and one callback user data pointer.

- The enums can be collapsed into a bit field.
This will reduce the size of the data structure.

- The two callback function pointers (for normal and error cases) can be
combined.
A parameter of error code can be used to differentiate the two cases. So,
the
current callback parameter of user data pointer will be replaced by two new
parameters. One for error code and the other one for channel id.

- Callback data pointer can be removed.
Currently, this field holds user data. It can be moved to driver data structure.
The callback function can dig out the information from dev pointer and
channel id passed to it.

Proposed Solution
--------

-- The following are the enums we have now.

handshake_interface /* which peripheral and direction*/
hankshake_polarity /* high or low*/
channel_direction /* memory to memory, memory to peripheral ... */
Source_transfer_width /* source data size */
Destination_transfer_width /* destination data size */
Source_burst_length /* source burst length */
Destination_burst_length /* destination burst length */

All these will be collapsed into a bit field. Some of them will have new names.

Besides the above, three new items will be added.
source_handshake /* HW or SW */
dest_handshake /* HW or SW */
channel_priority /* DMA channel priority */

-- For the callback function, there will be three parameters. They are device
pointer,
channel_id, and error code. As said above, the error callback will be
removed.

-- The callback_data pointer will be removed.

Final API Format
--------

/**
* @brief DMA configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_data_size [ 10 : 12 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_data_size [ 13 : 15 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 16 : 18 ] --number of source data
unit(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 19 : 21 ] -- number of dest data
unit(1,4,8,16,32,64,128 and 256)
* source_handshake [ 22 ] --HW or SW
* dest_handshake [ 23 ] --HW or SW
* channel_priority [ 24 : 27 ] --DMA channel priority
* RESERVED [ 28 : 31 ]
* dma_callback is the callback function pointer
*/
struct dma_channel_config {
uint32_t config;
void (*dma_callback)(struct device *dev, uint32_t channel, int
error_code); }

The remaining parts will stay the same.
No change to the structure dma_transfer_config.
No change to the API function prototypes:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

(Note: for xx_data_size and xx_burst_length in the above bit field, the value
will only serve as an index. For example, for source_data_size, bit field values
of 0, 1, 2, 3, 4 and 5 will correspond to sizes of 8,16,32,64,128 and 256 bits.)

Suggestions and comments are welcome.


RFC: API for "direct" interrupts

Boie, Andrew P
 

This is a new API for connecting interrupts that bypasses a lot of the common code, for those interrupts which need the lowest possible latency. I have been working on this with Carles, Chuck, Jon, Ben, and a few others. Details on usage and caveats in the patch itself.

Review appreciated: https://gerrit.zephyrproject.org/r/#/c/10183/

Andrew


Re: [RFC]DMA API Update

Liu, Baohong
 

Hi Piotr,

From: Piotr Mieńkowski [mailto:piotr.mienkowski(a)gmail.com]
Sent: Tuesday, January 24, 2017 5:25 AM
Subject: Re: [devel] [RFC]DMA API Update
[...]
"Instead, the callback would provide the pointer of struct dma_channel_config which triggered it. Then, up to the user to relevantly design his own data structure to be able to use CONTAINER_OF() with that pointer."

So we would need to pass a pointer to dma_config.
For the callback function to get the dma config info, channel id and device pointer are good enough.
A dma userdata pointer is not needed.

[...]
I'm not saying that we need to go to the old dma_api_channel_config/dma_api_transfer_config split. We may try to think about something else, e.g. have dma_start take something like the old dma_transfer_config struct as a parameter.
We need to take care of both single block and block chaining. What's your proposal?

[...]
Is one driver accessing other driver via a private and not public API violating some Zephyr design guideline?
If a driver (e.g. SPI or I2C driver) needs to use DMA, it should be using the DMA APIs
but not through any private API.


Re: samples/net/zoap_server - blockwise transfers?

Vinicius Costa Gomes
 

Hi Wojtek,

"Bober, Wojciech" <Wojciech.Bober(a)nordicsemi.no> writes:

Hi,

I'm playing around with zoap_server on nrf52_pca10040 but I can't get the blockwise transfers to work.
There are still some bugs in the implementation, I am working on solving
them, I just noticed it when I was running a CoAP test suite
(californium) against zoap-server. Seems that my previous tests were
incomplete.

When I do GET to /large I get "[zoap-server] [ERR] udp_receive: No handler for such request (-22)" in the log. The large_get handler fails at zoap_update_from_block() function. It doesn't matter if the block2 option is present in the request or not.

I also have issue with PUT to /large-update. The behaviour is inconsistent: sometimes I get the same error as above other times I get a reply to the request but I've also seen ACK Continue with Block2 (I think it should be Block1).

Any ideas what might be wrong?
In short, there was a stupid bug in parsing of integer options (this was
already merged into the net branch), but I am still working on it, I can
add you as reviewer as I propose the changes, if you are interested.


Kind regards,
Wojtek

Cheers,
--
Vinicius

5681 - 5700 of 8046