TODOs and Ideas

[salkinium]

Some rough ideas about what needs to be done without having to open an individual issue for each one of them. Please feel free to comment or add more features.

Library

• Run unittests in hardware on AVR and STM32 targets
• Fix AVR unittests
• Automatic code formatting (via Clang-Format?)
• Integrate gdbgui
• Move XPCC protocol out of modm into its own xpcc-communication repository.
• Refactor xpcc-generator into it's own proper python library
• Replace modm:fatfs with ufat
• Integrate upainter graphics algorithms
• Integrate fixed point math
• Let user choose which memory regions to use as heap
• assign linkerscript sections via memory attributes
• call same function on a set of pins (ie. access-optimized setAlternateFunction())
• Implement Semihost logging for boards without serial or SWO output
• Port fmtlib (aka. std::format in C++20)
• Port defmt offline formatting library from Rust
• Windows CI
• Use-case for Peripheral::connect() methods: e.g. combinations of SPI signals
  • only MO, no SCK: WS2812 accelerated bit-bang
  • MI and SCK: read-in 74HC165
  • MO and SCK: write-out 74HC595
  • Some SPI-slaves have Open-Drain pins -> optional PullUp
• Hook hardware events directly via generated ISR multiplexors (attach functions to GPIOs directly)
• Add USB stack by integrating one of these projects:
  • https://github.com/hathach/tinyusb
  • https://github.com/dmitrystu/libusb_stm32
  • https://github.com/IntergatedCircuits/USBDevice
  • https://github.com/kevinmehall/usb
• Integrate MRI: https://github.com/adamgreen/mri
• Better default configuration structs for drivers
• Generate a peripheral support matrix for all target families from lbuild data to replace the non-sensical "★" table in the main README.
• Write CI test to check if all examples are run by the CI
• Add a porting guide, this issue is coming up a lot more now:
  • Can be based on the comments for porting SAM* devices
• Add more heap allocator options for multi-pool heaps
• Use libusb1 in modm_tools to automatically choose programmer
• Integrate pyOCD as an alternative to OpenOCD. OpenOCD development picked up with the new maintainer. pyOCD cannot flash F469.
• Add a modm:ide:vscode module to add thorough support for Cortex-M devices

Build

• More flexible git info for any repository.

[ASMfreaK]

I saw some time ago discussion on code formatting.
I saw this tool on C++ Weekly, enabling one to choose and save clang-format configuration.
I'm not sure, if we'll be able to make great use out of it, since a lot of modm code is Jinja templates, unparseable by clang.

[parzival2]

Any plans to add USB support?

[salkinium]

Any plans to add USB support?

Yes, preferrably via third-party project integration though, since doing USB properly seems fairly complicated. I've bookmarked these projects to evaluate:

• https://github.com/hathach/tinyusb
• https://github.com/dmitrystu/libusb_stm32
• https://github.com/IntergatedCircuits/USBDevice
• https://github.com/kevinmehall/usb

[parzival2]

@salkinium Great. If I get around to gain a bit of knowledge into the project, may be I can create a pull-request using any of the above mentioned sources. I just discovered modm yesterday and its great.

[parzival2]

I saw that ROS is already available but having nanopb(https://github.com/nanopb/nanopb) will also be really great. It will be useful in writing binary files to SD-Card. The idea that I had in mind was to collect Accelerometer, Gyroscope data and play them back to simulate sensors like ROS bags. What do you guys think?

[salkinium]

What do you guys think?

You don't have to integrate nanopb into modm directly (in fact I would prefer to keep the modm core repo not expanding in size too much). You could make it a separate lbuild repository (like https://github.com/modm-io/Invensense-eMD) or modify the generated SCons/CMake build system to also build nanopb. The goal is to not have to "wrap" every library with modm, as modm probably adds very little to those libraries.

It will be useful in writing binary files to SD-Card

Note that our version of FatFS is very old, it should must be upgraded. In addition there isn't that much explicit support for SD-Cards or filesystems in general in modm. (sorry)

[salkinium]

Oh, nanopb comes with both CMake and SCons tools, so maybe it is warranted to create a proper lbuild repository and integrate not only the source but also the protocol builder into the modm build system. Probably not trivial though.

[W-M-D]

Implementing some SD support soon!

[rleh]

Implementing some SD support soon!

Once I added a block device interface (and implementations for SPI flash, heap storage and mirroring (like RAID1) to modm: https://docs.modm.io/develop/api/stm32g474vet7/classmodm_1_1BlockDevice.html
The idea was to use this interface also for SD cards, on-chip flash and other storage devices.

Then file systems like FAT (or ext3) could be implemented via this interface and used for all storage.

Unfortunately this interface has not been used for the recently added Eeprom driver in #321.

[mikewolfram]

I wasn't aware of the BlockDevice, so I did the CAT24AAxx driver by simply modifying the existing EEPROM driver. I'll look into it and change it.

[mikewolfram]

Talking about upcoming implementations, I'm interested in DMA and UI. I've been looking in lvgl but wasn't able to get it up and running. Their memory management didn't work on my L431. And also it adds a lot of code, my test of having a simple button added >30k (with -Og setting). I'd rather use something else. The current UI in modm has small footprint and would work perfectly to my needs.

[rleh]

DMA

You know there currently exists a very basic and hardly used DMA API?

@chris-durand and me started to work on DMA two years ago. On my feature/dmahal branch are a lot of WIP-commits. I'll try to rebase the branch soon.

DMA can be used for many different use cases. What is your use case?
Maybe we could discuss the use-cases and thus the interface of the DMA API(s) in a separate issue?

[salkinium]

I'm interested in DMA

Meme

Maybe we could discuss the use-cases and thus the interface of the DMA API(s) in a separate issue?

Yes please. I've added a bunch of DMA data already to the device files for this purpose!

[rleh]

For DMA: see #358

[ghost]

Better sanity checks. After some quick testing i encountered type mismatches across units. Too many warnings is disabled after my taste, which can lead to undefined behaviour. Tools as clang-tidy and cppcheck can be used on the generated code.

Example of code smells:

platform/fault/fault_storage.cpp:36:17: note: type 'const uint32_t' should match type 'const uint8_t'
36 | const uint32_t *fault_storage_heap_start{nullptr};

platform/core/heap_table.cpp:22:27: warning: type 'struct table_pool_t' violates the C++ One Definition Rule [-Wodr]
22 | } attribute((packed)) table_pool_t;

platform/fault/fault_storage.cpp:18:17: note: a field of same name but different type is defined in another translation unit
18 | uint32_t const traits;

[salkinium]

I completely agree! This only works if it is automated in the CI though. Would you be interested in setting this up (or adding more warnings)?