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@...
Hi all,
|
|
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 <tomeaus@...>
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, Can you check https://github.com/zephyrproject-rtos/hal_stm32#use-stm32cube-in-your-application and see if solving your issue ? Cheers Erwan
On Wed, 6 May 2020 at 05:44, Tristen Ennemuist <tomeaus@...> wrote:
|
|
can't enable CONFIG_USE_STM32_HAL_DMA2D and CONFIG_USE_STM32_HAL_* in general
Tristen Ennemuist <tomeaus@...>
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 <tomeaus@...>
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:
toggle quoted messageShow quoted text
- 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-----
|
|
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
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
Hellor Tristen,
|
|
Re: samples/basic/blinky
Tristen Ennemuist <tomeaus@...>
ah, thank you patrice - and now i've gained an understanding of the reason as well, much appreciated.
|
|
Re: samples/basic/blinky
Tristen Ennemuist <tomeaus@...>
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> | Learnmore 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 <tomeaus@...>
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. 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
|
|
[2.3 release] Feature merge window close (M2) next week
Carles Cufi
Hi all,
This is just a reminder that the feature merge window close is on the 8th of May. This means that any changes that are not bugfixes or documentation changes must be merged by then. See the full timeline for the 2.3 release here: https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management#actual-and-planned-milestone-dates Thanks, Carles
|
|
Re: Connect two Zephyr instances via zeth interface
Jukka Rissanen
Hi Lei,
toggle quoted messageShow quoted text
see this example how to setup Linux host in this kind of setup https://github.com/zephyrproject-rtos/zephyr/issues/24282 Cheers, Jukka
On Tue, 2020-04-28 at 17:19 +0200, Lei Xu wrote:
Hi,
|
|