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 + 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 Hello Karel, thanks for the clarification. I have to be honest: I missed the license change. That is a bit of a difficult one and will cause a discussion. @Duc: We need a new LICENSE file in the top level that represents that. Maybe split the CMSIS update into a separate patch so that it is clear why there is a new license file (if the license is only for the CMSIS and not for the STM HAL too). Do you mean I need to add a LICENSE.Apache-2.0 file in rtems source root? I found this file being shipped with STM HAL: https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/LICENSE.txt Should I copy this file and rename it to LICENSE.Apache-2.0? Short answer: Yes. A bit longer answer: Please make sure that it's really an unchanged Apache license before you copy it. I assume it is but just to be sure, I would use a diff with the one from opensource.org: https://opensource.org/licenses/Apache-2.0 Best regards Christian Best, Duc But my main concern was another one: Which BSPs use the CMSIS files? Beneath the stm32 variants, that's at least the atsam and imxrt. Maybe I missed some more. We should at least make sure that these BSPs are compile-clean with the updated cmsis headers. Best regards Christian ___ 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 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 + > > > > 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 > > > > Hello Karel, > > thanks for the clarification. I have to be honest: I missed the > license > change. That is a bit of a difficult one and will cause a discussion. > @Duc: We need a new LICENSE file in the top level that represents > that. Maybe split the CMSIS update into a separate patch so that it > is > clear why there is a new license file (if the license is only for the > CMSIS and not for the STM HAL too). > Do you mean I need to add a LICENSE.Apache-2.0 file in rtems source root? I found this file being shipped with STM HAL: https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/LICENSE.txt Should I copy this file and rename it to LICENSE.Apache-2.0? Best, Duc > But my main concern was another one: Which BSPs use the CMSIS files? > Beneath the stm32 variants, that's at least the atsam and imxrt. > Maybe I > missed some more. We should at least make sure that these BSPs are > compile-clean with the updated cmsis headers. > > Best regards > > Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Duc, Am 02.08.22 um 05:00 schrieb Duc Doan: Hello Christian, On Mon, 2022-08-01 at 20:32 +0200, o...@c-mauderer.de wrote: 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 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. Hm. Odd. In that case: Why does the diff show a complete removal and complete adding of (for example) cmsis_gcc.h: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16#diff-9632086ec773f52fc69a99f2d7fad711c51aad138e6449e01b4737f80201d185 I'm not sure why that happens. I used this page to compare line-by- line: https://www.diffchecker.com/xMCBtxbt This is the diff for cmsis_gcc. That page most likely ignores line endings. Try it with `file` or `dos2unix -i`: sh> git co master [...] sh> file bsps/arm/include/cmsis_gcc.h bsps/arm/include/cmsis_gcc.h: C source, ASCII text, with CRLF, LF line terminators sh> dos2unix -i bsps/arm/include/cmsis_gcc.h 1374 1 0 no_bomtextbsps/arm/include/cmsis_gcc.h sh> git co duc/master [...] sh> file bsps/arm/include/cmsis_gcc.h bsps/arm/include/cmsis_gcc.h: C source, ASCII text sh> dos2unix -i bsps/arm/include/cmsis_gcc.h 02085 0 no_bomtextbsps/arm/include/cmsis_gcc.h sh> The three numbers of dos2unix output is (in this order): Number of DOS line endings, number of UNIX line endings, number of MAC line endings. So line endings changed from CRLF to only LF. Either make that two steps (first changing the old one to LF in one commit and then updating it in another) or change the new file to use the CRLF format of the old one. Best regards Christian Best, Duc 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
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
Hello Christian, On Tue, 2022-08-02 at 07:26 +0200, Christian MAUDERER wrote: > That page most likely ignores line endings. Try it with `file` or > `dos2unix -i`: > > > sh> git co master > [...] > sh> file bsps/arm/include/cmsis_gcc.h > bsps/arm/include/cmsis_gcc.h: C source, ASCII text, with CRLF, LF > line > terminators > sh> dos2unix -i bsps/arm/include/cmsis_gcc.h > 1374 1 0 no_bom text > bsps/arm/include/cmsis_gcc.h > sh> git co duc/master > [...] > sh> file bsps/arm/include/cmsis_gcc.h > bsps/arm/include/cmsis_gcc.h: C source, ASCII text > sh> dos2unix -i bsps/arm/include/cmsis_gcc.h > 0 2085 0 no_bom text > bsps/arm/include/cmsis_gcc.h > sh> > > > The three numbers of dos2unix output is (in this order): Number of > DOS > line endings, number of UNIX line endings, number of MAC line > endings. > > So line endings changed from CRLF to only LF. Either make that two > steps > (first changing the old one to LF in one commit and then updating it > in > another) or change the new file to use the CRLF format of the old > one. > > Best regards > > Christian > > Thank you, this knowledge is new to me. I will change them to LF. Best, Duc ___ 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 Mon, 2022-08-01 at 20:32 +0200, o...@c-mauderer.de wrote: > 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 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. > > > > Hm. Odd. In that case: Why does the diff show a complete removal and > complete adding of (for example) cmsis_gcc.h: > > https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16#diff-9632086ec773f52fc69a99f2d7fad711c51aad138e6449e01b4737f80201d185 > > I'm not sure why that happens. I used this page to compare line-by- line: https://www.diffchecker.com/xMCBtxbt This is the diff for cmsis_gcc. Best, Duc > > > > > > > > > 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 > >
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 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. Hm. Odd. In that case: Why does the diff show a complete removal and complete adding of (for example) cmsis_gcc.h: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/6f1fbc7dd7a5e0877d8bff11e1b21558928dbc16#diff-9632086ec773f52fc69a99f2d7fad711c51aad138e6449e01b4737f80201d185 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. Great. Thanks for checking. Best regards Christian 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/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 ++
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 ++ > > > >
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 +
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 + > >
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 | 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 Hello Karel, thanks for the clarification. I have to be honest: I missed the license change. That is a bit of a difficult one and will cause a discussion. @Duc: We need a new LICENSE file in the top level that represents that. Maybe split the CMSIS update into a separate patch so that it is clear why there is a new license file (if the license is only for the CMSIS and not for the STM HAL too). But my main concern was another one: Which BSPs use the CMSIS files? Beneath the stm32 variants, that's at least the atsam and imxrt. Maybe I missed some more. We should at least make sure that these BSPs are compile-clean with the updated cmsis headers. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 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. 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. 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? .../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/stm32f4xx_hal_hash.c | 3514 +++ bsps/arm/stm32f4/hal/stm32f4xx_hal_hash_ex.c | 1040 + bsps/arm/stm32f4/hal/stm32f4xx_hal_hcd.c | 1728 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c.c | 7524 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c_ex.c | 182 + bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s.c | 2094 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s_ex.c | 1135 + bsps/arm/stm32f4/hal/stm32f4xx_hal_irda.c | 2687 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_iwdg.c | 262 + bsps/arm/stm32f4/hal/stm32f4xx_hal_lptim.c| 2484 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc.c | 2215 ++ bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc_ex.c | 151 + bsps/arm/stm32f4/hal/stm32f4xx_hal_mmc.c | 3201 +++ .../stm32f4/hal/stm32f4xx_hal_msp_template.c | 100 + bsps/arm/stm32f4/hal/stm32f4xx_hal_nand.c |
