Date   

Re: Fix RAM_CONSOLE buffer address to specific address #driver

mdecandia@...
 

Hi Andrew,
thank you.

To modify the linker script, I've seen this configuration option

https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_CUSTOM_SECTIONS_LD.html

Is this the correct way to do it?

Michele


Bluetooth examples failure with native_posix target #bluetooth #driver

mdecandia@...
 

Hi all,
I'm trying to run bluetooth examples on native_posix target an I'm facing this error:

zephyr/build/zephyr/zephyr.exe --bt-dev=hci0
*** Booting Zephyr OS build zephyr-v2.2.0-2229-g9b055ecf82c3  ***
Starting Beacon Demo
[00:00:00.000,000] <err> bt_hci_core: HCI driver open failed (-132)
Bluetooth init failed (err -132)

Here my hciconfig -a output:

hci0:    Type: Primary  Bus: USB
    BD Address: 08:3E:8E:A2:1D:BA  ACL MTU: 1021:8  SCO MTU: 64:1
    DOWN
    RX bytes:574 acl:0 sco:0 events:30 errors:0
    TX bytes:368 acl:0 sco:0 commands:30 errors:0
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
    Link policy: RSWITCH SNIFF
    Link mode: SLAVE ACCEPT

Any help?

Thanks,
Michele


Zephyr 2.3.0-rc1 tagged

Carles Cufi
 

Hi all,

The first release candidate for Zephyr 2.3.0 has now been tagged (v2.3.0-rc1).

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.3.0 is released; the stabilization period is now open.
During said stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master.
Additional features or enhancements for the 2.3 release will require approval by the TSC.
As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers.
Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline.

The full release log can be found here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.3.0-rc1

More details about Zephyr releases can found on the pages below:
https://docs.zephyrproject.org/latest/development_process/release_process.html
https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

The final release is tentatively scheduled for May 29th.

Note 1: You are of course free to send Pull Requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the larges extent possible, so that we can release 2.3.0 on time and in the best shape possible.
Note 2: If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request in question with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution.

Thanks,

Carles


Re: Fix RAM_CONSOLE buffer address to specific address #driver

Boie, Andrew P
 

It's just a character buffer.

 

If you need to pin it to a specific memory address, I imagine you'll have to route it to a special input section that is placed where you want it in memory in the linker script. This will require a little work but shouldn't be too bad.

 

Andrew

 

From: users@... <users@...> On Behalf Of mdecandia@...
Sent: Wednesday, May 6, 2020 11:44 PM
To: users@...
Subject: [Zephyr-users] Fix RAM_CONSOLE buffer address to specific address #driver

 

Hi all,
for a specific design need,
I would like to fix the address of the ram_console buffer in RAM_CONSOLE driver.

Which is the best way (if feasible) to set it?

Thanks,
Michele


Fix RAM_CONSOLE buffer address to specific address #driver

mdecandia@...
 

Hi all,
for a specific design need,
I would like to fix the address of the ram_console buffer in RAM_CONSOLE driver.

Which is the best way (if feasible) to set it?

Thanks,
Michele


[2.3 release] Feature merge window close (M2) tomorrow

Carles Cufi
 

Hi all,

This is just a reminder that the feature merge window closes tomorrow, the 8th of May.
This means that any changes that are not bugfixes or documentation changes must be merged by then.

Since I doubt I will be able to go through all GitHub emails in time for tomorrow, please make sure that your PR shows in the following filter if you want it merged:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Aapproved+status%3Asuccess+-label%3ADNM+draft%3Afalse++milestone%3Av2.3.0

This means that your PR must be approved, must pass CI and its milestone must be set to v2.3.0.

If you have additional requests or need help, please email me or ping me on Slack.

Regards,

Carles


Re: can't enable CONFIG_USE_STM32_HAL_DMA2D and CONFIG_USE_STM32_HAL_* in general

Tristen Ennemuist
 

erwan, you're a champion - thank you!


Re: can't enable CONFIG_USE_STM32_HAL_DMA2D and CONFIG_USE_STM32_HAL_* in general

Erwan Gouriou
 

Hi,


Cheers
Erwan

On Wed, 6 May 2020 at 05:44, Tristen Ennemuist <tomeaus@...> wrote:
hello zephyr users

i'm using the stmf469i discovery board and i'm trying to enable some stm32 hal drivers but, try as i might, i cannot.

so for example, if i look in menuconfig for CONFIG_USE_STM32_HAL_DMA2D it appears but it is in red. if i press ? for information:

Name: USE_STM32_HAL_DMA2D
Type: bool
Value: n

Help:

  Enable STM32Cube Chrom-Art Accelerator™ controller (DMA2D) HAL module
  driver

Direct dependencies (=y):
     HAS_STM32CUBE(=y)

Kconfig definition, with parent deps. propagated to 'depends on'
================================================================

At modules/Kconfig.stm32:108
Included via /home/tristen/zephyrproject/zephyr/Kconfig:8 -> Kconfig.zephyr:10 -> modules/Kconfig:21
Menu path: (Top) -> Modules

  config USE_STM32_HAL_DMA2D
        bool
        depends on HAS_STM32CUBE(=y)
        help
          Enable STM32Cube Chrom-Art Accelerator™ controller (DMA2D) HAL module
          driver

working back it says it

HAS_STM32CUBE (=y)
SOC_SERIES_STM32F4X(=y)

yet i can't explicitly enable that specific CONFIG_USE_STM32_HAL_DMA2D and i can't include it in the prj.conf (errors about not being able to explicitly set it) and so i don't know what to do.

in my code i could

#include <stm32f4xx_hal_dma2d.h>

and compile without errors however the linking process failed whenever i tried to access a function, eg: HAL_DMA2D_Init. so it's like the environment knows i want to use that HAL and makes the include available to me, but i can't complete the build.

so i don't know if i'm getting hung up on the idea of whether linking will work if i could only enable CONFIG_USE_STM32_HAL_DMA2D or whether there is another way to get my project to compile/link the required hal driver, or indeed whether there are other options i'm not aware of.

when i look in 

zephyrproject/modules/hal/stm32/stm32cube/stm32f4xx/CMakeLists.txt

there is a whole lot of stuff about zephyr_library_sources_ifdef(CONFIG_USE_STM32_HAL_[all the things i would like to enable but cannot]) but the problem is i can't actually enable any of them.

anyway i tried google every which way and i'm stuck, so if anyone can help a brother out i'd be over the moon, cheers all, tristen.




can't enable CONFIG_USE_STM32_HAL_DMA2D and CONFIG_USE_STM32_HAL_* in general

Tristen Ennemuist
 

hello zephyr users

i'm using the stmf469i discovery board and i'm trying to enable some stm32 hal drivers but, try as i might, i cannot.

so for example, if i look in menuconfig for CONFIG_USE_STM32_HAL_DMA2D it appears but it is in red. if i press ? for information:

Name: USE_STM32_HAL_DMA2D
Type: bool
Value: n

Help:

  Enable STM32Cube Chrom-Art Accelerator™ controller (DMA2D) HAL module
  driver

Direct dependencies (=y):
     HAS_STM32CUBE(=y)

Kconfig definition, with parent deps. propagated to 'depends on'
================================================================

At modules/Kconfig.stm32:108
Included via /home/tristen/zephyrproject/zephyr/Kconfig:8 -> Kconfig.zephyr:10 -> modules/Kconfig:21
Menu path: (Top) -> Modules

  config USE_STM32_HAL_DMA2D
        bool
        depends on HAS_STM32CUBE(=y)
        help
          Enable STM32Cube Chrom-Art Accelerator™ controller (DMA2D) HAL module
          driver

working back it says it

HAS_STM32CUBE (=y)
SOC_SERIES_STM32F4X(=y)

yet i can't explicitly enable that specific CONFIG_USE_STM32_HAL_DMA2D and i can't include it in the prj.conf (errors about not being able to explicitly set it) and so i don't know what to do.

in my code i could

#include <stm32f4xx_hal_dma2d.h>

and compile without errors however the linking process failed whenever i tried to access a function, eg: HAL_DMA2D_Init. so it's like the environment knows i want to use that HAL and makes the include available to me, but i can't complete the build.

so i don't know if i'm getting hung up on the idea of whether linking will work if i could only enable CONFIG_USE_STM32_HAL_DMA2D or whether there is another way to get my project to compile/link the required hal driver, or indeed whether there are other options i'm not aware of.

when i look in 

zephyrproject/modules/hal/stm32/stm32cube/stm32f4xx/CMakeLists.txt

there is a whole lot of stuff about zephyr_library_sources_ifdef(CONFIG_USE_STM32_HAL_[all the things i would like to enable but cannot]) but the problem is i can't actually enable any of them.

anyway i tried google every which way and i'm stuck, so if anyone can help a brother out i'd be over the moon, cheers all, tristen.




Re: samples/basic/blinky

Tristen Ennemuist
 

cheers lawrence i've been tinkering and i can confirm the following will behave as i originally expected, all four leds are initially off and then cycling through 'em in turn. i'm in the right universe after all, thank you!

gpio_pin_configure(green_led, DT_ALIAS_LED0_GPIOS_PIN, GPIO_OUTPUT_INACTIVE | GPIO_ACTIVE_LOW);
gpio_pin_configure(orange_led, DT_ALIAS_LED1_GPIOS_PIN, GPIO_OUTPUT_INACTIVE | GPIO_ACTIVE_LOW);
gpio_pin_configure(red_led, DT_ALIAS_LED2_GPIOS_PIN, GPIO_OUTPUT_INACTIVE | GPIO_ACTIVE_LOW);
gpio_pin_configure(blue_led, DT_ALIAS_LED3_GPIOS_PIN, GPIO_OUTPUT_INACTIVE | GPIO_ACTIVE_LOW);

u32_t counter = 0;

while (1)
{
counter++;

if (counter == 1)
{
printk("green on\n");

gpio_pin_set(green_led, DT_ALIAS_LED0_GPIOS_PIN, 1U);
gpio_pin_set(orange_led, DT_ALIAS_LED1_GPIOS_PIN, 0U);
gpio_pin_set(red_led, DT_ALIAS_LED2_GPIOS_PIN, 0U);
gpio_pin_set(blue_led, DT_ALIAS_LED3_GPIOS_PIN, 0U);
}

if (counter == 2)
{
printk("orange on\n");

gpio_pin_set(green_led, DT_ALIAS_LED0_GPIOS_PIN, 0U);
gpio_pin_set(orange_led, DT_ALIAS_LED1_GPIOS_PIN, 1U);
gpio_pin_set(red_led, DT_ALIAS_LED2_GPIOS_PIN, 0U);
gpio_pin_set(blue_led, DT_ALIAS_LED3_GPIOS_PIN, 0U);
}

if (counter == 3)
{
printk("red on\n");

gpio_pin_set(green_led, DT_ALIAS_LED0_GPIOS_PIN, 0U);
gpio_pin_set(orange_led, DT_ALIAS_LED1_GPIOS_PIN, 0U);
gpio_pin_set(red_led, DT_ALIAS_LED2_GPIOS_PIN, 1U);
gpio_pin_set(blue_led, DT_ALIAS_LED3_GPIOS_PIN, 0U);
}

if (counter == 4)
{
printk("blue on\n");

gpio_pin_set(green_led, DT_ALIAS_LED0_GPIOS_PIN, 0U);
gpio_pin_set(orange_led, DT_ALIAS_LED1_GPIOS_PIN, 0U);
gpio_pin_set(red_led, DT_ALIAS_LED2_GPIOS_PIN, 0U);
gpio_pin_set(blue_led, DT_ALIAS_LED3_GPIOS_PIN, 1U);

counter = 0;
}

k_sleep(1000);
}


Re: API meeting: agenda

Carles Cufi
 

Updated agenda:

- RFC: API change: Add I2C bus recovery API
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/23441
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23442

- RFC: use compatible name for prefix for device-specific API
- PR: https://github.com/zephyrproject-rtos/zephyr/issues/24978

- RTC API follow-up (if the relevant people are present and there is material for discussion)
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526

- Documenting API behavior in Doxygen:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/18970
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21061

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Carles Cufi via lists.zephyrproject.org
Sent: 05 May 2020 16:08
To: users@lists.zephyrproject.org; devel@lists.zephyrproject.org
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

*************************************************
We will be using Teams instead of Zoom:
https://teams.microsoft.com/l/meetup-
join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thr
ead.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-
d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-
f04e4e156f10%22%7d
*************************************************

Today's topics:

- RFC: use compatible name for prefix for device-specific API
- PR: https://github.com/zephyrproject-rtos/zephyr/issues/24978

- RTC API follow-up (if the relevant people are present and there is
material for discussion)
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526

- Documenting API behavior in Doxygen:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/18970
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21061

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



API meeting: agenda

Carles Cufi
 

Hi all,

*************************************************
We will be using Teams instead of Zoom:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_YzYzZTAzNGItOWFiMS00MDBkLTkyYmMtNzljZjkwNDVlMThm%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d
*************************************************

Today's topics:

- RFC: use compatible name for prefix for device-specific API
- PR: https://github.com/zephyrproject-rtos/zephyr/issues/24978

- RTC API follow-up (if the relevant people are present and there is material for discussion)
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/23526

- Documenting API behavior in Doxygen:
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/18970
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/21061

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: samples/basic/blinky

Lawrence King
 

Hi Patrice:

 

Your statement that the behavior of the LED is ‘inverted’ is completely correct.

 

Your statement about the current is at best confusing. It is true that the GPIO doesn’t need to ‘source’ the current to turn the LED, but the GPIO does need to ‘sink’ the current. The amount of current flowing either into or out of the GPIO will be same no matter how the LED and resistor are connected. The reason we electrical engineers always choose to have the GPIO ‘sink’ the current is purely historical.

 

In the dark ages when we used +5V TTL logic (example 74LS04), the outputs of a logic gate could only source a small amount of current typically 6mA, and could sink a larger amount of current, typically 18mA. The LEDs available at the time needed at least 10mA to light up (and even at 10mA were not very bright), hence we were forced to use the sink capabilities of the gate to connect a LED to an output.

 

For no good reason we have continued with this convention, current generation LEDs are very bright with only 2mA of current, and current logic gates are symmetric drive which can source or sink 10mA or even 20mA. There is no good reason to have the logic ‘inverted’ other than historical convention.

 

I haven’t tried out all of the features of the new GPIO functions yet, but I think you can setup a GPIO to be “GPIO_ACTIVE_LOW” when calling gpio_pin_configure() and then drive the pin to GPIO_OUTPUT_ACTIVE when calling gpio_pin_set(), I believe this should turn the LED on.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of patrice.gerin via lists.zephyrproject.org
Sent: Monday, May 4, 2020 3:41 AM
To: users@...
Subject: Re: [Zephyr-users] samples/basic/blinky

 

Hellor Tristen,

The behavior of your LED seems normal!
In embedded design, LED are usually and voluntary inverted. Doing this will avoid the GPIO pin to provide the current by itself, the LED current will be supplied by the power directly.
                led       resistor
VCC |------|>|-----^v^v^v----------< GPIO |
If GPIO is set => no current
if GPIO is unset => current from VCC to the GPIO, no current provided by the stm32!
The LED is "active low".
Patrice


Re: samples/basic/blinky

Tristen Ennemuist
 

ah, thank you patrice - and now i've gained an understanding of the reason as well, much appreciated.  


Re: samples/basic/blinky

Tristen Ennemuist
 

heya nik thank you for responding, thankfully the schematics are available for download so i'll take a look and see what i can learn.

whew i've done plenty of programming on linux but i've never had to understand anything at this level, so thank you again for taking the time to help me out.


Network forum agenda

Jukka Rissanen
 

Hi all,

There is a network forum meeting tomorrow 5 May at 8AM PDT / 17.00 CET.

We will be using Teams instead of Zoom:
________________________________________________________________
Join Microsoft Teams Meeting<
https://teams.microsoft.com/l/meetup-join/19%3ameeting_ODE2MzMzZmItYWZjNC00N2E5LThjZjAtNGY3YTJkNDhlYTQw%40thread.v2/0?context=%7b%22Tid%22%3a%22686ea1d3-bc2b-4c6f-a92c-d99c5c301635%22%2c%22Oid%22%3a%2262b63b80-05d3-4465-b5a0-f04e4e156f10%22%7d
+1 213-437-3346<tel:+1%20213-437-3346,,335898965#> United States, Los
Angeles (Toll)
Conference ID: 335 898 965#
Local numbers<
https://dialin.teams.microsoft.com/488d1b50-0dd2-4ca1-aee4-92bb50a48081?id=335898965
| Reset PIN<https://mysettings.lync.com/pstnconferencing> | Learn
more about Teams<https://aka.ms/JoinTeamsMeeting> | Meeting options<
https://teams.microsoft.com/meetingOptions/?organizerId=62b63b80-05d3-4465-b5a0-f04e4e156f10&tenantId=686ea1d3-bc2b-4c6f-a92c-d99c5c301635&threadId=19_meeting_ODE2MzMzZmItYWZjNC00N2E5LThjZjAtNGY3YTJkNDhlYTQw@thread.v2&messageId=0&language=en-US
________________________________________________________________

Preliminary agenda:

* TCP2 status
* User mode networking

If you have anything you want to discuss, please let me know.


Cheers,
Jukka


Re: samples/basic/blinky

patrice.gerin@...
 

Hellor Tristen,

The behavior of your LED seems normal!
In embedded design, LED are usually and voluntary inverted. Doing this will avoid the GPIO pin to provide the current by itself, the LED current will be supplied by the power directly.
                led       resistor
VCC |------|>|-----^v^v^v----------< GPIO |
If GPIO is set => no current
if GPIO is unset => current from VCC to the GPIO, no current provided by the stm32!
The LED is "active low".
Patrice


samples/basic/blinky

Tristen Ennemuist
 

hello, i am [slowly] working my way through the examples, and i am a bit confused with the blinky sample project.

it seems that when 0 (zero) is written using gpio_pin_set then the LED on my board lights up and when 1 (one) is written the LED turns off. this is the opposite of what i was expecting,

however i am completely new to embedded development so i must apologise in embarrassment if it is my expectation that is the opposite!

ok, with the code:

i increased SLEEP_TIME_MS to 10000 so i could be sure there wasn't a timing issue on the output and i added the if/printk block to the while loop, and sure enough writing a zero results in led on and writing a one results in led off.

ie: the led is unlit and "led is now on", the led is lit and "led is now off".

my board is the stm32f469i_disco and i'm developing on fedora, below is the modified while loop, any feedback/advice would be much appreciated, thank you.

 while (1) {
gpio_pin_set(dev, PIN, (int)led_is_on);

if (led_is_on)
{
printk("led is now on\n");
}
else
{
printk("led is now off\n");
}

led_is_on = !led_is_on;
k_sleep(SLEEP_TIME_MS);
}  


Using device's HW crypto module with zephyr OS #nrf52-pca10040 #crypto

mdl.mailme@...
 

Hi,

I tried figuring out how to use the HW AES module on my device (nrf52 dk) with zephyr OS, but I didn't find any example and didn't manage to understand the crypto API and how to use it. I would like to have a minimal example of a working AES encryption in CCM mode. What Kconfig options do I have to set? Which crypto library do I have to use? Which variables do I have to set and which functions do I have to call?

Thanks in advance and regards,

Marco Liess


Test-related labels on GitHub

Carles Cufi
 

Hi all,

I have tried to clean up the test-related labels on GitHub, performing the following changes:

- "Testing" has been removed
- "Testing Suite" has been renamed to "Test Framework" and should be used for issues that are related to either the framework or missing platforms (eg. a new target on QEMU, an issue that affects multiple individual tests)
- "Tests" should be used for issues related to specific tests
- "Sanitycheck" should be used for issues related to the sanitycheck Python script

Additional labels, such as "Bug" or the relevant architecture(s) should be used to complement the information provided by the Test-related ones.

I have tried to go through all test-related issues and re-label them as appropriate.
Please use the new labels as described.

Thanks,

Carles

621 - 640 of 2609