[PATCH] cpukit/dev/can: Added CAN support
---
cpukit/dev/can/can.c | 514 +
cpukit/include/dev/can/can-msg.h | 55 +++
cpukit/include/dev/can/can-queue.h | 127 +++
cpukit/include/dev/can/can.h | 102 ++
spec/build/cpukit/librtemscpu.yml | 6 +
5 files changed, 804 insertions(+)
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/include/dev/can/can-msg.h
create mode 100644 cpukit/include/dev/can/can-queue.h
create mode 100644 cpukit/include/dev/can/can.h
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 00..8feec8800b
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,514 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S (fishesprasha...@gmail.com)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+#include
+
+static ssize_t
+can_bus_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode);
+static ssize_t
+can_bus_read(rtems_libio_t *iop, void *buffer, size_t count);
+static ssize_t
+can_bus_write(rtems_libio_t *iop, const void *buffer, size_t count);
+static ssize_t
+can_bus_ioctl(rtems_libio_t *iop, ioctl_command_t request, void *buffer);
+
+static int can_xmit(struct can_bus *bus);
+
+static int can_create_sem(struct can_bus *);
+static int try_sem(struct can_bus *);
+static int take_sem(struct can_bus *);
+static int give_sem(struct can_bus *);
+
+/* sem_count this is for debug purpose, for debugging
+the take_sem and give_sem
+*/
+static int sem_count = 0;
+
+static void can_bus_obtain(can_bus *bus)
+{
+ rtems_recursive_mutex_lock(&bus->mutex);
+}
+
+static void can_bus_release(can_bus *bus)
+{
+ rtems_recursive_mutex_unlock(&bus->mutex);
+}
+
+int can_create_sem(struct can_bus *bus)
+{
+ int ret = 0;
+
+ ret = rtems_semaphore_create(rtems_build_name('c', 'a', 'n', bus->index),
+ CAN_TX_BUF_COUNT, RTEMS_FIFO | RTEMS_COUNTING_SEMAPHORE | RTEMS_LOCAL,
+ 0, &bus->tx_fifo_sem_id);
+
+ if (ret != 0) {
+printf("can_create_sem: rtems_semaphore_create failed %d\n", ret);
+ }
+
+ return ret;
+}
+
+static void can_interrupt_lock_acquire(struct can_bus *bus)
+{
+ can_bus_obtain(bus);
+ bus->can_dev_ops->dev_int(bus->priv, false);
+}
+
+static void can_interrupt_lock_release(struct can_bus *bus)
+{
+ bus->can_dev_ops->dev_int(bus->priv, true);
+ can_bus_release(bus);
+}
+
+static int take_sem(struct can_bus *bus)
+{
+ int ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_WAIT,
+RTEMS_NO_TIMEOUT);
+ if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("take_sem: Counting semaphore count = %d\n", ++sem_count);
+if (sem_count > CAN_TX_BUF_COUNT) {
+ printf("take_sem error: sem_count is misleading\n");
+ while (1);
+}
+ }
+
+ return ret;
+}
+
+static int give_sem(struct can_bus *bus)
+{
+ int ret = rtems_semaphore_release(bus->tx_fifo_sem_id);
+ if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("give_sem: Counting semaphore count = %d\n", --sem_count);
+if (sem_count < 0) {
+ printf("give_sem error: sem_count is misleading\n");
+ while (1);
+}
+ }
+
+ return ret;
+}
+
+static int try_sem(struct can_bus *bus)
+{
+ int ret = rtems_semaphore_obtain(bus->tx_fifo_sem_id, RTEMS_NO_WAIT,
+RTEMS_NO_TIMEOUT);
+ if (ret == RTEMS_SUCCESSFUL) {
+CAN_DEBUG_LOCK("take_sem: Counting semaphore count = %d\n", ++sem_count);
+if (sem_count > CAN_TX_BUF_COUNT) {
+ printf("take_sem error: sem_count is misleading\n");
[PATCH] cpukit/dev/can: Added CAN support (Prashanth S)
Hi All, This is a review request for CAN support. I have addressed the review comments. The files are work in progress, I need to add few more comments in the include (*.h) files. Regards Prashanth S On Sun, 31 Jul 2022 at 17:24, wrote: > Send devel mailing list submissions to > devel@rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-requ...@rtems.org > > You can reach the person managing the list at > devel-ow...@rtems.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > > Today's Topics: > >1. Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL (Karel Gardas) >2. Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL > (o...@c-mauderer.de) >3. [PATCH] cpukit/dev/can: Added CAN support (Prashanth S) > > > -- > > Message: 1 > Date: Sat, 30 Jul 2022 21:41:19 +0200 > From: Karel Gardas > To: o...@c-mauderer.de, Duc Doan , devel@rtems.org > Subject: Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL > Message-ID: <2af4f901-b157-c0b0-cc75-45921bf788eb@functional.vision> > Content-Type: text/plain; charset=UTF-8; format=flowed > > 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?? |?? 524 +- > >> ? bsps/arm/include/core_cm7.h?? |? 5186 ++-- > >> ? bsps/arm/include/mpu_armv7.h? |?? 270 + > > > > Are the cmsis files from the same source or directly from ARM? > > > > The cmsis_gcc.h has a lot of changes compared to the earlier version > > that has been present in RTEMS. A lot of the changes seem to be > > whitespace changes. Can these be avoided somehow (for example by using > > dos2unix before overwriting the file)? > > > > In the discord chat there was one suggestion from Ho Kaido to move the > > files one level down and make them BSP specific. I'm not sure whether > > I'm for or against that idea. Advantage is that it makes BSPs > > independant from each other. Disadvantage is that it duplicates code. > > > > I think I would try to avoid moving them down due to the code > > duplication but it raises the question: Which BSPs use the files too and > > did you try whether they still compile after the upgrade? > > We have had this dicussion with Duc on discord IIRC when he started. He > needed new CMSIS (v5) version due to new HAL which Duc claims depends on > them. I have not verified that claim personally. > > New CMSIS v5 brings obviously: > > - by ARM maintained code (v4 is unmaintained IIRC) > > but also: > > - license change from BSD to Apache-2 > > At that time I've told Duc to continue with the code and not to worry > about license changes -- as this would be longer discussion anyway. Not > sure, but IIRC he also wrote to Sebastian asking for clarification -- > well, not sure about that. Certainly IIRC I suggested that. > > Anyway, I took Duc code and try H7 BSPs and to my surprise they compiles > more or less all without any compilation related issue. Well, I've not > tried M4 variants. So far I've not run full tester on this. I'll, but > first I'd like to test his API if it's possible to also use with H7. > > BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then it's > perhaps possible to go in F4 HAL history back and grab just the three > with the v4 dependency. On the other hand, for ARM Apache-2 seems to be > the way forward and for some ST.com depended code too -- so I guess > RTEMS project will need to live with that fact somehow. > > Thanks, > Karel > > > -- > > Message: 2 > Date: Sat, 30 Jul 2022 22:19:54 +0200 > From: o...@c-mauderer.de > To: Karel Gardas , Duc Doan > , devel@rtems.org > Subject: Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL > Message-ID: <3628b5b2-0848-304f-9738-f6d64e9bb...@c-mauderer.de> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > > 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?? |?? 524 +- > >>> ? bsps/arm/include/core_cm7.h?? |? 5186 ++-- > >>> ? bsps/arm/include/mpu_armv7.h? |?? 270 + > >> > >> Are the cmsis files from the same source or directly from ARM? > >> > >> The cmsis_gcc.h has a lot of changes compared to the earlier version > >> that has been present in RTEMS. A lot of the changes seem
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
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 or a link to the zip file from ST (including a date, > version > or similar information). If you moved some stuff around compared to > the > original structure: Please describe about what you did. For example > in > the imxrt I just added the cp commands that I used: > > > https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285 > > Not the best solution but at least someone else can find out roughly > what I did. > Ah yes, I will do that. I thought I only needed to put the description in the email before. > Am 24.07.22 um 14:01 schrieb Duc Doan: > > This patch is too large so I cannot send via email. Please find it > > here: > > https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16 > > > > --- > > .gitignore | 1 + > > You added a "patches" directory to the gitignore. That looks like a > change that is specific to your method of working. These kind of > changes > should normall not be pushed. > > If you want to ignore stuff specific to your work environment, I > recommend to use a global .gitignore file. Git has a > "core.excludesfile" > config for that. > Thanks for the suggestion, I will fix that. > > 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 | 524 +- > > bsps/arm/include/core_cm7.h | 5186 ++-- > > bsps/arm/include/mpu_armv7.h | 270 + > > Are the cmsis files from the same source or directly from ARM? > They are from the same source (STM HAL v1.27.1). > The cmsis_gcc.h has a lot of changes compared to the earlier version > that has been present in RTEMS. A lot of the changes seem to be > whitespace changes. Can these be avoided somehow (for example by > using > dos2unix before overwriting the file)? > From what I've just read about dos2unix, it converts line breaks from CRLF to LF (please correct me if I'm wrong). How will this command resolve the whitespace changes? > In the discord chat there was one suggestion from Ho Kaido to move > the > files one level down and make them BSP specific. I'm not sure whether > I'm for or against that idea. Advantage is that it makes BSPs > independant from each other. Disadvantage is that it duplicates code. > > I think I would try to avoid moving them down due to the code > duplication but it raises the question: Which BSPs use the files too > and > did you try whether they still compile after the upgrade? > Until now I only know of STM32H7 BSP that is using the CMSIS files. I tried compiling it before and Karel also confirmed that the BSP compiles. > > > .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c | 1679 ++ > > .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c | 2307 ++ > > bsps/arm/stm32f4/hal/stm32f4xx_hal.c | 615 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c | 2110 ++ > > bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c | 1112 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c | 2462 ++ > > bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c | 996 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c | 502 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c | 328 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c | 7132 ++ > > bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c | 680 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c | 1341 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c | 495 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c | 1161 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c | 182 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c | 4423 > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c | 1305 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c | 2126 ++ > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c | 313 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c | 2760 +++ > > bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c | 3220 +++ > > bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c | 547 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c | 775 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c | 1347 + > > .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c | 172 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpi2c.c | 6864 ++ > > .../arm/stm32f4/hal/stm32f4xx_hal_fmpi2c_ex.c | 258 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpsmbus.c | 2749 +++ > > .../stm32f4/hal/stm32f4xx_hal_fmpsmbus_ex.c | 145 + > > bsps/arm/stm32f4/hal/stm32f4xx_hal_gpio.c | 533 + > > bsps/arm/stm32f4/hal/stm3
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 or a link to the zip file from ST (including a date, version or similar information). If you moved some stuff around compared to the original structure: Please describe about what you did. For example in the imxrt I just added the cp commands that I used: https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285 Not the best solution but at least someone else can find out roughly what I did. Ah yes, I will do that. I thought I only needed to put the description in the email before. Am 24.07.22 um 14:01 schrieb Duc Doan: This patch is too large so I cannot send via email. Please find it here: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16 --- .gitignore | 1 + You added a "patches" directory to the gitignore. That looks like a change that is specific to your method of working. These kind of changes should normall not be pushed. If you want to ignore stuff specific to your work environment, I recommend to use a global .gitignore file. Git has a "core.excludesfile" config for that. Thanks for the suggestion, I will fix that. 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 | 524 +- bsps/arm/include/core_cm7.h | 5186 ++-- bsps/arm/include/mpu_armv7.h | 270 + Are the cmsis files from the same source or directly from ARM? They are from the same source (STM HAL v1.27.1). The cmsis_gcc.h has a lot of changes compared to the earlier version that has been present in RTEMS. A lot of the changes seem to be whitespace changes. Can these be avoided somehow (for example by using dos2unix before overwriting the file)? From what I've just read about dos2unix, it converts line breaks from CRLF to LF (please correct me if I'm wrong). How will this command resolve the whitespace changes? I haven't looked at the exact type of whitespace changes. I had the impression that the difference is most likely only the line ending. It didn't look like tab / space issue. Is it a tab / space issue? In the discord chat there was one suggestion from Ho Kaido to move the files one level down and make them BSP specific. I'm not sure whether I'm for or against that idea. Advantage is that it makes BSPs independant from each other. Disadvantage is that it duplicates code. I think I would try to avoid moving them down due to the code duplication but it raises the question: Which BSPs use the files too and did you try whether they still compile after the upgrade? Until now I only know of STM32H7 BSP that is using the CMSIS files. I tried compiling it before and Karel also confirmed that the BSP compiles. Just as an example: core_cm4/7.h is included at least in stm32f4, stm32h7, atsam and imxrt. So we have to make sure that these three are compile-clean. Please use grep to find out where the headers are included and check whether I maybe missed a BSP. .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c | 1679 ++ .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c | 2307 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal.c | 615 + bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c | 2110 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c | 1112 + bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c | 2462 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c | 996 + bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c | 502 + bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c | 328 + bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c | 7132 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c | 680 + bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c | 1341 + bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c | 495 + bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c | 1161 + bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c | 182 + bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c | 4423 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c | 1305 + bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c | 2126 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c | 313 + bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c | 2760 +++ bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c | 3220 +++ bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c | 547 + bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c | 775 + bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c | 1347 + .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c | 172 + bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpi2c.c
Re: [PATCH] rtems-tools-6.cfg: Bump hash
OK
Thanks
Chris
On 30/7/2022 1:47 am, Ryan Long wrote:
> ---
> rtems/config/tools/rtems-tools-6.cfg | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-tools-6.cfg
> b/rtems/config/tools/rtems-tools-6.cfg
> index c032bd4..a667175 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %define rtems_tools_ext xz
> %else
> - %define rtems_tools_version f199d42e47e2e19175427e95797ca2f829f6aaa9
> + %define rtems_tools_version ace7db96d4561665b07ba15c2fe5f9349f4d3d8c
> %define rtems_tools_ext bz2
> %endif
>
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %source set rtems-tools
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
> %hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -
> VGmVZ8xUGYlnc7C6QGiwBbLp8e2e8/i1drFA0/y2gkoSIIcKMTIaS8gV+Qi6RuoBjJhg3HiNJ3pXIPsBCUi3Hw==
> +
> zYlopSJV6AEgEWqy3Y0c60BCy6cXWt1ej+F0OvFFzZf6PQ38avoKxlOkkDY1hzlfOjhR4AFaFM89k5vcYClreA==
>
> #
> # Optionally enable/disable building the RTEMS Tools via the command line.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
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 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 > > > the > > > original structure: Please describe about what you did. For > > > example > > > in > > > the imxrt I just added the cp commands that I used: > > > > > > > > > https://git.rtems.org/rtems/commit/bsps/arm/imxrt?id=48f6a6c302a3e1a3f8915e2503d0fe618d1af285 > > > > > > Not the best solution but at least someone else can find out > > > roughly > > > what I did. > > > > > > > Ah yes, I will do that. I thought I only needed to put the > > description > > in the email before. > > > > > Am 24.07.22 um 14:01 schrieb Duc Doan: > > > > This patch is too large so I cannot send via email. Please find > > > > it > > > > here: > > > > https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16 > > > > > > > > --- > > > > .gitignore | 1 + > > > > > > You added a "patches" directory to the gitignore. That looks like > > > a > > > change that is specific to your method of working. These kind of > > > changes > > > should normall not be pushed. > > > > > > If you want to ignore stuff specific to your work environment, I > > > recommend to use a global .gitignore file. Git has a > > > "core.excludesfile" > > > config for that. > > > > > > > Thanks for the suggestion, I will fix that. > > > > > > 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 | 524 +- > > > > bsps/arm/include/core_cm7.h | 5186 ++-- > > > > bsps/arm/include/mpu_armv7.h | 270 + > > > > > > Are the cmsis files from the same source or directly from ARM? > > > > > > > They are from the same source (STM HAL v1.27.1). > > > > > The cmsis_gcc.h has a lot of changes compared to the earlier > > > version > > > that has been present in RTEMS. A lot of the changes seem to be > > > whitespace changes. Can these be avoided somehow (for example by > > > using > > > dos2unix before overwriting the file)? > > > > > > > From what I've just read about dos2unix, it converts line breaks > > from > > CRLF to LF (please correct me if I'm wrong). How will this command > > resolve the whitespace changes? > > I haven't looked at the exact type of whitespace changes. I had the > impression that the difference is most likely only the line ending. > It > didn't look like tab / space issue. Is it a tab / space issue? > I've looked at the some files and noticed that the difference is mostly additional code/code change (e.g. adding support for ARMv8), but not whitespace changes. > > > > > In the discord chat there was one suggestion from Ho Kaido to > > > move > > > the > > > files one level down and make them BSP specific. I'm not sure > > > whether > > > I'm for or against that idea. Advantage is that it makes BSPs > > > independant from each other. Disadvantage is that it duplicates > > > code. > > > > > > I think I would try to avoid moving them down due to the code > > > duplication but it raises the question: Which BSPs use the files > > > too > > > and > > > did you try whether they still compile after the upgrade? > > > > > > > Until now I only know of STM32H7 BSP that is using the CMSIS files. > > I > > tried compiling it before and Karel also confirmed that the BSP > > compiles. > > Just as an example: core_cm4/7.h is included at least in stm32f4, > stm32h7, atsam and imxrt. So we have to make sure that these three > are > compile-clean. Please use grep to find out where the headers are > included and check whether I maybe missed a BSP. > I have checked using grep (grep -rl ~/gsoc2022/src/rtems/bsps/arm -e "cmsis\|core_cm" and found that stm32f4, imxrt, stm32h7, and atsam are using CMSIS files (you remembered all correctly!). I've checked and all 4 of them compile without error. Best, Duc > > > > > > > > > .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c | 1679 ++ > > > > .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c | 2307 ++ > > > > bsps/arm/stm32f4/hal/stm32f4xx_hal.c | 615 + > > > > bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c | 2110 ++ > > > > bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c | 1112 + > > > > bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c | 2462 ++ > > > > bsps/arm/stm32f4/hal/stm32
Re: [PATCH v5 2/4] bsps: New GPIO API & peripherals API framework
Hello Christian,
On Sat, 2022-07-30 at 17:50 +0200, o...@c-mauderer.de wrote:
> 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 +
> > spec/build/bsps/obj.yml | 4 +-
> > 5 files changed, 986 insertions(+), 1 deletion(-)
> > create mode 100644 bsps/include/bsp/gpio2.h
> > create mode 100644 bsps/include/bsp/periph_api.h
> > create mode 100644 bsps/shared/dev/gpio/gpio.c
> > create mode 100644 bsps/shared/dev/periph_api/periph_api.c
> >
> > diff --git a/bsps/include/bsp/gpio2.h b/bsps/include/bsp/gpio2.h
>
> I'm not really happy with the "2" in the name. But at the moment I
> don't
> have a much better idea either. But if you call it "gpio2", you
> should
> call the C files "gpio2" too. Maybe "dev/gpio/gpio.h" similar to the
> "dev/i2c/i2c.h"?
>
I will rename the C file to "gpio2.c" for now.
> > new file mode 100644
> > index 00..9cb1c720ab
> > --- /dev/null
> > +++ b/bsps/include/bsp/gpio2.h
> > @@ -0,0 +1,528 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +
>
> Your file is missing some general doxygen group information. Take a
> look
> at for example bsps/include/ofw/ofw.h.
>
Thanks for the reminder, I will add that.
> > +/*
> > + * Copyright (C) 2022 Duc Doan (dtbpkmte at gmail.com)
> > + *
> > + * Redistribution and use in source and binary forms, with or
> > without
> > + * modification, are permitted provided that the following
> > conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above
> > copyright
> > + * notice, this list of conditions and the following
> > disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above
> > copyright
> > + * notice, this list of conditions and the following disclaimer
> > in the
> > + * documentation and/or other materials provided with the
> > distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> > CONTRIBUTORS "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > LIMITED TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> > PARTICULAR PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> > CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> > EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> > PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> > BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> > WHETHER IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> > OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> > ADVISED OF THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +#ifndef LIBBSP_BSP_GPIO2_H
> > +#define LIBBSP_BSP_GPIO2_H
> > +
> > +#include
> > +#include
> > +
> > +/**
> > + * Configure the maximum number of GPIO controllers used in
> > + * a application.
> > + *
> > + * The macro CONFIGURE_GPIO_MAXIMUM_CONTROLLERS can be
> > + * defined in application code. If it is not defined,
> > + * it will default to BSP_GPIO_NUM_CONTROLLERS. If BSP's
> > + * number of controllers is not defined, it will default
> > + * to 1.
> > + */
> > +#ifndef CONFIGURE_GPIO_MAXIMUM_CONTROLLERS
>
> How do you manage that the CONFIGURE_GPIO_MAXIMUM_CONTROLLERS from
> the
> application is visible here?
>
I forgot to remove this CONFIGURE_GPIO_MAXIMUM_CONTROLLERS thing. At
first I wanted to do something like confdef but couldn't, so I changed
to use BSP_GPIO_NUM_CONTROLLERS, which is a build option. I will delete
that code. However, if you have a document about how confdef works, it
would be helpful for me and I may be able to make that
CONFIGURE_GPIO_MAXIMUM_CONTROLLERS work.
> > +
> > +#ifndef BSP_GPIO_NUM_CONTROLLERS
> > +#define CONFIGURE_GPIO_MAXIMUM_CONTROLLERS 1
> > +#else
> > +#define CONFIGURE_GPIO_MAXIMUM_CONTROLLERS
> > BSP_GPIO_NUM_CONTROLLERS
> > +#endif /* BSP_GPIO_NUM_CONTROLLERS */
> > +
> > +#endif /* CONFIGURE_GPIO_MAXIMUM_CONTROLLERS */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif /* __cplusplus */
> > +
> > +/**
> > + * @brief Macro to initialize rtems_gpio.
> > + *
> > + * @param gpioh pointer to GPIO handlers
> > + */
> > +#define RTEMS_GPIO_BUILD_BASE(_gpio_handlers) \
> > + (rtems_gpio) { .virtual_pin = 0, \
> > + .gpio_handlers = ( _gpio_handlers ), \
> > + .api = NULL \
> > + };
> > +
> > +/**
> > + * @name GPIO data structures
> > + *
> > + * @{
> > + */
> > +
> > +/**
> > + * @brief GPIO bit set and reset enumeration.
> >
