Skip to content

Conversation

@Vavat
Copy link
Collaborator

@Vavat Vavat commented Oct 13, 2022

@samkno1, @Niuslar, please review the PR at your leisure.
There are several things for you to consider when reviewing.

  • This PR does not have an open ticket, therefore, ideally you want to insist on thorough explanation of what is happening, so you can match whether authors intentions were implemented correctly. Author should not force you to guess what PR is trying to achieve.
  • This PR is a collection of a small feature + a lot of small refactoring jobs. This is normally frowned upon. One could argue that a better approach would have been to postpone the feature implementation until refactoring of hardware maps and Controller base class was done, then implement a feature on top. This would have resulted in 3 PRs instead of 1 large. The opposing view would be that refactoring without context of a new feature would have been confusing. See if you can formulate an opinion whether you see merits in both approaches. We can discuss it after.

Purpose of PR:

  • Implement mains control PWM hardware map methods.
  • Implement low level access API to control mains PWM.
  • As a result of the above certain refactoring had to be done to CController, IHardwareMap, and two implementations of the hardware map virtual class.

@Vavat Vavat requested review from Niuslar and samkno1 October 13, 2022 12:53
Copy link
Owner

@Niuslar Niuslar left a 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)
Copy link
Owner

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;
Copy link
Owner

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?

Copy link
Collaborator Author

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,
Copy link
Owner

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

@Vavat Vavat Oct 14, 2022

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);
Copy link
Owner

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

@Vavat Vavat Oct 14, 2022

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;
Copy link
Owner

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.

Copy link
Collaborator Author

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))
Copy link
Owner

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.

Copy link
Collaborator Author

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.

@Vavat Vavat requested a review from Niuslar October 16, 2022 09:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants