Share your modm projects #707
Replies: 8 comments
-
|
Beta Was this translation helpful? Give feedback.
-
|
I cannot provide any links since the code is hosted in-house. What we use it in our automation project as of now for:
The reason for us to select modm was, that it builds on modern C++, small footprint and still allows for lot of control. Had a look into mbed before and dislike, that there happens so much behind the scenes. |
Beta Was this translation helpful? Give feedback.
-
|
Some more (now public accessible) projects: |
Beta Was this translation helpful? Give feedback.
-
|
Very good question! Gives a good opportunity to look retrospectively at what I did the last years. As with Mike, I sadly cannot share many of the developments as they were for my clients or employers. In most cases, at least some code diffused into xpcc / modm. I was doing some stuff myself and sometimes initiated other people to work with xpcc / modm. Here are some in arbitrary order:
I probably need to extend the list later and watch out what I could do with some KUKA robots, a very large ABB 6-axis gantry robot at ERNE AG Holzbau here in Switzerland. I am probably looking into CANOpen and DeviceNet as I have to deal with some serious industrial stuff here. |
Beta Was this translation helpful? Give feedback.
-
I already started on CANopen and am also working on SECS protocol. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone! Myself and the rest of @uw-advanced-robotics has our own project to share 😄 At their core, our robots are all operated by STM32F4s; after a few years of working with... err... less pleasant tools (cough cough, Keil MDK, cough cough) we adopted modm around a year ago. We've since rebuilt almost all functionality in the modm world, with the exception of a few robots' special features which drew the short straw due to this past year's truncated season. I'd like to point out that our project is very much not vanilla as far as modm is concerned; we have some constraints regarding approach-ability for people brand new to C++, as well as miscellaneous aspects of the dev workflow which involved some customization. In particular, pretty much all modm classes are wrapped in our own types -- this is primarily for test-ability. Our All of that being said, we hope others can benefit from our work! Our main repo lives at https://gitlab.com/aruw/controls/aruw-mcb. We have a GitHub mirror at https://github.com/uw-advanced-robotics/aruw-mcb. We've only recently made the repos public, so there may be some rough edges as we make other repos and their docs public. Making the issue tracker public is in our short-term plans. From here on out, we're developing in the open. |
Beta Was this translation helpful? Give feedback.
-
|
I've been monopolizing the discussion board lately with my project, porting a secondary boot loader from the STM32F405 to the H735. It's been an adventure. I was searching for an embedded framework, for lack of a better phrase, that would let you focus more on your project and less on the mundane aspects of the common interfaces if of each different MCU. Along the lines of how Python and MicroPython enables that mindset across different OS platforms. I stumbled onto MODM, and despite being a newcomer to using old-style C++ in embedded applications, I took the plunge. Some aspects of the refactoring have been a real struggle, not because of MODM, but because the H7 is more different from the F4 than an overview of the 3000+ page reference manual would suggest. This port also adds a new interface other than serial -- Ethernet via a Wiznet chip using SPI. That was the most difficult part of the job for me, because it meant I had to add new drivers to MODM which I chose, maybe unwisely, to do in the MODM style. But in the end it was a great help to wrapping my mind around the modern C++ approach. At this point the hard stuff is done and I'm just putting some finishing touches, like a RAM message mailbox that's persistent between resets for communication between the boot loader and the main application. The secondary boot loader, like its predecessor, implements the same USART interface as the factory default boot loader, allowing one to use standard programming tools if desired. On the Ethernet side, I've implemented a TFTP server (yes, that's backwards from the norm). You can write ( program flash ) and read memory using the standard PUT / GET commands from your PC using an ordinary TFTP client (which are increasingly hard to find). Next on my MODM task list is to try my hand at refactoring my client's main app to MODM, just as a personal exercise to see how it goes. And also I'm planning to make a BSP for the ClearCore controller. While they provide an all-inclusive C++ library, the Microchip Studio runs only on Windows (although it's possible to convert it to an ARM-GCC tool chain with some shenanigans). I'm interested in it because that controller board is remarkably inexpensive (< $150) for a rugged industrial controller, and could be used in many projects, even those unrelated to motor control. |
Beta Was this translation helpful? Give feedback.
-
I want to build a list of projects that use modm, so that new people can perhaps explore "real" projects, not just the rather simple examples in modm.
Please add a link to your projects here, and perhaps some short feedback how well modm worked for you in this project. We're always looking for more feedback please!
Beta Was this translation helpful? Give feedback.
All reactions