vrmay23 opened a new pull request, #18397:
URL: https://github.com/apache/nuttx/pull/18397
Add board support for the ST Nucleo-H753ZI (MB1364) development board
featuring the STM32H753ZIT6 microcontroller (Arm Cortex-M7, 2 MB Flash, 1 MB
RAM).
This port was initially based on the linum-stm32h753bi board support, with a
corrected clock tree and a substantially redesigned board architecture aimed at
improving usability, scalability, and maintainability.
Clock Tree
----------
Both HSE configurations (8 MHz ST-LINK MCO and 25 MHz external crystal)
produce identical system performance:
SYSCLK = 400 MHz (VOS1), HCLK = 200 MHz, PCLK = 100 MHz
The original linum-based clock tree was corrected to fix PLL input range
registers, VCO frequency calculations, and peripheral kernel clock assignments.
FDCAN kernel clock is 25 MHz in both configurations (PLL2Q for 8 MHz HSE; HSE
direct for 25 MHz HSE), ensuring compliance with standard CAN bitrates
(125/250/500 kbps, 1 Mbps).
Menuconfig-Driven Architecture
-------------------------------
The central design goal of this port is to make NuttX more approachable for
developers working with real hardware. The intent is to expose as many hardware
options as practical through Kconfig/menuconfig, reducing the need to manually
edit source files for routine board bring-up tasks. This is a proposed
direction that could establish a new pattern for NuttX board ports -- one that
prioritizes developer agility and user-friendliness alongside the existing
coding standards.
This is a deliberate departure from the pattern found in most existing NuttX
board ports, where pin assignments, bus selections, and peripheral options are
hardcoded. The intent is not to break convention for its own sake, but to
demonstrate that a menuconfig-driven board layer reduces friction substantially
-- particularly for developers new to NuttX or porting it to derivative
hardware.
Specifically, this port provides menuconfig control over:
- HSE clock source (8 MHz ST-LINK MCO or 25 MHz external crystal)
- SPI bus enable/disable and alternative pin set selection (SPI1-SPI6, 2-4
pin sets each); CS pins are registered per-peripheral at runtime
- I2C bus enable/disable, alternative pin set selection (I2C1-I2C4, 2-5
pin sets each), and default bus frequency per bus; conflicting pin assignments
(e.g. I2C1 pinset 1 vs I2C4 pinset 4) are prevented at compile time via Kconfig
dependency rules
- LED control mode: automatic (kernel OS state), user (/dev/userleds), or
disabled
- Button driver: number of buttons (1-32), built-in button (PC13)
inclusion, additional button GPIO pins specified as a string (e.g.
"PB1,PD0,PG4"), with compile-time EXTI conflict validation
- ST7796 SPI LCD: bus, CS/DC/RESET/LED pins, CS polarity, color depth,
orientation, rotation, SPI frequency, framebuffer size
- MFRC522 RFID: bus, CS pin, CS polarity, IRQ pin, IRQ trigger type
- SSD1306 OLED: bus, I2C address, frequency, brightness, resolution,
device path
Scope of This Port
------------------
This is not a minimal board port. Separating a clean minimal port from the
full implementation was not practical at this stage, so the complete board
support is submitted as-is -- following the same approach taken by the
linum-stm32h753bi port. While the Nucleo-H753ZI is a development board rather
than an OEM product, the port is fully functional: anyone with the hardware can
build and run NuttX on it immediately using the provided configurations.
Source Organization
-------------------
The src/ directory uses a layered subdirectory structure to separate
concerns and make the codebase easier to navigate and extend. This is a
deliberate organizational choice that differs from the flat src/ layout common
in other NuttX board ports. If the project prefers the traditional flat layout,
all files can be moved directly into src/ with no functional changes required
-- the Makefile and CMakeLists.txt are the only files that would need updating.
src/
├── stm32_boot.c
├── stm32_bringup.c
├── stm32_appinitialize.c
├── stm32_boot_image.c
├── nucleo-h753zi.h
└── drivers/
├── driver_bus/ (SPI, I2C bus initialization)
├── driver_generic/ (ADC, buttons, GPIO, PWM, LEDs)
├── driver_middleware/ (USB, ROMFS, progmem, autoleds, UID)
└── driver_modules/ (peripheral drivers: displays, sensors,
wireless, storage)
Supported Peripheral Modules
-----------------------------
- ST7796 SPI LCD 320x480 IPS with framebuffer (/dev/fb0, LVGL-ready)
- SSD1306 I2C OLED 128x64/128x32
- MFRC522 SPI RFID 13.56 MHz (/dev/rfid0)
- NRF24L01 SPI 2.4 GHz transceiver
- MMC/SD card over SPI
- LSM6DSL, LSM303AGR, LSM9DS1 IMU sensors (I2C)
- LPS22HB pressure sensor (I2C)
- PCA9635 I2C LED controller
- PWM output (TIM1, CH1-CH4 + complementary)
- PROGMEM MTD, RTC, USB OTG FS (device/host), USB MSC, ROMFS
Configurations
--------------
nsh: NuttShell, user LEDs, GPIO driver;
button_driver : up to 11-button demo (PC13 + 10 external),
IRQ-driven, auto LEDs;
socketcan: FDCAN1 as SocketCAN, 500 kbps and
candump/cansend.
Testing
-------
The following drivers were validated on real hardware (Nucleo-H753ZI):
- buttons (IRQ-driven, 11-button configuration)
- leds (user and automatic modes)
- gpio (/dev/gpioN)
- mfrc522 (SPI RFID, /dev/rfid0)
- socketcan (FDCAN1, 500 kbps, candump/cansend)
- st7796 (SPI LCD, framebuffer, LVGL)
- ssd1306 (I2C OLED)
The ST7796 framebuffer driver (boards/.../stm32_st7796.c) and the FDCAN
SocketCAN driver fix (arch/arm/src/stm32h7/stm32_fdcan_sock.c) were both
developed and validated using this board.
*Note: Please adhere to [Contributing
Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md).*
## Summary
*Update this section with information on why change is necessary,
what it exactly does and how, if new feature shows up, provide
references (dependencies, similar problems and solutions), etc.*
## Impact
*Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.*
## Testing
*This section should provide a detailed description of what you did
to verify your changes work and do not break existing code.*
*Please provide information about your host machine, the board(s) you
tested your changes on, and how you tested. Logs should be included.*
*For example, when changing something in the core OS functions, you
may want to run the OSTest application to verify that there are no
regressions. Changes to ADC code may warrant running the `adc`
example. Adding a new uORB driver may require that you run
`uorb_listener` to verify correct operation.*
*Pure documentation changes can just be tested with `make html`
(see docs) and verification of the correct format in your
browser.*
**_PRs without testing information will not be accepted. We will
request test logs._**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
