Preliminary selection of micro-controllers for the hardware

[frroossst]

Micro-controllers

Micro-controller	Price	Stock	Core	Max Clock (MHz)	Program Memory Size (MB)	Number of IOs	CAN	I2C	SPI	UART	USART	USB
STM32F405RGT6	20.04	0	M4	168	1	51	1	1	1	1	1	1
STM32F407IGT6	25.71	0	M4	168	1	140	1	1	1	1	1	1
STM32F412VGT6	20.2	2143	M4	100	1	81	0	0	0	0	0	0
STM32F413VGT6	19.53	941	M4	100	1	81	1	1	1	1	1	1
STM32G0B1VET6	13.85	1064	M0+	64	0.5	94	1	1	1	1	1	0
STM32G0C1RET6	12.16	604	M0+	64	0.5	60	1	1	1	1	1	1
STM32L4R9VGT6	25.6	879	M4	120	1	77	1	1	1	1	1	1
STM32F412RGT6	19.17	1910	M4	100	1	50	1	1	1	1	1	1
STM32L476RET6	18.02	18349	M4	80	0.5	51	1	1	1	1	1	1
STM32L462RET6	16.28	3830	M4	80	0.5	52	1	1	1	1	1	1
STM32L451RET6TR	15.17	6980	M4	80	0.5	52	1	1	1	1	1	1

Footer

1 means, it supports that, 0 means it doesn't rather than the actual quantity

[frroossst]

@dhaussecker need your attention!

[dhaussecker]

Consider Platform-IO capability, and list what supplier you are getting information on the stock. Option 1 STM32F405RGT6 looks the best to me based on this at the moment (but the supply chain crisis might be difficult to navigate, there is stock from other suppliers but IDK where you got your stock information from), also considering availability from JLCPCB parts for potential of quick board manufacturing

STM32F405RGT6 | 20.04 | 0 | M4 | 168 | 1 | 51 | 1 | 1 | 1 | 1 | 1 | 1 | PIO | JLC $7.98 (1075 stock) STM32F407IGT6 | 25.71 | 0 | M4 | 168 | 1 | 140 | 1 | 1 | 1 | 1 | 1 | 1 | PIO JLC $48.2687 (581 stock) STM32F412VGT6 | 20.2 | 2143 | M4 | 100 | 1 | 81 | 0 | 0 | 0 | 0 | 0 | 0 | STM32F413VGT6 | 19.53 | 941 | M4 | 100 | 1 | 81 | 1 | 1 | 1 | 1 | 1 | 1 | STM32G0B1VET6 | 13.85 | 1064 | M0+ | 64 | 0.5 | 94 | 1 | 1 | 1 | 1 | 1 | 0 | STM32G0C1RET6 | 12.16 | 604 | M0+ | 64 | 0.5 | 60 | 1 | 1 | 1 | 1 | 1 | 1 STM32L4R9VGT6 | 25.6 | 879 | M4 | 120 | 1 | 77 | 1 | 1 | 1 | 1 | 1 | 1 STM32F412RGT6 | 19.17 | 1910 | M4 | 100 | 1 | 50 | 1 | 1 | 1 | 1 | 1 | 1 | PIO JLC 13.8318 (86 stock) STM32L476RET6 | 18.02 | 18349 | M4 | 80 | 0.5 | 51 | 1 | 1 | 1 | 1 | 1 | 1 STM32L462RET6 | 16.28 | 3830 | M4 | 80 | 0.5 | 52 | 1 | 1 | 1 | 1 | 1 | 1 STM32L451RET6TR | 15.17 | 6980 | M4 | 80 | 0.5 | 52 | 1 | 1 | 1 | 1 | 1 | 1

[frroossst]

Stock information is from mouser.ca and digikey.ca. (mostly mouser)

Also, not to be THAT guy, but PlatformIO compatibility just needs to be thrown down the drain, at least from my perspective (writing firmware) I won't be able to use pio, I have to use the STM_IDE. Most of these are however compatible with pio. But we wouldn't know until we try it out. In essence, if the CPU and architecture are supported, so should a specific board be.

[ATGr8]

I second not worrying about PIO compatibility, STMCube IDE gives access to a lot more natively

[ATGr8]

Another thing to consider would be the package, you don't wanna get QFN or BGAs because those would be painful to solder

[frroossst]

I mainly went with a LQM package

[ATGr8]

As long as the pins aren't under the chip its fine.

For the UART and USART: are they on different pins or is the UART able to add a clock to make USART?

[dhaussecker]

Only 3 of the selected microcontrollers have platform io capability from what I can tell. It was a group decision 2 weeks ago in the avionics meeting that the people programming the software want the capability to program these microcontrollers using platform io as it takes considerably less time to program it there. PIO will still be taken into consideration

[frroossst]

Right, but the team that decided things 2 weeks ago, is not programming the firmware. Also, it is simply impractical to do it with PlatformIO

Also to answer Atharva's question.

The STM32L4Rxxx devices have three embedded universal synchronous receiver transmitters (USART1, USART2 and USART3) and two universal asynchronous receiver transmitters (UART4, UART5)

I think you just attach an external clock

[ATGr8]

Has the team tried out STM Cube IDE? I don't think taking PIO compatibility as a primary reason for making this decision is a good idea, I wouldn't sacrifice performance for PIO compatibility. However if two have same performance and once supports PIO, we should choose the one with PIO compatibility

[frroossst]

PIO is 100% better than Arduino, and I hate, HATE, H A T E using proprietary IDEs, but the STM IDE is just far superior for the STM platform. We should choose a micro-controller and then figure our pio, cause regardless it will still work with STM IDE

Edit: I'm the guy that introduced PIO to the team, I AM SAYING WE SHOULD USE THE STM IDE!

[frroossst]

On the topic of the micro-controller, I am leaning towards this one

Although I would like one with multiple CAN transceivers

[ATGr8]

@dhaussecker @frroossst I think it would be a fair sacrifice as considering PIO compatibility as a secondary reason to choose the MCU.

Afterall no one on the team is writing the firmware because there is no STM firmware to write. PIO compatibility would be a nice to have and would lower the barrier to entry.

[ATGr8]

On the topic of the micro-controller, I am leaning towards this

(https://www.mouser.ca/ProductDetail/STMicroelectronics/STM32L4R9VGT6?qs=wd5RIQLrsJi9fM%2FlO6Dzzw%3D%3D)

Although I would like one with multiple CAN transceivers

It looks like 25 bucks a pop, don't think that's very economical

[dhaussecker]

I don't think that one is the best decision at all for multiple reasons: a) not PIO compatible b) expensive c) not on JLC PCB

[frroossst]

I also love this one but, it's on order.

[dhaussecker]

PIO capability will be a main priority as it reduces the gap of knowledge needed for members to begin programming. Also, makes things way simpler to program. I don't know if either of you have tried programming an STM32 with PIO but I have, it is simple cause you can just import the Arduino library and utilize all extensive libraries that are in that ecosystem. STM32 Cube IDE programming is a secondary objective IMO

[ATGr8]

Have you tried programming in the STM32 Cube IDE? To write low level firmware?

[ATGr8]

Things like assigning pin functions, setting registers is very easy in the Cube IDE cause its all natively built for a particular chip. Doing the same thing on PIO wont work as well and will be difficult. Plus why are we importing Arduino libraries here to write the drivers/firmware?

[dhaussecker]

But we don't need to be writing low level firmware for this in the first place?! Make things as simple as they can be

[ATGr8]

Yes we do. Our boards require us to write low level firmware. Our boards will be bare metal.

[frroossst]

ummm.....

[dhaussecker]

They do not have to be bare metal, we will be wasting time writing software when we could be doing other things if we had all the libraries that are provided with PlatformIO-compatible STM32s through the Arduino ecosystem. We will have a lot of tasks to do this year and teaching new first years how to program low level firmware in STM32 IDE is not feasible IMO, especially when we struggled getting everyone to code in PlatformIO at times during this year. For more experienced programmers, sure! Why not try out programming these in STM32 CubeIDE? It gives you a lot more experience writing low level firmware. But we also need to keep the option for new students who don't know anything about programming, to reduce the learning gap and to keep things as simple as possible.

[frroossst]

a. If we're not doing bare metal, what are we doing? b. We will be using the STM32 IDE regardless, as it provided a HAL, pinout and much more. so it's useful for design purposes c. The first years will not write firmware, by firmware we mean, can bus drivers and stuff. You do not want to mess with dependencies when doing embedded stuff, or heck even C/C++ stuff as they have no good dependency managers d. We cannot use the two platforms (no pun intended) interchangeably because they operate on different linker scripts e. If we wanna reduce the learning gap, that the whole stm32 thing might be a bad idea, as they are fundamentally more advanced when compared to something like a Teensy or an Arduino-alternative

[ATGr8]

I see your point here, but STM 32 Cube is not a steep learning curve and you don't have to write low level firmware in STM32Cube, it could be as high level as PIO. STM32Cube has more libraries supporting STM32 than PIO, it has the abilities to detect hardware faults. I'm not against using PIO, but I don't think its justified to use its compatibility as one of the main deciding factors. Members can also just use VSCode and only click build on Cube IDE if needed, we could also figure out a way to integrate those two.

[frroossst]

Not to mention, with STM32 you can have hardware breakpoints for days!

[dhaussecker]

The team as a whole decided that platformIO is the best way to go for now, without formal agreement that STM32 CubeIDE is best in the future I need the majority of the people who will be doing software to agree. In order to determine the feasibility of platformio over stm32 or vice versa we need to do some more programming in both first and make a convincing argument that one is better and convince the majority to accept the argument. Until then I am putting a restriction that the microcontroller needs to be able to be programmed using PlatformIO. @frroossst had the same concern when I wanted to switch to STM32CubeIDE previously and I followed that suggestion as that is what the team decided. So convince the entire team first who will ultimately end up programming this as well, if you do, I'm good with it. In the meantime, it shouldn't be that difficult to select one that meets all your requirements, the STM32F405RGT6 is $7.98 and is available from LCSC electronics

[frroossst]

Technically, majority of the people who do software is me. I have more commits on MiniRocket repo than everyone combined (including an effin' linting bot), and since they are commits, Dylan can't make an argument that I just copy pasted the entire code base, cause that's not how commits work. So, I agree we should use STM, therefore, your entire software team is in agreement.

No offense ofc.

[frroossst]

Also, we don't need to get the whole team's approval on everything. Direct democracy is a very bad thing for an engineering project, We need someone to make decisions that might be unpopular, I am not saying disregard the team, cause I am part of the team lol, but this RFC is a way of getting the team's feedback. If you keep this open for a week or two and no team members are active on here, and then by de facto they have lost the privilege to have their say. So, keep this open for 2 week(s) or so, but, if there are no oppositions here then the decision is made.

It is impractical to expect anyone to get the team actively involved in the RFC process, the process is open and transparent

[dhaussecker]

Dylan, Atharva, and Adhyan decided STM32F405RGT6 was the final decision, unless anyone else objects, please reply if you have any other opinons/concerns

[frroossst]

We should get this dev board, so that we are developing for the same platform as the final micro-controller that the code will run on