I don't like the term standard hardware. Maybe because I create tailored hardware for a living.
I love Nuttx for the flexibility. Please do not limit choice of hardware. -- Hard- and Softwaredevelopment Consultant Geschäftsführung: Simon Filgis USt-IdNr.: DE305343278 ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications> Nathan Hartman <hartman.nat...@gmail.com> schrieb am Di., 10. Juni 2025, 21:07: > Hi all, > > I have a few suggestions:: > > 1. I suggest to request INFRA to create a new repository for the design and > implementation of hardware, which initially will contain the NuttX Standard > Board hardware. I suggest the name nuttx-hardware. > > 2. Within the nuttx-hardware repository, I suggest to have a subdirectory > for the main board, and subdirectories for each MCU board that can plug in. > In the future, we might add other boards within the same repository. > > 3. I strongly recommend to use a free/open source electronics design > package. (The only one I am familiar with is KiCad [1].) By using free/open > source software, anyone will be able to participate without having to pay > expensive licensing costs for a commercial electronics design software. > > Thanks to everyone for your efforts! > > Nathan > > On Tue, Jun 10, 2025 at 1:51 PM Alan C. Assis <acas...@gmail.com> wrote: > > > Hi Tomek, > > > > Thank you for those nice suggestions. > > > > 1) Yes, even some companies like Freescale (now NXP) used that idea in > the > > past, i.e. DEMOQE board: > > https://www.nxp.com/docs/en/user-guide/DEMOQE128UM.pdf > > The MCU module boards need to have a minimum size to fit the connector > and > > also we need to think that some MCUs have a "big" package like LQFP176 > for > > example. > > In this case we are going to use 2 100-pin connectors, the same used on > > Raspberry Pi CM4. This connector is low cost and has many pins. > > > > 2) Yes, this is something we should have in the board to support sensors, > > modem, etc. mikroBUS and Pmod will be used, but we can think about using > > others as well. > > > > 3) The baseboard will have a USB/Serial interface to connect in the > > computer, at the moment we didn't know about include a programmer on it > to > > avoid increasing boards, the idea is just using JTAG/SWD/ISP connectors. > > Remember that this baseboard will be used not only for ARM, but also > > RISC-V, AVR, etc. > > > > 4) The connector will be unique for all MCU modules, but we will have two > > connectors: the first one is Required and will have all signals common > > between almost all MCUs (UART, SPI, I2C, GPIO, etc), the second will be > > Optional and will include signal present on more "advanced" MCUs: > Ethernet, > > Parallel LCD, USB, I2S Audio, etc. > > > > I moved the project to: https://github.com/NuttX/nuttx_board_std but I > > don't know if all people will see it or only those that are part of the > > organization. > > > > BR, > > > > Alan > > > > On Tue, Jun 10, 2025 at 12:26 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > > Aaah! NuttX BaseBoard is more self-exlpanatory thanks Alan! :-) > > > > > > I played like this in the 1990's with 8051 but instead having one > > > single board I created separate modules that were attached with 2.54 > > > wires and f/m-connectors this allowed me to reuse different modules > > > with different boards and applications. This is now called Arduino > > > served with modules on breadboards :-P > > > > > > I have many MCU boards on a wall of medium size breadboards (SYB-118) > > > connected over 16 port USB HUBs, some observations below that may give > > > some hints on the BaseBoard: > > > > > > 1. Some boards are bigger and takes unnecessary space for just MCU > > > testing, so tiny MCU boards are the best (like XIAO series). Several > > > small MCU boards can fit on a single breadboard, while big boards > > > (i.e. STM) needs to use two breadboards. Small increase in size of a > > > breadboard is big increase in price, so I bought 100x SYB-118 as the > > > compromise between size and price (these also have mounting holes). > > > > > > 2. We may want to have slots for different peripherals (i.e. several > > > stdandars I2C slots for sensor boards). Peripherals switching is > > > problematic and in perfect situation with my current environment I > > > would like to be able remotely re-route MCU board to a specific > > > peripheral that would allow testing. I know this is extremely > > > problematic but I do not know any solution like this, except using > > > digital mux, opto-isolators, or relays. Voltage levels are also > > > problem (i.e. 5V vs 3.3V vs 1.8V). But using isolators may be a kind > > > of "adrressing" solution too (i.e. #EN pin).. except those isolators > > > are expensive. > > > > > > 3. Debug probes are best when these provide JTAG/SWD and UART over > > > single USB connection. I found STLINK-V3MODS > > > (https://www.st.com/en/development-tools/stlink-v3mods.html) to be > > > most versatile (it provides JTAG/SWD and UART but also additional > > > interfaces like SPI/I2C/UART/CAN) cost ~$10 and is meant to be mounted > > > as module on a target board (pin raster is 2.0mm not 2.54mm > > > unfortunately). But its commercial and closed-source. > > > > > > 4. Pinouts and Adapters seems necessary as different MCUs will differ > > > in size and pinouts to be attached to a single baseboard. Here I found > > > different boards use male pins on top of the board, some use male pins > > > on the bottom of the boards, some use female connectors, either 2.54mm > > > or 2.0mm or even smaller raster. From my experience what is rapidly > > > changing / easy to replace (i.e. cables, small boards) should use male > > > pins, while rarely changes parts (modules, boards) should use female > > > connectors. Female connectors usually go up, male goes down. Best > > > raster is 2.54mm as most popular cheap and easy to handle. Its very > > > nice when each pin have two holes for additional up/down conenctor > > > (i.e. you want to attach arduino shield from top to female connector > > > below, but also want to solder additional pins to then stick the board > > > to breadboard below). I know this seems trivial but when you have > > > different boards to physically manage sometimes its a problem :-) > > > > > > Have a good day :-) > > > Tomek > > > > > > On Tue, Jun 10, 2025 at 4:02 PM Alan C. Assis <acas...@gmail.com> > wrote: > > > > > > > > Hi Tomek, > > > > > > > > The idea is to have a baseboard that could be used with different MCU > > > > modules, similar to Mikroe Fusion ARM: > > > > https://www.mikroe.com/fusion-for-arm > > > > > > > > But in our case the MCU modules are not limited only to ARM. We could > > use > > > > any MCU currently supported by NuttX, because the common signals > (UART, > > > > SPI, I2C, etc) are exposed at the same position on that connector > that > > is > > > > plugged in the baseboard. > > > > > > > > This way, instead of having a different process to test each board we > > > will > > > > test the baseboard in the same way, no matter what is the MCU module > > > used. > > > > > > > > BR, > > > > > > > > Alan > > > > > > > > On Mon, Jun 9, 2025 at 6:22 PM Tomek CEDRO <to...@cedro.info> wrote: > > > > > > > > > Thanks Alan :-) > > > > > > > > > > It would be nice to have a template for new boards along with > > > > > documentation, and maybe update existing boards when some standard > is > > > > > ready :-) > > > > > > > > > > https://github.com/acassis/nuttx_board_std - I get 404 here o_O > > > > > > > > > > I have question here, when looking at STM32 mcus/boards these seem > to > > > > > have lots of separate implementations, that are a bit inconsistent, > > > > > and usually confusing to newcomers (and to me too). Some > mcus/boards > > > > > have support for peripherals that are present in other similar MCUs > > > > > but not other mcus/boards, that ends up some mcus boards have > > paertial > > > > > support for some different peripherals or even the same peripherals > > > > > but in a different way. I know that code duplication is by design > not > > > > > to crash many things at once, but maybe there is a way to re-use > some > > > > > code among mcus/boards and so improve coherence? :-) > > > > > > > > > > Thanks :-) > > > > > Tomek > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 9, 2025 at 10:43 PM Alan C. Assis <acas...@gmail.com> > > > wrote: > > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > To implement the item 11 of the actions to improve NuttX: > > > > > > https://github.com/apache/nuttx/issues/16278 I requested ChatGPT > > to > > > list > > > > > > the most common signals/interfaces existent on NuttX: > > > > > > https://chatgpt.com/share/6841d483-5400-8012-ada6-b962d215f410 > > > > > > > > > > > > So I created a project to Document and later implement this > board: > > > > > > > > > > > > https://github.com/acassis/nuttx_board_std > > > > > > > > > > > > But before carrying on with the implementation I think it is > > > important to > > > > > > discuss with everybody here which features (peripherals) we need > to > > > have > > > > > on > > > > > > the baseboard. The MCU module is supposed to have only the MCU, > > > > > capacitors, > > > > > > crystal(s) and the connector to plug in the baseboard. > > > > > > > > > > > > I created a channel on Discord called #nuttx_standard_board to > > avoid > > > > > > polluting this mailing list. > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > Alan > > > > > > > > > > > > > > > > > > > > -- > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > > > > > > > > -- > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > >
