Re: [PATCH] gdb: prefere python3 if it is installed

On 20/08/2021 18:24, Gedare Bloom wrote: On Fri, Aug 20, 2021 at 2:02 AM Chris Johns wrote: On 20/8/21 5:42 pm, Christian MAUDERER wrote: Am 20.08.21 um 09:02 schrieb Chris Johns: On 20/8/21 4:48 pm, Christian MAUDERER wrote: Hello, Am 20.08.21 um 03:49 schrieb Chris Johns: On 20/8/21

Re: Outdated list of BSPs in rtems-tools/config

Hello Peter, Thomas, Karel, Am 14.09.23 um 22:15 schrieb Karel Gardas:   Hello Thomas, On 9/14/23 21:35, Thomas DOERFLER wrote: Hello Peter, just my two cents regarding eTPU: NXP has more or less left the PowerPC architecture and favor ARM for automotive applications. But the MPC5xxx

Re: Outdated list of BSPs in rtems-tools/config

Hello Peter, Am 13.09.23 um 19:22 schrieb Peter Dufault: On Jul 25, 2023, at 10:14 , Joel Sherrill wrote: Most of those are recent and from a lot of different people. GSoC, Kinsey, you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I think it has been around a LONG

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

Hello Duc, Am 24.06.22 um 16:28 schrieb Duc Doan: Hello Christian, On Thu, 2022-06-23 at 18:30 +0200, o...@c-mauderer.de wrote: Another tricky part can be how to handle pins or pin groups. At the moment I just used an "unsigned" for a single pin. That wouldn't be able to handle a pin group.

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

Hello Duc, Am 23.06.22 um 13:36 schrieb Duc Doan: On Tue, 2022-06-21 at 17:23 +0200, o...@c-mauderer.de wrote: OK. So every BSP that want's to use that API will have a different rtems_gpio_config_t (or every other structure) that is defined in (for example) bsp.h? The application has to know

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

Hello Duc, Am 25.06.22 um 13:43 schrieb Duc Doan: Hello Christian, On Fri, 2022-06-24 at 17:32 +0200, o...@c-mauderer.de wrote: Be careful with everything that depends on the BSP. Again: Please think about an i2c GPIO expander. That chip can be used on different BSPs. It can be even an

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

Hello Karel and Duc, Am 26.06.22 um 09:24 schrieb Duc Doan: Hello Karel, I came up with this solution: making a macro that returns a function depending on driver/BSP name. /** * @brief Get an GPIO control object. * * This macro requires BSPs/drivers to correctly implement *

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

Hello Duc, Am 29.06.22 um 13:46 schrieb Duc Doan: Hello Christian, I have been writing the complete API and also implementation for STM32F4. A patch is coming soon. On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote: Regarding pin groups: I think it's worth to think a bit about how

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

Am 21.06.22 um 16:31 schrieb Duc Doan: Using examples of working APIs is a good idea. But be careful not to copy any code from that framework because the license (GPL) wouldn't be compatible. Sure, I don't copy their code but only see what functions should be in a GPIO API (like

Re: Request for feedback for CAN message structure

Hello Pavel and Prashanth, Am 20.06.22 um 22:57 schrieb Pavel Pisa: Hello Prashanth S and others, excuse me for lower activity last weeks. We have exams period and I have lot of other duties and was even ill. I am at Embedded World in Nuremberg now, so may it be there is some chance to meet

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

Hello Duc, Am 14.06.22 um 16:46 schrieb Duc Doan: Dear all, I am proposing a new GPIO API for RTEMS. The current API is kind of tailored to some specific hardware and therefore may require some overhead to make it fit for others. The one I am proposing is not finished but it is aimed to be

Re: [PATCH] cpukit/dev/can: Added CAN support

Hello Prashanth, first question: You also worked on a driver for beagle DCAN. Did you already adapt that driver to this API? If yes, it would be usefull to post that as a patch too so that the direction and the method how it will be used is more clear. Note that some of my comments might

Re: [PATCH v4 1/7] bsps/stm32f4 Include STM32F4 HAL

Hello Duc, Am 23.07.22 um 09:37 schrieb Duc Doan: Hello Karel, On Sat, 2022-07-23 at 09:09 +0200, Karel Gardas wrote: Duc, where have you taken F4 HAL exactly? I'm asking since your import is full of CRLF line endings which we try hard to eliminate in RTEMS while original is not. Proof: $

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

Hello Duc, Am 01.08.22 um 04:13 schrieb Duc Doan: Hello Christian, On Sun, 2022-07-31 at 20:01 +0200, o...@c-mauderer.de wrote: Hello Duc, Am 31.07.22 um 17:07 schrieb Duc Doan: Hello Christian, On Sat, 2022-07-30 at 16:32 +0200, o...@c-mauderer.de wrote: Hello Duc, general note for the

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

Am 30.07.22 um 21:41 schrieb Karel Gardas: On 7/30/22 16:32, o...@c-mauderer.de wrote:   bsps/arm/include/cmsis_compiler.h |   266 +   bsps/arm/include/cmsis_gcc.h  |  3460 +--   bsps/arm/include/cmsis_version.h  |    39 +   bsps/arm/include/core_cm4.h 

Re: [PATCH v5 2/4] bsps: New GPIO API & peripherals API framework

Hello Duc, Am 24.07.22 um 14:01 schrieb Duc Doan: --- bsps/include/bsp/gpio2.h| 528 bsps/include/bsp/periph_api.h | 142 +++ bsps/shared/dev/gpio/gpio.c | 212 ++ bsps/shared/dev/periph_api/periph_api.c | 101 +

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

Hello Duc, general note for the patch: Please write in the commit message where you got the sources from. That can be a link to a github repo including a commit ID or a link to the zip file from ST (including a date, version or similar information). If you moved some stuff around compared to

Re: devel Digest, Vol 129, Issue 37

Hello Prashanth, I added a number of comments for the first (API) commit using the gitlab comment function: https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/2283ab18bd2fbfa363233c6dabcfa5123225f27c PS: Please don't answer to Devel Digests. That adds totally unrelated content to your

Re: Review Request for DCAN patches

Hello Prashanth, from my point of view the patches look good and I think you processed Gedares feedback too. So if no one objects I'll pus the patches on the weekend. Last version is this one: https://gitlab.com/slpp95prashanth/gsoc-2022/-/commits/30199c2af1c65f05f820a/ Like discussed in

Re: Adding third-party source with Apache-2.0 license

Hello Duc, Am 07.08.22 um 13:06 schrieb Duc Doan: Dear all, I am working on a project that needs to include ST's STM32F4 HAL into RTEMS, specifically release v1.27.1 at: https://github.com/STMicroelectronics/STM32CubeF4. However, the CMSIS files in this repository have Apache-2.0 license. What

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

Hello Duc, Am 31.07.22 um 17:07 schrieb Duc Doan: Hello Christian, On Sat, 2022-07-30 at 16:32 +0200, o...@c-mauderer.de wrote: Hello Duc, general note for the patch: Please write in the commit message where you got the sources from. That can be a link to a github repo including a commit ID

Re: [PATCH] cpukit/dev/can: Added CAN support

Hello Duc, general note: You add an API to cpukit. Most APIs there should have a test case in the testsuite. In this case the test case would have to create some dummy CAN driver and check whether everything works like expected. As an example take a look at the SPI test:

Re: [PATCH v5 2/4] bsps: New GPIO API & peripherals API framework

Hello Duc, Am 02.08.22 um 09:17 schrieb Duc Doan: [...] diff --git a/bsps/include/bsp/periph_api.h b/bsps/include/bsp/periph_api.h new file mode 100644 index 00..fb02b701dc --- /dev/null +++ b/bsps/include/bsp/periph_api.h Isn't it an API just because you add it here. Is it really

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

Hello Duc, Am 02.08.22 um 12:37 schrieb Duc Doan: Hello Christian, On Sat, 2022-07-30 at 22:19 +0200, o...@c-mauderer.de wrote: Am 30.07.22 um 21:41 schrieb Karel Gardas: On 7/30/22 16:32, o...@c-mauderer.de wrote:   bsps/arm/include/cmsis_compiler.h |   266 +  

Re: Fwd: Identify 3rd party source in spec?

Hello Gedare, Am 31.10.22 um 20:01 schrieb Gedare Bloom: Resending without the first patch since it may trigger size filters. -- Forwarded message - From: Gedare Bloom Date: Mon, Oct 31, 2022 at 12:55 PM Subject: Identify 3rd party source in spec? To: devel@rtems.org Hello

Re: RSB repo commits need approval

Hello Joel, Am 28.04.23 um 00:19 schrieb Joel Sherrill: On Wed, Apr 26, 2023 at 7:06 PM Chris Johns > wrote: Hi, All RSB repo commits need to be posted for review and independent approval given before being pushed to the top level repo. I thought

Re: RSB repo commits need approval

Am 30.04.23 um 23:53 schrieb Chris Johns: On 29/4/2023 3:48 am, o...@c-mauderer.de wrote: Hello Joel, Am 28.04.23 um 00:19 schrieb Joel Sherrill: On Wed, Apr 26, 2023 at 7:06 PM Chris Johns mailto:chr...@rtems.org>> wrote:     Hi,     All RSB repo commits need to be posted for review

Re: libbsd development policy clarification needed?

Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two

Re: [PATCH rtems 6/6] bsps/imxrt: Add imxrt1166_cm7_saltshaker BSP

Hello Jacob, Am 14.07.23 um 09:08 schrieb Christian MAUDERER: Hello Jacob, On 2023-07-14 08:36, Christian MAUDERER wrote: Hello Jacob, On 2023-07-13 18:59, Jacob Killelea wrote: Hi Christian, This looks awesome! Do you have any interest in adding support for the i.MXRT1062 based Teensy

Re: Discussion: How to handle HALs, SDKs and libraries

Hello Karel, Am 15.07.23 um 19:22 schrieb Karel Gardas: On 7/15/23 16:00, o...@c-mauderer.de wrote: We should avoid rebasing and overwriting the old branch because we have to preserve a version that can be used with older RTEMS versions. So for rebasing, we would have to use multiple

Re: Westernization of RTEMS/stm32H7 [was: Re: Discussion: How to handle HALs, SDKs and libraries]

Hello Karel, Am 16.07.23 um 00:07 schrieb Karel Gardas:   Hello, Christian mentioned Zephyr west tool as one of good/possible candidates for RTEMS tree modularization especially with regarding to HALs and other 3rd party libraries. I mentioned it as one of three tools that I know that

Re: Discussion: How to handle HALs, SDKs and libraries

Hello Karel, Am 16.07.23 um 12:37 schrieb Karel Gardas: On 7/16/23 10:03, o...@c-mauderer.de wrote: Of course the revision from two months back has to be available in the repo. It doesn't really matter whether it's on master because the code just worked or whether it's a RTEMS specific branch

Re: Discussion: How to handle HALs, SDKs and libraries

Hello Karel, thanks for trying that. I wouldn't object to add it to 6 but I wouldn't expect it either because it means a lot of adaptions to the release scripts. Chris most likely can tell you more about whether it's even thinkable at that point in the release cycle or not. Am 15.07.23 um

Re: Discussion: How to handle HALs, SDKs and libraries

Hello Karel, Am 15.07.23 um 12:17 schrieb Karel Gardas: On 7/15/23 09:47, o...@c-mauderer.de wrote: Am 15.07.23 um 01:48 schrieb Karel Gardas:   Hello, I've created setup where I've put updated STM32H7 HAL consisting of two submodules: - stm32h7xx_hal_driver - cmsis_device_h7 and ARM's

Re: Discussion: How to handle HALs, SDKs and libraries

Hello Karel, Am 15.07.23 um 15:03 schrieb Karel Gardas: On 7/15/23 14:33, o...@c-mauderer.de wrote: I like submodules because they are well-supported by the usual tools. Honestly. I like submodules idea, but hate its implementation. Some reasons: - submodules were added as a light weight

Re: [PATCH rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

Hello Gedare, thanks for taking a look at the patch set. Am 05.05.23 um 15:56 schrieb Gedare Bloom: On Thu, May 4, 2023 at 9:01 AM Christian Mauderer wrote: Hello, this patch set for the arm/imxrt BSP family updates the SDK files to the latest version of the mcux-sdk from NXP and prepares

Re: [PATCH rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant

Hello Chris, Am 15.05.23 um 05:18 schrieb Chris Johns: On 6/5/2023 2:02 am, Gedare Bloom wrote: On Fri, May 5, 2023 at 9:02 AM wrote: Hello Gedare, thanks for taking a look at the patch set. Am 05.05.23 um 15:56 schrieb Gedare Bloom: On Thu, May 4, 2023 at 9:01 AM Christian Mauderer