1. users@lists.zephyrproject.org
  2. Messages
   Date   
Re: Enable traces on Serial Wire Output #debugging

Carles Cufi
 

Hi there,

 

We don’t use SWO but RTT (also from Segger) and we don’t need to reset the JLinkRTTViewer/Logger when we reset the target.

Could it be that the way Zephr flashes and then resets the target (pin reset vs software reset) is different from FreeRTOS?

 

In theory this is all handled by the on-board debugger chip so it should make no difference.

 

Which board are you using?

 

Carles

 

From: users@... <users@...> On Behalf Of David K via Lists.Zephyrproject.Org
Sent: 10 March 2020 17:13
To: users@...
Cc: users@...
Subject: Re: [Zephyr-users] Enable traces on Serial Wire Output #debugging

 

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks
Re: Enable traces on Serial Wire Output #debugging

David K
 

I am still struggling to figure out why I cannot keep receiving traces through reboots. On the same dev board with FreeRTOS it was consistent: I was able to log target resets without re-launching swoview.

I don't understand why even with the basics samples (blinky, button, ...) when I reset the target the SWO output is "broken" and I have to launch a new instance of swoview to get traces again. Is it something in the DTS to configure ?

Thanks
Re: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Carles Cufi
 

Hi all,

Due to the switch to summer time in the US, the meeting today is at 17h CET/8AM PDT, so in 15min.

Regards,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 10 March 2020 15:36
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>;
users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Just a friendly reminder that today's API meeting will be dedicated to
watchdog handling in Zephyr.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 05 March 2020 09:51
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to
watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a
temporary solution to what is ultimately a wider problem that requires
a discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the
CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and
document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and
- Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles
Re: API meeting next week: Focusing on watchdogs

Carles Cufi
 

Hi all,

Just a friendly reminder that today's API meeting will be dedicated to watchdog handling in Zephyr.

Thanks,

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 05 March 2020 09:51
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Cc: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting next week: Focusing on watchdogs

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to
watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a
temporary solution to what is ultimately a wider problem that requires a
discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the
CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and
document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-
Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles
Re: Opinions / experiences requested regarding choosing the right IoT embedded OS

Carles Cufi
 

Hi Noëlle,

 

Since I have participated in similar comparison efforts in the past, I thought I may post my two cents here.

Please do bear in mind the following disclaimers:

  • I work for a company that contributes to Zephyr
  • I have been involved with Zephyr for a number of years
  • My knowledge of other open source RTOS is limited to very basic use and examination of the codebase, as well as feedback from experience users
  • ThreadX is currently (still) proprietary and, AFAIK, there’s no way to inspect its source code

 

Trying to reply to your questions here:

 

  1. Yes, there is quite a big difference. Without any hard numbers to support that statement (though those should be easy to collect from commit logs), I believe the situation is quite different for both projects
    1. Contributions to Zephyr tend to come from silicon vendors (Intel, NXP, Nordic and others), from organizations that work closely with silicon vendors (Linaro) or from companies that use Zephyr as an RTOS in their products
    2. Contributions to RIOT seem to come more often from Universities (FU Berlin, INRIA and HAW Hamburg mainly)
    3. The Zephyr contributor base seems to be about 3x the one in RIOT (as per GitHub)
    4. When it comes to advantages and disadvantages, I think the obvious advantage for Zephyr is that silicon vendors tend to know their ICs very well, which makes optimizing for their hardware is more easily achieved. I assume the advantage with more research-oriented contributions (i.e. for RIOT) is the possibility to get access to more innovative (proven or unproven) technologies in some cases
  2. Well, the license is completely different. Zephyr uses the Apache v2.0 license, which is much more permissive than RIOT’s LGPLv2. IANAL, but with RIOT any changes you make to the RTOS codebase you will be obliged to contribute back to the community. With Zephyr anyone can take the codebase at any point in time and modify it at will without any obligations (except for attribution)
  3. Don’t really know RIOT’s model today, but Zephyr uses proven technologies (Devicetree and Kconfig) to describe the hardware and configure the software. RIOT is actually currently working on integrating support for those very technologies in the RTOS, following Zephyr’s steps. Zephyr uses vendor-provided HAL libraries to implement drivers in most cases, which benefit from additional testing and maturity since those HALs are typically used in several other software products, not only Zephyr
  4. I am not sure if there’s a clear, stated goal in terms of using the RTOS, but from experience the goal of the different companies using it seems to be to use it in actual, real-world products. In our case we use it as a building block for our SDK, which is the provided to our customers. Those customers end up making end-products which, by extension, run Zephyr
  5. Yes, power management in particular is under heavy development. I cannot compare to RIOT since I don’t know how much it supports. There are also upcoming changes identified as important by the community such as better timeout handling in the kernel, multiple improvements to the various driver APIs and more.
  6. Likely a few in some areas, but again, without an in-depth comparison it is difficult to share. There are likely some technical advantages to RIOT as well (especially in the area of networking, since RIOT seems to focus more on that).  Typically things like userspace support, multiple architecture support (including Xtensa and now Cortex-A), TEE support are features that are not common in other RTOS outside Zephyr.

 

Thanks,

 

Carles

 

 

From: users@... <users@...> On Behalf Of Noëlle Clement via Lists.Zephyrproject.Org
Sent: 09 March 2020 13:21
To: users@...
Cc: users@...
Subject: [Zephyr-users] Opinions / experiences requested regarding choosing the right IoT embedded OS

 

Hi users part of the Zephyr project!

 

My team is looking into the possibility to transition from a bare-metal application to an OS for our embedded controllers. We develop IoT and wireless sensors solutions, for which we have also developed our own controller and platform. A lot of in-house development and maintenance!

 

Would some of you be willing to answer some questions about why Zephyr OS would be a good choice for us? (The main comparison right now is between Zephyr Project, RIOT-OS and ThreadX)

 

To give a summary of the reasons for even looking into a more advanced architecture: there are a few features common in embedded (IoT) OS' that would be very convenient for future development of the controller. Things like hardware abstraction and task scheduling are very welcome. In general we want to make it easier to maintain the code (pre- and post release) and decrease time-to-market for new controller versions (with new/upgraded hardware modules). A common requirement that also applies to us are the resource constraints and the ultra low power features (we need to be able to use the low power modes for the STM32L151CC, but that can be added in the port). Real-time isn’t a priority for us at all, although the priority (pre-emptive)-based scheduling would be very useful.

The controller is part of the in-house developed IoT system, which currently is mostly used for Smart Waste and Smart Silo products (detecting fill rates in both).

 

A few questions that popped up during my own research on this (mostly about Zephyr vs RIOT):

1) Are there advantages / disadvantages to the different kinds of groups supporting and contributing to Zephyr vs RIOT  (US/Europe, industry/academic, ?/?)

2) Are there advantages / disadvantages I should be aware of for using the OS commercially (compared to RIOT)

3) Are there advantages / disadvantages to the hardware abstraction method Zephyr OS uses (DTS vs HAL?)

4) What is the goal of the development of the OS (use by industry, academic, educational use, hobby projects)?

5) Any technical limitations I should be aware of?

6) Any technical advantages (over RIOT)?

 

Any help is really appreciated!

 

All the best,

Noelle
Re: Opinions / experiences requested regarding choosing the right IoT embedded OS

Lee Courtney <leec2124@...>
 

Hi Noelle,

I'd be interested in contributing to this survey, which is directly applicable to us also. But, only if you collate and publish the results back to the list. Thanks!

--
Lee Courtney
Opinions / experiences requested regarding choosing the right IoT embedded OS

Noëlle Clement
 

Hi users part of the Zephyr project!

My team is looking into the possibility to transition from a bare-metal application to an OS for our embedded controllers. We develop IoT and wireless sensors solutions, for which we have also developed our own controller and platform. A lot of in-house development and maintenance!

Would some of you be willing to answer some questions about why Zephyr OS would be a good choice for us? (The main comparison right now is between Zephyr Project, RIOT-OS and ThreadX)

To give a summary of the reasons for even looking into a more advanced architecture: there are a few features common in embedded (IoT) OS' that would be very convenient for future development of the controller. Things like hardware abstraction and task scheduling are very welcome. In general we want to make it easier to maintain the code (pre- and post release) and decrease time-to-market for new controller versions (with new/upgraded hardware modules). A common requirement that also applies to us are the resource constraints and the ultra low power features (we need to be able to use the low power modes for the STM32L151CC, but that can be added in the port). Real-time isn’t a priority for us at all, although the priority (pre-emptive)-based scheduling would be very useful.
The controller is part of the in-house developed IoT system, which currently is mostly used for Smart Waste and Smart Silo products (detecting fill rates in both).

A few questions that popped up during my own research on this (mostly about Zephyr vs RIOT):
1) Are there advantages / disadvantages to the different kinds of groups supporting and contributing to Zephyr vs RIOT  (US/Europe, industry/academic, ?/?)
2) Are there advantages / disadvantages I should be aware of for using the OS commercially (compared to RIOT)
3) Are there advantages / disadvantages to the hardware abstraction method Zephyr OS uses (DTS vs HAL?)
4) What is the goal of the development of the OS (use by industry, academic, educational use, hobby projects)?
5) Any technical limitations I should be aware of?
6) Any technical advantages (over RIOT)?

Any help is really appreciated!

All the best,
Noelle
Re: Questions about Dynamic Threads

Boie, Andrew P
 

1. Is there any support for runtime creation of a new thread's stack in
k_thread_create(), through the likes of malloc()? I only see
K_THREAD_STACK_DEFINE(), which allocate it at compile-time. I'm porting an
existing library to Zephyr that creates threads (and their
stacks) on-demand, and having compile-time-only stacks would mean that I
have to do some ugly changes to the APIs where stack pointers get passed all
the way through multiple API layers.
There isn't, due to the lack of a memory allocator which returns aligned pointers.

2. I currently work around this by creating "stack pools" through
K_THREAD_STACK_ARRAY_DEFINE(), where each stack can be reused by
another thread once one has finished executing (that's a bit of a waste of
memory though). I do this by locking and releasing these stacks through an
atomic in-use flag. It gets set for the stack before the thread starts, and gets
cleared by the parent thread right after the thread's main function releases a
semaphore at the end of execution in a join-like operation. However, this
fails when a new thread reuses the stack right after the old thread has
released it with a message of "Illegal load of EXC_RETURN into PC". I assume
that's because the previous thread still needs the stack for a while even after
the last instruction in its main function (the release of the join semaphore)
was executed. It's "fixed" by sleeping for a short while before starting a new
thread with the stack, but that's obviously a very unsafe hack. So how would
I know when it's safe to reuse the stack? Does Zephyr allow reusing stacks in
this way at all?
You sound like a good customer for the k_thread_join() API I recently sent a PR for:

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

-Andrew
Questions about Dynamic Threads

David Lerch
 

Hi,

I'm using Zephyr for the first time with the NRF9160, and I have a few
questions about Zephyr's support of threads:

1. Is there any support for runtime creation of a new thread's stack
in k_thread_create(), through the likes of malloc()? I only see
K_THREAD_STACK_DEFINE(), which allocate it at compile-time. I'm
porting an existing library to Zephyr that creates threads (and their
stacks) on-demand, and having compile-time-only stacks would mean that
I have to do some ugly changes to the APIs where stack pointers get
passed all the way through multiple API layers.

2. I currently work around this by creating "stack pools" through
K_THREAD_STACK_ARRAY_DEFINE(), where each stack can be reused by
another thread once one has finished executing (that's a bit of a
waste of memory though). I do this by locking and releasing these
stacks through an atomic in-use flag. It gets set for the stack before
the thread starts, and gets cleared by the parent thread right after
the thread's main function releases a semaphore at the end of
execution in a join-like operation. However, this fails when a new
thread reuses the stack right after the old thread has released it
with a message of "Illegal load of EXC_RETURN into PC". I assume
that's because the previous thread still needs the stack for a while
even after the last instruction in its main function (the release of
the join semaphore) was executed. It's "fixed" by sleeping for a short
while before starting a new thread with the stack, but that's
obviously a very unsafe hack. So how would I know when it's safe to
reuse the stack? Does Zephyr allow reusing stacks in this way at all?


Thanks,

David
API meeting next week: Focusing on watchdogs

Carles Cufi
 

Hi all,

Next week (Tuesday 10th of March) we will focus our attention to watchdog handling in Zephyr.

We recently closed #22858 with the merge of #22859, but this was a temporary solution to what is ultimately a wider problem that requires a discussion regarding the way Zephyr manages watchdogs in general.

A good description of the current issues with the CONFIG_WDT_DISABLE_AT_BOOT option can be found in #22858.

During the call we will discuss the approach we want to take and document it in #23282, which I just created today.

Original issue:
https://github.com/zephyrproject-rtos/zephyr/issues/22858
Pull request:
https://github.com/zephyrproject-rtos/zephyr/pull/22859
New tracking issue:
https://github.com/zephyrproject-rtos/zephyr/issues/23282

Meeting:
https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion

Thanks,

Carles
API meeting: agenda

Carles Cufi
 

Hi all,

The topics for today:

- PR: Fix handling of WDT_DISABLE_AT_BOOT option
- https://github.com/zephyrproject-rtos/zephyr/pull/22859

- PR (cont): generalize async notification and add queued operation manager
- https://github.com/zephyrproject-rtos/zephyr/pull/22853

- PR (RFC): asynchronous sequence manager (assuming the relevant stakeholders are present)
- https://github.com/zephyrproject-rtos/zephyr/pull/23075

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles
Re: Enable traces on Serial Wire Output #debugging

David K
 

Replying to my own issue:

First I misunderstood module registration:

#include <logging/log.h>
// Must be done outside the function
LOG_MODULE_REGISTER(toto, LOG_LEVEL_DBG);

void main(void)
{
    //...
    LOG_INF("Hello World ! %s\n", CONFIG_BOARD);
    // ...
}

Then, I used west build -t menuconfig to enable:

[*] Logging-->    // This one was not enabled
    [*] Enable Serial Wire Output (SWO) backend
    (0)     Set SWO output frequency

After that I managed to get traces via the JLINK SWO Viewer.

However, it only works if I launch the SWO viewer AFTER my application is launched. If I trigger a reset of the target during a swoview session, I lost traces. I have to re-launch the swo viewer to get the logs again, meaning that I cannot have traces of a reboot for example and I cannot figure out why because the file log_backend_swo_init has the procedure described in JLINK User guide (3.8.4 Configure SWO output after device reset)
Re: simple coap client-server communication of two posix applications #coap

Jukka Rissanen
 

Hi Stefan,

I have had similar issues when zephyr tries to send data to host. In
all cases my firewall was blocking the connection. If this is the case
here, then just allow incoming packets from zeth. In Fedora, I just
mark the zeth as trusted interface in Firewall program.


Cheers,
Jukka

On Fri, 2020-02-28 at 01:19 -0800, Stefan Hristozov wrote:
Hi,
I want to set up a simple setup of two posix projects -- one running
a simple coap server and other running a simple coap client.

What I did so far:

1) I build both
/zephyrproject/zephyr/samples/net/sockets/coap_client and
zephyrproject/zephyr/samples/net/sockets/coap_server without any
changes.



2) I executed ./net-setup.sh. With sudo ifconfig I can see the new
zeth interface:
zeth: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.0.2.2 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 2001:db8::2 prefixlen 128 scopeid 0x0<global>
ether 00:00:5e:00:53:ff txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



3) I started the coap server posix program and tested it by sending a
get request to the core1 resource (I used the coap-cli tool
https://www.npmjs.com/package/coap-cli):

coap get coap://[2001:db8::1]/core1

to which the server replied with:

(2.05) Just a test

So the server works as expected. In addition I used wireshark
sniffing on the zeth interface --> The CoAP get request and the
response was there.



4)I started the client -- on the consol I see:

***** Booting Zephyr OS build v2.0.0-rc2 *****

CoAP client GET

but I cannot see any packets send in wireshark. I think something is
not properly configured probably the zeth interface?

How to test the coap_client sample when running it as a posix
application?

Best regards,
Stefan
simple coap client-server communication of two posix applications #coap

Stefan Hristozov
 

Hi,
I want to set up a simple setup of two posix projects -- one running a simple coap server and other running a simple coap client.

What I did so far:

1) I build both  /zephyrproject/zephyr/samples/net/sockets/coap_client and zephyrproject/zephyr/samples/net/sockets/coap_server without any changes.



2) I executed ./net-setup.sh. With sudo ifconfig I can see the new zeth interface:
zeth: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.0.2.2  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 2001:db8::2  prefixlen 128  scopeid 0x0<global>
        ether 00:00:5e:00:53:ff  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



3) I started the coap server posix program and tested it by sending a get request to the core1 resource (I used the coap-cli tool https://www.npmjs.com/package/coap-cli):

coap get coap://[2001:db8::1]/core1

to which the server replied with:

(2.05)    Just a test

So the server works as expected. In addition I used wireshark sniffing on the zeth interface --> The CoAP get request and the response was there.



4)I started the client -- on the consol I see:

 ***** Booting Zephyr OS build v2.0.0-rc2 *****

CoAP client GET

but I cannot see any packets send in wireshark. I think something is not properly configured probably the zeth interface?

How to test the coap_client sample when running it as a posix application?

Best regards,
Stefan
Enable traces on Serial Wire Output #debugging

David K
 

Hi, I am just getting started with Zephyr and currently working on a STM32F746ZE. I added a custom configuration for this board based on STM32F746G_DISCO. After having run successfully the blinky example, I am now trying to have traces on SWO (not UART), so that ultimately ITM_sendchar() would be called.

I have added in my Kconfig.defconfig:

config LOG_BACKEND_SWO_FREQ_HZ
	default 0

Following the documentation, I added in the blinky main.c:

//...
#include <logging/log.h>

void main(void)
{
    //...
    LOG_MODULE_REGISTER(toto, LOG_LEVEL_DBG);
    LOG_INF("Hello World ! %s\n", CONFIG_BOARD);
    // ...
}

I build and flash it flawlessly but I got no output on my console (using JLINK to connect and swoview). When I debug this with GDB I see that I don't go through the 2 lines I have added so I guess they are removed at compilation time.

I guess I am missing a flag/define/config somewhere (I get a little confused about where to define things in dts/kconfig/defconfig, ...), but I cannot find any example: any pointers ? Best regards
API meeting: cancelled today

Carles Cufi
 

Hi all,

Due to several contributors being unavailable today and myself having an additional commitment I have decided to cancel this week's API meeting.
Next week the meeting will take place as usual.

Thanks,

Carles
Serial communication Node-red #ble #bluetoothmesh #gpio #usb #bluetooth

Daniel Fox <danny.fox97@...>
 

Hi,
I am wondering if anyone has tried reading for a serial port using node-red
Currently, I'm using putty to read messages sent from my device built with help from zephyr mesh demo, as I'm using the bbc microbits with the nrf51's. Putty prints out a message e.g "button pressed" I was wondering if it can be done using node-red, it can read my usb port but it won't receive any messages. I'm not sure if it's compatible or not using c++.
I'm wondering if anyone has been able to do something similar to this using the zephyr project. 

I need this because I am using home assistant to monitor various parts of my house, I want to read serial port on my raspberry pi (microbit connected to raspberry pi) which is running home assistant and output the message to the main user page (like how putty does with the terminal).
Any help would be great thanks!
Thanks for your time,
Danny.
API meeting: agenda

Carles Cufi
 

Hi all,

The topics for today:

- Discussion on whether to move the hw_info API to stable

- PR: generalize async notification and add queued operation manager
- https://github.com/zephyrproject-rtos/zephyr/pull/22853

- Defining the expected behavior of API calls in different contexts: settle on documentation guidelines
- https://github.com/zephyrproject-rtos/zephyr/issues/18970


Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles
Re: Help on Devicetree aliases on eclipse #dts #eclipse #nrf52840

Carles Cufi
 

Hi there,

 

Most of the questions you ask are covered in the DT documentation:

https://docs.zephyrproject.org/latest/guides/dts/index.html#

 

The macros are generated by a Python script at build time, see the link above for details.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of henrique.guimaraes via Lists.Zephyrproject.Org
Sent: 18 February 2020 15:08
To: users@...
Cc: users@...
Subject: [Zephyr-users] Help on Devicetree aliases on eclipse #dts #eclipse #nrf52840

 

Good morning!

I'm a total newbie to Zephyr, learning the basics to implement in a project for an IoT sensor, more specifically IIoT(Industrial IoT). The module I'm using is a NINAB302, which incorporates a NRF52840. I know that Nordic Semi supports the project and that the microcontroller that I'm using is capable of running it. The IDE I'm using is Eclipse with the Zephyr pĺugin for it.

My question is about the Devicetree aliases defines in the C/C++ code for example those in the Blinky example: "DT_ALIAS_LED0_GPIOS_PIN" .
In my that code, eclipse isn't able to find the source of the aliases and freaks out putting red errors all over the place. But when I build the project, none of the errors matter, it builds perfectly and I can even flash the code to the device flawlessly. That's nice and all, but I feel like those defines could be very helpful if I knew where they were and how to use them.

So, how the devicetree aliases defines works? Where are they found? And how can one create their personal defines?

Help on Devicetree aliases on eclipse #dts #eclipse #nrf52840

henrique.guimaraes@...
 

Good morning!

I'm a total newbie to Zephyr, learning the basics to implement in a project for an IoT sensor, more specifically IIoT(Industrial IoT). The module I'm using is a NINAB302, which incorporates a NRF52840. I know that Nordic Semi supports the project and that the microcontroller that I'm using is capable of running it. The IDE I'm using is Eclipse with the Zephyr pĺugin for it.

My question is about the Devicetree aliases defines in the C/C++ code for example those in the Blinky example: "DT_ALIAS_LED0_GPIOS_PIN" .
In my that code, eclipse isn't able to find the source of the aliases and freaks out putting red errors all over the place. But when I build the project, none of the errors matter, it builds perfectly and I can even flash the code to the device flawlessly. That's nice and all, but I feel like those defines could be very helpful if I knew where they were and how to use them.

So, how the devicetree aliases defines works? Where are they found? And how can one create their personal defines?
1041 - 1060 of 2948