Date   

Re: Chain booting in Zephyr

Carles Cufi
 

Hi David,

-----Original Message-----
From: David Brown [mailto:david.brown(a)linaro.org]
Sent: Monday, December 12, 2016 22:54
To: devel(a)lists.zephyrproject.org
Subject: [devel] Chain booting in Zephyr

As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've been
running into is setting the vector table address in the chained image.
Of the two Cortex-M boards I have, I've found two different kinds of
failure, and was wondering if anyone had ideas on the best way to make
this work.

The way the bootloader works on these devices with built-in flash, is
that the bootloader itself is located at the beginning of flash.
There are then 1 or more partitions following this that contain the main
image. Since the image does not start at the beginning of flash, and
Zephyr on ARM uses a ROM-based vector table, it is necessary to update
the vector table address (VTOR) before enabling interrupts.

- FRDM-K64F

This board support seems to assume that the code always resides at
the beginning of flash, and doesn't seem to write to the VTOR at
all.

- STM32F4 (96b_carbon)

This board support does write the vector table offset, but assumes
that it is always the same as CONFIG_FLASH_BASE_ADDRESS.

Both of these have some problems. With the boot loader, there is a
header at the beginning of the image, and the vector table itself always
follows this.

Having the vector table in ROM does have some advantages (simplicity, as
well as minor security).

I guess my question is, should I just try to fix this in an ad-hoc
manner as I discover targets that don't chain-boot correctly. It seems
like a good general solution would be to add a symbol (or use a
symbol) for the vector table, instead of trying to guess where it might
be.

Do we have any expectation of having a RAM vector table in the future?
I do not know if there's plans to have the actual hardware vector table in RAM, but there are as I understand plans to change the current software ISR table and the way it's populated, as part of the hard real-time interrupt optimizations upcoming. Andrew Boie should have more details regarding these changes.

Regards,

Carles


Re: Chain booting in Zephyr

Sterling Hughes <sterling@...>
 

Hi David,

On 12 Dec 2016, at 13:54, David Brown wrote:

As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've
been running into is setting the vector table address in the chained
image. Of the two Cortex-M boards I have, I've found two different
kinds of failure, and was wondering if anyone had ideas on the best
way to make this work.

The way the bootloader works on these devices with built-in flash, is
that the bootloader itself is located at the beginning of flash.
There are then 1 or more partitions following this that contain the
main image. Since the image does not start at the beginning of flash,
and Zephyr on ARM uses a ROM-based vector table, it is necessary to
update the vector table address (VTOR) before enabling interrupts.

- FRDM-K64F

This board support seems to assume that the code always resides at
the beginning of flash, and doesn't seem to write to the VTOR at
all.
This is similar to how the NRF51 operates. In Mynewt these values are
trampolined to SRAM locations (i.e. the interrupt vectors jump to code
in SRAM.) We locate the bootloader after the vector table, and the
vector table points to locations in RAM after boot. Obviously, we leave
interrupts disabled in the bootloader, until we’ve initialized the
vector table in RAM.

- STM32F4 (96b_carbon)

This board support does write the vector table offset, but assumes
that it is always the same as CONFIG_FLASH_BASE_ADDRESS.

Both of these have some problems. With the boot loader, there is a
header at the beginning of the image, and the vector table itself
always follows this.

Having the vector table in ROM does have some advantages (simplicity,
as well as minor security).

I guess my question is, should I just try to fix this in an ad-hoc
manner as I discover targets that don't chain-boot correctly. It
seems like a good general solution would be to add a symbol (or use a
symbol) for the vector table, instead of trying to guess where it
might be.
Agreed.


Do we have any expectation of having a RAM vector table in the future?
I would say RAM vector table is simpler and nicer, if you can burn the
RAM (~256 bytes.) We’ve certainly made that trade-off, and said
“we’ll optimize when we need to.”

Cheers,

Sterling


Chain booting in Zephyr

David Brown
 

As some of you may know, I've been working on making the Mynewt
bootloader work as a bootloader build with Zephyr. One issue I've
been running into is setting the vector table address in the chained
image. Of the two Cortex-M boards I have, I've found two different
kinds of failure, and was wondering if anyone had ideas on the best
way to make this work.

The way the bootloader works on these devices with built-in flash, is
that the bootloader itself is located at the beginning of flash.
There are then 1 or more partitions following this that contain the
main image. Since the image does not start at the beginning of flash,
and Zephyr on ARM uses a ROM-based vector table, it is necessary to
update the vector table address (VTOR) before enabling interrupts.

- FRDM-K64F

This board support seems to assume that the code always resides at
the beginning of flash, and doesn't seem to write to the VTOR at
all.

- STM32F4 (96b_carbon)

This board support does write the vector table offset, but assumes
that it is always the same as CONFIG_FLASH_BASE_ADDRESS.

Both of these have some problems. With the boot loader, there is a
header at the beginning of the image, and the vector table itself
always follows this.

Having the vector table in ROM does have some advantages (simplicity,
as well as minor security).

I guess my question is, should I just try to fix this in an ad-hoc
manner as I discover targets that don't chain-boot correctly. It
seems like a good general solution would be to add a symbol (or use a
symbol) for the vector table, instead of trying to guess where it
might be.

Do we have any expectation of having a RAM vector table in the future?

Thanks,
David


Re: Reg: Zephyr 1.6 GPIO Mask and Unmask gpio interrupts

vishnuvaradan vishnuvaradan
 

Hi Tomasz

Thanks for replying

Inside the gpio_pin_enable function I have called gpio_pin_disable_function
but my code gets hang inside that isr itself.

Should I need to use gpio_pin_disable macro inside the isr instead of
gpio_pin_disable_function?

On Fri, Dec 9, 2016 at 2:05 PM, Tomasz Bursztyka <
tomasz.bursztyka(a)linux.intel.com> wrote:

Hi,

Have a look at samples/basic/button/src/main.c for instance.

Zephyr GPIO API first requires to configure it through
gpio_pin_configure()
and then to setup a callback and enabled/disable the relevant pin for that
callback (you can do it by port directly,
if you need multiples pins at once). We don't expose the mask/unmask logic
directly.

Tomasz

Hi tomasz and mahendra

what #define to be used in gpio_pin_configure to mask and unmask gpio
interrupt ?
can you help me with an example ?

On Thu, Dec 8, 2016 at 8:20 PM, Tomasz Bursztyka <
tomasz.bursztyka(a)linux.intel.com> wrote:

Hi,

So from the application level to mask and unmask gpio interrupts can I
use QM_IR_MASK_INTERRUPTS & QM_IR_UNMASK_INTERRUPTS functions

(Or) should I use settings in gpio_pin_configure function ??


The second one. Always use the Zephyr GPIO API, so include/gpio.h

Tomasz


Re: Using/misusing k_sem_init()

Benjamin Walsh <benjamin.walsh@...>
 

Hi Piotr,

Sorry for the late response.

I'm reviewing my new code for Atmel SAM low level Ethernet driver and
there is one place where I have a troubling use of k_sem_init()
function. Very shortly my situation:

As is typically the case Atmel's Ethernet MAC module is using a so
called descriptor list to define a linked list of transmission and
reception buffers. These shared buffers are then used to pass data
between MAC module and low level Ethernet driver.

Let's focus on the transmit path. Assuming we have two transmission
buffers and each buffer can store one full Ethernet frame the Ethernet
driver can send up to two frames to the MAC module but to send a third
frame it has to wait until a free buffer becomes available. This is a
perfect case for using counting semaphores.

During driver initialization phase we would call

k_sem_init(&tx_sem, 2, 2);

to initialize semaphores and then k_sem_take() in transmit thread every
time we send a frame and k_sem_give() in IRQ handler every time the MAC
module has read all the data from the transmit buffer. So far so good.
However, now we can have a situation where the driver (transmit thread)
has sent two frames, stopped on k_sem_take() call when trying to send a
third one and at that moment an unrecoverable transmission error
happens. At this point I would like to reinitialize the descriptor list
and also reinitialize the semaphores, i.e. I would like to call
k_sem_init() while there is a thread waiting for the very semaphore to
become available.
What is the behaviour you expect exactly ? What would a semaphore
re-init signal to the thread pending on the semaphore in your
application ?

I can tell you that with the current implementation of k_sem_init(), the
thread would not be awakened, but the wait queue would be reinitialized,
so that thread would be "lost".

You could give the semaphore twice (since you initialize it with '2') to
flush the threads pending on it, but that would probably just cause them
to pend again on the semaphore. Worst, the thread would probably just
think it got the semaphore and just try to do the operation expected of
it when it is able to get the semaphore.

Would that be OK, is there a better solution?
One thing you could do would be to abort the thread, then re-init the
semaphore, then respawn the thread.

We could maybe add a k_sem_flush() API, that unpend all threads waiting
on the semaphore, but returning them an errno.

Cheers,
Ben


Thanks and regards,
Piotr
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/8997 : samples: net: Add echo_client build test for CC2520 configuration
- https://gerrit.zephyrproject.org/r/8998 : scripts: fix wrong RAM reporting on ARM
- https://gerrit.zephyrproject.org/r/8996 : net: Remove unnecessary k_wakeup
- https://gerrit.zephyrproject.org/r/8994 : samples: net: Fix compile error following API change
- https://gerrit.zephyrproject.org/r/8987 : gpio: nrf5x: Add support for GPIOTE and GPIO callbacks
- https://gerrit.zephyrproject.org/r/8992 : Bluetooth: RFCOMM: Disconnect session after last dlc disconnection
- https://gerrit.zephyrproject.org/r/8991 : net: echo_client: Fix using CONFIG_NETWORKING_WITH_BT
- https://gerrit.zephyrproject.org/r/8989 : samples/net/README: Add DNS client section
- https://gerrit.zephyrproject.org/r/8990 : tests: add driver aio comparator test case
- https://gerrit.zephyrproject.org/r/8986 : kernel: enhance realtime-ness when handling timeouts
- https://gerrit.zephyrproject.org/r/8985 : kernel: fix typo
- https://gerrit.zephyrproject.org/r/8984 : sample/philosphers: ignore format-security warning
- https://gerrit.zephyrproject.org/r/8983 : kernel: fix mis-use of sys_dlist_t vs sys_dnode_t in _timeout
- https://gerrit.zephyrproject.org/r/8982 : kernel/timers: move tick computation out of irq_lock block
- https://gerrit.zephyrproject.org/r/8981 : kernel: add defines for delta_ticks_from_prev special values

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/5652 : net: buf: Redesigned pool & buffer allocation API
- https://gerrit.zephyrproject.org/r/8888 : iot/dns: Use a k_timer for the DNS rx routine
- https://gerrit.zephyrproject.org/r/8979 : kernel: remove NANOKERNEL config option
- https://gerrit.zephyrproject.org/r/8978 : kernel: disable MDEF by default
- https://gerrit.zephyrproject.org/r/8977 : scripts: remove old qemu patch
- https://gerrit.zephyrproject.org/r/8947 : sensor: update drivers to not return double values
- https://gerrit.zephyrproject.org/r/8944 : sensor: remove unused Q16_16 value type
- https://gerrit.zephyrproject.org/r/8945 : sensor: remove SENSOR_VALUE_TYPE_INT
- https://gerrit.zephyrproject.org/r/8946 : sensor: use integers for simple value calculations
- https://gerrit.zephyrproject.org/r/8759 : samples/drivers: Add Counters example
- https://gerrit.zephyrproject.org/r/8714 : [DO NOT SUBMIT] RFC: Bluetooth: SDP client API user concept draft
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/7612 : Bluetooth: AVDTP: Add AV-Stream data structure
- https://gerrit.zephyrproject.org/r/7626 : flash/stm32: flash driver for STM32F3x series microcontrollers
- https://gerrit.zephyrproject.org/r/7625 : exti/stm32: add support for F334 & F373 MCUs
- https://gerrit.zephyrproject.org/r/7623 : clock/stm32: add STM32F3X reset and clock control
- https://gerrit.zephyrproject.org/r/8726 : kernel: legacy: Fix int overflow in nano_stack_init
- https://gerrit.zephyrproject.org/r/8951 : net: Remove legacy tinydtls.h header
- https://gerrit.zephyrproject.org/r/7622 : clock/stm32: add STM32F107 reset and clock control
- https://gerrit.zephyrproject.org/r/7615 : boards: add initial support for STM32373C-EVAL with SoC STM32F373VC
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/7614 : boards: add initial support for Nucleo-64 with Soc STM32F334
- https://gerrit.zephyrproject.org/r/6913 : power: Add ARC core suspend and resume support
- https://gerrit.zephyrproject.org/r/8976 : tcp: Validate net_context_put return code
- https://gerrit.zephyrproject.org/r/8900 : tests: add gpio driver test case
- https://gerrit.zephyrproject.org/r/8889 : iot/dns: Update sample application
- https://gerrit.zephyrproject.org/r/8886 : iot/dns: Introduce the dns_context structure
- https://gerrit.zephyrproject.org/r/8923 : tests/iot/http: Initialize parser struct
- https://gerrit.zephyrproject.org/r/8919 : tests/tcp: Initialize buffer to NULL
- https://gerrit.zephyrproject.org/r/8887 : iot/dns: Update DNS client private routines
- https://gerrit.zephyrproject.org/r/8970 : samples/mbedtls_dtlsclient: Add ARG_UNUSED
- https://gerrit.zephyrproject.org/r/8969 : samples/mbedtls_dtlsclient: Validate destination buffer size
- https://gerrit.zephyrproject.org/r/8793 : samples/mbedtls_dtlsclient: Using semaphore for rx
- https://gerrit.zephyrproject.org/r/8811 : kernel/arch: enhance the "ready thread" cache
- https://gerrit.zephyrproject.org/r/8974 : kernel: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8973 : shell: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8975 : x86/soc: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8968 : samples: added disco_fever app
- https://gerrit.zephyrproject.org/r/8871 : random: Restructure RANDOM Kconfig
- https://gerrit.zephyrproject.org/r/8971 : kernel/mem_pool: Use the right data-type
- https://gerrit.zephyrproject.org/r/8972 : kernel/mem_slab: Use the right data-type

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8988 : MAINTAINERS: Update network applications section
- https://gerrit.zephyrproject.org/r/8980 : device: do not set struct as deprecated
- https://gerrit.zephyrproject.org/r/8831 : device: add deprecated attribute to device sync APIs


Re: Zephyr versioning (1.6.0 or 0.1.6?)

Jon Trulson
 

On Sat, 10 Dec 2016, Nashif, Anas wrote:


On 5 Dec 2016, at 17:20, Jon Trulson <jon(a)radscan.com> wrote:

On Mon, 5 Dec 2016, Jon Trulson wrote:

Hi,

I noticed that a new Zephyr version was tagged, 1.6.0. I am confused a
little bit by the version number though:
[...]

Responding to my own post - clearly KERNEL_VERSION_NUMBER is the wrong
macro. It seems like KERNELVERSION is supposed to be the correct one
for these macros? A little confusing.

Anyway, I just decided to use KERNEL_VERSION_MAJOR,
KERNEL_VERSION_MINOR, and KERNEL_PATCHLEVEL directly. This works
fine.

Sorry for the noise.
Here is a snippet:

uint32_t version = sys_kernel_version_get();

printk("Zephyr version %d.%d.%d\n",
SYS_KERNEL_VER_MAJOR(version),
SYS_KERNEL_VER_MINOR(version),
SYS_KERNEL_VER_PATCHLEVEL(version));

This is the correct usage, and yes, KERNEL_VERSION_NUMBER is not the right macro.
Yes, I had seen sys_kernel_version_get(), but what I was trying to do
was get this information at compile time so that some timer code I was
using could be supported in both 1.5 and 1.6 versions of Zephyr
(nanotimer vs. k_timer).

Using the macros I mentioned previously works fine. Thanks for the
response!


--
Jon Trulson

"If we can hit that bull's-eye, the rest of the dominoes will fall
like a house of cards... Checkmate."
-- Zapp Brannigan


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/8968 : samples: added disco_fever app
- https://gerrit.zephyrproject.org/r/8967 : toolchain: Add a popcount macro for GCC
- https://gerrit.zephyrproject.org/r/8979 : kernel: remove NANOKERNEL config option
- https://gerrit.zephyrproject.org/r/8978 : kernel: disable MDEF by default
- https://gerrit.zephyrproject.org/r/8977 : scripts: remove old qemu patch
- https://gerrit.zephyrproject.org/r/8976 : tcp: Validate net_context_put return code
- https://gerrit.zephyrproject.org/r/8975 : x86/soc: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8974 : kernel: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8973 : shell: Add ARG_UNUSED macro to avoid compiler warnings
- https://gerrit.zephyrproject.org/r/8972 : kernel/mem_slab: Use the right data-type
- https://gerrit.zephyrproject.org/r/8971 : kernel/mem_pool: Use the right data-type
- https://gerrit.zephyrproject.org/r/8970 : samples/mbedtls_dtlsclient: Add ARG_UNUSED
- https://gerrit.zephyrproject.org/r/8969 : samples/mbedtls_dtlsclient: Validate destination buffer size

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8871 : random: Restructure RANDOM Kconfig
- https://gerrit.zephyrproject.org/r/8931 : kernel: Refactor remaining time evaluation for timeouts
- https://gerrit.zephyrproject.org/r/8932 : kernel: Introduce new k_delayed_work_remaining_get API
- https://gerrit.zephyrproject.org/r/7068 : boards: added support for the zedboard_pulpino board
- https://gerrit.zephyrproject.org/r/8926 : kernel: introduce single-threaded kernel

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8980 : device: do not set struct as deprecated
- https://gerrit.zephyrproject.org/r/8898 : samples: spi_fram: correct syntax error and update comments
- https://gerrit.zephyrproject.org/r/8868 : drivers: adc: replace device sync APIs with semaphores
- https://gerrit.zephyrproject.org/r/8832 : drivers: spi: replace device sync APIs with semaphores
- https://gerrit.zephyrproject.org/r/8927 : samples: gpio: use correct gpio driver name
- https://gerrit.zephyrproject.org/r/8873 : drivers: i2c: replace device sync APIs with semaphores
- https://gerrit.zephyrproject.org/r/8831 : device: add deprecated attribute to device sync APIs
- https://gerrit.zephyrproject.org/r/8924 : arm: Fix irq offload inline asm memory ordering.
- https://gerrit.zephyrproject.org/r/8870 : random: Rewrite sys_rand32_init() with SYS_INIT()
- https://gerrit.zephyrproject.org/r/8869 : Remove application calls to sys_rand32_init.
- https://gerrit.zephyrproject.org/r/7660 : sensor: Add nRF5 temperature driver.
- https://gerrit.zephyrproject.org/r/8805 : samples: Add thermometer
- https://gerrit.zephyrproject.org/r/8929 : samples: sensor: fxos8700: Check sample fetch return value
- https://gerrit.zephyrproject.org/r/8956 : printk: Export _vprintk similar to how _prf is exported
- https://gerrit.zephyrproject.org/r/8957 : Bluetooth: Use _vprintk() instead of _prf()
- https://gerrit.zephyrproject.org/r/8826 : pinmux: Introduce new ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8827 : frdm_k64f: Add pin init using ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8828 : hexiwear_k64: Add pin init using ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8829 : k64: Change the default pinmux driver to the ksdk one
- https://gerrit.zephyrproject.org/r/8830 : pinmux: Deprecate the k64 pinmux driver
- https://gerrit.zephyrproject.org/r/7217 : meta-zephyr-sdk: disable MIPS


Re: Zephyr versioning (1.6.0 or 0.1.6?)

Nashif, Anas
 

On 5 Dec 2016, at 17:20, Jon Trulson <jon(a)radscan.com> wrote:

On Mon, 5 Dec 2016, Jon Trulson wrote:

Hi,

I noticed that a new Zephyr version was tagged, 1.6.0. I am confused a
little bit by the version number though:

Is it really Version 1.6.0? Or 0.1.6?

If you look at (and I tested this with a simple example) the results of
the version macros (SYS_KERNEL_VER_MAJOR(), et. al.) and the kernel
version (KERNEL_VERSION_NUMBER), I get the following results:

SYS_KERNEL_VER_MAJOR(KERNEL_VERSION_NUMBER) == 0
SYS_KERNEL_VER_MINOR(KERNEL_VERSION_NUMBER) == 1
SYS_KERNEL_VER_PATCHLEVEL(KERNEL_VERSION_NUMBER) == 6

So, this implies the "real" version is 0.1.6. Am I missing something?
Responding to my own post - clearly KERNEL_VERSION_NUMBER is the wrong
macro. It seems like KERNELVERSION is supposed to be the correct one
for these macros? A little confusing.

Anyway, I just decided to use KERNEL_VERSION_MAJOR,
KERNEL_VERSION_MINOR, and KERNEL_PATCHLEVEL directly. This works
fine.

Sorry for the noise.
Here is a snippet:

uint32_t version = sys_kernel_version_get();

printk("Zephyr version %d.%d.%d\n",
SYS_KERNEL_VER_MAJOR(version),
SYS_KERNEL_VER_MINOR(version),
SYS_KERNEL_VER_PATCHLEVEL(version));

This is the correct usage, and yes, KERNEL_VERSION_NUMBER is not the right macro.


Anas


--
Jon Trulson

"If we can hit that bull's-eye, the rest of the dominoes will fall
like a house of cards... Checkmate."
-- Zapp Brannigan


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/8958 : Bluetooth: Kconfig: Fix logging dependency on printk
- https://gerrit.zephyrproject.org/r/8961 : drivers: QMSI counter: Update reentrancy code to use DEFINED macro
- https://gerrit.zephyrproject.org/r/8962 : arc: em_starterkit default changed to EM7D
- https://gerrit.zephyrproject.org/r/8960 : gpio: added support for the pulpino GPIO controller driver
- https://gerrit.zephyrproject.org/r/8957 : Bluetooth: Use _vprintk() instead of _prf()
- https://gerrit.zephyrproject.org/r/8956 : printk: Export _vprintk similar to how _prf is exported
- https://gerrit.zephyrproject.org/r/8952 : samples: disco: updated disco app to be board dependent
- https://gerrit.zephyrproject.org/r/8953 : boards: nucleo_f103rb: added ED1_GPIO_PORT, LED1_GPIO_PIN and LED2_GPIO_PIN definitions
- https://gerrit.zephyrproject.org/r/8951 : net: Remove legacy tinydtls.h header
- https://gerrit.zephyrproject.org/r/8950 : samples: button: set EDGE to SW0_GPIO_INT_CONF if defined

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8826 : pinmux: Introduce new ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8802 : board: add initial support for Nucleo-64 with Soc STM32F411RE
- https://gerrit.zephyrproject.org/r/8813 : driver: ethernet: adds reset signal to enc28j60 driver
- https://gerrit.zephyrproject.org/r/7064 : arch: added support for the riscv32 architecture
- https://gerrit.zephyrproject.org/r/7090 : arc: Define _arc_v2_irq_unit device
- https://gerrit.zephyrproject.org/r/8897 : samples/zoap-client: Fix using wrong addresses
- https://gerrit.zephyrproject.org/r/8916 : jira: install jira pip package locally
- https://gerrit.zephyrproject.org/r/8711 : timer: added support for the riscv-qemu timer driver
- https://gerrit.zephyrproject.org/r/7063 : scripts: added Makefile to handle an external riscv32 toolchain
- https://gerrit.zephyrproject.org/r/7068 : boards: added support for the zedboard_pulpino board
- https://gerrit.zephyrproject.org/r/4871 : util.h: Add DEFINED() macro for expresion-legal ifdef-checking
- https://gerrit.zephyrproject.org/r/8710 : riscv32: added support for the riscv32-qemu soc
- https://gerrit.zephyrproject.org/r/8709 : riscv32: added support for the pulpino soc
- https://gerrit.zephyrproject.org/r/7066 : unified: added _MOVE_INSTR for RISCV32 architecture
- https://gerrit.zephyrproject.org/r/8712 : serial: added support for the riscv-qemu UART driver
- https://gerrit.zephyrproject.org/r/7065 : kernel: updated default IDLE_STACK_SIZE to 512 for RISCV32
- https://gerrit.zephyrproject.org/r/7067 : timer: added timer driver for the pulpino SOC
- https://gerrit.zephyrproject.org/r/8713 : boards: added support for the qemu_riscv32 board
- https://gerrit.zephyrproject.org/r/8928 : driver: pwm: give arc the access to pwm
- https://gerrit.zephyrproject.org/r/7613 : soc/stm32: add initial support for STM32F3X series
- https://gerrit.zephyrproject.org/r/8926 : kernel: introduce single-threaded kernel
- https://gerrit.zephyrproject.org/r/7664 : second test
- https://gerrit.zephyrproject.org/r/8930 : subsys: disk: Refactor disk_access stuff into a directory
- https://gerrit.zephyrproject.org/r/8888 : iot/dns: Use a k_timer for the DNS rx routine
- https://gerrit.zephyrproject.org/r/8923 : tests/iot/http: Initialize parser struct
- https://gerrit.zephyrproject.org/r/8889 : iot/dns: Update sample application
- https://gerrit.zephyrproject.org/r/8887 : iot/dns: Update DNS client private routines
- https://gerrit.zephyrproject.org/r/8886 : iot/dns: Introduce the dns_context structure
- https://gerrit.zephyrproject.org/r/7104 : drivers: spi: Add nRF5 SPI slave driver
- https://gerrit.zephyrproject.org/r/8925 : cc3200: Ensure UART can wake up Zephyr after wfi in idle

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8959 : logging: Remove bogus SYS_LOG dependency on STDOUT_CONSOLE
- https://gerrit.zephyrproject.org/r/8964 : samples: aio: fix some coding style issues
- https://gerrit.zephyrproject.org/r/8965 : samples: spi_flash: remove redundant code lines from config file
- https://gerrit.zephyrproject.org/r/8966 : drivers: sensor: add missing license header
- https://gerrit.zephyrproject.org/r/8955 : Bluetooth: Remove not needed header in uuid.c file
- https://gerrit.zephyrproject.org/r/8954 : Bluetooth: Fix format specifier in UUID DBG helpers
- https://gerrit.zephyrproject.org/r/8948 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/8912 : drivers: usb: remove unneeded include path additions
- https://gerrit.zephyrproject.org/r/8913 : drivers: timers: remove unneeded include path addition
- https://gerrit.zephyrproject.org/r/8914 : drivers: slip: remove unneeded include path addition
- https://gerrit.zephyrproject.org/r/8920 : samples/logger-hook: Increase main stack size
- https://gerrit.zephyrproject.org/r/8921 : samples/logger-hook: Initialize variable to 0
- https://gerrit.zephyrproject.org/r/8933 : samples: echo apps: Use Kconfig options to setup IPv6 on cc2520 config
- https://gerrit.zephyrproject.org/r/8910 : net: echo_client: Enable Bluetooth support
- https://gerrit.zephyrproject.org/r/8939 : samples: wpanusb: Removing legacy left-over


Re: reg: zephyr 1.6 => samples\usb\console

Chuck Jordan <Chuck.Jordan@...>
 

So I think I misunderstood since "console" is a name can have various meanings.
But I think Zephyr's use of console is the one-and-only-one place your printk's go ... True?

The notion of a CLI or SHELL is the thing that might need to have multiple instantiations - and if you have a collection of UARTs out there, I suppose it is up to the application whether it wants to spawn a task for n UART ports and support n shells, etc.
Not all UART ports would necessarily be used in that way. They might be opened for use with modem or point-to-point connection to another computer, or to talk to a little chip that provides UART connectivity, etc.

-Chuck

From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Friday, December 09, 2016 3:45 PM
To: Chuck Jordan <Chuck.Jordan(a)synopsys.com>; Joseph, Jithu <jithu.joseph(a)intel.com>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: zephyr 1.6 => samples\usb\console

We do support the use case of selecting which UART to use for console, for instance on Nios II we used to have the JTAG UART as the default console instead of the 16550. But the way this is configured is pretty unintuitive.
Don't think we support sending console to multiple UARTS yet.

Andrew

From: Chuck Jordan [mailto:Chuck.Jordan(a)synopsys.com]
Sent: Friday, December 9, 2016 12:41 PM
To: Joseph, Jithu <jithu.joseph(a)intel.com<mailto:jithu.joseph(a)intel.com>>; 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: zephyr 1.6 => samples\usb\console

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 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: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Re: reg: zephyr 1.6 => samples\usb\console

Boie, Andrew P
 

We do support the use case of selecting which UART to use for console, for instance on Nios II we used to have the JTAG UART as the default console instead of the 16550. But the way this is configured is pretty unintuitive.
Don't think we support sending console to multiple UARTS yet.

Andrew

From: Chuck Jordan [mailto:Chuck.Jordan(a)synopsys.com]
Sent: Friday, December 9, 2016 12:41 PM
To: Joseph, Jithu <jithu.joseph(a)intel.com>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 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: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Re: reg: zephyr 1.6 => samples\usb\console

Chuck Jordan <Chuck.Jordan@...>
 

Well actually, I guess there are two concepts:

* "console" which could be printk's from even kernel code - going to one-and-only-one place

* "cli" - command line interface, which might support ascii commands, command-line-edit, history - such as the "readline" API.
It would be "cli" that could appear in many instantiations.

-Chuck

From: Chuck Jordan
Sent: Friday, December 09, 2016 2:41 PM
To: 'Joseph, Jithu' <jithu.joseph(a)intel.com>; Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: RE: reg: zephyr 1.6 => samples\usb\console

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 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: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Re: reg: zephyr 1.6 => samples\usb\console

Chuck Jordan <Chuck.Jordan@...>
 

Actually, it would be more ideal if on any given UART port, you could designate whether or not it should run a console, or be left to be open by the Application for some other purpose. If you had 2 UARTS, you might want a console on each.
OR you might want one to be running a modem and the other as a console.

Consoles should also APPEAR above a TELNET service if wifi/enet, if wanted.

Or a console on USB - yes.

I suppose even a web page can have a console inside - if someone implements that - and it could be more secure with ssl.

Consoles might also be wanted over JTAG - if JTAG has UART.

-Chuck


From: Joseph, Jithu [mailto:jithu.joseph(a)intel.com]
Sent: Monday, December 05, 2016 12:49 PM
To: Mahendravarman Rajarao (RBEI/EAA3) <Mahendravarman.Rajarao(a)in.bosch.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: reg: zephyr 1.6 => samples\usb\console

Please find the answers below :

Device binding is not needed for console display ?
No - application code need not do that. It is enough that the apps define CONFIG_UART_CONSOLE_ON_DEV_NAME if they want to override the default console device


Console output devices are opened from uart_console_init() ( drivers/console/uart_console.c ) as

uart_console_dev = device_get_binding(CONFIG_UART_CONSOLE_ON_DEV_NAME);


If CONFIG_USB_UART console is defined, CONFIG_UART_CONSOLE_ON_DEV_NAME defaults to "CDC_ACM" via (arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series)


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

The first one implements an echo type console on usb UART, wherein whatever character you type in minicom comes to the zephyr device and is echoed back to minicom. (While the debug prints still get routed to the actual physical uart). So in the sample app code you would see this logic.



In the second case, the config options cause the effect that all the debug prints come out via minicom on the host via the USB UART . The logic is mostly in the console driver (to plumb all the printks to USB UART) and the sample is meant to show config options as called out in README.



Hope that helps.

Thanks
Jithu

From: Mahendravarman Rajarao (RBEI/EAA3) [mailto:Mahendravarman.Rajarao(a)in.bosch.com]
Sent: Monday, December 5, 2016 5:18 AM
To: devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>
Subject: [devel] reg: zephyr 1.6 => samples\usb\console

Hi

Please help on the following

In the latest zephyr 1.6 release , under samples\usb\console folder, the example is given to show the console output coming to USB UART.

dev = device_get_binding(CONFIG_CDC_ACM_PORT_NAME); is missing in this console example
Device binding is not needed for console display ?


What the difference between the samples\usb\cdc_acm and samples\usb\console codes ?

Best regards
Mahendravarman


Re: tinycrypt - mbedtls

Rodriguez, Sergio SF <sergio.sf.rodriguez@...>
 

Hi all,

One of the points was that the crypto algorithms and cyphers of mbedTLS cover the ones required for secure connection protocols (e.g. Thread). The mbedTLS library is more oriented to use by secure connection protocols (TLS, DTLS) and cryptography is not only its main usage.

TinyCrypt provides a minimal set of standard cryptography primitives and does not have TLS/DTLS support.

Regards
Sergio
________________________________________
From: Marcus Shawcroft [marcus.shawcroft(a)gmail.com]
Sent: Friday, December 09, 2016 12:48 AM
To: devel(a)lists.zephyrproject.org
Cc: Heath, Constanza M; Santes, Flavio; Joseph, Jithu; Rodriguez, Sergio SF; Tseng, Kuo-Lang
Subject: Re: tinycrypt - mbedtls

Adding the various maintainers CC...

Your thoughts/views on this would be much appreciated...

On 30 November 2016 at 11:27, Marcus Shawcroft
<marcus.shawcroft(a)gmail.com> wrote:
Hi,

We have two crypto libraries in /ext, tinycrypt and mbedtls. Can
someone help me understand:
- What is the plan / strategy here, are we moving the code base from
one to the other.
- Do we expect both to coexist in the tree long term.
- Where there are overlaps in features/capability are we intending to
prefer one implementation over the other.

?

Cheers
/Marcus


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/8945 : sensor: remove SENSOR_VALUE_TYPE_INT
- https://gerrit.zephyrproject.org/r/8949 : samples: zperf: Correct the include files path to eliminate compile errors
- https://gerrit.zephyrproject.org/r/8946 : sensor: use integers for simple value calculations
- https://gerrit.zephyrproject.org/r/8948 : Merge bluetooth branch into master
- https://gerrit.zephyrproject.org/r/8944 : sensor: remove unused Q16_16 value type
- https://gerrit.zephyrproject.org/r/8941 : drivers/flash: add stm32F4xx flash driver
- https://gerrit.zephyrproject.org/r/8942 : boards: stm32f4x: Enable Flash driver
- https://gerrit.zephyrproject.org/r/8947 : sensor: update drivers to not return double values
- https://gerrit.zephyrproject.org/r/8943 : frdm_k64f: Setup PTC12 pin as GPIO
- https://gerrit.zephyrproject.org/r/8937 : drivers: eth_ksdk: There is a unique L2 driver
- https://gerrit.zephyrproject.org/r/8936 : drivers: eth_ksdk: Theres is no longer 'ETHERNET' Kconfig option
- https://gerrit.zephyrproject.org/r/8931 : kernel: Refactor remaining time evaluation for timeouts
- https://gerrit.zephyrproject.org/r/8932 : kernel: Introduce new k_delayed_work_remaining_get API
- https://gerrit.zephyrproject.org/r/8929 : samples: sensor: fxos8700: Check sample fetch return value
- https://gerrit.zephyrproject.org/r/8921 : samples/logger-hook: Initialize variable to 0
- https://gerrit.zephyrproject.org/r/8923 : tests/iot/http: Initialize parser struct
- https://gerrit.zephyrproject.org/r/8919 : tests/tcp: Initialize buffer to NULL
- https://gerrit.zephyrproject.org/r/8926 : kernel: introduce single-threaded kernel
- https://gerrit.zephyrproject.org/r/8930 : subsys: disk: Refactor disk_access stuff into a directory
- https://gerrit.zephyrproject.org/r/8928 : driver: pwm: give arc the access to pwm
- https://gerrit.zephyrproject.org/r/8927 : samples: gpio: use correct gpio driver name
- https://gerrit.zephyrproject.org/r/8925 : cc3200: Ensure UART can wake up Zephyr after wfi in idle
- https://gerrit.zephyrproject.org/r/8913 : drivers: timers: remove unneeded include path addition
- https://gerrit.zephyrproject.org/r/8914 : drivers: slip: remove unneeded include path addition
- https://gerrit.zephyrproject.org/r/8920 : samples/logger-hook: Increase main stack size
- https://gerrit.zephyrproject.org/r/8924 : arm: Fix irq offload inline asm memory ordering.
- https://gerrit.zephyrproject.org/r/8917 : net: tcp: Select correct source address for SYNACK packets
- https://gerrit.zephyrproject.org/r/8922 : scripts: Add device tree parser script
- https://gerrit.zephyrproject.org/r/8912 : drivers: usb: remove unneeded include path additions
- https://gerrit.zephyrproject.org/r/8916 : jira: install jira pip package locally

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/7612 : Bluetooth: AVDTP: Add AV-Stream data structure
- https://gerrit.zephyrproject.org/r/4358 : net: samples: Revamp QEMU-QEMU networking in echo_server & echo_client
- https://gerrit.zephyrproject.org/r/8714 : [DO NOT SUBMIT] RFC: Bluetooth: SDP client API user concept draft
- https://gerrit.zephyrproject.org/r/7263 : Bluetooth: HFP HF: Implement missing callback for indicators
- https://gerrit.zephyrproject.org/r/7076 : Bluetooth: AT: Change API name skip_whitespace to skip_space
- https://gerrit.zephyrproject.org/r/7030 : Bluetooth: HFP HF: SLC Connection send/parse CIND
- https://gerrit.zephyrproject.org/r/7077 : Bluetooth: HFP HF: SLC query indicators present value
- https://gerrit.zephyrproject.org/r/7029 : Bluetooth: AT: Command parsing for range of values
- https://gerrit.zephyrproject.org/r/7028 : Bluetooth: AT: Improve API() to work with buffer increment
- https://gerrit.zephyrproject.org/r/6291 : Bluetooth: SDP: Initial SDP client interface API
- https://gerrit.zephyrproject.org/r/8826 : pinmux: Introduce new ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8830 : pinmux: Deprecate the k64 pinmux driver
- https://gerrit.zephyrproject.org/r/8829 : k64: Change the default pinmux driver to the ksdk one
- https://gerrit.zephyrproject.org/r/8827 : frdm_k64f: Add pin init using ksdk pinmux driver
- https://gerrit.zephyrproject.org/r/8823 : drivers: spi_k64: Fix slave select
- https://gerrit.zephyrproject.org/r/8824 : drivers: spi_k64: Set PCS as activ low and continuous per default
- https://gerrit.zephyrproject.org/r/8893 : drivers: spi_k64: Fix premature shutdown of SPI
- https://gerrit.zephyrproject.org/r/7103 : defconfig: 96b_carbon: Enable the SPI driver by default
- https://gerrit.zephyrproject.org/r/7107 : tests: Add spi_masterslave test program
- https://gerrit.zephyrproject.org/r/7106 : boards: 96b_carbon_nrf51: add support for 96Boards Carbon nRF51 chip
- https://gerrit.zephyrproject.org/r/7102 : defconfig: nucleo_f401re: Enable the SPI driver by default
- https://gerrit.zephyrproject.org/r/7104 : drivers: spi: Add nRF5 SPI slave driver
- https://gerrit.zephyrproject.org/r/7101 : drivers: spi: Add STM32f4 SPI driver
- https://gerrit.zephyrproject.org/r/7098 : pinmux: stm32f4: Setup SPI pins
- https://gerrit.zephyrproject.org/r/8902 : defconfig: 96b_nitrogen: Enable the SPI slave driver by default
- 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/7099 : pinmux: nucleo_f401re: Setup SPI pins on the board
- https://gerrit.zephyrproject.org/r/7100 : pinmux: 96b_carbon: Setup SPI pins on the board
- https://gerrit.zephyrproject.org/r/8894 : tests: spi_test: refactor and add support for the k64
- https://gerrit.zephyrproject.org/r/8886 : iot/dns: Introduce the dns_context structure
- https://gerrit.zephyrproject.org/r/8871 : random: Restructure RANDOM Kconfig
- https://gerrit.zephyrproject.org/r/6149 : Test: Ignore, just for testing purposes.
- https://gerrit.zephyrproject.org/r/8897 : samples/zoap-client: Fix using wrong addresses
- https://gerrit.zephyrproject.org/r/8887 : iot/dns: Update DNS client private routines
- https://gerrit.zephyrproject.org/r/8888 : iot/dns: Use a k_timer for the DNS rx routine
- https://gerrit.zephyrproject.org/r/8889 : iot/dns: Update sample application
- https://gerrit.zephyrproject.org/r/7217 : meta-zephyr-sdk: disable MIPS

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/8933 : samples: echo apps: Use Kconfig options to setup IPv6 on cc2520 config
- https://gerrit.zephyrproject.org/r/8910 : net: echo_client: Enable Bluetooth support
- https://gerrit.zephyrproject.org/r/8939 : samples: wpanusb: Removing legacy left-over
- https://gerrit.zephyrproject.org/r/8940 : Bluetooth: Fix stack overhead amount when debug is enabled
- https://gerrit.zephyrproject.org/r/8935 : Bluetooth: Fix left-over printf usage
- https://gerrit.zephyrproject.org/r/8934 : Bluetooth: Fix BT_STACK_DEBUG_EXTRA for BLUETOOTH_DEBUG_LOG
- https://gerrit.zephyrproject.org/r/8918 : drivers: bluetooth: nble: remove unneeded include path additions
- https://gerrit.zephyrproject.org/r/8907 : Bluetooth: L2CAP: Fix uninitialized pointer
- https://gerrit.zephyrproject.org/r/8906 : boards: nrf51_pca10028: Add button and LED definitions
- https://gerrit.zephyrproject.org/r/8908 : boards: nrf52_pca10040: Add button and LED definitions
- https://gerrit.zephyrproject.org/r/8909 : boards: nrf52840_pca10056: Add button and LED definitions
- https://gerrit.zephyrproject.org/r/8911 : boards: bbc_microbit: Add button and LED definitions
- https://gerrit.zephyrproject.org/r/8715 : samples: net: echo apps: Add cc2520 configuration for frdm_k64f
- https://gerrit.zephyrproject.org/r/6305 : net: echo_server: Enable Bluetooth support
- https://gerrit.zephyrproject.org/r/8744 : Bluetooth: shell: Add support for RFCOMM Disconnect
- https://gerrit.zephyrproject.org/r/8743 : Bluetooth: RFCOMM: Implement Disconnect API
- https://gerrit.zephyrproject.org/r/8905 : boards: arm: Refactor the GPIO and UART dependencies
- https://gerrit.zephyrproject.org/r/8761 : kernel: Disable interrupts after tick calculation in k_sleep()


Re: tinycrypt - mbedtls

Marcus Shawcroft <marcus.shawcroft@...>
 

Adding the various maintainers CC...

Your thoughts/views on this would be much appreciated...

On 30 November 2016 at 11:27, Marcus Shawcroft
<marcus.shawcroft(a)gmail.com> wrote:
Hi,

We have two crypto libraries in /ext, tinycrypt and mbedtls. Can
someone help me understand:
- What is the plan / strategy here, are we moving the code base from
one to the other.
- Do we expect both to coexist in the tree long term.
- Where there are overlaps in features/capability are we intending to
prefer one implementation over the other.

?

Cheers
/Marcus


Re: Reg: Zephyr 1.6 GPIO Mask and Unmask gpio interrupts

Tomasz Bursztyka
 

Hi,

Have a look at samples/basic/button/src/main.c for instance.

Zephyr GPIO API first requires to configure it through gpio_pin_configure()
and then to setup a callback and enabled/disable the relevant pin for
that callback (you can do it by port directly,
if you need multiples pins at once). We don't expose the mask/unmask
logic directly.

Tomasz

Hi tomasz and mahendra

what #define to be used in gpio_pin_configure to mask and unmask gpio
interrupt ?
can you help me with an example ?

On Thu, Dec 8, 2016 at 8:20 PM, Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com
<mailto:tomasz.bursztyka(a)linux.intel.com>> wrote:

Hi,

So from the application level to mask and unmask gpio interrupts
can I use QM_IR_MASK_INTERRUPTS & QM_IR_UNMASK_INTERRUPTS functions

(Or) should I use settings in gpio_pin_configure function ??
The second one. Always use the Zephyr GPIO API, so include/gpio.h

Tomasz


Re: k_timer

Flavio Santes <flavio.santes@...>
 

Hello Johan,

I was thinking on adding an additional parameter to the callbacks as seen in some cb's that receive the "user_data" parameter. So, it seems the best way to solve this is with CONTAINER_OF. Thanks for the feedback!

Regards,
Flavio


Re: k_timer

Johan Hedberg
 

Hi Flavio,

On Thu, Dec 08, 2016, Flavio Santes wrote:
After playing a bit with k_timer and the expiry and stop callbacks, I
realize that there is no way to manipulate application specific data
inside the callbacks. These routines are implemented by the user so it
makes sense that user-provided data can be manipulated inside expiry
and stop routines. What do you think?
At least I'm using CONTAINER_OF() to accomplish this. I think that's the
main idea of how these APIs are designed (same with k_work as well). So
you embed these objects in your "user data" struct and the get back your
own struct in the callback with the help of CONTAINER_OF.

Johan

5741 - 5760 of 7751