Date   

SDK 0.11.2 Release

Kumar Gala
 

Hi,

Some fixes based on usage of SDK v0.11.x and addition of some new xtensa variants to enable work from the Sound Open Firmware Project (https://www.sofproject.org).

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.2

Please download and try things out and report any issues.

• Fixed issue with setjmp/longjmp not existing on x86 32-bit build

• Fixed python support on GDB:
NOTE: Since python support is enabled in GDB the host system needs
python3.6 installed. Otherwise you might get an error like:

arm-zephyr-eabi-gdb: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

On newer fedora systems this can show up and be fixed by:

sudo dnf install python36

• Added support for Intel BDW and BDW Audio DSP xtensa toolchains.

• Added support for NXP IMX8 and IMX8M Audio DSP xtensa toolchains.

• Updated xtensa targets to GDB 8.3.1 (except S1000)

Thanks to all that contributed fixes and enhancements to this version of the SDK.

- k


Re: [Zephyr-devel] The topic-gpio branch has been merged to master

Piotr Mienkowski <piotr.mienkowski@...>
 

Hi all,

I would like to provide a bit more information about the recent change
to the GPIO API.

The main drive behind the rework was to support GPIO DTS bindings
https://github.com/torvalds/linux/blob/master/include/dt-bindings/gpio/gpio.h
as known from Linux DTS. That meant introduction of new flags:

- GPIO_ACTIVE_HIGH, GPIO_ACTIVE_LOW
- GPIO_OPEN_DRAIN, GPIO_OPEN_SOURCE
- GPIO_PULL_UP, GPIO_PULL_DOWN

All of the above flags are meant to be located in the DTS, typically at
the board level. This allows to decouple application / driver code from
the properties of the hardware they happen to work with.

As an example, if gpio pin is connected to a button it could be
described in the board DTS file as follows:

    button0: button_0 {
        gpios = <&gpio0 17 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
        label = "Push button 0";
    };

It means that the GPIO driver will need to enable a pull up on a pin and
that the pin is active low. All this is transparent to the application
which simply needs to pull in the DTS flags when configuring the pin. To
access the flags generated from the DTS at the application level it is
best to use the so called DT_ALIAS defines. The special DTS aliases node

aliases {
    sw0 = &button0;
};

is a convenient way to give generic application level names to specific
DTS nodes.

The resulting call in the application code could look like this

    gpio_pin_configure(dev_button, DT_ALIAS_SW0_GPIOS_PIN,
DT_ALIAS_SW0_GPIOS_FLAGS | GPIO_INPUT);

To access the flags at the driver level we should ideally be using the
so called DT_INST defines. But here the situation is a little bit more
complicated.

The two new flags that had the biggest impact on the shape of the new
GPIO API are GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW. They define pin
active level known in the new API as logical pin level. From the
documentation

"If pin is configured as Active High, a low physical level will be
interpreted as logical value 0. If pin is configured as Active Low, a
low physical level will be interpreted as logical value 1."

At the application level the two flags encode cause -> effect
relationship. In the above example of a button the GPIO_ACTIVE_LOW flag
means that regardless of the specific design of the hardware button and
the circuitry surrounding it if the button is pressed the pin will see
low physical value. This relationship should be defined in DTS bindings.

This level of abstraction is useful not only when building a generic
application that reacts to the press of a button or has to turn on an
LED but also when building a driver for a well documented external
hardware module. Such module, e.g. a sensor connected over I2C bus, can
provide an active high interrupt pin that should be routed to a GPIO pin
on a SoC. A driver for the hardware module which is using pin logical
rather than pin physical level allows for the possibility that the
interrupt signal from the hardware module is routed to the GPIO pin via
an inverter, e.g. because external module is in a different power
domain. Once again the active level of the interrupt pin will be defined
in DTS and allows the driver code to be decoupled from the specifics of
the PCB design.

An application can get / set pin logical level by calling gpio_pin_get,
gpio_pin_set functions. It is still possible to access pin physical
level, if required, by calling gpio_pin_get_raw, gpio_pin_set_raw functions.

All these concepts are not entirely new. The old GPIO API provided flags
such as GPIO_INT_ACTIVE_LOW and GPIO_POL_INV which aimed to achieve
similar goal. However, they were not very well documented and not
consistently implemented.

Other modifications to the GPIO API include:

- Interrupt configuration was moved to the dedicated
gpio_pin_interrupt_configure() function. Configuring interrupts via
gpio_pin_configure() is still supported but this feature will be removed
in future releases.

- New set of flags allows to define arbitrary interrupt configuration
(if supported by the driver) based on pin physical or logical levels.
The include/drivers/gpio.h contains in fact two sets of interrupt
related flags, one targeted at the driver developers and the other at
the users of the API. Only the latter is documented at
https://docs.zephyrproject.org/latest/reference/peripherals/gpio.html
and should be used by the applications.

- New set of port functions that operate simultaneously on multiple pins
that belong to the same controller.

- New set of flags to configure pin as input, output or in/out as well
as set output initial state.

Majority of the old GPIO API has been deprecated and, to limit impact on
the code size, re-implemented in terms of the new API. While the care
was taken to preserve backward compatibility due to the scope of the
work it was not possible to fully achieve this goal.

We recommend to switch to the new GPIO API as soon as possible.

Areas where the deprecated API may behave differently to the original
old implementation are:

- Configuration of pin interrupts, especially involving
GPIO_INT_ACTIVE_LOW and GPIO_POL_INV flags.

- Behavior of gpio_pin_configure() when invoked without interrupt
related flags. In the new implementation of this deprecated
functionality the interrupts remain unmodified. In the original
implementation some of the GPIO drivers would disable the interrupts.

Regards,
Piotr


API meeting: agenda

Carles Cufi
 

Hi all,

The topics for today:

- New API: DAC
- https://github.com/zephyrproject-rtos/zephyr/pull/21805

- Overall post-GPIO triage and decision on what to tackle next

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


BBC-Microbit BLE MESH sending data #ble #bluetoothmesh #gpio #bluetooth #nrf51822

Daniel Fox <danny.fox97@...>
 

Hi,
I am currently doing an engineering project for my final year, I have been using the bluetooth mesh demo on the zephyr project using the bbc microbits, I have set up a pir sensor up to produce a simple print statement("warning motion detected") to a serial communication terminal (Putty).
Set up as follows:
- BBC microbit hooked up to motion sensor
-BBC microbits acting as beacons to send data to final device 
-Final bbc microbit connected to computer with putty running

I want to send temperature readings to display onto a serial communication terminal. I am not sure how to send the readings over the mesh network as all i have really done is placed a print statement in the code. I'm wondering how do I send sensor readings over the ble mesh network using bbc microbits?(from my understanding I may need to send data packets but I'm unsure on how I would begin to code this). 
Any help would be appreciated, thanks for your time!
Regards,
Danny


Re: Private: Re: [Zephyr-users] bt_set_name() and setting local name #ble #bt #bluetooth #api

Carles Cufi
 

Hi there,

 

The name is placed in the advertising data automatically when you call bt_le_adv_start(BT_LE_ADV_CONN_NAME).  When you call bt_set_name(), that is updated as well:

https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/host/hci_core.c#L5444

 

That said, the name is placed in the scan response, so you need to make sure the scanner is performing active scanning.

 

Regards,

 

Carles

 

From: j.cheng via Lists.Zephyrproject.Org <j.cheng=de-haardt.com@...>
Sent: 10 February 2020 10:56
To: Cufi; Cufi, Carles <Carles.Cufi@...>
Subject: Private: Re: [Zephyr-users] bt_set_name() and setting local name #ble #bt #bluetooth #api

 

Hi,

Thanks for the quick reply.

I tried connecting and disconnecting several times. Also tried reinstalling the app. After waiting for some minutes, it still displays Zephyr. Is it possible that the local name differs from the advertising name?

Regards,

Jamie


Re: bt_set_name() and setting local name #bt #bluetooth #api #ble

Carles Cufi
 

Hi there,

 

Most smartphones implement some sort of advertising data caching. Try stopping and starting scanning from the phone a couple of times to see if the name is updated without the need to connect.

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of j.cheng via Lists.Zephyrproject.Org
Sent: 10 February 2020 10:06
To: users@...
Cc: users@...
Subject: [Zephyr-users] bt_set_name() and setting local name #ble #bt #bluetooth #api

 

Hello,

I want to change the ble device name during runtime. I've enabled BT_DEVICE_NAME_DYNAMIC and BT_SETTINGS.

To change the device name during runtime i'm using bt_set_name(). However, when scanning for the device using the nrf connect toolbox app on my android device, i still see ''Zephyr'' as the device name. Only after connecting with the device, i see the correct new device name that was set by bt_set_name().

The bt_set_name() works, but not the way i would like to. Is there a way to show the changed device name before connecting with the device?

Kind regards,

Jamie


bt_set_name() and setting local name #bt #bluetooth #api #ble

j.cheng@...
 

Hello,

I want to change the ble device name during runtime. I've enabled BT_DEVICE_NAME_DYNAMIC and BT_SETTINGS.

To change the device name during runtime i'm using bt_set_name(). However, when scanning for the device using the nrf connect toolbox app on my android device, i still see ''Zephyr'' as the device name. Only after connecting with the device, i see the correct new device name that was set by bt_set_name().

The bt_set_name() works, but not the way i would like to. Is there a way to show the changed device name before connecting with the device?

Kind regards,

Jamie


Re: Devicetree config generation

Carles Cufi
 

Hi Petr,

 

Yes, this has been talked about repeatedly over the last couple of years.

You can find most of the issues and PRs related to the work that has been done so far in this umbrella issue:

https://github.com/zephyrproject-rtos/zephyr/issues/8499

 

In the dev-review meeting on Thursdays we are currently discussing DeviceTree-related topics, and code generation, and in particular to solve the pinctrl/pinmux problem but also for instancing, is one of those topics.

Kumar Gala (on copy) drives the overall DT efforts within Zephyr. Feel free to join the meeting or comment on the multiple issues or Pull Requests on GitHub to drive the feature forward.

 

Regards,

 

Carles

 

From: <users@...> on behalf of "Petr Buchta via Lists.Zephyrproject.Org" <cz7asm=googlemail.com@...>
Reply-To: "cz7asm@..." <cz7asm@...>
Date: Sunday, 9 February 2020 at 16:48
To: "users@..." <users@...>
Cc: "users@..." <users@...>
Subject: [Zephyr-users] Devicetree config generation

 

Hi, I just started looking around Zephyr and coming from Linux world I really like the idea of using Devicetree for driver configuration.

 

I noticed, however, that config generation that enables particular low level driver must be dobe manualy using Kconfig. I know that this is the same in Linux but given the way Zephyr leverages DT I would think that, in this case, config generation based on DT could simplify things.

 

For example looking at led_strip driver code samples, there are projects that duplicate almost all code only to bind to a different low level driver, like samples/drivers/apa102 and samples/drivers/ws2812. They even have the same prj.conf. 

If the DT processing could provide things like mapping "enabled device compatible string" -> "LL driver CONFIG_xx parameter", then there would be no need for code duplication and all the samples utilizing same driver api could share same project.

 

Is this something that's been considered but abandoned for a reason?

 

Thanks,

Petr


Devicetree config generation

Petr Buchta <cz7asm@...>
 

Hi, I just started looking around Zephyr and coming from Linux world I really like the idea of using Devicetree for driver configuration.

I noticed, however, that config generation that enables particular low level driver must be dobe manualy using Kconfig. I know that this is the same in Linux but given the way Zephyr leverages DT I would think that, in this case, config generation based on DT could simplify things.

For example looking at led_strip driver code samples, there are projects that duplicate almost all code only to bind to a different low level driver, like samples/drivers/apa102 and samples/drivers/ws2812. They even have the same prj.conf. 
If the DT processing could provide things like mapping "enabled device compatible string" -> "LL driver CONFIG_xx parameter", then there would be no need for code duplication and all the samples utilizing same driver api could share same project.

Is this something that's been considered but abandoned for a reason?

Thanks,
Petr


West 0.7.0 released, requires manual intervention on Ubuntu

Bolivar, Marti
 

Hello,

West 0.7.0 has been released. The main new feature since 0.6.x is the
addition of "manifest imports", which let you pull in west.yml files
from elsewhere into your own manifest file.

You can upgrade in the usual ways:

pip3 install west==0.7.0 # Windows and macOS
pip3 install --user west==0.7.0 # Linux

Please note that there is a problem with the upgrade on the version of
pip3 which ships with Ubuntu 18.04. Other Linux distributions, macOS,
and Windows are all upgrading successfully.

On Ubuntu only, you will need to choose from one of the following
workarounds to upgrade west:

1. Remove the old west before upgrading, like this:

$ pip3 show west | grep Location: | cut -f 2 -d ' '
/home/foo/.local/lib/python3.6/site-packages
$ rm -r /home/foo/.local/lib/python3.6/site-packages/west
$ pip3 install --user west==0.7.0

2. Install west in a virtual environment using a more recent
version of pip3, e.g. using the venv module:

https://docs.python.org/3/library/venv.html

Further details in this issue:

https://github.com/zephyrproject-rtos/west/issues/373

And in particular, this comment:

https://github.com/zephyrproject-rtos/west/issues/373#issuecomment-583489272

Thanks,
Marti


The topic-gpio branch has been merged to master

Carles Cufi
 

Hi all,

As of this morning the 313 commits in the topic-gpio branch have been merged into Zephyr's master branch.

What this means for you if:

a) You are a GPIO API user:

- Big chunks of the existing API have been deprecated, leading to deprecation build warnings. You should port your application to the new GPIO API as soon as possible, although you have 2 full Zephyr releases until the deprecated API is finally removed. Please refer to Peter Bigot's "porting guide" in this GitHub comment for additional information:
https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497

b) You have outstanding, unmerged Pull Requests:

- The Pull Requests may show green CI, but that is misleading. We encourage you to rebase your Pull Request as soon as possible against the current master and push.

- If your Pull Request makes use of the GPIO API, it will not pass CI due to deprecation warnings. There is no solution but to port your code to the new GPIO API. If you are on a deadline for 2.2 feature freeze ping us on the #gpio channel on Slack to see if we can help.

c) You are a maintainer with merge rights:

- You need to make sure that CI has been rerun after the topic-gpio merge happened and *before* you merge any Pull Request to master

Additional information about the merge process can be found here:

https://github.com/zephyrproject-rtos/zephyr/issues/21789

Finally I want to thank everybody who contributed to this effort, which has spanned many months and several hundred commits.
Special mention to Piotr Mienkowski and Peter Bigot, whose dedication to getting this done has made it possible to merge this branch in time for the 2.2 release.

Regards,

Carles


API meeting: Agenda

Carles Cufi
 

Hi all,

Today we will talk first about GPIO and the merge of the topic-gpio branch to master:

- Cleanup the public and private API with typedefs
- Testing status
- Issues with master CI that might prevent the merge to master
- https://github.com/zephyrproject-rtos/zephyr/issues/21789

Additionally I'd like to discuss:

- RFC: API Change: clock_control
- https://github.com/zephyrproject-rtos/zephyr/issues/22424

- Ability to use an API with device without extending its own API
- https://github.com/zephyrproject-rtos/zephyr/issues/22415

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: SDK 0.11.1 Release

Nashif, Anas
 

Hi,
Thanks Kumar.

Please note that this version of the SDK is now required for development on master and is enabled in CI.


Anas

On 03/02/2020, 05:56, "users@lists.zephyrproject.org on behalf of Kumar Gala" <users@lists.zephyrproject.org on behalf of kumar.gala@linaro.org> wrote:

Hi,

Some minor fixes that got missed for the v0.11.0 release. Mostly impacts OpenOCD and newlib usage.

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.1

Please download and try things out and report any issues.

OpenOCD:

• Fixed missing commits from rebase - related to ARC and Zephyr RTOS awareness

Newlib:

• Removed setting -DMISSING_SYSCALL_NAMES on builds. Make syscall function names consistent and naming compatible with 3rd party GNU toolchains.

Thanks to all that contributed fixes and enhancements to this version of the SDK.

- k


SDK 0.11.1 Release

Kumar Gala
 

Hi,

Some minor fixes that got missed for the v0.11.0 release. Mostly impacts OpenOCD and newlib usage.

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.1

Please download and try things out and report any issues.

OpenOCD:

• Fixed missing commits from rebase - related to ARC and Zephyr RTOS awareness

Newlib:

• Removed setting -DMISSING_SYSCALL_NAMES on builds. Make syscall function names consistent and naming compatible with 3rd party GNU toolchains.

Thanks to all that contributed fixes and enhancements to this version of the SDK.

- k


Re: Setting #uart parity to 'even' with #stm32 using device tree #uart #stm32

Pauli
 

Dear all,

if somebody tumbles here with google about the parity, i found no way to do it from device tree, but 8-databits, even parity, 1 stopbit seems to work in my case with patch pasted below. There are devicetree bindings on the same file, but nothing regarding the parity (i could make pull for this single case, but i guess the modifications should go to serial-device tree bindings, and that sounds like larger pull that i am afraid i do not have time).

Also, ror the record: with this setup one can use HC-05 with stm32_min_dev board, and with burned in st-system bootloader one can achive "update over bluetooth" using stm32loader.py: shell command to enter bootloader (writes to backup registers that next reset jump to bootloader, followed by system reset) -- and then closes command terminal and runs stm32loader.py over bluetooth.

Br,
Pauli


diff --git a/drivers/serial/uart_stm32.c b/drivers/serial/uart_stm32.c
index 3d0dd1ca84..03948225a0 100644
--- a/drivers/serial/uart_stm32.c
+++ b/drivers/serial/uart_stm32.c
@@ -671,8 +671,8 @@ static int uart_stm32_init(struct device *dev)
 
        /* 8 data bit, 1 start bit, 1 stop bit, no parity */
        LL_USART_ConfigCharacter(UartInstance,
-                                LL_USART_DATAWIDTH_8B,
-                                LL_USART_PARITY_NONE,
+                                LL_USART_DATAWIDTH_9B,
+                                LL_USART_PARITY_EVEN,
                                 LL_USART_STOPBITS_1);
 
        if (config->hw_flow_control) {


Re: Adding a costume module to my project #west

Bolivar, Marti
 

Hi,

Please check your build directory's zephyr_modules.txt file to make sure
it is being included in the list. If it's not, please check where you
are setting ZEPHYR_EXTRA_MODULES again.

If it is present in zephyr_modules.txt but you're not seeing it get
compiled, please try debugging with this PR:

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

If that patch doesn't generate any errors, I suspect your module's
CMakeLists.txt is not building the source code.

HTH,
Marti

"Stefan Hristozov via Lists.Zephyrproject.Org"
<stefan.hristozov=aisec.fraunhofer.de@lists.zephyrproject.org> writes:

Hi,

I moved

set ( $ENV{ZEPHYR_EXTRA_MODULES} pbs_path/module1)

before

include ( $ENV{ZEPHYR_BASE} /cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project (NONE)


Unfortunately I am still getting the same linker error.

Best regards
Stefan


Am 01/29/2020 um 02:10 AM schrieb Bolivar, Marti:
"stefan.hristozov via Lists.Zephyrproject.Org"
<stefan.hristozov=aisec.fraunhofer.de@lists.zephyrproject.org> writes:

Hi,

I want to add a module to my project. My folder structure looks like this:

<top dir>
|---modules
| |---module1
| | |---CMakeLists.txt
| | |---inc
| | |---src
| | |---zephyr
| | |---module.yml
| |---module2
|---app
|---app1

*Where modules/module1/CMakeLists.txt:*

zephyr_interface_library_named(test)
target_include_directories(test INTERFACE inc)
zephyr_library()
zephyr_library_sources(
src/test.c
)
zephyr_library_link_libraries(test)
target_link_libraries(test INTERFACE zephyr_interface)

*modules/module1/zephyr/module.yml:*

build:
cmake: .

*app/app1/CMakeLists.txt:*
cmake_minimum_required (VERSION 3.13.1)
include ( $ENV{ZEPHYR_BASE} /cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project (NONE)

set ( $ENV{ZEPHYR_EXTRA_MODULES} pbs_path/module1)
Looking at this quickly, ZEPHYR_EXTRA_MODULES needs to be set before
including the boilerplate file, not before. You can also set it as an
ordinary CMake variable; you don't need to set it in the environment.


FILE (GLOB app_sources src/*.c)
target_sources (app PRIVATE ${app_sources} )
target_include_directories (app PRIVATE $ENV{ZEPHYR_BASE} /subsys/net/ip)

target_link_libraries (app PRIVATE test)

Unfortunately, with this set up module1 doesn't get compiled and I get a linker error when I try to use functions from that module. I assume that something goes wrong with ZEPHYR_EXTRA_MODULES but I don't know what.
HTH,
Marti

Best regards
Stefan

--
Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC
Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. +49 89 32299 86 157
stefan.hristozov@aisec.fraunhofer.de
http://www.aisec.fraunhofer.de
http://twitter.com/FraunhoferAISEC



Re: Adding a costume module to my project #west

Stefan Hristozov
 

Hi,

I moved

set ( $ENV{ZEPHYR_EXTRA_MODULES} pbs_path/module1)

before

include ( $ENV{ZEPHYR_BASE} /cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project (NONE)


Unfortunately I am still getting the same linker error.

Best regards
Stefan


Am 01/29/2020 um 02:10 AM schrieb Bolivar, Marti:

"stefan.hristozov via Lists.Zephyrproject.Org"
<stefan.hristozov=aisec.fraunhofer.de@lists.zephyrproject.org> writes:

Hi,

I want to add a module to my project. My folder structure looks like this:

<top dir>
|---modules
| |---module1
| | |---CMakeLists.txt
| | |---inc
| | |---src
| | |---zephyr
| | |---module.yml
| |---module2
|---app
|---app1

*Where modules/module1/CMakeLists.txt:*

zephyr_interface_library_named(test)
target_include_directories(test INTERFACE inc)
zephyr_library()
zephyr_library_sources(
src/test.c
)
zephyr_library_link_libraries(test)
target_link_libraries(test INTERFACE zephyr_interface)

*modules/module1/zephyr/module.yml:*

build:
cmake: .

*app/app1/CMakeLists.txt:*
cmake_minimum_required (VERSION 3.13.1)
include ( $ENV{ZEPHYR_BASE} /cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project (NONE)

set ( $ENV{ZEPHYR_EXTRA_MODULES} pbs_path/module1)
Looking at this quickly, ZEPHYR_EXTRA_MODULES needs to be set before
including the boilerplate file, not before. You can also set it as an
ordinary CMake variable; you don't need to set it in the environment.


FILE (GLOB app_sources src/*.c)
target_sources (app PRIVATE ${app_sources} )
target_include_directories (app PRIVATE $ENV{ZEPHYR_BASE} /subsys/net/ip)

target_link_libraries (app PRIVATE test)

Unfortunately, with this set up module1 doesn't get compiled and I get a linker error when I try to use functions from that module. I assume that something goes wrong with ZEPHYR_EXTRA_MODULES but I don't know what.
HTH,
Marti

Best regards
Stefan

--
Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC
Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. +49 89 32299 86 157
stefan.hristozov@aisec.fraunhofer.de
http://www.aisec.fraunhofer.de
http://twitter.com/FraunhoferAISEC


Re: Adding a costume module to my project #west

Bolivar, Marti
 

"stefan.hristozov via Lists.Zephyrproject.Org"
<stefan.hristozov=aisec.fraunhofer.de@lists.zephyrproject.org> writes:

Hi,

I want to add a module to my project. My folder structure looks like this:

<top dir>
|---modules
|      |---module1
|      |      |---CMakeLists.txt
|      |      |---inc
|      |      |---src
|      |      |---zephyr
|      |            |---module.yml
|      |---module2
|---app
|---app1

*Where modules/module1/CMakeLists.txt:*

zephyr_interface_library_named(test)
target_include_directories(test INTERFACE inc)
zephyr_library()
zephyr_library_sources(
src/test.c
)
zephyr_library_link_libraries(test)
target_link_libraries(test INTERFACE zephyr_interface)

*modules/module1/zephyr/module.yml:*

build:
cmake: .

*app/app1/CMakeLists.txt:*
cmake_minimum_required (VERSION 3.13.1)
include ( $ENV{ZEPHYR_BASE} /cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project (NONE)

set ( $ENV{ZEPHYR_EXTRA_MODULES} pbs_path/module1)
Looking at this quickly, ZEPHYR_EXTRA_MODULES needs to be set before
including the boilerplate file, not before. You can also set it as an
ordinary CMake variable; you don't need to set it in the environment.



FILE (GLOB app_sources src/*.c)
target_sources (app PRIVATE ${app_sources} )
target_include_directories (app PRIVATE $ENV{ZEPHYR_BASE} /subsys/net/ip)

target_link_libraries (app PRIVATE test)

Unfortunately,  with this set up module1 doesn't get compiled and I get a linker error when I try to use functions from that module. I assume that something goes wrong with ZEPHYR_EXTRA_MODULES but I don't know what.
HTH,
Marti

Best regards
Stefan


Adding a costume module to my project #west

Stefan Hristozov
 

Hi,

I want to add a module to my project. My folder structure looks like this:

<top dir>
    |---modules
    |      |---module1
    |      |      |---CMakeLists.txt
    |      |      |---inc
    |      |      |---src
    |      |      |---zephyr
    |      |            |---module.yml
    |      |---module2
    |---app
           |---app1

Where modules/module1/CMakeLists.txt:

zephyr_interface_library_named(test)
target_include_directories(test INTERFACE inc)
zephyr_library()
zephyr_library_sources(
    src/test.c
)
zephyr_library_link_libraries(test)
target_link_libraries(test INTERFACE zephyr_interface)

modules/module1/zephyr/module.yml:

build:
  cmake: .

app/app1/CMakeLists.txt:
cmake_minimum_required(VERSION 3.13.1)
include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(NONE)

set($ENV{ZEPHYR_EXTRA_MODULES} pbs_path/module1)


FILE(GLOB app_sources src/*.c)
target_sources(app PRIVATE ${app_sources})
target_include_directories(app PRIVATE $ENV{ZEPHYR_BASE}/subsys/net/ip)

target_link_libraries(app PRIVATE test)

Unfortunately,  with this set up module1 doesn't get compiled and I get a linker error when I try to use functions from that module. I assume that something goes wrong with ZEPHYR_EXTRA_MODULES but I don't know what.

Best regards
Stefan


Setting #uart parity to 'even' with #stm32 using device tree #uart #stm32

Pauli
 

Hello all,

I have been doing development with stm32f103 (blue-pill) board - and it has the system bootloader burned in. The bootloader uses settings 115200, 1 stop, even parity [1]. I would like to change my "normal" uart settings accordingly. I tried googling for device tree bindings, but it seems like there is no bindings for parity at device-tree level?

If device tree has no support for parity - i guess it is OK to re-initialize the uart with proper settings in early "application" main() ?

Long story:

I have successfully flashed the device with UART_1 using stm32loader.py over wire and wireless. Now final aim is to do firmware upgrade with the system bootloader over bluetooth by connecting HC-05 to the serial port and enter the bootloader programatically (by writing certain value to backup-registers, and checking that value on early boot). It shall require (for simplicity) that "normal mode" and "bootloader mode" shall use same uart settings. I tested that flashing over bluetooth seems to work ( but is painfully slow ).

[1] St / AN3155

Br,
Pauli

721 - 740 of 2607