EEPROJ Selecting Common MCUs for Our Projects - Revision history

21stCP Wiki BDFL at 06:02, 31 January 2022

2022-01-31T06:02:55Z

← Older revision		Revision as of 02:02, 31 January 2022
Line 10:		Line 10:

	Due to who currently offers M7 MCUs, we chose to settle on just Microchip Technology and STMicroelectronics offerings, with NXP penciled in as a stand-by for reserve.		Due to who currently offers M7 MCUs, we chose to settle on just Microchip Technology and STMicroelectronics offerings, with NXP penciled in as a stand-by for reserve.

			After some ICs are picked, we then choose to only work with ICs with more than 100 pins, instead of picking the minimum package size for each project. We will also, even if not using connectivity options like Ethernet, will still pre-allocate pins for such features on a permanent basis, Just In Case. Otherwise, it will take far too much repeating the large amount of effort it takes to decide on IC pin allocation (as we are known to need "every interface type offered by the IC" for our projects).

21stCP Wiki BDFL at 05:57, 31 January 2022

2022-01-31T05:57:54Z

← Older revision		Revision as of 01:57, 31 January 2022
Line 1:		Line 1:
	While we have plenty of experience with some "historic" MCU architectures and families (from hardcore PIC programmed in Assembly to outdated Parallax MCUs interpreting BASIC to fashionable but wasteful and childish Arduino, and many other ones in between), we have decided to ~~standardtize~~ on the ARM Cortex architecture running old-fashion compiled embedded C language.		While we have plenty of experience with some "historic" MCU architectures and families (from hardcore PIC programmed in Assembly to outdated Parallax MCUs interpreting BASIC to fashionable but wasteful and childish Arduino, and many other ones in between), we have decided to standardize on the ARM Cortex architecture running old-fashion compiled embedded C language.

	We believe that ARM MCU architecture is the future. Side note: we believe claims that some Chinese new fashionable architecture is an "ARM killer" are all more than premature at this point. We are quite set on this choice after careful considerations and evaluations.		We believe that ARM MCU architecture is the future. Side note: we believe claims that some Chinese new fashionable architecture is an "ARM killer" are all more than premature at this point. We are quite set on this choice after careful considerations and evaluations.
Line 6:		Line 6:

	We see the craziness of everyone going for SoC cores with Application cores/processors and WiFi, Ethernet, etc cores or modules attached. As will be discussed elsewhere, we do not like wireless, WiFi, Bluetooth, IoT, Ethernet, and related craziness for emissions, safety, health, and MCU-overloading concerns. Unless there is a reason to do otherwise, none of our projects will require, contain, or even support wireless, WiFi, Bluetooth, IoT, or Ethernet.		We see the craziness of everyone going for SoC cores with Application cores/processors and WiFi, Ethernet, etc cores or modules attached. As will be discussed elsewhere, we do not like wireless, WiFi, Bluetooth, IoT, Ethernet, and related craziness for emissions, safety, health, and MCU-overloading concerns. Unless there is a reason to do otherwise, none of our projects will require, contain, or even support wireless, WiFi, Bluetooth, IoT, or Ethernet.

			Within the ARM category, we specifically choose the Cortex M4F family for lightweight projects, Cortex M7 for more advanced projects, and heterogeneous solutions using either an M4F or an M7 core in a multi-core or SoC solution.

			Due to who currently offers M7 MCUs, we chose to settle on just Microchip Technology and STMicroelectronics offerings, with NXP penciled in as a stand-by for reserve.

21stCP Wiki BDFL at 05:52, 31 January 2022

2022-01-31T05:52:59Z

← Older revision		Revision as of 01:52, 31 January 2022
Line 1:		Line 1:
	While we have plenty of experience with some "historic" MCU architectures and families (from hardcore PIC programmed in Assembly to outdated Parallax MCUs interpreting BASIC to fashionable but wasteful and childish Arduino, and many other ones in between), we		While we have plenty of experience with some "historic" MCU architectures and families (from hardcore PIC programmed in Assembly to outdated Parallax MCUs interpreting BASIC to fashionable but wasteful and childish Arduino, and many other ones in between), we have decided to standardtize on the ARM Cortex architecture running old-fashion compiled embedded C language.

			We believe that ARM MCU architecture is the future. Side note: we believe claims that some Chinese new fashionable architecture is an "ARM killer" are all more than premature at this point. We are quite set on this choice after careful considerations and evaluations.

			Specifically within ARM, we like the distinction between M (embedded), A (application), and R (real-time), although R cores will very likely be fully absorbed into M or A cores as time goes on.

			We see the craziness of everyone going for SoC cores with Application cores/processors and WiFi, Ethernet, etc cores or modules attached. As will be discussed elsewhere, we do not like wireless, WiFi, Bluetooth, IoT, Ethernet, and related craziness for emissions, safety, health, and MCU-overloading concerns. Unless there is a reason to do otherwise, none of our projects will require, contain, or even support wireless, WiFi, Bluetooth, IoT, or Ethernet.

21stCP Wiki BDFL: Created page with "While we have plenty of experience with some "historic" MCU architectures and families (from hardcore PIC programmed in Assembly to outdated Parallax MCUs interpreting BASIC to fashionable but wasteful and childish Arduino, and many other ones in between), we"

2022-01-31T05:38:43Z

Created page with "While we have plenty of experience with some "historic" MCU architectures and families (from hardcore PIC programmed in Assembly to outdated Parallax MCUs interpreting BASIC to fashionable but wasteful and childish Arduino, and many other ones in between), we"

New page

While we have plenty of experience with some "historic" MCU architectures and families (from hardcore PIC programmed in Assembly to outdated Parallax MCUs interpreting BASIC to fashionable but wasteful and childish Arduino, and many other ones in between), we