microntroller selection for defence application

[VPath.1]

I want to build product for defense application. Are there any microcontroller with display capable which is millenary grade certified and has DSP capabilities as well. need 2 SPI and 1 I2C ethernet and serial interface has minimum of 4 MB flash and 512 Kb of RAM. arm controller preffered 

[TDK]

> millenary grade certified

Be more specific. STM32s aren't automotive certified, so unlikely they will meet anything more stringent.

> minimum of 4 MB flash and 512 Kb of RAM

No STM32 MCU has more than 2MB of FLASH. Lots of them meet your other requirements.

The MCU Selector in CubeMX can help guide your decision.

[Tesla DeLorean]

Most of these parts are for general consumer use, and specifically not for military or medical (life/death) applications.

Perhaps start with the hiring choices, and an awareness of what's usable and who the manufacturers are for these types/classes of products.

http://vita.mil-embedded.com/articles/is-arm-the-future-for-airborne-platforms-in-military-and-aerospace-2/

[Pavel A.]

Hope I'm not giving out a horrible secret, but where I live, STM32H743/753 are used in military products. At least for less critical modules, not "hard realtime". Of course these STM32s are helped by external watchdogs, power stabilizers, FPGAs, redundancy and so on.

A lot of STM32s are used in drones everywhere.

[Piranha]

Using consumer hardware in non-critical military devices is one thing, but can you comment on software? I guess they don't use Cube/HAL/LL junk... Or do they?

[Pavel A.]

@Piranha​ For board bring-up and tests they use Cube and HAL, like <pick your favorite curse>. The rest is classified 🙂

[Piranha]

Thanks. Well... If the developer has a decent libraries and are using those for some task, he will not go back to some junk for other task. Just look at such a simple peripheral as UART. If one has a decent driver and is used to use it with few lines of code, then going back to HAL and writing mountains of workaround code requires one to mentally damage the mind.

I guess I should put a sticker on my projects: "More robust than some military grade devices!" :D

[Pavel A.]

Here I respectfully disagree. Linux gives one a lot of framework and standard APIs for many device classes. There you have to just push new/custom devices into this framework and call it done.

Not so with small microcontrollers. There are very few low level libraries for UARTs , USB, Ethernet, as we all see here. Common portable libraries begin a bit above that.

The ST libraries (HAL, LL or whatever) provide at least some common ground for quick evaluation and experimenting with their stuff.

The Cube GUI lets me start the MCU pinout work with h/w people and make few bring-up tests.

When we request support from ST or other contractors, we reproduce problems with HAL based code, again to have a common ground (and because we cannot give them our proprietary stuff).

You say how good is your code (and I believe fully) - but you don't show it. OK. Understandable. ST code is visible for everybody, thus it has no-nonsense value.

[Piranha]

Selecting the pins in CubeMX, when designing the board, is OK, but generating a broken code...

const xpin_ts BSP_GPIO_asMain[] = {
	// GPO
	{BSP_LED_SYSTEM , XPIN_LOCK | 1, XPIN_MODE_OUTPUT | XPIN_OTYPE_PP | XPIN_OSPEED_LOW | XPIN_PUPD_NONE},
	{BSP_LED_NETWORK, XPIN_LOCK | 0, XPIN_MODE_OUTPUT | XPIN_OTYPE_PP | XPIN_OSPEED_LOW | XPIN_PUPD_NONE},
	{BSP_LED_SYNC   , XPIN_LOCK | 0, XPIN_MODE_OUTPUT | XPIN_OTYPE_PP | XPIN_OSPEED_LOW | XPIN_PUPD_NONE},
 
	// GPI
	{BSP_BTN_RESET, XPIN_LOCK, XPIN_MODE_INPUT | XPIN_PUPD_NONE},
 
	// ETH
	{XPIN(A, 1), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_MEDIUM | XPIN_PUPD_NONE}, // RMII_REF_CLK
	{XPIN(A, 7), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_MEDIUM | XPIN_PUPD_NONE}, // RMII_CRS_DV
	{XPIN(C, 4), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_MEDIUM | XPIN_PUPD_NONE}, // RMII_RXD0
	{XPIN(C, 5), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_MEDIUM | XPIN_PUPD_NONE}, // RMII_RXD1
	{XPIN(G,11), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_MEDIUM | XPIN_PUPD_NONE}, // RMII_TX_EN
	{XPIN(G,13), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_MEDIUM | XPIN_PUPD_NONE}, // RMII_TXD0
	{XPIN(B,13), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_MEDIUM | XPIN_PUPD_NONE}, // RMII_TXD1
	{XPIN(C, 1), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_LOW | XPIN_PUPD_NONE}, // RMII_MDC
	{XPIN(A, 2), XPIN_LOCK | 11, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_LOW | XPIN_PUPD_NONE}, // RMII_MDIO
 
	// USART
	{XPIN(D, 9), XPIN_LOCK |  7, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_LOW | XPIN_PUPD_UP}, // STLK_TX (USART3_RX)
	{XPIN(D, 8), XPIN_LOCK |  7, XPIN_MODE_AF | XPIN_OTYPE_PP | XPIN_OSPEED_LOW | XPIN_PUPD_NONE}, // STLK_RX (USART3_TX)
 
	// I2C
	{XPIN(B, 8), XPIN_LOCK |  4, XPIN_MODE_AF | XPIN_OTYPE_OD | XPIN_OSPEED_LOW | XPIN_PUPD_UP}, // I2C_A_SCL
	{XPIN(B, 9), XPIN_LOCK |  4, XPIN_MODE_AF | XPIN_OTYPE_OD | XPIN_OSPEED_LOW | XPIN_PUPD_UP}, // I2C_A_SDA
};

This one is for a NUCLEO-144 boards. One line per pin! Writing such a pin configuration array doesn't take more than an hour for a new board. Of course, with HAL it is not possible and one has to write or generate hundreds of bloated code lines. Also I can split the pins to multiple such arrays and reconfigure those groups of pins easily at runtime. With CubeMX it's normally impossible, because, in order to enable the peripherals, you have to have all of their pins configured and they will be initialized.

What can you actually quickly evaluate with that code? Transmit "Hello world!" through UART, it glitches, hangs etc. and you don't even know if it's because of hardware or it's just the broken bloatware again... And a reception, which ST presents as a "solution" to their "flawed by design" API. That code has 50 lines, which are an application code, which you supposedly can implement quickly. In comparison similar code with my driver library looks like I've shown in this topic. Effectively 6 lines! So which one is easier and quicker to use?

And you already do know how you can quickly test Ethernet with Cube/HAL... Is waiting for 15 years and counting considered quick? 😉

A support from ST. They have a decent hardware engineers, but for software it's a waste of time, which you can spend better on writing actually useful code.