Rewrite

[NathanielDelgado]

What it can do:

• Compile HAL and FreeRTOS for different stm32 targets
• Clang-tidy
• Clang-format
• Flash
• Basic starting folder for BSP development
• OpenOCD config files
• MKDocs

TODO:

• uncomment to allow import of modules used
• Unit testing
• Coding style guide
• Update MKDocs with previous docs (abbreviations, style guide, glossary)
• Scripts: copyright updater, install

[NathanielDelgado]

@IshDeshpa

1. Lot of the imported stuff doesn't seem like it would be any use to us. Do we really need every variant of the L4 and F4 config headers in here? Do we need any of the CI and gh stuff for FreeRTOS? What do you mean every variant? What do you mean by CI and gh stuff?
2. Inclusion of a Test folder in Drivers may not be a bad idea. The idea is that Drivers has all the stuff you need to compile. Everything under BSP is treated like a "high-level project".
3. Just curious, why not call it "Tests"? Call what Tests?

[IshDeshpa]

What do you mean every variant? What do you mean by CI and gh stuff?

1. I meant the startup and include files for the different variants of the STM32F4/L4, and I meant the .git and .github metadata that came with downloading the repository rather than the release. It seems the second issue has been resolved, but the first issue is not.

It's just these files. Honestly not a huge issue, idrc if you keep them since they come with CMSIS, but the alternative perspective is we can just import the correct header file whenever we do make a port for a different variant of the L4/F4.

The idea is that Drivers has all the stuff you need to compile. Everything under BSP is treated like a "high-level project".

2. I see. That's fair.

Call what Tests?

3. Sorry, I should have elaborated. I meant renaming Drivers/Test to Drivers/Tests (plural). Just looks nicer IMO but kind of a nitpick.

[NathanielDelgado]

1. I meant the startup and include files for the different variants of the STM32F4/L4, and I meant the .git and .github metadata that came with downloading the repository rather than the release. It seems the second issue has been resolved, but the first issue is not.

I can but it also doesn't matter. I want them there as is

3. Sorry, I should have elaborated. I meant renaming Drivers/Test to Drivers/Tests (plural). Just looks nicer IMO but kind of a nitpick.

Yeah, that's chill

[NathanielDelgado]

Also, why not have a high level makefile? The flow of Controls makefile -> Embedded-Sharepoint BSP makefile -> Drivers makefile seems pretty odd to me if the intention is that the Drivers folder has everything we need for compilation. I like the seperation of the makefiles from one huge ass makefile, but I'd like to have a higer level makefile that does most of what the BSP makefile does (or we just remove the BSP makefile altogether) and then we keep the Drivers makefile.

You don't need BSP to compile. Drivers will have another folder called BSP/bsp or something and that will have the bsp stuff. BSP folder is simply there to act as a higher level project to compile for (which has the configs and test files, maybe extra stuff, idk).

So the flow is high-level project -> Drivers

What's the plan for Driver tests like SD-Card? I propose a Tests/ folder in the top level directory and we just throw all tests into there as opposed to multiple tests folder.

I want it in another folder within Drivers called common-app or something

[Lakshay983]

Also, why not have a high level makefile? The flow of Controls makefile -> Embedded-Sharepoint BSP makefile -> Drivers makefile seems pretty odd to me if the intention is that the Drivers folder has everything we need for compilation. I like the seperation of the makefiles from one huge ass makefile, but I'd like to have a higer level makefile that does most of what the BSP makefile does (or we just remove the BSP makefile altogether) and then we keep the Drivers makefile.

You don't need BSP to compile. Drivers will have another folder called BSP/bsp or something and that will have the bsp stuff. BSP folder is simply there to act as a higher level project to compile for (which has the configs and test files, maybe extra stuff, idk).

So the flow is high-level project -> Drivers

What's the plan for Driver tests like SD-Card? I propose a Tests/ folder in the top level directory and we just throw all tests into there as opposed to multiple tests folder.

I want it in another folder within Drivers called common-app or something

If we do a seperate tests folder within Drivers we're going to need to change the Drivers makefile for standalone testing. Instead can we move the BSP makefile to the top directory that way we can compile both BSP and common-app tests

[IshDeshpa]

Why is there a need to keep "everything necessary to build" under drivers? isn't that just the entire embedded-sharepoint?

[Lakshay983]

Why is there a need to keep "everything necessary to build" under drivers? isn't that just the entire embedded-sharepoint?

I agree with this, putting the FreeRTOS Kernel seems very odd to put under drivers. I think the nomenclature we've been using where we refer to device drivers as drivers is good. Ie the Drivers folder we keep as just shared device drivers like SD-Card

[NathanielDelgado]

@IshDeshpa @Lakshay983

I put everything under Driver's because I wanted to have a single folder which had all the source material to compile. But I think at this point there isn't much other folders (only BSP and maybe some script folder or something). So how about I delete Drivers folder and put everything that was in it at the root level?

[IshDeshpa]

So would the headers for BSP go in BSP/Src? Or in common?

[Lakshay983]

@IshDeshpa @Lakshay983

I put everything under Driver's because I wanted to have a single folder which had all the source material to compile. But I think at this point there isn't much other folders (only BSP and maybe some script folder or something). So how about I delete Drivers folder and put everything that was in it at the root level?

Can you keep drivers folder so we can put device drivers in there?

[IshDeshpa]

@Lakshay983 I believe the Drivers folder still exists if you look at the file tree. I'm fine with just keeping device drivers under Drivers/common.