Date   

Zephyr on STM32F042/072/405 with USB?

Christer Weinigel
 

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 7
[ZEP-1103] Propose and implement synchronization flow for multicore power management
https://jira.zephyrproject.org/browse/ZEP-1103

[ZEP-1572] Update QMSI to 1.4
https://jira.zephyrproject.org/browse/ZEP-1572

[ZEP-1321] Glossary of Terms needs updating
https://jira.zephyrproject.org/browse/ZEP-1321

[ZEP-1389] Add support for KW41 SoC
https://jira.zephyrproject.org/browse/ZEP-1389

[ZEP-1558] Support of user private data pointer in Timer expiry function
https://jira.zephyrproject.org/browse/ZEP-1558

[ZEP-1374] Add ksdk spi shim driver
https://jira.zephyrproject.org/browse/ZEP-1374

[ZEP-1549] k_cpu_sleep_mode unaligned byte address
https://jira.zephyrproject.org/browse/ZEP-1549


CLOSED JIRA items within last 24 hours: 2
[ZEP-1404] (Won't Do) Move documentation to kernel-doc
https://jira.zephyrproject.org/browse/ZEP-1404

[ZEP-1578] (Duplicate) Kernel documentation still has TBD section
https://jira.zephyrproject.org/browse/ZEP-1578


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10052 : kernel: doc: Add deprecation notice to legacy.h
- 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
- https://gerrit.zephyrproject.org/r/10051 : doc: add a doxygen group for the Kernel API
- https://gerrit.zephyrproject.org/r/9983 : bluetooth: hci_core: Fix conn params validity check
- https://gerrit.zephyrproject.org/r/10050 : boards: quark_d2000_crb: add board image to documentation
- https://gerrit.zephyrproject.org/r/9997 : samples: dtls: Fixed layout and titles in documentation
- https://gerrit.zephyrproject.org/r/9998 : boards: add qemu_x86 board documentation
- https://gerrit.zephyrproject.org/r/9996 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/10002 : boards: categorize boards by architecture
- https://gerrit.zephyrproject.org/r/10000 : doc: application porting guide to the unified kernel
- https://gerrit.zephyrproject.org/r/9999 : boards: add qemu_cortex_m3 board documentation
- https://gerrit.zephyrproject.org/r/10004 : samples: doc: remove 'make pristine', it is not needed
- 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/10049 : drivers/ethernet: Update default GPIO pin for the ENC28J60 module
- https://gerrit.zephyrproject.org/r/10048 : samples/net: Remove redundant configuration variable
- https://gerrit.zephyrproject.org/r/9995 : samples: allow demo to run in coop/preempt-only modes
- https://gerrit.zephyrproject.org/r/9991 : kernel: use PREEMPT_ENABLED instead of NUM_PREEMPT_PRIORITIES > 0
- 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/9992 : kernel: fix main/work_q prios in coop/preempt-only modes
- 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
- https://gerrit.zephyrproject.org/r/9987 : tests: Update spi driver test for mcux
- 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/9984 : spi: Add shared default configs

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback
- https://gerrit.zephyrproject.org/r/9968 : ext: hal: qmsi: implement I2C Fast Plus Mode
- https://gerrit.zephyrproject.org/r/9953 : Bluetooth: RFCOMM: Implement Aggregate Flow Control

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9943 : sensor: remove sensor value type


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

Appala Raju <raju.ga@...>
 

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


Zephyr on STM32F042/072/405 with USB?

Christer Weinigel
 

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.

Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer

--
Have laptop, will travel. I'm a consultant looking for interesting
jobs anywhere in the world. I'm an experienced software engineer with
a solid understanding of hardware. Specialities: Linux, device
drivers and embedded systems in general. Find me at www.weinigel.se.


Re: Trying Nucleo-64 STM32F411RE

Piotr Król <piotr.krol at 3mdeb.com...>
 

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: Any plan for OTA support?

Carles Cufi
 

Hi Linh,

I was actually asking myself the same question recently. I think Linaro has started working on making the Mynewt bootloader usable with Zephyr, but that is only the first step I assume.

Also, to add a bit to your question, are there plans for IP-based OTA only, or is “regular” BLE OTA support also planned? By regular I mean similar to the proprietary solutions that vendors offer today, where one can update the firmware using only GATT, without requiring IPSP or LE Connection-Oriented Channels.

Thanks,

Carles

From: nvl1109(a)gmail.com [mailto:nvl1109(a)gmail.com]
Sent: Saturday, January 14, 2017 15:43
To: devel(a)lists.zephyrproject.org <devel(a)lists.zephyrproject.org>
Subject: [devel] Any plan for OTA support?

Hi all,

Do you have any plans to support OTA framework on Zephyr?

Thank & Regards,
Linh Nguyen


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 7
[ZEP-1577] Add support for the Arduino Ethernet Shield V2
https://jira.zephyrproject.org/browse/ZEP-1577

[ZEP-1576] Simple Network Time Protocol support
https://jira.zephyrproject.org/browse/ZEP-1576

[ZEP-1578] Kernel documentation still has TBD section
https://jira.zephyrproject.org/browse/ZEP-1578

[ZEP-1579] external links to zephyr technical docs are broken
https://jira.zephyrproject.org/browse/ZEP-1579

[ZEP-1575] Getting warning messages due to Macro SYS_LOG_DOMAIN defined in bmi160.h file
https://jira.zephyrproject.org/browse/ZEP-1575

[ZEP-1573] net/tcp: User provided data in net_context_recv is not passed to callback
https://jira.zephyrproject.org/browse/ZEP-1573

[ZEP-1580] broken links on zephyrproject.org/doc need a nice 404 error page response
https://jira.zephyrproject.org/browse/ZEP-1580


UPDATED JIRA items within last 24 hours: 12
[ZEP-1457] Add SPDX Tags to Zephyr licence boilerplate
https://jira.zephyrproject.org/browse/ZEP-1457

[ZEP-1474] BLE Connection Parameter Request/Response Processing
https://jira.zephyrproject.org/browse/ZEP-1474

[ZEP-810] Network Time Protocol v4
https://jira.zephyrproject.org/browse/ZEP-810

[ZEP-820] HTTP v1.1 Server Sample
https://jira.zephyrproject.org/browse/ZEP-820

[ZEP-795] Path MTU Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-795

[ZEP-1554] Xtensa integration
https://jira.zephyrproject.org/browse/ZEP-1554

[ZEP-1557] RISC V Port
https://jira.zephyrproject.org/browse/ZEP-1557

[ZEP-1571] Update "Changes from Version 1 Kernel" to include a "How-To Port Apps" section
https://jira.zephyrproject.org/browse/ZEP-1571

[ZEP-852] SPI API Update
https://jira.zephyrproject.org/browse/ZEP-852

[ZEP-1558] Support of user private data pointer in Timer expiry function
https://jira.zephyrproject.org/browse/ZEP-1558

[ZEP-1532] Wrong accelerometer readings
https://jira.zephyrproject.org/browse/ZEP-1532

[ZEP-1574] Samples/net/dhcpv4_client: Build fail as undefined reference to `net_mgmt_add_event_callback'
https://jira.zephyrproject.org/browse/ZEP-1574


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/9968 : ext: hal: qmsi: implement I2C Fast Plus Mode
- https://gerrit.zephyrproject.org/r/9977 : samples: net: "Mini HTTP" example & validator for TCP layer
- https://gerrit.zephyrproject.org/r/9982 : drivers: spi: enable gpio driver automatically when needed
- https://gerrit.zephyrproject.org/r/9981 : samples: spi_flash: remove an unnecessary config symbol
- https://gerrit.zephyrproject.org/r/9979 : kernel: sysclock: Add an API to get tick delta
- https://gerrit.zephyrproject.org/r/9980 : tests: include: Move timestamp.h into common location
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission
- https://gerrit.zephyrproject.org/r/9976 : net: tcp: Issue connection callback on RST
- https://gerrit.zephyrproject.org/r/9974 : Xtensa port: Added support for XCC, the Cadence Systems Inc compiler, toolchain.
- https://gerrit.zephyrproject.org/r/9973 : Bluetooth: Controller: Use CMSIS NVIC APIs directly
- 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/9970 : arm: cmsis: Introduce CMSIS layer
- https://gerrit.zephyrproject.org/r/9967 : arm: Adjust entry point of XIP kernels to the __reset function

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/9933 : tests: benchmark: sys_kernel: Porting to unified
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/9941 : net: tcp: Don't ACK inbound FIN packets
- 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/9935 : net: tcp: Pass correct user_data pointers
- https://gerrit.zephyrproject.org/r/9940 : net: tcp: Destroy net_tcp struct at the same time as the context
- https://gerrit.zephyrproject.org/r/9960 : Xtensa port: Started port to for Xtensa cores family.
- 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: net_linkaddr: introduce net_linkaddr_set function
- https://gerrit.zephyrproject.org/r/9894 : net: ipv6: fix link address handling in handle_ns_neighbor
- https://gerrit.zephyrproject.org/r/9964 : Xtensa port: Added board configuration files for the Xtensa simulator paltform.
- https://gerrit.zephyrproject.org/r/9949 : net: tcp: skip processing of TCP_ACK buffers
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use
- https://gerrit.zephyrproject.org/r/9891 : net: linkaddr: calculate linkaddr storage addr size via config
- https://gerrit.zephyrproject.org/r/9828 : Bluetooth: Add HCI SPI driver
- https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running
- https://gerrit.zephyrproject.org/r/9887 : k64: Change the default serial driver to the mcux one
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Convert enable_floating_point to use CMSIS
- https://gerrit.zephyrproject.org/r/9928 : net: tcp: Also signal EOF with a negative status code
- https://gerrit.zephyrproject.org/r/9924 : arm: cmsis: Convert DO_REBOOT to use CMSIS
- https://gerrit.zephyrproject.org/r/9923 : arm: cmsis: Convert systick to CMSIS
- https://gerrit.zephyrproject.org/r/9922 : arm: cmsis: Remove unused code from scb/scs layers
- https://gerrit.zephyrproject.org/r/9943 : sensor: remove sensor value type
- https://gerrit.zephyrproject.org/r/9830 : Bluetooth: Kconfig: Specify stack size for Bluetooth SPI
- https://gerrit.zephyrproject.org/r/9829 : Bluetooth: samples/beacon: Print message at start of sample
- https://gerrit.zephyrproject.org/r/9827 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9826 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9885 : serial: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9969 : Merge net branch into master
- https://gerrit.zephyrproject.org/r/9966 : arm: kinetis: Remove duplicate & unused defines
- https://gerrit.zephyrproject.org/r/9945 : kernel: add user data API to timers
- https://gerrit.zephyrproject.org/r/9946 : tests: add test for k_timer_user_data_set/get()
- https://gerrit.zephyrproject.org/r/9092 : sanitycheck: riscv: add vector to recognised sections
- https://gerrit.zephyrproject.org/r/9721 : tests: kernel: context: account for riscv32 architecture
- https://gerrit.zephyrproject.org/r/9722 : tests: legacy: kernel: context: account for riscv32 architecture
- https://gerrit.zephyrproject.org/r/9723 : tests: kernel: threads_scheduling: increased stack size to 512 for riscv32 architecture
- https://gerrit.zephyrproject.org/r/7068 : boards: added support for the zedboard_pulpino board
- https://gerrit.zephyrproject.org/r/8712 : serial: added support for the riscv-qemu UART driver
- https://gerrit.zephyrproject.org/r/8710 : riscv32: added support for the riscv32-qemu soc
- https://gerrit.zephyrproject.org/r/9091 : libc: add support for risc v
- https://gerrit.zephyrproject.org/r/8713 : boards: added support for the qemu_riscv32 board
- https://gerrit.zephyrproject.org/r/8709 : riscv32: added support for the pulpino soc
- https://gerrit.zephyrproject.org/r/8960 : gpio: added support for the pulpino GPIO controller driver
- https://gerrit.zephyrproject.org/r/8711 : timer: added support for the riscv-qemu timer driver
- https://gerrit.zephyrproject.org/r/7067 : timer: added timer driver for the pulpino SOC
- https://gerrit.zephyrproject.org/r/7065 : kernel: updated default IDLE_STACK_SIZE to 512 for RISCV32
- https://gerrit.zephyrproject.org/r/9720 : libc-hooks: added USED_RAM_SIZE and MAX_HEAP_SIZE definitions for riscv32
- https://gerrit.zephyrproject.org/r/7066 : unified: added _MOVE_INSTR for RISCV32 architecture
- https://gerrit.zephyrproject.org/r/7063 : scripts: added Makefile to handle an external riscv32 toolchain
- https://gerrit.zephyrproject.org/r/7064 : arch: added support for the riscv32 architecture
- https://gerrit.zephyrproject.org/r/6306 : net: zoap_server: Enable connecting with bluetooth
- https://gerrit.zephyrproject.org/r/9880 : Bluetooth: ATT: Fix using k_fifo API with net_buf
- https://gerrit.zephyrproject.org/r/9881 : Bluetooth: fix write cmd handling


Any plan for OTA support?

nvl1109@...
 

Hi all,

Do you have any plans to support OTA framework on Zephyr?

Thank & Regards,
Linh Nguyen


Re: [RFC]DMA API Update

Liu, Baohong
 

Thanks for the feedback. See my reply inline.

From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Friday, January 13, 2017 5:49 AM

On Wed, 2017-01-11 at 19:49 +0000, Liu, Baohong wrote:

/**
* @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
Is hankshake_polarity something which affects both source_handshake and
dest_handshake? If so, you sure that no hardware combination might want
different polarities for these? And is handshake something that can have
more than one valid setting, or is it determined by how the hardware is
constructed and wired up? If the latter, then these values probably shouldn't
be in a public API for use by applications and instead set by the DMA engine
to the correct values based on the value of dma_slot or something other
property of the transfer it knows.
The setting will be set before a new transfer. But, both sending and receiving
sides must follow the same setting.

This is needed to cater for different SoCs.


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

Why are burst lengths a fixed sequence of power's of two? And why isn't '2'
in the list? Why not just have an arbitrary integer? That's a rhetorical question,
I know why, because it matches the Quark hardware, and the DMA API, like a
lot of APIs in Zephyr, is specific to that one piece of hardware.
I can add one more value which is 2. So, the burst length will become power's of two.

In my opinion, it does not need to be an arbitrary integer.


* 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(...)
I also see the existing DMA API doesn't support scatter-gather, that's a fairly
common and useful feature of DMA hardware.
Will add.


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.


Currently, the only code in Zephyr that does DMA is of course Quark, and the
driver for each peripheral that can do DMA is Quark specific and knows about
Quark DMA.

So what about an SoC with a some generic DMA IP that has a Zephyr driver,
and a bunch of generic peripherals with there own drivers, and an application
that wants to use one of the said peripherals, which software component
configures the dma channel and how is the system configured so that has the
right knowledge to do that?

That's probably a rhetorical question to. The answer is that Zephyr get's
device-tree support and pinches designed ideas from Linux (which
presumably borrowed heavily from other places as well).

--
Tixy


Re: [RFC]DMA API Update

Liu, Baohong
 

Thanks for the feedback. See my reply inline.

From: Huaqi Fang [mailto:Huaqi.Fang(a)synopsys.com]
Sent: Thursday, January 12, 2017 10:25 PM

Hi Baohong,

First thanks for proposal about DMA API update.
I want to post some of our use cases and requirements around DMA
API, since I am working on Designware ARC Core support in Synopsys, our
hardware platform EMSK is already supported in zephyr, and in EMSK 2.2
version, there is a uDMA component in it.
For uDMA component description:
https://www.synopsys.com/dw/ipdir.php?ds=arc-system-integration-
options
1. As other developers said, for DMA transfers, there are different
types of transfer, single list transfer, linked list transfer. But it seems in this
API proposal, there is no consideration.
Will add.

2. In ARC core, it has many aux registers, and the DMA support not
just memory to memory, or memory to peripheral, it also support memory to
aux interface. Maybe some other DMA component also support different
interfaces.
dma_slot field has 6 bits and it can cater for 64 different handshake interfaces.

3. For DMA transfer, each burst transfer can be auto-requested or
manual requested by peripheral interface signal.
It has been taken care already. (HW or SW).


Currently we have uDMA driver for ARC in embARC project:
https://www.embarc.org/, if you want to take a look at it, you can register an
account and download it.

I post our use cases and requirements here, so hopes that the DMA
API can take these into consideration.

Thanks
Huaqi


Re: [RFC]DMA API Update

Liu, Baohong
 

-----Original Message-----
From: Nallasellan, Singaravelan
Sent: Thursday, January 12, 2017 9:40 PM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC]DMA API Update

It is required to add slave or controller id which is 32 bits. Some DMA
Please attach document (datasheets for example) and point out which page/section
you were referring to.

controllers require to program mux to connect the hardware handshake
signals to the selected peripheral with the channel.
There are different names for this across SoCs. Dma_slot, handshake_interface...
I chose dma_slot. In other words, it has been taken care.


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


Hi everyone,

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

Known Problems
--------

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

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

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

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

Proposed Solution
--------

-- The following are the enums we have now.

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

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

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

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

-- The callback_data pointer will be removed.

Final API Format
--------

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

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

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

Suggestions and comments are welcome.


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

Liu, Baohong
 

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


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 5
[ZEP-1571] Update "Changes from Version 1 Kernel" to include a "How-To Port Apps" section
https://jira.zephyrproject.org/browse/ZEP-1571

[ZEP-1568] Replace arm cortex_m scs and scb functionality with direct CMSIS-core calls
https://jira.zephyrproject.org/browse/ZEP-1568

[ZEP-1566] WDT: Interrupt is triggered multiple times @ARC
https://jira.zephyrproject.org/browse/ZEP-1566

[ZEP-1569] net/tcp: TCP in server mode doesn't support multiple concurrent connections
https://jira.zephyrproject.org/browse/ZEP-1569

[ZEP-1570] net/tcp: TCP in server mode is unable to close client connections
https://jira.zephyrproject.org/browse/ZEP-1570


UPDATED JIRA items within last 24 hours: 9
[ZEP-822] Simple Network Management Protocol v2
https://jira.zephyrproject.org/browse/ZEP-822

[ZEP-813] RPL: IPv6 Routing Protocol
https://jira.zephyrproject.org/browse/ZEP-813

[ZEP-799] HTTP over TLS
https://jira.zephyrproject.org/browse/ZEP-799

[ZEP-216] LWM2M for device management
https://jira.zephyrproject.org/browse/ZEP-216

[ZEP-831] ICMPv6 "Packet Too Big" support
https://jira.zephyrproject.org/browse/ZEP-831

[ZEP-759] Add preliminary support for Atmel SAM E70 (Cortex-M7) chipset family and SAM E70 Xplained board
https://jira.zephyrproject.org/browse/ZEP-759

[ZEP-1492] Add Atmel SAM family GMAC Ethernet driver
https://jira.zephyrproject.org/browse/ZEP-1492

[ZEP-1507] fxos8700 broken gpio_callback implementation
https://jira.zephyrproject.org/browse/ZEP-1507

[ZEP-1548] Python script invocation is inconsistent
https://jira.zephyrproject.org/browse/ZEP-1548


CLOSED JIRA items within last 24 hours: 1
[ZEP-1274] (Won't Do) galileo has pinmux driver in boards/x86/galileo/, while all the rest in drivers/pinmux/
https://jira.zephyrproject.org/browse/ZEP-1274


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/9964 : Xtensa port: Added board configuration files for the Xtensa simulator paltform.
- https://gerrit.zephyrproject.org/r/9960 : Xtensa port: Started port to for Xtensa cores family.
- https://gerrit.zephyrproject.org/r/9963 : Bluetooth: Introduce a new connection parameter request callback
- https://gerrit.zephyrproject.org/r/9937 : net: tcp: Get rid of `recv_mss` field from TCP struct
- https://gerrit.zephyrproject.org/r/9936 : net: tcp: Remove unused `recv_ack` field from TCP context
- https://gerrit.zephyrproject.org/r/9931 : net: tcp: Ensure `recv_mss` won't overflow if interface MTU is <40
- https://gerrit.zephyrproject.org/r/9929 : net: tcp: Ensure all timers are disposed of when releasing context
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- 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/9941 : net: tcp: Don't ACK inbound FIN packets
- https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use
- https://gerrit.zephyrproject.org/r/9926 : drivers: slip: Just unref, don't destroy sent buf chains
- https://gerrit.zephyrproject.org/r/9938 : drivers: bmi160: add sample ready check
- https://gerrit.zephyrproject.org/r/9939 : samples: bmi160: reduce polling mode sampling frequency
- https://gerrit.zephyrproject.org/r/9928 : net: tcp: Also signal EOF with a negative status code
- https://gerrit.zephyrproject.org/r/9944 : net: tcp: Reduce size of `state` member from 32 to 4 bits
- https://gerrit.zephyrproject.org/r/9924 : arm: cmsis: covert aircr
- https://gerrit.zephyrproject.org/r/9930 : net: tcp: Use an uint8_t for retry timeout instead of an uin32_t
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9949 : net: tcp: skip processing of TCP_ACK buffers
- https://gerrit.zephyrproject.org/r/9953 : Bluetooth: RFCOMM: Implement Aggregate Flow Control
- https://gerrit.zephyrproject.org/r/9923 : arm: cmsis: convert systick to CMSIS
- 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/9945 : kernel: add user data API to timers
- https://gerrit.zephyrproject.org/r/9947 : tests/pwm: add PINMUX config for D2000 board
- https://gerrit.zephyrproject.org/r/9946 : tests: add test for k_timer_user_data_set/get()
- https://gerrit.zephyrproject.org/r/9933 : tests: benchmark: sys_kernel: Porting to unified
- https://gerrit.zephyrproject.org/r/9943 : sensor: remove sensor value type
- https://gerrit.zephyrproject.org/r/9927 : build: Just use the ZEPHYRINCLUDE path for when we make offsets
- https://gerrit.zephyrproject.org/r/9922 : arm: cmsis: Prep for move to CMSIS by remove unused code
- https://gerrit.zephyrproject.org/r/9920 : arm: cortex-m: Create CONFIG_BOOT_HEADER_SIZE

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/6306 : net: zoap_server: Enable connecting with bluetooth
- https://gerrit.zephyrproject.org/r/9805 : ext: mcux: add MCR20Overwrites.h
- https://gerrit.zephyrproject.org/r/9889 : serial: k64: Remove the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9888 : frdm_k64f: hexiwear_k64: Remove defaults for the uart_k20 driver
- https://gerrit.zephyrproject.org/r/9887 : k64: Change the default serial driver to the mcux one
- https://gerrit.zephyrproject.org/r/9886 : frdm_k64f: hexiwear_k64: Add defaults for the mcux serial driver
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/9806 : boards: frdm_k64f: add pinmux settings for MCR20A
- https://gerrit.zephyrproject.org/r/9809 : samples: ieee802154: add MCR20A
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Port prep_c.c to CMSIS
- https://gerrit.zephyrproject.org/r/9653 : net: slip: Do not remove fragments when sending data
- https://gerrit.zephyrproject.org/r/9891 : net: linkaddr: calculate linkaddr storage addr size via config
- https://gerrit.zephyrproject.org/r/9893 : net: ipv6: fix NULL reference in handle_ra_neighbor
- https://gerrit.zephyrproject.org/r/6410 : initial xtensa code drop
- https://gerrit.zephyrproject.org/r/9709 : Bluetooth: SDP: Add API to extract Attribute Value
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/9693 : pinmux/stm32: extend pinmux driver functionality to support STM32F3X series MCUs
- https://gerrit.zephyrproject.org/r/9701 : pinmux/stm32: default pin assignment for STM32373C-EVAL board
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs
- https://gerrit.zephyrproject.org/r/9325 : gpio/stm32: provide GPIO driver implementation for STM32F3X family
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- 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/9700 : pinmux/stm32: default pin assignment for NUCLEO-F334R8 board
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/7034 : tests: add fifo/lifo test cases with unified kernel
- https://gerrit.zephyrproject.org/r/8922 : scripts: Add device tree parser script
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9885 : serial: Introduce new mcux shim driver
- https://gerrit.zephyrproject.org/r/7104 : drivers: spi: Add nRF5 SPI slave driver
- https://gerrit.zephyrproject.org/r/5604 : drivers: spi: Add SPI_SLAVE flag to allow platform drivers to switch to slave mode
- https://gerrit.zephyrproject.org/r/7107 : tests: Add spi_masterslave test program

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9918 : net: ieee802154: inform about unsupported frames
- https://gerrit.zephyrproject.org/r/9965 : net: mgmt: Make NET_MGMT_GET_* macros return meaningful values
- https://gerrit.zephyrproject.org/r/9921 : Bluetooth: GATT: Fix missing connection address comparison
- https://gerrit.zephyrproject.org/r/9962 : Bluetooth: Prefer struct bt_le_conn_param over individual values
- https://gerrit.zephyrproject.org/r/9958 : samples: net: Fix dhcpv4 building with net mgmt event support
- https://gerrit.zephyrproject.org/r/9957 : net: mgmt: Silently ignore net_mgmt_event functions if not enabled
- https://gerrit.zephyrproject.org/r/9959 : Bluetooth: ATT: Add new error code from CSSv7
- https://gerrit.zephyrproject.org/r/9932 : arc: fix unaligned variables resulting in unaligned k_cpu_sleep_mode
- https://gerrit.zephyrproject.org/r/9942 : MAINTAINERS: update sensor drivers section
- https://gerrit.zephyrproject.org/r/9919 : Merge arm branch into master
- https://gerrit.zephyrproject.org/r/9916 : net: bt: Add disconnect shell command
- https://gerrit.zephyrproject.org/r/9867 : net: bt: Add scan shell command
- https://gerrit.zephyrproject.org/r/9917 : net: echo_client: Enable CONFIG_NET_L2_BLUETOOTH_SHELL in prj_bt.conf
- https://gerrit.zephyrproject.org/r/9862 : net: echo_client: Don't start sending packets if interface is not UP
- https://gerrit.zephyrproject.org/r/9915 : net: bt: Add disconnect management command
- https://gerrit.zephyrproject.org/r/9861 : net: echo_client: Fix using CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/9864 : net: bt: Add connect management command
- https://gerrit.zephyrproject.org/r/9863 : net: bt: Fix not showing any logs
- https://gerrit.zephyrproject.org/r/9860 : net: mgmt: Decode event fields
- https://gerrit.zephyrproject.org/r/9866 : net: bt: Add scan management command
- https://gerrit.zephyrproject.org/r/9865 : net: bt: Add shell support
- https://gerrit.zephyrproject.org/r/8624 : tcptest: Fix wrong variable type in in print() call
- https://gerrit.zephyrproject.org/r/9439 : tests: add timer test case with unified kernel
- https://gerrit.zephyrproject.org/r/9353 : scripts: Explicitly call out python2
- https://gerrit.zephyrproject.org/r/9354 : samples: task_profiler: Be explicit about python
- https://gerrit.zephyrproject.org/r/9816 : tests: Add PWM driver api test


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

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

Hi

An update to the below query.Under zephyr 1.6

I have used SPI routines x86 to read the chip id of bma255 and its working fine

But,

If I have used SPI routines on ARC ..chip id reading is returning as 0xFF..

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

So only I have a doubt, can we access SPI directly from ARC which is connected to x86 ?

Please help !!!



From: Mahendravarman Rajarao (RBEI/EAA3)
Sent: Friday, January 13, 2017 5:46 PM
To: 'Liu, Baohong' <baohong.liu(a)intel.com>; 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


Re: [RFC]DMA API Update

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

On Wed, 2017-01-11 at 19:49 +0000, Liu, Baohong wrote:

/**
* @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
Is hankshake_polarity something which affects both source_handshake and
dest_handshake? If so, you sure that no hardware combination might want
different polarities for these? And is handshake something that can have
more than one valid setting, or is it determined by how the hardware is
constructed and wired up? If the latter, then these values probably
shouldn't be in a public API for use by applications and instead set by
the DMA engine to the correct values based on the value of dma_slot or
something other property of the transfer it knows.

* 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)
Why are burst lengths a fixed sequence of power's of two? And why isn't
'2' in the list? Why not just have an arbitrary integer? That's a
rhetorical question, I know why, because it matches the Quark hardware,
and the DMA API, like a lot of APIs in Zephyr, is specific to that one
piece of hardware.

* 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(...)
I also see the existing DMA API doesn't support scatter-gather, that's a
fairly common and useful feature of DMA hardware.

But finally, the big elephant in the room is: how are DMA APIs actually
expected to used? And how should the system be configured?

Currently, the only code in Zephyr that does DMA is of course Quark, and
the driver for each peripheral that can do DMA is Quark specific and
knows about Quark DMA.

So what about an SoC with a some generic DMA IP that has a Zephyr
driver, and a bunch of generic peripherals with there own drivers, and
an application that wants to use one of the said peripherals, which
software component configures the dma channel and how is the system
configured so that has the right knowledge to do that?

That's probably a rhetorical question to. The answer is that Zephyr
get's device-tree support and pinches designed ideas from Linux (which
presumably borrowed heavily from other places as well).

--
Tixy


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

Luiz Augusto von Dentz
 

Hi,

zoap_server does not have BT support, but Ive created a patch adding
support for it:

https://gerrit.zephyrproject.org/r/6306

On Fri, Jan 13, 2017 at 11:38 AM, Appala Raju <raju.ga(a)gmail.com> wrote:
Thanks Tomasz...

Just now I checked-out master branch and tried zoap_server as Ravi explained. Now it is booting with out any issues and seeing "shell >" on UART messages.

After that, I am trying to discover the BLE device from Linux machine using "sudo hcitool lescan". Here, nothing is showing. What could be the reason.
--
Luiz Augusto von Dentz


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

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

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

5821 - 5840 of 8040