Date   

Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10427 : Bluetooth: add storage flag for secure connection pairing LTK
- https://gerrit.zephyrproject.org/r/10426 : Bluetooth: HFP HF: Enable extended AG Error Result Code
- https://gerrit.zephyrproject.org/r/10409 : soc: arm: mps2: Add configuration for CMSDK 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/10416 : i2c: stm32: change deprecated constant
- https://gerrit.zephyrproject.org/r/10419 : flash: update stm32 flash_f3x to support LL 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/10414 : pinmux: update stm32 pinmux to support LL clock control driver
- 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/10417 : i2c: update stm32 i2c_lx 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/10413 : gpio: update stm32 gpio to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10415 : uart: update stm32 uart to support LL clock control driver
- https://gerrit.zephyrproject.org/r/10370 : Bluetooth: Controller: Fix build error with newlib
- https://gerrit.zephyrproject.org/r/10412 : clock control:stm32: provide STM32Cube LL based driver
- https://gerrit.zephyrproject.org/r/10411 : doc: Update mps2_an385 documentation
- https://gerrit.zephyrproject.org/r/10410 : boards: arm: mps2_an385: Enable CMSDK Drivers
- 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/10405 : net: tcp: Only return -ETIMEDOUT if timeout>0 in connect
- https://gerrit.zephyrproject.org/r/10394 : samples: net: irc_bot: handle messages across multiple fragments
- https://gerrit.zephyrproject.org/r/10398 : samples: net: irc_bot: remove NET_TESTING config in Makefile
- 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/10402 : doc: net: Fix networking documentation
- 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/10387 : samples: net: irc_bot: simplify connect path
- https://gerrit.zephyrproject.org/r/10386 : samples: net: irc_bot: make some functions more accessible
- 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/10382 : samples: net: irc_bot: add helper function in_addr_set()
- https://gerrit.zephyrproject.org/r/10381 : samples: net: irc_bot: remove unneeded typecasts and extra var
- 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/10375 : samples/coaps_client CoAP over DTLS client example app using mbedTLS
- https://gerrit.zephyrproject.org/r/10401 : Bluetooth: shell: Use API to get record handle
- https://gerrit.zephyrproject.org/r/10400 : Bluetooth: SDP: Add API to get Record handle
- https://gerrit.zephyrproject.org/r/10365 : frdm_kw41z: Add frdm_kw41z board
- https://gerrit.zephyrproject.org/r/10397 : samples: net: Add IRC bot example
- https://gerrit.zephyrproject.org/r/10366 : MAINTAINERS: Add frdm_kw41z board
- https://gerrit.zephyrproject.org/r/10364 : kw41z: Add kw41z SoC
- https://gerrit.zephyrproject.org/r/10363 : k64: Rename security_frdm_k64f section
- https://gerrit.zephyrproject.org/r/10362 : serial: Introduce new mcux lpuart shim driver
- https://gerrit.zephyrproject.org/r/10360 : mcux: Import mcux for kw41z
- https://gerrit.zephyrproject.org/r/10361 : flash: Update mcux shim to new mcux version

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/10286 : Xtensa port: Added support in arch/cpu.h for Xtensa cores.
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- 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/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/9975 : net: tcp: Make the connect callback on success, not transmission
- https://gerrit.zephyrproject.org/r/10313 : doc: nios2 altera max 10 board documentation
- https://gerrit.zephyrproject.org/r/10312 : docs: add Arduino 101 board documentation
- https://gerrit.zephyrproject.org/r/10346 : boards/bbc_microbit: Enable and configure default I2C_NRF if I2C is enabled.
- https://gerrit.zephyrproject.org/r/10345 : i2c/nrf5: Implement NRF5 I2C driver.
- https://gerrit.zephyrproject.org/r/9230 : gpio/nrf5: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/9229 : gpio: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/10344 : i2c: Sort Makefile in alphabetical order.
- https://gerrit.zephyrproject.org/r/10320 : Xtensa port: Added Xtensa specific C files.
- https://gerrit.zephyrproject.org/r/10319 : Xtensa port: Added Xtensa specific assembly files.
- https://gerrit.zephyrproject.org/r/10249 : samples/coaps_server CoAP over DTLS server example app using mbedTLS
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attribute internals
- https://gerrit.zephyrproject.org/r/9714 : Bluetooth: shell: Add getting ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9715 : Bluetooth: SDP: Add API to get SupportedFeature attribute
- https://gerrit.zephyrproject.org/r/9712 : Bluetooth: shell: Add SDP client support
- https://gerrit.zephyrproject.org/r/9713 : Bluetooth: SDP: Add API to get ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9717 : Bluetooth: shell: Add support to retrieve A2SRC record
- https://gerrit.zephyrproject.org/r/9716 : Bluetooth: shell: Use SupportedFeature attribute API
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/10176 : Add support for STM32Cube HAL_PCD USB driver
- https://gerrit.zephyrproject.org/r/10175 : cdc_acm - Use endpoint 2 instead of endpoint 4 for IN BULK endpoint
- https://gerrit.zephyrproject.org/r/10304 : Bluetooth: Move Bluetooth docs to rst
- https://gerrit.zephyrproject.org/r/10183 : irq: introduce 'direct' interrupt API definition
- https://gerrit.zephyrproject.org/r/3311 : include/crypto: Crypto abstraction header
- https://gerrit.zephyrproject.org/r/10291 : drivers: Add Atmel SAM Timer Counter (TC) driver
- https://gerrit.zephyrproject.org/r/9977 : samples: net: "Mini HTTP" example & validator for TCP layer
- https://gerrit.zephyrproject.org/r/10318 : Xtensa port: Added support for Xtensa architecture in zephyr include files.
- https://gerrit.zephyrproject.org/r/10322 : Xtensa port: Added Xtensa specific include files.
- https://gerrit.zephyrproject.org/r/10288 : Xtensa port: Added fields offset support for kernel and thread structures.
- https://gerrit.zephyrproject.org/r/10287 : Xtensa port: Added support for Xtensa cores in toolchain/gcc.h.
- https://gerrit.zephyrproject.org/r/9883 : i2c: Adds a functions set that supports 16 bit addressing.
- https://gerrit.zephyrproject.org/r/10323 : Xtensa port: Added linker script for several Xtensa cores.
- https://gerrit.zephyrproject.org/r/10321 : Xtensa port: Added Kbuild file for Xtensa arch.
- https://gerrit.zephyrproject.org/r/10307 : stm32f4 - add configuration option to set flash latency
- https://gerrit.zephyrproject.org/r/10133 : Windows Build: ussing a precompiled kbuild on windows
- https://gerrit.zephyrproject.org/r/10295 : MAINTAINERS: add xtensa arch

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10425 : tests: newlib: disable bluetooth for now
- https://gerrit.zephyrproject.org/r/10407 : net: bt: Fix warning when compiling without debug
- https://gerrit.zephyrproject.org/r/10406 : net: bt: Fix not checking channel state
- https://gerrit.zephyrproject.org/r/10399 : Bluetooth: Doc: RFCOMM PICS file
- https://gerrit.zephyrproject.org/r/10373 : Merge arm branch into master
- https://gerrit.zephyrproject.org/r/10374 : samples: power_mgmt: Convert README to RST format
- https://gerrit.zephyrproject.org/r/10350 : tests: arm_irq_vector_table: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/10349 : arm: cmsis: Convert relocate_vector_table to use CMSIS
- https://gerrit.zephyrproject.org/r/10359 : commit-message: skip length checks for http/https URLs
- https://gerrit.zephyrproject.org/r/9982 : drivers: spi: enable gpio driver automatically when needed
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/10276 : sensor: fxos8700: expand trigger requirement to include pulse config
- https://gerrit.zephyrproject.org/r/10300 : filter-known-issues: add warning support, clean up, add more help
- https://gerrit.zephyrproject.org/r/10317 : tests: kernel: mbox_api: fix uninit variable and unchecked value
- https://gerrit.zephyrproject.org/r/10316 : tests: kernel: mpool: fix assert side effect
- https://gerrit.zephyrproject.org/r/10315 : tests: kernel: mpool: fix unchecked return value
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/10334 : tests: kernel: msgq: fix unused value
- https://gerrit.zephyrproject.org/r/10327 : kernel: remove K_STATIC
- https://gerrit.zephyrproject.org/r/10332 : build: add _ASMLANGUAGE to all asm files
- https://gerrit.zephyrproject.org/r/10325 : kernel: move volatile from k_thread.prio to k_thread.sched_locked
- https://gerrit.zephyrproject.org/r/10326 : kernel: include kernel.h in kernel_structs.h in asm files
- https://gerrit.zephyrproject.org/r/10328 : kernel: rename thread states symbols
- https://gerrit.zephyrproject.org/r/10329 : kernel: move K_ESSENTIAL from thread_state to execution_flags
- https://gerrit.zephyrproject.org/r/10330 : kernel/x86: move INT_ACTIVE/EXC_ACTIVE to thread_state
- https://gerrit.zephyrproject.org/r/10331 : kernel/arch: streamline thread user options
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9809 : samples: ieee802154: add MCR20A
- https://gerrit.zephyrproject.org/r/9805 : ext: mcux: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/10281 : samples: net: add configs for MCR20A
- https://gerrit.zephyrproject.org/r/10347 : net: samples: Fix config option
- https://gerrit.zephyrproject.org/r/10338 : net: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10341 : net: tests: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10340 : net: samples: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10339 : net: Fix 80 line character limit
- https://gerrit.zephyrproject.org/r/10337 : net: tests: Fix invalid config option in 6lo tests
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Convert enable_floating_point to use CMSIS
- https://gerrit.zephyrproject.org/r/9923 : arm: cmsis: Convert systick to CMSIS
- https://gerrit.zephyrproject.org/r/9924 : arm: cmsis: Convert DO_REBOOT to use CMSIS
- https://gerrit.zephyrproject.org/r/9970 : arm: cmsis: Introduce CMSIS layer
- https://gerrit.zephyrproject.org/r/9922 : arm: cmsis: Remove unused code from scb/scs layers
- https://gerrit.zephyrproject.org/r/9971 : timer: nrf_rtc: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/9972 : clock_control: nrf5_power: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/9973 : Bluetooth: Controller: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/10244 : doc: update MAINTAINERS for .rst files
- https://gerrit.zephyrproject.org/r/10277 : arm: soc: Add SoC series for ARM's Cortex-M Prototyping System (MPS2)
- https://gerrit.zephyrproject.org/r/10278 : boards: arm: Add board for MPS2 with AN383
- https://gerrit.zephyrproject.org/r/10309 : boards: arduino 101: set user LED values correctly
- https://gerrit.zephyrproject.org/r/9984 : spi: Add shared default configs
- https://gerrit.zephyrproject.org/r/9986 : k64: Change the default spi driver to the mcux shim
- https://gerrit.zephyrproject.org/r/9985 : spi: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9987 : tests: Update spi driver test for mcux
- https://gerrit.zephyrproject.org/r/9989 : spi: k64: Remove the k64 spi driver
- https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level


Re: [RFC]DMA API Update

Jon Medhurst (Tixy) <tixy@...>
 

On Tue, 2017-01-24 at 02:37 +0100, Piotr Mieńkowski wrote:
[...]
* I know that this comment is coming very late but I was wondering if
we really want the device drivers to use this DMA API? Device
drivers are always written for a specific SoC
No they aren't. The same IP blocks gets reused in multiple SoCs,
sometimes from different manufactures. E.g ARM provide IP for lots of
generic devices that then gets integrated by different manufacturers
into their SoC. Other companies do too, e.g. Synopsys has DesignWare IP.
Then there's things not on the SoC itself that the board manufacturer
adds. They need drivers and I'm sure people would prefer not to have to
cut'n'paste an existing driver and hack it to fit the DMA driver for the
particular SoC there using.

and their code doesn't
need to be portable between architectures,
What about drivers that talk to other devices over things like SPI or
I2C busses? They are completely SoC and architecture agnostic.
There's also people integrating things like 16550 compatible UARTs in
devices of different architectures, which could have a common driver.

[...]
Is one driver accessing other driver via a
private and not public API violating some Zephyr design guideline?
It's breaking common sense on how you design an OS that's pretending to
be in any way generic.

--
Tixy


samples/net/zoap_server - blockwise transfers?

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

Hi,

I'm playing around with zoap_server on nrf52_pca10040 but I can't get the blockwise transfers to work.

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?

Kind regards,
Wojtek


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Appala Raju <raju.ga@...>
 

Hi Carles,

I can understand that and that would be fine for me. I hope this is also applicable in all other OS like Contiki & RIOT and even in Nordic SDK.

Thanks,
Raju


Re: [RFC]DMA API Update

Piotr Mieńkowski <piotr.mienkowski at gmail.com...>
 

Hi Baohong,

Thanks for preparing the new DMA API and am very sorry for not replying
earlier. I was busy with other things. I do have some comments to the
proposal.

* the callback data pointer was removed, the reasoning was as follows:

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

I believe that's not correct. The callback function will have no way
to dig out the required information from the DMA dev pointer. The
original idea as described in the Jira issue by Tomasz Bursztyka was
different.

"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. I'm however not
sure if that's really the right way to go. Using CONTAINER_OF() is
an extremely clever idea to save a byte of RAM but also one which
will keep many users scratching their heads. We are talking here
about public API, one which should be straightforward to use and
accessible also to less experienced users. Maybe the original
concept was better?

* Often, when working with DMA, we need to configure DMA channel once
and then perform several transfers where the only difference to the
last setup is the location of the source or the destination buffer.
Yet again I think the original concept was a little bit better as it
split channel configuration in two parts exactly along this lines.
That way we didn't have to go through a somewhat lengthy process of
fully reconfiguring the DMA channel when we wanted to change source
address only. One could argue that it's what linked lists are for
but in practice we do not always know up front what will be the
location of the next buffer so setting up a linked list transfer is
not always an option. 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.

* I know that this comment is coming very late but I was wondering if
we really want the device drivers to use this DMA API? Device
drivers are always written for a specific SoC and their code doesn't
need to be portable between architectures, i.e. Quark DMA driver
will never be used with Atmel DAC driver. When writing Atmel or
Quark DAC driver I would rather access private API of Atmel/Quark
DMA module and not this one. Private APIs correlate well with the
documentation, put no limits on features the hardware module can
offer and add only a thin layer of code. This API has to be
universal and that's good but there is a price to pay. All the
various bit field parameters which we defined will have to be
translated to the device native format. Cutting a bit field and
moving it elsewhere is actually not a very expensive operation but
we have a lot of parameters to process and not all of them will be
straightforward to translate. So this API adds a relatively thick
layer of code. Maybe it would be better if it was targeted
exclusively at user space programs? The only use case involving a
user space program and DMA driver that I can think of is a memory to
memory transfer. Any memory to peripheral or peripheral to memory
transfer will be handled by a respective device driver. Or am I
wrong on this one? Is one driver accessing other driver via a
private and not public API violating some Zephyr design guideline?

Regards,
Piotr

On 01/23/2017 10:53 PM, Liu, Baohong wrote:
Hi everyone,

Based on the feedbacks, 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_int_en [ 9 ] --completion interrupt enable
* 0-disable, 1-enable
* block_int_en [ 10 ] --block completion interrupt enable
* 0-disable, 1-enable
* source_int_en [ 11 ] --source completion interrupt enable
* 0-disable, 1-enable
* dest_int_en [ 12 ] --destination completion interrupt enable
* 0-disable, 1-enable
* error_int_en [ 13 ] --error interrupt enable
* 0-disable, 1-enable
* source_handshake [ 14 ] --0-HW, 1-SW
* dest_handshake [ 15 ] --0-HW, 1-SW
* channel_priority [ 16 : 19 ] --DMA channel priority
* source_chaining_en [ 20 ] --enable/disable source block chaining
* 0-disable, 1-enable
* dest_chaining_en [ 21 ] --enable/disable destination block chaining
* 0-disable, 1-enable
* RESERVED [ 22 : 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
*/
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
Sent: Tuesday, January 10, 2017 6:29 PM
To: 'Liu, Baohong' <baohong.liu(a)intel.com>
Subject: [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.
--------

Structure dma_channel_config consists of quite a few variables of enum type,
two callback pointers, and one callback data pointer.

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

- The two callback pointers (for normal and error cases) can be combined.
One new callback parameter will be used to return error code.

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

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.

Besides the above, three new items will be added into the bit field.
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:
* handshake_interface [ 0 : 3 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 4 ] --high or low
* channel_direction [ 5 : 7 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_transfer_width [ 8 : 10 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_transfer_width [ 11 : 13 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 14 : 16 ] --source burst
length(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 17 : 19 ] -- destination burst
length(1,4,8,16,32,64,128 and 256)
* source_handshake [ 20 ] --HW or SW
* dest_handshake [ 21 ] --HW or SW
* channel_priority [ 22 : 24 ] --DMA channel priority
* RESERVED [ 25 : 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 calls:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

Suggestions and comments are welcome.


Re: How to overcome timer delay

Dinh, Kien T
 

Hi Benjamin,

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

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?

Thanks,
Kien

PS: It would be fun blowing up the HW with some code. I used to blow up
the circuit with a capacitor soldered mistakenly in opposite way. Please let
me follow your advice not to use K_FOREVER in this case.

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

Hi Kien,

> 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

Cheers,
Ben

> …
>
> Thanks,
> Kien

--
Benjamin Walsh, SMTS
WR VxWorks Virtualization Profile
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


[RFC]DMA API Update

Liu, Baohong
 

Hi everyone,

Based on the feedbacks, 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_int_en [ 9 ] --completion interrupt enable
* 0-disable, 1-enable
* block_int_en [ 10 ] --block completion interrupt enable
* 0-disable, 1-enable
* source_int_en [ 11 ] --source completion interrupt enable
* 0-disable, 1-enable
* dest_int_en [ 12 ] --destination completion interrupt enable
* 0-disable, 1-enable
* error_int_en [ 13 ] --error interrupt enable
* 0-disable, 1-enable
* source_handshake [ 14 ] --0-HW, 1-SW
* dest_handshake [ 15 ] --0-HW, 1-SW
* channel_priority [ 16 : 19 ] --DMA channel priority
* source_chaining_en [ 20 ] --enable/disable source block chaining
* 0-disable, 1-enable
* dest_chaining_en [ 21 ] --enable/disable destination block chaining
* 0-disable, 1-enable
* RESERVED [ 22 : 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
*/
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
Sent: Tuesday, January 10, 2017 6:29 PM
To: 'Liu, Baohong' <baohong.liu(a)intel.com>
Subject: [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.
--------

Structure dma_channel_config consists of quite a few variables of enum type,
two callback pointers, and one callback data pointer.

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

- The two callback pointers (for normal and error cases) can be combined.
One new callback parameter will be used to return error code.

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

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.

Besides the above, three new items will be added into the bit field.
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:
* handshake_interface [ 0 : 3 ] --which peripheral and
direction(HW specific)
* hankshake_polarity [ 4 ] --high or low
* channel_direction [ 5 : 7 ] --0-memory to memory, 1-
memory to peripheral,
* 2-peripheral to memory
* source_transfer_width [ 8 : 10 ] --source data size(8,16,32,64,128
and 256 bits)
* dest_transfer_width [ 11 : 13 ] --destination data
size(8,16,32,64,128 and 256 bits)
* source_burst_length [ 14 : 16 ] --source burst
length(1,4,8,16,32,64,128 and 256)
* dest_burst_length [ 17 : 19 ] -- destination burst
length(1,4,8,16,32,64,128 and 256)
* source_handshake [ 20 ] --HW or SW
* dest_handshake [ 21 ] --HW or SW
* channel_priority [ 22 : 24 ] --DMA channel priority
* RESERVED [ 25 : 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 calls:
dma_channel_config(...)
dma_transfer_config(...)
dma_transfer_start(...)
dma_transfer_stop(...)

Suggestions and comments are welcome.


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Carles Cufi
 

Hi Raju,

-----Original Message-----
From: Appala Raju [mailto:raju.ga(a)gmail.com]
Sent: Monday, January 23, 2017 18:39
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
"/samples/net/coap_server" example is not working on "nrf52_pca10040"
board

As per this post "https://devzone.nordicsemi.com/question/6566/how-to-
get-6-byte-mac-address-at-nrf51822/" we can have unique Mac address but
it seems this is not mapped in this OS properly. Can we implement the
same.
I'll try to send a patch to read the FICR address in the nRF5x. But even then remember that you will end up with a *random static* address, since the Nordic nRF5x ICs do not come with a public address by default. That said, it will be the same random static address every time you boot.

Regards,

Carles


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Johan Hedberg
 

Hi,

On Mon, Jan 23, 2017, Appala Raju wrote:
As per this post
"https://devzone.nordicsemi.com/question/6566/how-to-get-6-byte-mac-address-at-nrf51822/"
we can have unique Mac address but it seems this is not mapped in this
OS properly. Can we implement the same.
That's indeed a good idea. If someone wants to pick up the task, I think
following would probably be the appropriate location:

--- a/subsys/bluetooth/host/hci_core.c
+++ b/subsys/bluetooth/host/hci_core.c
@@ -3285,6 +3285,10 @@ static int set_static_addr(void)
}
}

+ if (IS_ENABLED(CONFIG_SOC_FAMILY_NRF5)) {
+ /* Read address from nRF5-specific storage */
+ }
+
BT_DBG("Generating new static random address");

err = bt_addr_le_create_static(&bt_dev.id_addr);

Johan


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Appala Raju <raju.ga@...>
 

As per this post "https://devzone.nordicsemi.com/question/6566/how-to-get-6-byte-mac-address-at-nrf51822/" we can have unique Mac address but it seems this is not mapped in this OS properly. Can we implement the same.

Thanks,
Raju


Re: How to overcome timer delay

Benjamin Walsh <benjamin.walsh@...>
 

Hi Kien,

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

Cheers,
Ben



Thanks,
Kien
--
Benjamin Walsh, SMTS
WR VxWorks Virtualization Profile
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-1624] GPIO: Interrupt fails to work after resume from deepsleep @ARC
https://jira.zephyrproject.org/browse/ZEP-1624

[ZEP-1626] SPI: spi cannot work in CPHA mode @ ARC
https://jira.zephyrproject.org/browse/ZEP-1626


UPDATED JIRA items within last 24 hours: 4
[ZEP-1566] WDT: Interrupt is triggered multiple times @ARC
https://jira.zephyrproject.org/browse/ZEP-1566

[ZEP-1545] AON Counter : ISR triggered twice on ARC
https://jira.zephyrproject.org/browse/ZEP-1545

[ZEP-1625] tests/gpio: test case won't judge GPIO_INT_LEVEL
https://jira.zephyrproject.org/browse/ZEP-1625

[ZEP-1592] echo-server does not build with newlib
https://jira.zephyrproject.org/browse/ZEP-1592


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10345 : i2c/nrf5: Implement NRF5 I2C driver.
- https://gerrit.zephyrproject.org/r/10344 : i2c: Sort Makefile in alphabetical order.
- https://gerrit.zephyrproject.org/r/10341 : net: tests: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10347 : net: samples: Fix config option
- https://gerrit.zephyrproject.org/r/10340 : net: samples: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10346 : boards/bbc_microbit: Enable and configure default I2C_NRF if I2C is enabled.
- https://gerrit.zephyrproject.org/r/10338 : net: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10339 : net: Fix 80 line character limit
- https://gerrit.zephyrproject.org/r/10337 : net: tests: Fix invalid config option
- https://gerrit.zephyrproject.org/r/10335 : tests/gpio: don't call risk function
- https://gerrit.zephyrproject.org/r/10333 : test_mbedtls: for testing Port AES-CMAC-PRF-128 library
- https://gerrit.zephyrproject.org/r/10334 : tests: kernel: msgq: fix unused value
- https://gerrit.zephyrproject.org/r/10332 : build: add _ASMLANGUAGE to all asm files
- https://gerrit.zephyrproject.org/r/10328 : kernel: rename thread states symbols
- https://gerrit.zephyrproject.org/r/10329 : kernel: move K_ESSENTIAL from thread_state to execution_flags
- https://gerrit.zephyrproject.org/r/10330 : kernel/x86: move INT_ACTIVE/EXC_ACTIVE to thread_state
- https://gerrit.zephyrproject.org/r/10331 : kernel/arch: streamline thread user options
- https://gerrit.zephyrproject.org/r/10326 : kernel: include kernel.h in kernel_structs.h in asm files
- https://gerrit.zephyrproject.org/r/10325 : kernel: move volatile from k_thread.prio to k_thread.sched_locked
- https://gerrit.zephyrproject.org/r/10327 : kernel: remove K_STATIC
- https://gerrit.zephyrproject.org/r/10321 : Xtensa port: Added Kbuild file for Xtensa arch.
- https://gerrit.zephyrproject.org/r/10318 : Xtensa port: Added support for Xtensa architecture in zephyr include files.
- https://gerrit.zephyrproject.org/r/10322 : Xtensa port: Added Xtensa specific include files.
- https://gerrit.zephyrproject.org/r/10324 : Xtensa core: Added placeholder for core specific C code.
- https://gerrit.zephyrproject.org/r/10323 : Xtensa port: Added linker script for several Xtensa cores.
- https://gerrit.zephyrproject.org/r/10320 : Xtensa port: Added Xtensa specific C files.
- https://gerrit.zephyrproject.org/r/10319 : Xtensa port: Added Xtensa specific assembly files.

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/6384 : stm32lx: spi add SPI driver for STM32Lx family
- https://gerrit.zephyrproject.org/r/10224 : arm: cortex-m: Implement CONFIG_TEXT_SECTION_OFFSET
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/9036 : counter: cmsdk: Add Dualtimer as a Timer
- https://gerrit.zephyrproject.org/r/9001 : counter: cmsdk: Add Timer 0 and 1 as Timers
- https://gerrit.zephyrproject.org/r/10211 : samples: net: Add IRC bot example
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/9030 : counter: cmsdk: Add clock control to TMR Counters.
- https://gerrit.zephyrproject.org/r/10282 : counter: cmsdk: Add common interface
- https://gerrit.zephyrproject.org/r/10278 : boards: arm: Add board for MPS2 with AN383
- https://gerrit.zephyrproject.org/r/10277 : arm: soc: Add SoC series for ARM's Cortex-M Prototyping System (MPS2)
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9805 : ext: mcux: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/9809 : samples: ieee802154: add MCR20A
- https://gerrit.zephyrproject.org/r/10281 : samples: net: add configs for MCR20A
- https://gerrit.zephyrproject.org/r/10307 : stm32f4 - add configuration option to set flash latency
- https://gerrit.zephyrproject.org/r/9230 : gpio/nrf5: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/9229 : gpio: Support drive strength configuration.
- https://gerrit.zephyrproject.org/r/10249 : samples/coaps_server CoAP over DTLS server example app using mbedTLS
- https://gerrit.zephyrproject.org/r/10304 : Bluetooth: Move Bluetooth docs to rst
- https://gerrit.zephyrproject.org/r/10084 : net: buf: Introduce net_buf_save/restore APIs
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/9716 : Bluetooth: SDP: Use SupportedFeature attr API in BTshell
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/9336 : tests: spi: Add support for SPI_K64

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10343 : boards:arm: Provide debug option on some boards
- https://gerrit.zephyrproject.org/r/10348 : docs: sensor: update included example code
- https://gerrit.zephyrproject.org/r/10336 : net: Set default NET_NBUF_RX_COUNT to 4.
- https://gerrit.zephyrproject.org/r/10270 : wpan_serial: Queue only full packet to RX queue
- https://gerrit.zephyrproject.org/r/10132 : samples/zoap_server: Also listen on the unicast address
- https://gerrit.zephyrproject.org/r/10303 : samples/zoap: Update zoap samples documentation
- https://gerrit.zephyrproject.org/r/10305 : license: use SPDX identifier for files in ext/


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Luiz Augusto von Dentz
 

Hi,

There could be 2 reasons why you end up with a random address, either
you are setting CONFIG_BLUETOOTH_PRIVACY or the adapter don't have a
valid address (e.g. 00:00:00:00:00:00) which will cause the stack to
generate a static random address, for the former you just need to
disable privacy but in case of the later you need to check with the
manufacturer if it can provide a public address or in case it is a
qemu + btproxy setup just try another USB dongle.

On Sun, Jan 22, 2017 at 5:55 PM, Appala Raju <raju.ga(a)gmail.com> wrote:
Hi Luiz Augusto von Dentz,

Yes, I am able to connect by passing 2 after address. How can I go with static address by using device Mac ID instead of random address.

Thanks,
Raju
--
Luiz Augusto von Dentz


How to overcome timer delay

Dinh, Kien T
 

Hi,

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?

=====

#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);
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


Thanks,
Kien


Mailing list: Please remove

Jason Rotella <jrotella@...>
 

Please remove me from this mailing list for the time being.

Thank you,
Jason


Re: "/samples/net/coap_server" example is not working on "nrf52_pca10040" board

Appala Raju <raju.ga@...>
 

Hi Luiz Augusto von Dentz,

Yes, I am able to connect by passing 2 after address. How can I go with static address by using device Mac ID instead of random address.

Thanks,
Raju


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 6
[ZEP-1620] Concise Binary Object Representation (CBOR)
https://jira.zephyrproject.org/browse/ZEP-1620

[ZEP-1621] Stack Monitoring
https://jira.zephyrproject.org/browse/ZEP-1621

[ZEP-1619] Default value of NET_NBUF_RX_COUNT is too low, causes lock up on startup
https://jira.zephyrproject.org/browse/ZEP-1619

[ZEP-1623] (Parts) of Networking docs still refer to 1.5 world model (with fibers and tasks) and otherwise not up to date
https://jira.zephyrproject.org/browse/ZEP-1623

[ZEP-1618] Error in device initialization discarded
https://jira.zephyrproject.org/browse/ZEP-1618

[ZEP-1622] I2C problem Zephyr OS sensor example on NRF51 and F401re
https://jira.zephyrproject.org/browse/ZEP-1622


UPDATED JIRA items within last 24 hours: 12
[ZEP-1466] Memory Protection Unit Support
https://jira.zephyrproject.org/browse/ZEP-1466

[ZEP-1597] no good way to include library code outside of $(PROJECT_BASE)
https://jira.zephyrproject.org/browse/ZEP-1597

[ZEP-1461] Add zephyr support to openocd upstream
https://jira.zephyrproject.org/browse/ZEP-1461

[ZEP-948] Revisit the timeslicing algorithm
https://jira.zephyrproject.org/browse/ZEP-948

[ZEP-1538] Convert documentation of zoap samples to RST
https://jira.zephyrproject.org/browse/ZEP-1538

[ZEP-1601] Console over Telnet
https://jira.zephyrproject.org/browse/ZEP-1601

[ZEP-1463] Add Zephyr Support in segger SystemView
https://jira.zephyrproject.org/browse/ZEP-1463

[ZEP-1599] printk() support for the '-' indicator in format string (left justifier)
https://jira.zephyrproject.org/browse/ZEP-1599

[ZEP-1563] move board documenation for NRF51/NRF52 back to git tree
https://jira.zephyrproject.org/browse/ZEP-1563

[ZEP-1028] shrink k_block struct size
https://jira.zephyrproject.org/browse/ZEP-1028

[ZEP-1495] Networking API details documentation is missing
https://jira.zephyrproject.org/browse/ZEP-1495

[ZEP-1592] echo-server does not build with newlib
https://jira.zephyrproject.org/browse/ZEP-1592


CLOSED JIRA items within last 24 hours: 1
[ZEP-1147] (Won't Do) tests/bluetooth/: remove build_only so it can be run in HW
https://jira.zephyrproject.org/browse/ZEP-1147


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10314 : tests/gpio: fix test GPIO_INT_LEVEL bug
- https://gerrit.zephyrproject.org/r/10317 : tests: kernel: mbox_api: fix uninit variable and unchecked value
- https://gerrit.zephyrproject.org/r/10316 : tests: kernel: mpool: fix assert side effect
- https://gerrit.zephyrproject.org/r/10315 : tests: kernel: mpool: fix unchecked return value
- https://gerrit.zephyrproject.org/r/10313 : doc: nios2 altera max 10 board documentation
- https://gerrit.zephyrproject.org/r/10312 : docs: add Arduino 101 board documentation
- https://gerrit.zephyrproject.org/r/10311 : tests: kernel: threads_customdata: increase STACK_SIZE to 512 for riscv32
- https://gerrit.zephyrproject.org/r/10310 : tests: kernel: test_mpool_concept: increase STACK_SIZE to 1024 for riscv32

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10211 : samples: net: Add IRC bot example
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: add PINMUX config for D2000 board
- https://gerrit.zephyrproject.org/r/10140 : tests/gpio: enable gpio cases to run on more platforms
- https://gerrit.zephyrproject.org/r/10304 : Bluetooth: Move Bluetooth docs to rst
- https://gerrit.zephyrproject.org/r/10281 : samples: net: add configs for MCR20A

MERGED within last 24 hours:


Re: Networking-with-Qemu wiki page updated

Paul Sokolovsky
 

Hello Anas,

On Fri, 20 Jan 2017 09:24:52 -0500
Anas Nashif <nashif(a)gmail.com> wrote:

Paul,

Thank you for the update.

Maybe it makes sense to move this to the source tree and have it as
part of the documentation alongside the samples. This way the
information for older versions will always be available. There will
always be users of released versions.
Given that it appears to be the current approach (move docs from wiki
to git), I guess it makes sense to do that eventually. I'm just not
sure when, or that it all should be done at once (moving board docs
to git might be enough for 1.7). In either case, there're more
important things to do for Networking docs for now, e.g.
https://jira.zephyrproject.org/browse/ZEP-1623 ,
https://jira.zephyrproject.org/browse/ZEP-1495 .


Anas

On Fri, Jan 20, 2017 at 8:46 AM, Paul Sokolovsky
<paul.sokolovsky(a)linaro.org
wrote:
Hello,

This is just a background notice that the page
https://wiki.zephyrproject.org/view/Networking-with-Qemu , which
previously contained information for 1.6 and earlier, was updated
for the master branch status (i.e. 1.7-pre). This page is also
linked from the official docs at
https://www.zephyrproject.org/doc/samples/net/qemu_setup.html , so
is a kind of motion towards updating the docs for 1.7.

The page itself tries to provide a bit more detailed walkthru on
setting up IP networking test environment using QEMU, than the
reference Zephyr docs, and provide more hints/caveats, to make the
process easy even for Zephyr newcomers.

I also post about it at this time with the outlook that Zephyr moves
towards 1.7 freeze, and it would be really great if in 1.7 we
finally had the robustly working native IP stack. So, everyone
interested is welcome to test it using the instructions above and
update status/submit new issues at:
https://jira.zephyrproject.org/issues/?jql=project+%3D+
ZEP+AND+component+%3D+%22Networking+%2F+IP+Stack%22

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

5701 - 5720 of 8043