-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added dummy parameter to Timer::isChannelConfiguredAsInput for 1 channel #344
Added dummy parameter to Timer::isChannelConfiguredAsInput for 1 channel #344
Conversation
@rleh I guess there's a small regression in the new GCC version that makes the flash overflow on the F103 unittests. I've fixed this in #343. |
… with 1 channel only. This allows a unified interface for all general purpose timers, independent of the number of available channels.
648a9e5
to
4978db8
Compare
Thank you @rleh and @salkinium for your prompt reaction and review. 💐 It motivates me to contribute to this awesome project. 👍 |
Thanks for the feedback, that's what we aim for! I'm curious to know what you're using modm for? If it's a professional project, how does modm integrate into your team's workflow? Do you have some feedback about how the code generation step is accepted by other team members? What parts of modm need improvement? |
I'm curious to know what you're using modm for? If it's a professional project, how does modm integrate into your team's workflow?
I am currently evaluating modm as part of a professional project. For
the moment I am only generating classes for hand-picked peripheral and
include those in legacy software. I do not use a generated build system
configuration.
One aspect of the evaluation will be the memory usage. Another will be
the applicability of the peripheral configuration being linked to the
static typing.
Do you have some feedback about how the code generation step is accepted by other team members?
Code generation is definitively smoother in Linux environments, as it
can be executed in the native shell and it does not require to install
Anaconda or Miniconda. Unfortunately other development tools "require"
the use of Windows in my working environment. I am not sure how much of
the code generation might be eventually integrated in our continuous
integration tool-chain because of the dependencies it imposes. As the
need to generate the library anew will be seldom, this shall not be
critical.
As it is still under evaluation, no other team members are involved in
the code generation.
What parts of modm need improvement?
At the moment the *documentation and manual* is very important for me.
I greatly appreciate the Getting Started manual! I will see to ask
anything unclear. In some cases that may be something to add to the
documentation. As I understand questions are to be asked as issues in
Github.
Thank you for maintaining modm!
|
Excellent, that was what I had in mind with our ulta-modularized HAL: Be able to only generate the absolute bare-minimum of code required and then integrate it into your own project.
Good Windows support is… interesting. So much stupid, so much pain.
Yes, it's much better than with xpcc, particularly now that @rleh got the API docs working so nicely!
Looking back at it now, I find it a bit chaotic, I need to rewrite it to be clearer in places. See also issue #280, which I haven't had the mental space to get into yet. Writing docs is very difficult without a proper review.
Absolutely! |
Added dummy parameter to
Timer::isChannelConfiguredAsInput
for timers which have only one channel.This allows a unified interface for all general purpose timers, independent of the number of available channels. As a default argument is given, it is backwards compatible.