Date   

Re: EMULATOR BOARD QEMU

Andrei
 

Hi,

On Thu, Oct 25, 2018 at 05:42:06PM -0300, Amir Camillo wrote:
I want to learn how to use sephyr, I am not finding the steps to emulate
the boards in qemu, I would like to know how to emulate the ZEPHYR IN A
QEMU EMULATOR. 
https://docs.zephyrproject.org/latest/boards/x86/qemu_x86/doc/board.html

cd $ZEPHYR_BASE/samples/synchronization
mkdir build && cd build

# Use cmake to configure a Ninja-based build system:
cmake -GNinja -DBOARD=qemu_x86 ..

# Now run ninja on the generated build system:
ninja run

Best regards
Andrei Emeltchenko


Re: [RFC] k_poll_signal name and MISRA

Nashif, Anas
 

I think this was just a typo __

On 25/10/2018, 21:39, "devel@lists.zephyrproject.org on behalf of Abderrezak Mekkaoui" <devel@lists.zephyrproject.org on behalf of ab.mekka@gmail.com> wrote:

Hi Flavio,

First thing that came to my mind when I saw k_pll is a PLL. Hopefully
there is a better abbreviation for poll than pll.
Regards
Abderrezak Mekkaoui

On 10/25/2018 4:06 PM, Flavio Ceolin wrote:
> Hi guys,
>
> MISRA-C rule 5.7 says that a tag name shall be a unique identifier, also
> reuse tag names is an undefined behavior recognized in C99 (Section
> 6.7.2.3).
>
> It happens that we have in Zephyr both a struct and a function called
> k_poll_signal (there may be others cases in the project), the question
> is, what it is preferable, change the function to something like,
> k_pll_signal_signal() or change the struct nam ? In the latter, what is the
> suggestion ? Remembering that I'll follow this pattern if necessary.
>
>
> Regards,
> Flavio Ceolin
>
>
>


EMULATOR BOARD QEMU

Amir Camillo <amircam@...>
 

I want to learn how to use sephyr, I am not finding the steps to emulate the boards in qemu, I would like to know how to emulate the ZEPHYR IN A QEMU EMULATOR. 

tHANK'S 

--


Re: [RFC] k_poll_signal name and MISRA

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi Flavio,

First thing that came to my mind when I saw k_pll is a PLL. Hopefully there is a better abbreviation for poll than pll.
Regards
Abderrezak Mekkaoui

On 10/25/2018 4:06 PM, Flavio Ceolin wrote:
Hi guys,

MISRA-C rule 5.7 says that a tag name shall be a unique identifier, also
reuse tag names is an undefined behavior recognized in C99 (Section
6.7.2.3).

It happens that we have in Zephyr both a struct and a function called
k_poll_signal (there may be others cases in the project), the question
is, what it is preferable, change the function to something like,
k_pll_signal_signal() or change the struct nam ? In the latter, what is the
suggestion ? Remembering that I'll follow this pattern if necessary.


Regards,
Flavio Ceolin


[RFC] k_poll_signal name and MISRA

Flavio Ceolin
 

Hi guys,

MISRA-C rule 5.7 says that a tag name shall be a unique identifier, also
reuse tag names is an undefined behavior recognized in C99 (Section
6.7.2.3).

It happens that we have in Zephyr both a struct and a function called
k_poll_signal (there may be others cases in the project), the question
is, what it is preferable, change the function to something like,
k_pll_signal_signal() or change the struct nam ? In the latter, what is the
suggestion ? Remembering that I'll follow this pattern if necessary.


Regards,
Flavio Ceolin


IPv6 Mesh over BLUETOOTH Low Energy using IPSP

Reto Schneider
 

Hi all,

Via the paper "Bluetooth Low Energy Mesh Networks: A Survey" [1] I found
out about the WIP IETF RFC "IPv6 Mesh over BLUETOOTH(R) Low Energy using
IPSP" [2].

Being able to use IPv6 over a meshed BLE network looks very promising to
me and I am wondering if anyone in the Zephyr community is working on
this or at least interested?

[1]
https://www.researchgate.net/publication/317822566_Bluetooth_Low_Energy_Mesh_Networks_A_Survey
[2] https://tools.ietf.org/html/draft-ietf-6lo-blemesh-03

Kind regards,
Reto


lwip integration with OpenThread #nrf52840 #lwip #openthread

deepa.gopinath@...
 

Hi all,
 
For reference, Can you please share an lwip example application built on top of Zephyrt's OpenThread integration code base?
Do you support all the features of OT stack in Zephyrt's OpenThread integration code?
 
Thanks & Regards,
Deepa


Re: SPI Kconfig.nrfx changes in recent (1.13.99) clone - setting GPIO pins for SPI master now fails.

Jan Van Winkel
 

Hi Chuck,

As far as I know a lot of progress is ongoing in Zephyr to move to DTS and if I'm not mistaken I2C was there before SPI.

Regards,
Jan



On Mon, Oct 22, 2018 at 10:23 PM <cpmcparland@...> wrote:
Jan,

Thanks....am working on an overlay now.  Sure makes the prj.cfg look a lot
cleaner.  Am I right to expect that this sort of transformation will make its way
into other drivers as well (e.g. I2C)?

Regards,
Chuck


Re: SPI Kconfig.nrfx changes in recent (1.13.99) clone - setting GPIO pins for SPI master now fails.

cpmcparland@...
 

Jan,

Thanks....am working on an overlay now.  Sure makes the prj.cfg look a lot
cleaner.  Am I right to expect that this sort of transformation will make its way
into other drivers as well (e.g. I2C)?

Regards,
Chuck


subsys/storage/flash_map - FLASH_DEV_NAME definition

Jiří Kubias <jiri.kubias@...>
 

Hi,
Im playing with subsys/storage/flash_map   and I have one problem with  flash_drivers_map structure.

Currently it is defined as 

struct driver_map_entry {
u8_t id;
const char * const name;
};

static const struct driver_map_entry  flash_drivers_map[] = {
#ifdef FLASH_DEV_NAME /* SoC embedded flash driver */
{SOC_FLASH_0_ID, FLASH_DEV_NAME},
#endif
#ifdef CONFIG_SPI_FLASH_W25QXXDV
{SPI_FLASH_0_ID, CONFIG_SPI_FLASH_W25QXXDV_DRV_NAME},
#endif
};

Im using SOC flash map so I need to define FLASH_DEV_NAME  - by looking into the source codes is sees tat it should be defined in dts.fixup  - for example it is defined in:
./arch/arm/soc/nordic_nrf/nrf52/dts.fixup:29:#define FLASH_DEV_NAME                     NRF_NRF52_FLASH_CONTROLLER_4001E000_LABEL

But from structure driver_map_entry definition the second variable must be a const char * const name - so it does not fit. 

So am I doing something wrong or it is need some fixes in Zephyr? In my opinion is should be defined in .config file as CONFIG_FLASH_MAP_DEV_NAME   

Im using 1.13.0 as stable release.

Regards, 
Jiri




--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


Re: SPI Kconfig.nrfx changes in recent (1.13.99) clone - setting GPIO pins for SPI master now fails.

Jan Van Winkel
 

Hi Chuck,

SPI config has switched to devicetree and you only need following configs in you prj.conf file for SPI_0:
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_NRFX=y

All other configurations come from the boards DTS files. Have a look at boards/arm/nrf52840_pca10059/nrf52840_pca10059.dts and dts/arm/nordic/nrf52840.dtsi . 

In case you need to adapt the default settings you can add an overlay to your project directory.

Regards,
Jan
 

On Mon, Oct 22, 2018 at 1:18 AM <cpmcparland@...> wrote:
My zephyr app, built on ver 1.13.0 with the following prj.cfg file:

CONFIG_FLOAT=y
CONFIG_FP_SHARING=y
CONFIG_NEWLIB_LIBC=y
CONFIG_HEAP_MEM_POOL_SIZE=16384

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_ASYNC=y
CONFIG_SPI_0_NAME="SPI_0"
CONFIG_SPI_0_OP_MODES=1
CONFIG_SPI_0_IRQ_PRI=0
CONFIG_SPI_NRFX=y
CONFIG_SPI_0_NRF_SPIM=y
CONFIG_SPI_0_NRF_SCK_PIN=28
CONFIG_SPI_0_NRF_MOSI_PIN=29
CONFIG_SPI_0_NRF_MISO_PIN=30
CONFIG_SPI_0_NRF_ORC=0xf

built and ran successfully on a nrf52840_pca10056 board.  I have recently updated to ver 1.13.99 and it no longer
gets through cmake because several symbols are no longer in the Kconfig.nrfx file for the SPI driver.  Namely,
CONFIG_SPI_0_SCK_PIN, _MOSI_PIN, and _MISO_PIN. I need to set these pins to coincide with target hardware,
Also, SPI_0_NAME seems to have disappeared.

Looking more closely at the Kconfig.nrfx files from both clones, the latest version has changed and does not include
symbols to set up these pins.  I guess I could edit the .config file, but that would be overwritten every time I run cmake.

Maybe I'm just out of phase here.  Is there a nrf spim driver update in progress?  Any help would be appreciated.

Thanks,
Chuck


Workq stack size confusion

Christoph Schramm <schramm@...>
 

Dear All,

 

I’m really confused about the workqs at the moment.

I want to implement a modem driver and for that I need a Workq to process AT commands sequentially. Idea was, to have multiple structs carrying info about the stacks, so I tried to create a “device context struct” like this:

 

struct uart_dev_ctx {

  struct k_thread rx_thread;
  struct _k_thread_stack_element* rx_thread_stack;

}

 

But it seems this is not legal, because when accessing the stack, I immediately get MPU faults.

 

This is how I simply assign it:

dev_ctx.rx_thread = quectelmdm_rx_thread;
dev_ctx.
rx_thread_stack = quectelmdm_rx_stack;

 

I checked with

STACK_ANALYZE("RX stack", dev_ctx.rx_thread_stack);

And it gives “4” (which is the alignment size)

 

While

STACK_ANALYZE("RX stack", quectelmdm_rx_stack);

gives 1024 which is correct and the real size

 

Any suggestions how I can share Stacks with structs?

 

Thanks,

Chris


SPI Kconfig.nrfx changes in recent (1.13.99) clone - setting GPIO pins for SPI master now fails.

cpmcparland@...
 

My zephyr app, built on ver 1.13.0 with the following prj.cfg file:

CONFIG_FLOAT=y
CONFIG_FP_SHARING=y
CONFIG_NEWLIB_LIBC=y
CONFIG_HEAP_MEM_POOL_SIZE=16384

CONFIG_GPIO=y
CONFIG_SPI=y
CONFIG_SPI_0=y
CONFIG_SPI_ASYNC=y
CONFIG_SPI_0_NAME="SPI_0"
CONFIG_SPI_0_OP_MODES=1
CONFIG_SPI_0_IRQ_PRI=0
CONFIG_SPI_NRFX=y
CONFIG_SPI_0_NRF_SPIM=y
CONFIG_SPI_0_NRF_SCK_PIN=28
CONFIG_SPI_0_NRF_MOSI_PIN=29
CONFIG_SPI_0_NRF_MISO_PIN=30
CONFIG_SPI_0_NRF_ORC=0xf

built and ran successfully on a nrf52840_pca10056 board.  I have recently updated to ver 1.13.99 and it no longer
gets through cmake because several symbols are no longer in the Kconfig.nrfx file for the SPI driver.  Namely,
CONFIG_SPI_0_SCK_PIN, _MOSI_PIN, and _MISO_PIN. I need to set these pins to coincide with target hardware,
Also, SPI_0_NAME seems to have disappeared.

Looking more closely at the Kconfig.nrfx files from both clones, the latest version has changed and does not include
symbols to set up these pins.  I guess I could edit the .config file, but that would be overwritten every time I run cmake.

Maybe I'm just out of phase here.  Is there a nrf spim driver update in progress?  Any help would be appreciated.

Thanks,
Chuck


Re: bt_le_scan of node in Mesh network

Martin <ma@...>
 

Hi!
Thanks, this looks exactly like what I was looking for. Even seems to
be easier than the NRF52 SDK-approach with the timing API.

Best Regards,
Martin
Am Mo., 15. Okt. 2018 um 08:25 Uhr schrieb <julian.schneider@ledcity.ch>:


Hi Martin,
We needed the same functionality that you are describing.

After some analysis of the BT Mesh subsystem in the Zephryr, we came to the same conclusion as Vinayak. The Mesh system is using the BT 4 features to receive packages itself, i.e. the Mesh subsystem starts scanning with bt_le_scan on initialization and registeres its own callback (bt_mesh_scan_cb in Zephyr/subsys/bluetooth/host/mesh/adv.c). The system does not allow a second (concurrent) call of bt_le_scan.

Hence, the only option is a small adaptation of the Zephyr source.
The Mesh scan callback only recognises Mesh specific scan packages and ignores the rest. Introducing an extra callback enabled us to receive all scan packages that are ignored by Mesh (see code snipped below).

Best,
Julian

Here is a code snippet of our adaptations of adv.c starting on line 253:
///////////////////changes here
//callback function pointer to be set from project code
void (*bt_mesh_scan_unprocressed_nonconn_ad_cb)(const bt_addr_le_t *addr, s8_t rssi,
struct net_buf_simple *buf, u8_t type_from_buf, u8_t data_len) = NULL;
/////////////////

static void bt_mesh_scan_cb(const bt_addr_le_t *addr, s8_t rssi,
u8_t adv_type, struct net_buf_simple *buf)
{
if (adv_type != BT_LE_ADV_NONCONN_IND) {
return;
}

BT_DBG("len %u: %s", buf->len, bt_hex(buf->data, buf->len));

while (buf->len > 1) {
struct net_buf_simple_state state;
u8_t len, type;

len = net_buf_simple_pull_u8(buf);
/* Check for early termination */
if (len == 0) {
return;
}

if (len > buf->len) {
BT_WARN("AD malformed");
return;
}

net_buf_simple_save(buf, &state);

type = net_buf_simple_pull_u8(buf);

buf->len = len - 1;

switch (type) {
case BT_DATA_MESH_MESSAGE:
bt_mesh_net_recv(buf, rssi, BT_MESH_NET_IF_ADV);
break;
#if defined(CONFIG_BT_MESH_PB_ADV)
case BT_DATA_MESH_PROV:
bt_mesh_pb_adv_recv(buf);
break;
#endif
case BT_DATA_MESH_BEACON:
bt_mesh_beacon_recv(buf);
break;
///////////////////changes here
default:
if (bt_mesh_scan_unprocressed_nonconn_ad_cb != NULL)
bt_mesh_scan_unprocressed_nonconn_ad_cb(addr,rssi,buf,type,len-1);
break;
/////////////////
}

net_buf_simple_restore(buf, &state);
net_buf_simple_pull(buf, len);
}
}


Re: Slip TCP connection between linux host and nrf52840

Andrei Emeltchenko <andrei.emeltchenko@...>
 

Hi,

On Thu, Oct 18, 2018 at 11:22:10AM -0700, cpmcparland@rtisys.org wrote:
All,

Thanks for the suggestions and sharing results.  I think I'll go with USB
network device solution.  I've tried the sample "samples/net/echo_server"
and, with the addition of the overlay-netusb(?) to the prj.config, it came
up and worked.  The current docs have the 3 additional linux side commands
to add the enumerated net device to the linux ip stack, bring it up and,
lastly, provide a route. 
Some Linux distros might do most of work configuring interfaces for you.

If you enable IPv4 autoconfiguration and LLMNR or mDNS you should be able
to access zephyr with short name "zephyr" or "zephyr.local".
We need to document this though...

Best regards
Andrei Emeltchenko

Adding the overlay config file in the cmake is a
nice trick, but took a bit of digging to find an example. I hope this
solution will be stable...will report on results.  It seems to have fewer
moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble
(hopefully bluetooth 5) net into a linux platform.  Initially tried
setting up a HCI connection to zephyr hci firmware running in the ble
dongle; but, couldn't get the HCI interface to come up on the linux side.
While wading through the btattach and config docs, I came across the usb
network device option.  Fortunately, I have sufficient resources on the
dongle to run a dual stack (ip/ble) and add an app to bring the stream
into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's
my plan at the moment.  But, I am curious about how others are dealing
with this issue....are folks using (or waiting for!) commercial ble/ip
gateways to bridge this gap or is there another solution I'm not aware of
yet?

Cheers,
Chuck


References

Visible links
1. https://lists.zephyrproject.org/g/devel/message/5263
2. mailto:cpmcparland@rtisys.org?subject=Private:%20Re:%20Re%3A%20%5BZephyr-devel%5D%20Slip%20TCP%20connection%20between%20linux%20host%20and%20nrf52840
3. mailto:devel@lists.zephyrproject.org?subject=Re:%20Re%3A%20%5BZephyr-devel%5D%20Slip%20TCP%20connection%20between%20linux%20host%20and%20nrf52840
4. https://lists.zephyrproject.org/mt/27261061/900599
5. https://lists.zephyrproject.org/g/devel/post
6. https://lists.zephyrproject.org/g/devel/editsub/900599
7. mailto:devel+owner@lists.zephyrproject.org
8. https://lists.zephyrproject.org/g/devel/unsub


Zephyr SDK 0.9.4-rc5 available for testing

Nashif, Anas
 

Hi,

A release candidate of the Zephyr SDK is available for general testing. It has the following changes since the 0.9.3 release:

 

-          New QEMU release (based on 3.0.0+git 19b599f7664b2ebfd0f405fb79c14dd241557452)

-          New OpenOCD based master with Zephyr related changes (commit: 05e0d633)

-          New DTC version 1.4.7+git (commit 2e930b7f8f6421638869a04b00297034c42e1a82)

 

The release can be found here: https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.4-rc5

 

 

Note:

Qemu for NIOS2 and RISCV are not compatible with current master of Zephyr and require additional changes that are maintained in pull request:

 

https://github.com/zephyrproject-rtos/zephyr/pull/10136

 

 

Please test that release and let us know if you find any issues.

 

Regards,

Anas

 

 

 


Re: Slip TCP connection between linux host and nrf52840

Paul Sokolovsky
 

Hello,

On Thu, 18 Oct 2018 11:22:10 -0700
cpmcparland@rtisys.org wrote:

All,
[]

ble/ipv6.  At least that's my plan at the moment.  But, I am curious
about how others are dealing with this issue...
I'm sure that someone without imagination would just stream data over
old good serial connection - either in textual form, as a sequence of
lines, or with some simple binary protocol.

From my side, I can only encourage people to play with something more
advanced than that - we need people to try that, report back results,
us fix it as needed. Oftentimes it's indeed a matter of docs
[1] (including common pitfalls and troubleshooting sections). So indeed,
without poking, too little and too slow will happen, so thanks for
trying it!


[1] I for one ate enough dogfood on playing with BLE IPSP support and
tried to provide detailed enough walkthru on setting it up in the
corresponding docs:
https://docs.zephyrproject.org/latest/samples/bluetooth/ipsp/README.html



Cheers,
Chuck
--
Best Regards,
Paul

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


Re: Slip TCP connection between linux host and nrf52840

cpmcparland@...
 

Marti,

Not rude at all...will look over your web site.  Finding the right fit for a commercial
embedded, mostly software product is a tough problem.  Will be interested to see
where you folks fit in the "app stack".  Will contact foundries.io separately if I have
further product questions.

Cheers,
Chuck


Re: Slip TCP connection between linux host and nrf52840

Marti Bolivar <marti@...>
 

Hi Chuck,

On Thu, Oct 18, 2018 at 12:22 PM <cpmcparland@...> wrote:
All,

Thanks for the suggestions and sharing results.  I think I'll go with USB network device solution.  I've tried the sample "samples/net/echo_server" and, with the addition of the overlay-netusb(?) to the prj.config, it came up and worked.  The current docs have the 3 additional linux side commands to add the enumerated net device to the linux ip stack, bring it up and, lastly, provide a route.  Adding the overlay config file in the cmake is a nice trick, but took a bit of digging to find an example. I hope this solution will be stable...will report on results.  It seems to have fewer moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble (hopefully bluetooth 5) net into a linux platform.  Initially tried setting up a HCI connection to zephyr hci firmware running in the ble dongle; but, couldn't get the HCI interface to come up on the linux side. While wading through the btattach and config docs, I came across the usb network device option.  Fortunately, I have sufficient resources on the dongle to run a dual stack (ip/ble) and add an app to bring the stream into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's my plan at the moment.  But, I am curious about how others are dealing with this issue....are folks using (or waiting for!) commercial ble/ip gateways to bridge this gap or is there another solution I'm not aware of yet?

Since you've asked, I guess it's not rude to note that my company (https://foundries.io/) does have Linux-based BLE/IP gateway software you can take a look at (with support for multiple architectures and boards). They're integrated with Zephyr; we provide detailed instructions in our docs for how to set them up etc. They work with nRF52840 on the Zephyr side, as well as other boards. The product is subscription-based but you get full source access.

Best,
Marti
 

Cheers,
Chuck


Re: Slip TCP connection between linux host and nrf52840

cpmcparland@...
 

All,

Thanks for the suggestions and sharing results.  I think I'll go with USB network device solution.  I've tried the sample "samples/net/echo_server" and, with the addition of the overlay-netusb(?) to the prj.config, it came up and worked.  The current docs have the 3 additional linux side commands to add the enumerated net device to the linux ip stack, bring it up and, lastly, provide a route.  Adding the overlay config file in the cmake is a nice trick, but took a bit of digging to find an example. I hope this solution will be stable...will report on results.  It seems to have fewer moving (and, perhaps, simpler)  parts on the linux side than using slip.

This issue has come up because my app needs to stream data from a ble (hopefully bluetooth 5) net into a linux platform.  Initially tried setting up a HCI connection to zephyr hci firmware running in the ble dongle; but, couldn't get the HCI interface to come up on the linux side. While wading through the btattach and config docs, I came across the usb network device option.  Fortunately, I have sufficient resources on the dongle to run a dual stack (ip/ble) and add an app to bring the stream into the linux box as ip - as opposed to hci + ble/ipv6.  At least that's my plan at the moment.  But, I am curious about how others are dealing with this issue....are folks using (or waiting for!) commercial ble/ip gateways to bridge this gap or is there another solution I'm not aware of yet?

Cheers,
Chuck

2761 - 2780 of 8041