-
Notifications
You must be signed in to change notification settings - Fork 4
Feature/srm mains power control #123
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
base: develop
Are you sure you want to change the base?
Conversation
Niuslar
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's only one thing I think we might need to check. The rest looks good, thanks.
| uint32_t run_period_ms) | ||
| : CController(name, run_period_ms), | ||
| m_breather_light(BREATHING_GPIO_Port, BREATHING_Pin) | ||
| mp_hw(p_hardware_map) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should check that this is not anullptr somewhere.
| m_breather_light.toggle(); | ||
| static float breathing_light_intensity = 0; | ||
| mp_hw->setBreathingLight(breathing_light_intensity); | ||
| breathing_light_intensity = breathing_light_intensity ? 0 : 100; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understood correctly, this function sets the duty cycle to 0 or 100 to turn the LED on/off every time run() is called?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. This is really just a plug for when we get around to beautifying it. Ideally, we would want CDebugController to be able to switch this light from slow flash for "Everything is OK" to other types of flashing for when something is the matter and might require attention. But this is frills and cannot distract us right now.
| etl::format_spec(), | ||
| true); | ||
| CController::s_scratch_pad += ": "; | ||
| etl::to_string(mains_power, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to have an overloaded "addToString()" function that adds floats, ints, and string to the buffer before calling send(). I might have a look this weekend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That'd be awesome. Like c# and java do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What might be a good thing to do is create a child class based on etl::string and expand it with ability to absorb numbers.
Another option is to expand send() method within CComsController to be able to accept parameters like sprintf() does.
| mains_channel = (uint8_t)(*p_command)[0]; | ||
| if (mains_channel != (*p_command)[0]) | ||
| { | ||
| return (ICommand::ERROR_TYPE_MISMATCH); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this ever be true? How can mains_channel != (*p_command)[0] if we are assigning it that value the line before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit of an awkward way of seeing if an argument is a float. Horrible solution, but I couldn't come up with a better one. Open to suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One option I can think of is to simply cast whatever is in the first argument into unsigned int and then range check. If it was sent as float, then we ignore the decimal part and use it as if it was an integer. This will not cause failures, but it'd be possible to request channel 2.5 to switch to 100% power, which will switch channel 2 or will bounce back with error depending on how casting works.
| power = 100; | ||
| } | ||
| uint16_t ccr = p_timer->Instance->ARR * mainsPowerCorrection(power) / 100; | ||
| p_timer->Instance->CCR1 = ccr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't change anything, but the HAL has a __HAL_TIM_SET_COMPARE(__HANDLE__, __CHANNEL__, __COMPARE__) "function" that sets the CCR register.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dislike macros. Any compelling reason I should use your suggestion?
| mains_power = (*p_command)[1]; | ||
| } | ||
| // range check arguments. | ||
| if ((mains_channel > 2) || (mains_power < 0) || (mains_power > 100)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to fix this because if _command->getArgumentCount() is not 1 or 2, then mains_channel and mains_power will be uninitialised.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's because I forgot final else{}. Fixed.
@samkno1, @Niuslar, please review the PR at your leisure.
There are several things for you to consider when reviewing.
Purpose of PR: