Date   

[RFC]DMA API Update

Liu, Baohong
 

Hi everyone,

Based on the feedbacks, I updated the RFC.

Data Structure Definitions
-------

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

/**
* @brief DMA channel 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 ...
* complete_int_en [ 10 ] --completion interrupt enable
* block_int_en [ 11 ] --block completion interrupt enable
* source_int_en [ 12 ] --source completion interrupt enable
* dest_int_en [ 13 ] --destination completion interrupt enable
* error_int_en [ 14 ] --error interrupt enable
* source_handshake [ 15 ] --HW or SW
* dest_handshake [ 16 ] --HW or SW
* channel_priority [ 17 : 20 ] --DMA channel priority
* source_chaining_en [ 21 ] --enable/disable source block chaining
* dest_chaining_en [ 22 ] --enable/disable destination block chaining
* RESERVED [ 23 : 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_channel_config {
uint32_t config;
uint32_t config_size;
uint32_t block_count;
struct dma_block_config *block_head;
void (*dma_callback)(struct device *dev, uint32_t channel, int error_code);
}

Remove struct dma_transfer_config

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_channel_config(struct device *dev, uint32_t channel,
struct dma_channel_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_transfer_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_transfer_stop(struct device *dev, uint32_t channel)
{
}

Remove API interface dma_transfer_config().

Suggestions and comments are welcome.

-----Original Message-----
From: Liu, Baohong
Sent: Wednesday, January 11, 2017 11:50 AM
To: devel(a)lists.zephyrproject.org
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
--------

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.


Re: reg: Routing SPI signals connected from x86 core to the Arc core

Liu, Baohong
 

there is any patch available for zephyr 1.6 , which I can install and use  ARC to directly access GPIO including AON_GPIO and SPI ?
https://gerrit.zephyrproject.org/r/#/c/8708/
You already have ARC GPIO access.

Thanks
Baohong


From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Monday, January 16, 2017 11:49 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Cc: Estrada, Giovani <giovani.estrada(a)intel.com>
Subject: [devel] Re: reg: Routing SPI signals connected from x86 core to the Arc core

there is any patch available for zephyr 1.6 , which I can install and use  ARC to directly access GPIO including AON_GPIO and SPI ?
https://gerrit.zephyrproject.org/r/#/c/8708/

Thanks
Baohong


Zephyr SDK 0.9 pre-release

Nashif, Anas
 

Hi,

We are about to release Zephyr SDK 0.9 and need some more testing and feedback, the installer can be found here:

https://jenkins.zephyrproject.org/job/meta-zephyr-sdk-merge/68/artifact/meta-zephyr-sdk/scripts/zephyr-sdk-0.9-setup.run


Once installed, it should work with the latest master without any modifications. If you find any issues please reply to this thread or file a bug in Jira.

Thanks,

Anas




Here are a the *draft* release notes showing the contents of the new SDK:


Release Notes Zephyr SDK 0.9
============================

SDK 0.9 Contents
================
ARC toolchain:
gcc version 6.2.1 20160824 (ARCompact/ARCv2 ISA elf32 toolchain 11f277e211411c21808cbb9f6cf165902edefea3)
GNU ld (GNU Binutils) 2.26.51.20160308
GNU gdb (GDB) 7.12.0.20161010-git
newlib: 2.4.0 (patched, multilib)

ARM toolchain:
gcc version 6.2.0 (GCC)
GNU ld (GNU Binutils) 2.27.0.20160806
GNU gdb (GDB) 7.11.0.20160511-git
newlib: 2.4.0 (patched, multiconfig)

x86 toolchain:
gcc version 6.2.0 (GCC)
GNU ld (GNU Binutils) 2.27.0.20160806
GNU gdb (GDB) 7.11.0.20160511-git
newlib: 2.4.0 (patched, multiconfig)

IAMCU toolchain:
gcc version 6.2.0 (GCC)
GNU ld (GNU Binutils) 2.27.0.20160806
GNU gdb (GDB) 7.11.0.20160511-git (patched)
newlib: 2.4.0 (patched)

NIOS2 toolchain:
gcc version 6.2.0 (GCC)
GNU ld (GNU Binutils) 2.27.0.20160806
GNU gdb (GDB) 7.11.0.20160511-git
newlib: 2.4.0 (patched, multilib)

XTENSA toolchain:
gcc version 6.2.0 (GCC) (patched for little endian)
GNU ld (GNU Binutils) 2.27.0.20160806
GNU gdb (GDB) 7.11.0.20160511-git
newlib: 2.2.0 (patched for little endian)

RISC-V toolchain:
gcc version 6.1.0 (GCC)
GNU ld (GNU Binutils) 2.27.51 (patched)
GNU gdb (GDB) 7.12.50.20161011-git
newlib: 2.2.0 (patched)


DTC (Device Tree Compiler) DTC 1.4.1-dirty

python2.7 : Python 2.7.12 (default, Dec 5 2016, 09:31:54)
python3 : Python 3.5.2 (default, Dec 5 2016, 09:31:25)

BOSSA tools (bossac, bossash)
Basic Open Source SAM-BA Application (BOSSA) Version 1.6.1-arduino

Python PLY module (for python2.7 and python3.4)

QEMU emulators:
qemu-system-arm (zephyr specific patch)
qemu-system-i386
qemu-system-mips
qemu-system-xtensa
qemu-system-nios2 (zephyr specific patch)
QEMU emulator version 2.6.0,

qemu-system-riscv32:
QEMU emulator version 2.7.50 (-dirty)

openocd 0.9 (Open On-Chip Debugger with additional Quark SE support)

Firmware tools: rimage, rmbox


SDK 0.9 Major Changes from SDK 0.8.2
====================================
The SDK 0.9 is built using Yocto distribution "morty".
The whole SDK is now 64 bit, as opposed to 32 bit previously.

Updated toolchains:
Renamed vendor ("poky" -> "zephyr")
Updated binutils:
ARM, x86, IAMCU, Nios2: 2.25 -> 2.27
Updated compilers:
ARC : 4.8.5 -> 6.2.1
ARM, x86, IAMCU, Nios2: 5.x -> 6.x
Updated GDB
ARC: 7.5.1 -> 7.12.0
ARM, x86, IAMCU, Nios2: 7.9.1 -> 7.11.0

Updated QEMUs (2.1.3 -> 2.6.0)

Updated OpenOCD: patched 0.9 with ARC specific code based on arc-2016.09-rc1

Updated newlib:
gettimeofday prototype fix:
support for nano-formattted-io

GDB: enable gdb/mi

Added Xtensa toolchain
Added RISC-V toolchain
Added DTC
Added firmware tools: rimage, rmbox

Removed host tools: compiler, make, binutils
Removed MIPS toolchain
Removed OpenOCD-legacy

JIRA issues addressed in SDK 0.9:
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-479
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-644
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-678
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-692
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-710
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-736
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-974
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-1118
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-1129
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-1162
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-1143
https://jira.zephyrproject.org/projects/ZEP/issues/ZEP-1435


Re: git describe of v1.5.0-3830-gecd209f

Paul Sokolovsky
 

Hello Anas,

On Tue, 17 Jan 2017 16:34:15 +0000
"Nashif, Anas" <anas.nashif(a)intel.com> wrote:

Current "git describe" for the master gives "v1.5.0-3830-gecd209f".
This is a little bit unfortunate, especially that soon after 1.6.0
it was like "v1.6.0-27-gb6fb798". I assume there were good thinking
on switching from "tag major releases in the master" to "tag any
release in a branch", so this is just a late notice of when it may
matter.
[]


The 1.6 tag was created on the branch. Starting with 1.6 we create a
branch during the stabilisation period and continue development on
master or the next release. This is the current model also described
on the wiki.
I see, apparently, we used a local release branch based on
v1.6.0-branch, that's why I saw "v1.6.0-27-gb6fb798" previously.

I know git describe won’t work with this model, we need to find an
alternative way. Probably when we change the version to 1.x.99, we
could tag master so we can get something like: v1.6.99-1772-g003a46a
Yes, that would be nice. I'm just afraid that makes the release process
more and more complicated, but I guess as Zephyr grows, it would become
such anyway.

Anas
Thanks for the reply!

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


Re: How to generate .hex image

Boie, Andrew P
 

At the moment, you can add these two lines to your soc or arch-level Makefile to get ihex files generated.
A better enhancement would be to control this with Kconfig.

zephyr: $(KERNEL_HEX_NAME)
all: $(KERNEL_HEX_NAME)

From: Tidy(ChunHua) Jiang [mailto:tidyjiang(a)163.com]
Sent: Sunday, January 15, 2017 6:40 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] How to generate .hex image

Hello,

When building, some BOARDs will generate both .bin and .hex, but others only .bin.
Is there a build switch to control this ?

My current stupid method is that, enter the directory where zephyr.elf is located, and then type:
/opt/zephyr-sdk/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-eabi/arm-poky-eabi-objcopy -S -O ihex -R .note -R .comment -R COMMON -R .eh_frame zephyr.elf zephyr.hex

Thanks.


Re: git describe of v1.5.0-3830-gecd209f

Nashif, Anas
 

On 17 Jan 2017, at 07:53, Paul Sokolovsky <paul.sokolovsky(a)linaro.org> wrote:

Hello,

Current "git describe" for the master gives "v1.5.0-3830-gecd209f". This
is a little bit unfortunate, especially that soon after 1.6.0 it was
like "v1.6.0-27-gb6fb798". I assume there were good thinking on
switching from "tag major releases in the master" to "tag any release
in a branch", so this is just a late notice of when it may matter.

(And indeed, git describe is not the most important command, I myself
never use it, until e.g. there's a need to suffix loads of binaries
from CI and similar, to make it better distinguishable by humans;
v1.6.0-27-gb6fb798 looks much better than v1.5.0-3830-gecd209f in this
respect).

The 1.6 tag was created on the branch. Starting with 1.6 we create a branch during the stabilisation period and continue development on master or the next release. This is the current model also described on the wiki.

I know git describe won’t work with this model, we need to find an alternative way. Probably when we change the version to 1.x.99, we could tag master so we can get something like: v1.6.99-1772-g003a46a


Anas



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


RFC: ieee802154 radio api

Johann Fischer
 

Dear developers,

during the implementation of the MCR20A driver I missed some functions
of the ieee802154 radio API, which I known by linux kernel and RIOT-OS.

I do not know if a todo already exist, I have not found any, so I try to
summarize it:

The transceivers can have different capabilities (csma, autoack ...).
During the initialization of the driver, the appropriate flags should be
set by the driver. During the initializing of the subsystem, the flags
must be checked and enabled according to the desired behavior.

For example, if the hardware can automatically perform CCA before the TX
sequence (IEEE802154_HW_LBT is set), the linklayer does not have to call
the API function int (*cca)(struct device *dev);

The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
- IEEE802154_HW_TX_OMIT_CKSUM
- IEEE802154_HW_LBT (listen before transmit or CCA before TX)
- IEEE802154_HW_CSMA_PARAMS
- IEEE802154_HW_FRAME_RETRIES
- IEEE802154_HW_AFILT
- IEEE802154_HW_PROMISCUOUS
- IEEE802154_HW_RX_OMIT_CKSUM
- IEEE802154_HW_RX_DROP_BAD_CKSUM

In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)
- IEEE802154_HW_RX_ACKREQ (RX ACK frame is expected after TX)
- IEEE802154_RF_TESTMODE (disabled by default, Modes: RX, CW, PRBS9 ...)
- bit field for supported channels ?
Other suggestions and comments are welcome.

What would be the appropriate place for the flags variable, Network
Interface structure?

Then the ieee802154_radio_api could then be extended by the following
operations:
...
int (*set_lbt)(struct device *dev, bool on),

int (*set_csma_params)(struct device *dev, ...),

int (*set_cca_mode)(struct device *dev, ...),

int (*set_cca_threshold)(struct device *dev, int32_t level),

int (*set_promiscuous_mode)(struct device *dev, bool on),

int (*set_frame_retries)(struct device *dev, bool on),

int (*set_hw_addr_filt)(struct device *dev, ...),

int (*set_auto_ack)(struct device *dev, ...),

int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
...

Is it ok to use the same identifiers as Linux kernel?

--
Best Regards,
Johann Fischer


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 2
[ZEP-1429] NXP MCR20A Driver
https://jira.zephyrproject.org/browse/ZEP-1429

[ZEP-1498] commit-message.py script is too strict that blocks merge commits
https://jira.zephyrproject.org/browse/ZEP-1498


CLOSED JIRA items within last 24 hours: 1
[ZEP-1574] (Fixed) Samples/net/dhcpv4_client: Build fail as undefined reference to `net_mgmt_add_event_callback'
https://jira.zephyrproject.org/browse/ZEP-1574


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10107 : kernel: including legacy.h depends on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10114 : sensor: remove unused legacy macros
- https://gerrit.zephyrproject.org/r/10112 : tests: footprint: set ARCH correctly and provide defaults
- https://gerrit.zephyrproject.org/r/10113 : samples: legacy: enable legacy kernel
- https://gerrit.zephyrproject.org/r/10108 : kernel: use __ticks_to_ms directly
- https://gerrit.zephyrproject.org/r/10097 : legacy: Move TICKS_UNLIMITED -> K_FOREVER
- https://gerrit.zephyrproject.org/r/10096 : legacy: use k_cycle_get_32 instead of legacy sys_cycle_get_32
- https://gerrit.zephyrproject.org/r/10099 : tests: do not use RC_OK, use 0 instead
- https://gerrit.zephyrproject.org/r/10100 : kernel: build legacy timer only conditionally
- https://gerrit.zephyrproject.org/r/10103 : kernel: include limits.h for UINT_MAX
- https://gerrit.zephyrproject.org/r/10098 : net: zoap_client: fix usage of legacy APIs
- https://gerrit.zephyrproject.org/r/10102 : kernel: mailbox: legacy calls depend on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10101 : kernel: make legacy calls depends on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10111 : Bluetooth: L2CAP: Fix always using RX_BUF_COUNT as initial credits
- https://gerrit.zephyrproject.org/r/10110 : Bluetooth: L2CAP: Make sure state is correctly updated
- https://gerrit.zephyrproject.org/r/10109 : Bluetooth: IPSP: Reuse buffer fragments instead of copying
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/10104 : Bluetooth: hci_core: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10105 : samples: net: Fix DHCPv4 config options and run on its own thread
- https://gerrit.zephyrproject.org/r/10088 : riscv32: fix KConfig selection of ATOMIC_OPERATIONS_C
- https://gerrit.zephyrproject.org/r/10095 : Bluetooth: Add __printf_like annotation for bt_log
- https://gerrit.zephyrproject.org/r/10094 : Bluetooth: Take advantage of IS_ENABLED macro for BT_DBG
- https://gerrit.zephyrproject.org/r/10093 : net/samples: HTTP server sample application
- https://gerrit.zephyrproject.org/r/10091 : net/mqtt: Add the testcase.ini file to the MQTT Publisher sample app

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/10077 : net: buf: fix user_data_size initialization.
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/8961 : drivers: QMSI AON counter: Simplify driver reentrancy code
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: add PINMUX config for D2000 board
- https://gerrit.zephyrproject.org/r/9325 : gpio/stm32: provide GPIO driver implementation for STM32F3X family
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/9710 : Bluetooth: SDP: Add SDP client interface to BTshell app
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/9868 : uart/stm32: add STM32F3X support for uart
- https://gerrit.zephyrproject.org/r/9699 : pinmux/stm32: default pin assignment for STM3210C-EVAL board
- https://gerrit.zephyrproject.org/r/9701 : pinmux/stm32: default pin assignment for STM32373C-EVAL board
- https://gerrit.zephyrproject.org/r/9700 : pinmux/stm32: default pin assignment for NUCLEO-F334R8 board
- https://gerrit.zephyrproject.org/r/9464 : tests: kernel: added memory pool threadsafe test
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/10075 : net/mqtt: Add the MQTT Publisher sample application
- https://gerrit.zephyrproject.org/r/10074 : net/mqtt: Add the "malformed" callback to the MQTT ctx structure
- https://gerrit.zephyrproject.org/r/10072 : net/mqtt: Move upwards buffer size validation
- https://gerrit.zephyrproject.org/r/10073 : net/mqtt: Simplify the MQTT high-level API
- https://gerrit.zephyrproject.org/r/9859 : Bluetooth: Kconfig: Specify stack size for Bluetooth SPI
- https://gerrit.zephyrproject.org/r/9858 : Bluetooth: samples/beacon: Print message at start of sample
- https://gerrit.zephyrproject.org/r/9857 : Bluetooth: Add HCI SPI driver
- https://gerrit.zephyrproject.org/r/9905 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9904 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9951 : net: tcp: don't assume TCP_FIN buffers are NET_DROP
- https://gerrit.zephyrproject.org/r/9952 : net: tcp: if buffer is TCP_FIN increment send_ack by 1
- https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission
- https://gerrit.zephyrproject.org/r/9894 : net: ipv6: fix link address handling in handle_ns_neighbor
- https://gerrit.zephyrproject.org/r/4457 : DONT: MERGE - cause checkpatch warnings
- https://gerrit.zephyrproject.org/r/9979 : kernel: sysclock: Add an API to get tick delta
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10090 : verify: cat raw logs before filter
- https://gerrit.zephyrproject.org/r/10086 : Bluetooth: L2CAP: Remove RECV_RESERVE from BT_L2CAP_RX_MTU
- https://gerrit.zephyrproject.org/r/10085 : Bluetooth: Remove ACL details from BT_BUF_RX_SIZE
- https://gerrit.zephyrproject.org/r/9990 : kernel: correct the highest priority in coop-only modes
- https://gerrit.zephyrproject.org/r/9991 : kernel: use PREEMPT_ENABLED instead of NUM_PREEMPT_PRIORITIES > 0
- https://gerrit.zephyrproject.org/r/10053 : ztest: enable coop/preempt configurations
- https://gerrit.zephyrproject.org/r/9992 : kernel: fix main/work_q prios in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9993 : kernel/mutex: prevent priority inheritance from lowering owner's prio
- https://gerrit.zephyrproject.org/r/9994 : kernel: fix total number of coop prios in coop-only mode
- https://gerrit.zephyrproject.org/r/9995 : samples/philosophers: enable demo to run in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/10083 : tests/context: fix Coverity warning about array overrun
- https://gerrit.zephyrproject.org/r/10057 : samples/net: Improve text indentation and clarify some instructions
- https://gerrit.zephyrproject.org/r/10058 : doc: update doc building README instructions
- https://gerrit.zephyrproject.org/r/9996 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/9998 : boards: add qemu_x86 board documentation
- https://gerrit.zephyrproject.org/r/9999 : boards: add qemu_cortex_m3 board documentation
- https://gerrit.zephyrproject.org/r/10001 : boards: add arduino_due board documentation
- https://gerrit.zephyrproject.org/r/10002 : boards: categorize boards by architecture
- https://gerrit.zephyrproject.org/r/10003 : boards: add em_starterkit board documentation
- https://gerrit.zephyrproject.org/r/10004 : samples: doc: remove 'make pristine', it is not needed
- https://gerrit.zephyrproject.org/r/10050 : boards: quark_d2000_crb: add board image to documentation
- https://gerrit.zephyrproject.org/r/10000 : doc: application porting guide to the unified kernel
- https://gerrit.zephyrproject.org/r/10051 : doc: add a doxygen group for the Kernel API
- https://gerrit.zephyrproject.org/r/10067 : doc: make build process quiet
- https://gerrit.zephyrproject.org/r/10052 : kernel: doc: Add deprecation notice to legacy.h
- https://gerrit.zephyrproject.org/r/10082 : net: doc: add section about networking with qemu
- https://gerrit.zephyrproject.org/r/9997 : samples: dtls: Fixed layout and titles in documentation
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback


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

Luiz Augusto von Dentz
 

Hi,

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

Thanks for the patch. I have update the same and build for zoap_server.

LE SCAN output:
LE Scan ...
CA:2E:39:48:00:77 (unknown)
CA:2E:39:48:00:77 Test IPSP node

This is the debug output on UART:
[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [INF] show_dev_info: Identity: ca:2e:39:48:00:77 (random)
[bt] [INF] show_dev_info: HCI: version 4.2 (0x08) revision 0x0000, manufacturer 0xffff
[bt] [INF] show_dev_info: LMP: version 4.2 (0x08) subver 0xffff
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20005020) CID 0x0004
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20005020) CID 0x0006
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[bt] [DBG] bt_l2cap_le_fixed_chan_register: (0x20005020) CID 0x0005

Then I am trying to connect to this server using following command. But it .is not connecting. What could be the reason?

echo "connect ca:2e:39:48:00:77 1" | tee /sys/kernel/debug/bluetooth/6lowpan_control
Well it seems the address is random: ca:2e:39:48:00:77 (random),
should you should pass 2 instead of 1 after the address.

--
Luiz Augusto von Dentz


git describe of v1.5.0-3830-gecd209f

Paul Sokolovsky
 

Hello,

Current "git describe" for the master gives "v1.5.0-3830-gecd209f". This
is a little bit unfortunate, especially that soon after 1.6.0 it was
like "v1.6.0-27-gb6fb798". I assume there were good thinking on
switching from "tag major releases in the master" to "tag any release
in a branch", so this is just a late notice of when it may matter.

(And indeed, git describe is not the most important command, I myself
never use it, until e.g. there's a need to suffix loads of binaries
from CI and similar, to make it better distinguishable by humans;
v1.6.0-27-gb6fb798 looks much better than v1.5.0-3830-gecd209f in this
respect).


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


Re: [RFC] STM32 pinmux - simplify pinmux logic

Erwan Gouriou
 

Hi Christer,


I agree with the observation that gpio/pinmux configuration is
overcomplicated.
Your proposal is interesting and look rather easy to use.
Maybe you can also have a look to Adam's porting of STM32F3x family, in
which
he's trying to by pass pin configuration this in another way:
https://gerrit.zephyrproject.org/r/#/c/9701
I'd be glad to get your feedback

Btw, I think that you could submit your RFC as a patch in Gerrit, so we can
better appreciate the differences and comment easily.

Best
Erwan

On 15 January 2017 at 20:02, Christer Weinigel <christer(a)weinigel.se> wrote:

Hi all,

BTW, for RFC patches like this that break the build, should
I submit them to Gerrit instead or do you prefer to see them
on the list?

I've just managed to port Zephyr to my STM32F405 based board.
One thing that I stumbled on and took me a few hours to figure
out is that I'm using UART2 on PD5/PD6 as my serial port and
for some reason I did not get any UART output. It turns out
that in addition to adding a few lines to pinmux_stm32f4.h
defining the UART2 alternate functions on PD5/PD6 I also had
to add mappings for PD5/PD6 to soc_pinmux.c. Without the
second change everything compiles nicely but the alternate
functions won't be activated anyway.

After thinking about this a bit I feel that the indirection
through stm32_get_pin_config in soc_pinmux.c is a bit, well,
overcomplicated. It also limits what I can do from my board
file, what if I acutally want to have a UART where RX is
pulled down (I want to see continuous breaks if nothing is
connected to the port)? Right now I can't do that without
modifying the Zephyr core.

Can't we just simplify this so that we encode the conf part
directly in the table? This allows us to remove all the
code in soc_pinmux.c and this way it's kind of obvious that
if you add a line in pinmux_stm32f4.h you have to specify
both the conf part and the altf part.

This is only a RFC, the patch as is breaks the stm32f1 and
stm32l4 ports. I can fix those up if you think this way of
doing things is a good idea.

/Christer

---
arch/arm/soc/st_stm32/stm32f4/Makefile | 1 -
arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c | 112
-----------------------------
drivers/pinmux/stm32/pinmux_stm32.c | 9 +--
drivers/pinmux/stm32/pinmux_stm32f4.h | 24 ++++---
4 files changed, 20 insertions(+), 126 deletions(-)
delete mode 100644 arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c

diff --git a/arch/arm/soc/st_stm32/stm32f4/Makefile
b/arch/arm/soc/st_stm32/stm32f4/Makefile
index 6ae6e19..1ef7b4a 100644
--- a/arch/arm/soc/st_stm32/stm32f4/Makefile
+++ b/arch/arm/soc/st_stm32/stm32f4/Makefile
@@ -1,7 +1,6 @@
obj-y += soc.o

obj-$(CONFIG_GPIO) += soc_gpio.o
-obj-$(CONFIG_PINMUX) += soc_pinmux.o

zephyr: $(KERNEL_HEX_NAME)
all: $(KERNEL_HEX_NAME)
diff --git a/arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c
b/arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c
deleted file mode 100644
index ef79ef4..0000000
--- a/arch/arm/soc/st_stm32/stm32f4/soc_pinmux.c
+++ /dev/null
@@ -1,112 +0,0 @@
-/*
- * Copyright (c) 2016 Linaro Limited.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-#include <errno.h>
-
-#include "soc.h"
-#include <device.h>
-#include <misc/util.h>
-#include <pinmux/stm32/pinmux_stm32.h>
-#include <drivers/clock_control/stm32_clock_control.h>
-
-static const stm32_pin_func_t pin_pa9_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA9_USART1_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa10_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA10_USART1_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pb6_funcs[] = {
- [STM32F4_PINMUX_FUNC_PB6_USART1_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pb7_funcs[] = {
- [STM32F4_PINMUX_FUNC_PB7_USART1_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa2_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA2_USART2_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa3_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA3_USART2_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pa0_funcs[] = {
- [STM32F4_PINMUX_FUNC_PA0_PWM2_CH1 - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pd5_funcs[] = {
- [STM32F4_PINMUX_FUNC_PD5_USART2_TX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-static const stm32_pin_func_t pin_pd6_funcs[] = {
- [STM32F4_PINMUX_FUNC_PD6_USART2_RX - 1] =
- STM32F4X_PIN_CONFIG_AF_PUSH_UP,
-};
-
-/**
- * @brief pin configuration
- */
-static const struct stm32_pinmux_conf pins[] = {
- STM32_PIN_CONF(STM32_PIN_PA9, pin_pa9_funcs),
- STM32_PIN_CONF(STM32_PIN_PA10, pin_pa10_funcs),
- STM32_PIN_CONF(STM32_PIN_PB6, pin_pb6_funcs),
- STM32_PIN_CONF(STM32_PIN_PB7, pin_pb7_funcs),
- STM32_PIN_CONF(STM32_PIN_PA2, pin_pa2_funcs),
- STM32_PIN_CONF(STM32_PIN_PA3, pin_pa3_funcs),
- STM32_PIN_CONF(STM32_PIN_PA0, pin_pa0_funcs),
- STM32_PIN_CONF(STM32_PIN_PD5, pin_pa2_funcs),
- STM32_PIN_CONF(STM32_PIN_PD6, pin_pa3_funcs),
-};
-
-int stm32_get_pin_config(int pin, int func)
-{
- /* GPIO function is always available, to save space it is not
- * listed in alternate functions array
- */
- if (func == STM32_PINMUX_FUNC_GPIO) {
- return STM32F4X_PIN_CONFIG_BIAS_HIGH_IMPEDANCE;
- }
-
- /* analog function is another 'known' setting */
- if (func == STM32_PINMUX_FUNC_ANALOG) {
- return STM32F4X_PIN_CONFIG_ANALOG;
- }
-
- func -= 1;
-
- for (int i = 0; i < ARRAY_SIZE(pins); i++) {
- if (pins[i].pin == pin) {
- if (func > pins[i].nfuncs) {
- return -EINVAL;
- }
-
- return pins[i].funcs[func];
- }
- }
-
- return -EINVAL;
-}
diff --git a/drivers/pinmux/stm32/pinmux_stm32.c
b/drivers/pinmux/stm32/pinmux_stm32.c
index dfc13b4..9a9d94a 100644
--- a/drivers/pinmux/stm32/pinmux_stm32.c
+++ b/drivers/pinmux/stm32/pinmux_stm32.c
@@ -102,17 +102,18 @@ static int stm32_pin_configure(int pin, int func,
int altf)
int _pinmux_stm32_set(uint32_t pin, uint32_t func,
struct device *clk)
{
- int config;
+ int conf;
+ int altf;

/* make sure to enable port clock first */
if (enable_port(STM32_PORT(pin), clk)) {
return -EIO;
}

- /* determine config for alternate function */
- config = stm32_get_pin_config(pin, func);
+ conf = STM32F4_PINMUX_CONF(func);
+ altf = STM32F4_PINMUX_ALTF(func);

- return stm32_pin_configure(pin, config, func);
+ return stm32_pin_configure(pin, conf, altf);
}

/**
diff --git a/drivers/pinmux/stm32/pinmux_stm32f4.h
b/drivers/pinmux/stm32/pinmux_stm32f4.h
index 8ec7f25..79c97d6 100644
--- a/drivers/pinmux/stm32/pinmux_stm32f4.h
+++ b/drivers/pinmux/stm32/pinmux_stm32f4.h
@@ -21,18 +21,24 @@
* @file Header for STM32F4 pin multiplexing helper
*/

-#define STM32F4_PINMUX_FUNC_PA9_USART1_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PA10_USART1_RX STM32_PINMUX_FUNC_ALT_7
+#include "soc.h"

-#define STM32F4_PINMUX_FUNC_PB6_USART1_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PB7_USART1_RX STM32_PINMUX_FUNC_ALT_7
+#define STM32F4_PINMUX_ENCODE(conf, altf) (((conf)<<8) | (altf))
+#define STM32F4_PINMUX_CONF(func) ((func) >> 8)
+#define STM32F4_PINMUX_ALTF(func) ((func) & 0xff)

-#define STM32F4_PINMUX_FUNC_PA2_USART2_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PA3_USART2_RX STM32_PINMUX_FUNC_ALT_7
+#define STM32F4_PINMUX_FUNC_PA9_USART1_TX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PA10_USART1_RX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7

-#define STM32F4_PINMUX_FUNC_PD5_USART2_TX STM32_PINMUX_FUNC_ALT_7
-#define STM32F4_PINMUX_FUNC_PD6_USART2_RX STM32_PINMUX_FUNC_ALT_7
+#define STM32F4_PINMUX_FUNC_PB6_USART1_TX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PB7_USART1_RX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)

-#define STM32F4_PINMUX_FUNC_PA0_PWM2_CH1 STM32_PINMUX_FUNC_ALT_1
+#define STM32F4_PINMUX_FUNC_PA2_USART2_TX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PA3_USART2_RX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+
+#define STM32F4_PINMUX_FUNC_PD5_USART2_TX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+#define STM32F4_PINMUX_FUNC_PD6_USART2_RX STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_7)
+
+#define STM32F4_PINMUX_FUNC_PA0_PWM2_CH1 STM32F4_PINMUX_ENCODE(
STM32F4X_PIN_CONFIG_AF_PUSH_UP, STM32_PINMUX_FUNC_ALT_1)

#endif /* _STM32F4_PINMUX_H_ */
--
1.9.1


Re: Trying Nucleo-64 STM32F411RE

Erwan Gouriou
 

Hi Jack


If you want to develop driver based on STM32Cube HAL, you could check
serial or pwm drivers as example.
You can also find other examples of using HAL in Cube SDK that you could
download from st website:
For instance, for STM32F4 family:
http://www.st.com/en/embedded-software/stm32cubef4.html ("get software" at
the very bottom of the page)
You'll find a Examples sections in the provided code.
If you need specific support on using the HAL, you'll find support in ST
community website:
https://community.st.com/

Finally, use of hal should not be a blocker, you could implement native
driver if you feel more comfortable.

Good luck
Erwan

On 16 January 2017 at 17:33, jack ma <assangema(a)gmail.com> wrote:

if someone can write some document for how to use hal drivers(eg,stm32
cube) to write drivers or give an example for that ?
I really want use Zephyr for new project, but not familiar with the
driver develop. after browse the code tree, I did not find a method, so
temporarily abandoned.

2017-01-16 17:42 GMT+08:00 Erwan Gouriou <erwan.gouriou(a)linaro.org>:

Hi Piotr,

You should indeed first look at Zephyr documentation, and particularly
i2c API.
Then, regarding STM32 driver/IP, there are several sources that could
help you to develop I2C driver for STM32F4xx family
(as your driver should benefit to other SoCs from the F4 family):
-Zephyr native implementation of stm32lx i2c driver:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=tre
e;f=drivers/i2c
-HAL implementation from STM32Cube SDK (that you could get here
http://www.st.com/en/embedded-software/stm32cubef4.html)
Inside SDK, you'll find i2c code examples using HAL
(Projects/xx/Examples/I2C/)
-stm32f411re Refence Manual for information about stm32f411re I2C (
http://www.st.com/en/microcontrollers/stm32f411re.html)

Then, you have two options:
-based on STM32Cube HAL, develop a generic STM32 driver that will benefit
to all STM32 based boards.
-develop a Zephyr "native" STM32F4 I2C API that will benefit to STM32F4
family devices (similar to stm32lx.c driver)

Either ways, note that you could use STM32Cube SDK
(ext/hal/st/stm32cube/stm32f4xx/soc/stm32f411xe.h) to benefit from
useful structures, macros and defines that provide abstraction capability
so you don't have to deal with subtle differences between
similar SoCs (such as stm32f401re and stm32f411re).

Good luck with your project
Erwan


On 14 January 2017 at 23:26, Piotr Król <piotr.krol(a)3mdeb.com> wrote:

On Mon, Jan 02, 2017 at 03:03:58PM +0100, Erwan Gouriou wrote:
Hi Piotr,
Hi Erwan,


There was an issue on F411RE clock initialisation steps.
I've submitted following change to correct it:
https://gerrit.zephyrproject.org/r/9571

Hope it helps.
This helps sample code works correctly. With that I can continue with my
target project, which is i2c driver for F411RE.

Can you point me to information how I should approach adding i2c driver
for this board ?

I assume first I should familiarize myself with Zephyr documentation and
contribution guidelines, but have you got any reference code for i2c
driver ?

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com


Re: reg: Routing SPI signals connected from x86 core to the Arc core

Liu, Baohong
 

there is any patch available for zephyr 1.6 , which I can install and use ARC to directly access GPIO including AON_GPIO and SPI ?
https://gerrit.zephyrproject.org/r/#/c/8708/

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, January 16, 2017 4:13 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Cc: Estrada, Giovani <giovani.estrada(a)intel.com>
Subject: RE: reg: Routing SPI signals connected from x86 core to the Arc core

Hi Liu

We have finalized zephyr 1.6 version for our project

there is any patch available for zephyr 1.6 , which I can install and use ARC to directly access GPIO including AON_GPIO and SPI ?

Please help and reply

Best regards
Mahendra


Re: Trying Nucleo-64 STM32F411RE

jack ma
 

if someone can write some document for how to use hal drivers(eg,stm32
cube) to write drivers or give an example for that ?
I really want use Zephyr for new project, but not familiar with the driver
develop. after browse the code tree, I did not find a method, so
temporarily abandoned.

2017-01-16 17:42 GMT+08:00 Erwan Gouriou <erwan.gouriou(a)linaro.org>:

Hi Piotr,

You should indeed first look at Zephyr documentation, and particularly i2c
API.
Then, regarding STM32 driver/IP, there are several sources that could help
you to develop I2C driver for STM32F4xx family
(as your driver should benefit to other SoCs from the F4 family):
-Zephyr native implementation of stm32lx i2c driver:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=
tree;f=drivers/i2c
-HAL implementation from STM32Cube SDK (that you could get here
http://www.st.com/en/embedded-software/stm32cubef4.html)
Inside SDK, you'll find i2c code examples using HAL
(Projects/xx/Examples/I2C/)
-stm32f411re Refence Manual for information about stm32f411re I2C (
http://www.st.com/en/microcontrollers/stm32f411re.html)

Then, you have two options:
-based on STM32Cube HAL, develop a generic STM32 driver that will benefit
to all STM32 based boards.
-develop a Zephyr "native" STM32F4 I2C API that will benefit to STM32F4
family devices (similar to stm32lx.c driver)

Either ways, note that you could use STM32Cube SDK (ext/hal/st/stm32cube/stm32f4xx/soc/stm32f411xe.h)
to benefit from
useful structures, macros and defines that provide abstraction capability
so you don't have to deal with subtle differences between
similar SoCs (such as stm32f401re and stm32f411re).

Good luck with your project
Erwan


On 14 January 2017 at 23:26, Piotr Król <piotr.krol(a)3mdeb.com> wrote:

On Mon, Jan 02, 2017 at 03:03:58PM +0100, Erwan Gouriou wrote:
Hi Piotr,
Hi Erwan,


There was an issue on F411RE clock initialisation steps.
I've submitted following change to correct it:
https://gerrit.zephyrproject.org/r/9571

Hope it helps.
This helps sample code works correctly. With that I can continue with my
target project, which is i2c driver for F411RE.

Can you point me to information how I should approach adding i2c driver
for this board ?

I assume first I should familiarize myself with Zephyr documentation and
contribution guidelines, but have you got any reference code for i2c
driver ?

Best Regards,
--
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-1582] How to create a Zephyr ROM library
https://jira.zephyrproject.org/browse/ZEP-1582

[ZEP-1581] [nRF52832] Blinky hangs after some minutes
https://jira.zephyrproject.org/browse/ZEP-1581


UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0


Re: [RFC]DMA API Update

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

On Sat, 2017-01-14 at 00:31 +0000, Liu, Baohong wrote:
Thanks for the feedback. See my reply inline.
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]

But finally, the big elephant in the room is: how are DMA APIs actually
expected to used? And how should the system be configured?
The same way as other device drivers. There will be a driver to implement
the APIs for each SoC. App does the config, and initiate the transfer by
calling the APIs.
As far as I can see there is no documentation or examples in Zephyr that
give a clue as to how DMA can be used with device drivers. So it's very
difficult to review a DMA API without some more explanation on it's
expected use.

Let me try some more specific questions...

Say I have a system which has:
A) a driver for a DMA Controller (it implement struct dma_driver_api) 
B) a driver for some interface, e.g. SPI
C) an app which wants to talk to a device attached to that interface
e.g. and LCD controller
D) other things

Which of the above will call

- dma_channel_config
- dma_transfer_config
- dma_transfer_start
- dma_transfer_stop

?

The SPI subsystem interface doesn't have anything DMA related in it, so
I can only assume that DMA use will have to be hidden inside the SPI
driver, and for each spi_transceive request made made of it will setup
and operate on an appropriate struct dma_transfer_config? (Or use
scatter-gather lists when API's get that ;-)

If so, every device driver in zephyr that anyone wants to use with DMA
will need to add DMA support to it and make it configurable to
(optionally) use the generic DMA API. Or is it expected that all APIs
like SPI grow new functions for use with DMA specifically?

That still leaves the question as to who calls dma_channel_config and
how the parameters for that get into the system. Is each driver that
implements DMA support going to have a bunch of KConfig entries to
dma_slot, hankshake_polarity etc? Or will the SoC have a bunch of
#defines (like we currently have for IRQ numbers) for setting these DMA
attributes (assuming they are fixed in hardware).

There's also the question as to how channel numbers are allocated. Is
this more per-driver KConfig options or should we have a DMA channel
allocator function so they can just be assigned at runtime?

I'm also thinking about the fact that there are likely to be more
devices capable of DMA than channels available so how about an API to
free a channel? E.g. dma_channel_config claims a channel for use and
dma_channel_free releases for someone else. That way even with static
allocation of channels we have the option of allocating the same channel
to two different devices if we know they can't be active at the same
time.

--
Tixy


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10083 : tests/context: fix Coverity warning about array overrun
- https://gerrit.zephyrproject.org/r/10067 : doc: make build process quiet
- https://gerrit.zephyrproject.org/r/10082 : net: doc: add section about networking with qemu
- https://gerrit.zephyrproject.org/r/10077 : net: buf: fix user_data_size initialization.
- https://gerrit.zephyrproject.org/r/10073 : net/mqtt: Simplify the MQTT high-level API
- https://gerrit.zephyrproject.org/r/10074 : net/mqtt: Add the "malformed" callback to the MQTT ctx structure
- https://gerrit.zephyrproject.org/r/10072 : net/mqtt: Move upwards buffer size validation
- https://gerrit.zephyrproject.org/r/10058 : doc: update doc building README instructions
- https://gerrit.zephyrproject.org/r/10057 : samples/net: Improve text indentation and clarify some instructions

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/10052 : kernel: doc: Add deprecation notice to legacy.h
- https://gerrit.zephyrproject.org/r/9805 : ext: mcux: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/10002 : boards: categorize boards by architecture
- https://gerrit.zephyrproject.org/r/10004 : samples: doc: remove 'make pristine', it is not needed
- https://gerrit.zephyrproject.org/r/9998 : boards: add qemu_x86 board documentation
- https://gerrit.zephyrproject.org/r/10003 : boards: add em_starterkit board documentation
- https://gerrit.zephyrproject.org/r/10001 : boards: add arduino_due board documentation
- https://gerrit.zephyrproject.org/r/10000 : doc: application porting guide to the unified kernel
- https://gerrit.zephyrproject.org/r/9997 : samples: dtls: Fixed layout and titles in documentation
- https://gerrit.zephyrproject.org/r/10051 : doc: add a doxygen group for the Kernel API
- https://gerrit.zephyrproject.org/r/9999 : boards: add qemu_cortex_m3 board documentation
- https://gerrit.zephyrproject.org/r/9996 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/10050 : boards: quark_d2000_crb: add board image to documentation
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9446 : Bluetooth: AVDTP: Added params to AVDTP Request structure
- https://gerrit.zephyrproject.org/r/9988 : samples: net: Increase spi log level
- https://gerrit.zephyrproject.org/r/9859 : Bluetooth: Kconfig: Specify stack size for Bluetooth SPI
- https://gerrit.zephyrproject.org/r/9857 : Bluetooth: Add HCI SPI driver
- https://gerrit.zephyrproject.org/r/9904 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9905 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9858 : Bluetooth: samples/beacon: Print message at start of sample
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/9660 : Bluetooth: Controller: Conditional compile roles
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission
- https://gerrit.zephyrproject.org/r/9573 : Bluetooth: Controller: conditional compile advertiser only
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/9894 : net: ipv6: fix link address handling in handle_ns_neighbor
- https://gerrit.zephyrproject.org/r/9663 : Bluetooth: AVDTP: Add AVDTP Receive Function
- https://gerrit.zephyrproject.org/r/9928 : net: tcp: Also signal EOF with a negative status code
- https://gerrit.zephyrproject.org/r/9977 : samples: net: "Mini HTTP" example & validator for TCP layer
- https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/4457 : DONT: MERGE - cause checkpatch warnings
- https://gerrit.zephyrproject.org/r/7664 : second: test
- https://gerrit.zephyrproject.org/r/5137 : DONT_MERGE: - add changes to two different branches
- https://gerrit.zephyrproject.org/r/5445 : DONT_MERGE: - break sanity
- https://gerrit.zephyrproject.org/r/3114 : DONT MERGE: - break doc
- https://gerrit.zephyrproject.org/r/9968 : ext: hal: qmsi: implement I2C Fast Plus Mode
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9713 : Bluetooth: SDP: Add API to get ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9715 : Bluetooth: SDP: Add API to get SupportedFeature attribute
- https://gerrit.zephyrproject.org/r/9716 : Bluetooth: SDP: Use SupportedFeature attr API in BTshell
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9710 : Bluetooth: SDP: Add SDP client interface to BTshell app
- https://gerrit.zephyrproject.org/r/9995 : samples/philosophers: enable demo to run in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9993 : kernel/mutex: prevent priority inheritance from lowering owner's prio
- https://gerrit.zephyrproject.org/r/9992 : kernel: fix main/work_q prios in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9994 : kernel: fix total number of coop prios in coop-only mode
- https://gerrit.zephyrproject.org/r/9991 : kernel: use PREEMPT_ENABLED instead of NUM_PREEMPT_PRIORITIES > 0
- https://gerrit.zephyrproject.org/r/9990 : kernel: correct the highest priority in coop-only modes
- https://gerrit.zephyrproject.org/r/10053 : ztest: enable coop/preempt configurations

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10080 : Bluetooth: L2CAP: Fix using CONFIG_BLUETOOTH_RX_BUF_LEN as MTU
- https://gerrit.zephyrproject.org/r/10056 : samples/net: Remove legacy configuation variables
- https://gerrit.zephyrproject.org/r/10078 : samples: thermometer: use convert to double function from sensor.h
- https://gerrit.zephyrproject.org/r/10081 : MAINTAINERS: fix email address typo in sensor drivers section
- https://gerrit.zephyrproject.org/r/10079 : Bluetooth: Add documentation for connection callbacks
- https://gerrit.zephyrproject.org/r/10048 : samples/net: Remove redundant configuration variable
- https://gerrit.zephyrproject.org/r/10049 : drivers/ethernet: Update default GPIO pin for the ENC28J60 module
- https://gerrit.zephyrproject.org/r/9895 : net: route: remove extra variable use in net_route_add()
- https://gerrit.zephyrproject.org/r/9893 : net: ipv6: fix NULL reference in handle_ra_neighbor
- https://gerrit.zephyrproject.org/r/9892 : net: linkaddr: introduce net_linkaddr_set function
- https://gerrit.zephyrproject.org/r/9940 : net: tcp: Destroy net_tcp struct at the same time as the context
- https://gerrit.zephyrproject.org/r/9935 : net: tcp: Pass correct user_data pointers
- https://gerrit.zephyrproject.org/r/9891 : net: linkaddr: calculate linkaddr storage addr size via config
- https://gerrit.zephyrproject.org/r/9953 : Bluetooth: RFCOMM: Implement Aggregate Flow Control
- https://gerrit.zephyrproject.org/r/9983 : bluetooth: hci_core: Fix conn params validity check


Re: Consistency in Kconfig organization, depends / select

Jukka Rissanen
 

Hi Marcus,

On Mon, 2017-01-16 at 10:46 +0000, Marcus Shawcroft wrote:
Hi!

I noticed this review fly by:

https://gerrit.zephyrproject.org/r/#/c/9982/

Which essentially adjusts a Kconfig to have an SPI driver Kconfig
explicitly select a GPIO driver when it needs the GPIO driver.

Many, perhaps most of the dependence relationships between drivers
are
currently expressed using a Kconfig "depends" model rather than the
"select" model.

Over the last few months I've pondered the use of the "depends" model
rather than a "select" model.  Superficially the "select" model has a
number of user facing advantages over the "depends" model, ones that
spring to mind are:
- As a user I can just enable the high level components/drivers I
need
to solve the applications problem, all the dependencies get dragged
in
automatically.
If you use "select", then the dependencies of that select are not
selected by default. This makes "select" a bit cumbersome and error
prone to use IMHO. 

- As a user I don;t need to dig around in Kconfig to figure out which
config options I need  to first enable in order to get the actual
option I'm looking for to appear in the config menus (I've often
found
myself having to do this :-(.

Looking in the drivers tree, there are many driver dependencies that
IMHO would give a better user config experience if we adopted a
selects model instead of the current depend model, for example:
- *sensor* -> I2C.
- console -> serial
- flash -> spi
- spi -> gpio
- ethernet -> random

What do folks think about adopting a more aggressive use of 'select'
?

Cheers
/Marcus

Cheers,
Jukka


Re: reg: Routing SPI signals connected from x86 core to the Arc core

Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao@...>
 

Hi Liu

We have finalized zephyr 1.6 version for our project

there is any patch available for zephyr 1.6 , which I can install and use ARC to directly access GPIO including AON_GPIO and SPI ?

Please help and reply

Best regards
Mahendra




From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Saturday, January 14, 2017 12:16 AM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: Routing SPI signals connected from x86 core to the Arc core

Post 1.6. You need to use master. You do not need x86 at all.

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Friday, January 13, 2017 4:16 AM
To: Liu, Baohong <baohong.liu(a)intel.com<mailto:baohong.liu(a)intel.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: RE: reg: Routing SPI signals connected from x86 core to the Arc core

Hi Liu

As you have stated below

"Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all"

Is this done in zephyr 1.6 ? Even AON_GPIO can I declare and use directly at ARC ?

Please Note we have connected bma255 at SPI lines of x86.


Best regards

Mahendravarman Rajarao

Mobil +919952921253
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 03, 2017 11:36 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com<mailto:Mahendravarman.Rajarao(a)in.bosch.com>>; devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] Re: reg: Routing SPI signals connected from x86 core to the Arc core

Zephyr drivers for SPI and GPIO were updated recently to allow ARC to directly access GPIO including AON_GPIO and SPI. You do not need x86 at all.

Please see the updated driver and sample app for BMI160 (top of the free, master).

Thanks
Baohong

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Tuesday, January 3, 2017 4:24 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: Routing SPI signals connected from x86 core to the Arc core

Hi

We have connected an Accelerometer to the x86 core of C1000 (Quark_se) through SPI interface.
Interrupt line of accelerometer is also connected to the AON_GPIO_3

Now I need to route the SPI connection of x86 to Arc core. Is that possible ?

Any sample code in zephyr I can refer for this activity ?

Best regards
Mahendra

5801 - 5820 of 8046