Hi Giovanni,
Thank you for accepting those patches! I've found that for some reason multi ADC, TRNG and TRC tests were not added. I've attached them in the tarball for your convenience. All included demos and the mentioned tests work!
In addition to that, I've moved from UARTv2 to UARTv3, made small cleanups and some fixes for USB related RCC functions and added multi UART and USB_CDC tests. However, UART and USB_CDC tests are not working at this moment:
UART: The problem is that uartSendTimeout(..., TIME_INFINITE) never finishes and fails if TIME_INFINITE is changed to some finite value.
USB_CDC: The problem is that PORTAB_SDU1.config->usbp->state equals to USB_READY and never changes to USB_ACTIVE.
I will continue debugging them but it would be great if you can take a look at them as well.
Best regards,
Ilya.
STM32WB55 support
Re: STM32WB55 support
- Attachments
-
- STM32WB55xx-549b33.zip
- STM32WB55xx ADC, RTC, TRNG, UART and USB_CDC tests
- (55.9 KiB) Downloaded 450 times
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: STM32WB55 support
Hi Giovanni,
Thank you, I've tested them. Can you also include small fixes and tests for UART and USB_CDC attached to this post?
Best regards,
Ilya.
Thank you, I've tested them. Can you also include small fixes and tests for UART and USB_CDC attached to this post?
Best regards,
Ilya.
- Attachments
-
- STM32WB55xx-ec8031.zip
- Fixes, UART and USB_CDC tests
- (27.67 KiB) Downloaded 501 times
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: STM32WB55 support
Hi Ilya,
I just noticed this.
For HAL and test files:
You licensed all the code under your copyright, this is not correct because the code is a modification of code created by me. The usual way to proceed is to add your statement after my normal header like this:
For chconf.h files:
Those are configuration files, changing the copyright or adding further copyrights is not acceptable at all.
To be clear, I am willing to accept code into the mainline as long copyright is assigned to me or I would not be able to re-license it, ChibiOS is also a commercial product and I need to keep it copyright-clean.
Is this clear and acceptable for you?
Giovanni
I just noticed this.
For HAL and test files:
You licensed all the code under your copyright, this is not correct because the code is a modification of code created by me. The usual way to proceed is to add your statement after my normal header like this:
Code: Select all
/*
ChibiOS - Copyright (C) 2006..2020 Giovanni Di Sirio
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
/*
Concepts and parts of this file have been contributed by Ilya Kharin.
*/
For chconf.h files:
Those are configuration files, changing the copyright or adding further copyrights is not acceptable at all.
To be clear, I am willing to accept code into the mainline as long copyright is assigned to me or I would not be able to re-license it, ChibiOS is also a commercial product and I need to keep it copyright-clean.
Is this clear and acceptable for you?
Giovanni
Re: STM32WB55 support
Hi Giovanni,
Frankly speaking, I didn't pay enough attention to this subject before. I noticed that files in the repository licensed by different names, that's why I put my name under all new files, including those which were copied and modified and those which were written from the ground, thinking that it was a right way to specify developer's name. I'm fine with what you wrote as it's the only way to contribute.
Best regards,
Ilya.
Frankly speaking, I didn't pay enough attention to this subject before. I noticed that files in the repository licensed by different names, that's why I put my name under all new files, including those which were copied and modified and those which were written from the ground, thinking that it was a right way to specify developer's name. I'm fine with what you wrote as it's the only way to contribute.
Best regards,
Ilya.
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: STM32WB55 support
Hi Ilya,
Copyrights are quite important so it is better to be clear.
On the community repository there could other names but in the main there are only credits to contributors (or I missed something??) and one exception, EX is copyright of Rocco Marco, he is the full author of that module and I have a special agreement with him.
I don't want to force anybody, you have the option to put the port on the community repository and keep combined ownership. I need to be able to re-license ChibiOS for commercial customers and mixed copyrights would prevent me to do so, I cannot re-license code that belongs to others.
Giovanni
Copyrights are quite important so it is better to be clear.
On the community repository there could other names but in the main there are only credits to contributors (or I missed something??) and one exception, EX is copyright of Rocco Marco, he is the full author of that module and I have a special agreement with him.
I don't want to force anybody, you have the option to put the port on the community repository and keep combined ownership. I need to be able to re-license ChibiOS for commercial customers and mixed copyrights would prevent me to do so, I cannot re-license code that belongs to others.
Giovanni
Re: STM32WB55 support
Hi Ilya,
I've migrated a substantial project to WB55-NUCLEO and have basic functionality running.
The application is using SPI, RTC and WDG so far and will also exercise I2C when I add a device to access.
I've made a few updates to the files so far:
1. Updated copyright notice in board.c/h files
2. Changed DMA assignments in mcuconf.h files to use DMAMUX (STM32_DMA_STREAM_ID_ANY)
3. Added GPIOE and GPIOH (OSC_IN, OSC_OUT) to board definitions and registry file.
4. Added checks for STM32WB3x in registry.
5. Fixed I2C2 reference in registry.
6. Update EXTI number and mask2 in registry.
I will push these updates today.
There is still plenty to do for sure in just basic RCC, etc. in addition to IPCC and HSEM drivers.
The EFL will need to handle the Secure Flash boundary and being a shared resource should use HSEM in the driver.
The .ld will also need to reflect the CPU2 secured flash area and SRAM2 as being separate, etc.
So the list of extra details to deal with for CPU2 goes on and on (as I'm sure you know)
Giovanni,
For the moment the exercise of using RCCv1 might be best held off until more of the CPU2 specific details are dealt with.
--
Bob
I've migrated a substantial project to WB55-NUCLEO and have basic functionality running.
The application is using SPI, RTC and WDG so far and will also exercise I2C when I add a device to access.
I've made a few updates to the files so far:
1. Updated copyright notice in board.c/h files
2. Changed DMA assignments in mcuconf.h files to use DMAMUX (STM32_DMA_STREAM_ID_ANY)
3. Added GPIOE and GPIOH (OSC_IN, OSC_OUT) to board definitions and registry file.
4. Added checks for STM32WB3x in registry.
5. Fixed I2C2 reference in registry.
6. Update EXTI number and mask2 in registry.
I will push these updates today.
There is still plenty to do for sure in just basic RCC, etc. in addition to IPCC and HSEM drivers.
The EFL will need to handle the Secure Flash boundary and being a shared resource should use HSEM in the driver.
The .ld will also need to reflect the CPU2 secured flash area and SRAM2 as being separate, etc.
So the list of extra details to deal with for CPU2 goes on and on (as I'm sure you know)
Giovanni,
For the moment the exercise of using RCCv1 might be best held off until more of the CPU2 specific details are dealt with.
--
Bob
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: STM32WB55 support
Thanks Bob,
The only things we should add are:
1) Support in the board files generator and create .chcfg files.
2) Updater tool for the mcuconf.h.
After this it will be in line with other ports.
Giovanni
The only things we should add are:
1) Support in the board files generator and create .chcfg files.
2) Updater tool for the mcuconf.h.
After this it will be in line with other ports.
Giovanni