Age | Commit message (Collapse) | Author |
|
Do reference the period's start and end sample numbers when the
duty cycle is written to the binary output stream. The previous
implementation inappropriately used the period counter instead.
|
|
Move more items from the Python object's members to local variables of the
decode() method, as they are used there exclusively.
Mark a spot where the binary output references suspicious "sample numbers".
|
|
With the simplicity of PWM waveforms and the convenience of the v3 API,
there is no need to maintain internal state. After the start of the
first period was determined based on the input signal's polarity, any
period is defined by just the next two edges, and the next period is
immediately to follow.
|
|
|
|
|
|
Have edges detected in common library code.
|
|
Remove the FSF postal address as it might change (it did in the past).
Reference the gnu.org website instead which is more stable.
|
|
The previous **kwargs some PDs had is not actually ever used, so drop it.
|
|
|
|
|
|
This is more consistent with annotation syntax and looks slightly
better in most cases.
|
|
It seems the Python we ship along our Windows binaries does not
support u"..." strings, even though it's been a language feature
since Python 2. Remove the "u" prefix to avoid a syntax error.
Also, consistently use format "%.1f" at all scales.
This fixes bug #569.
|
|
|
|
Reworked in the algorithm:
- Fixed the polarity setting
- Taken in consideration the first transition
- Using the 'None' state instead of -1 and 0 value
- Simplify the algorithm and remove useless branches and variables
- Avoid re-calculating the same thing more than once
- Renamed a few variables for a better understanding
- Duty cycle precision changed to floating value
Otherwise:
- Added a meta OUTPUT for the duty cycle average
- Renamed the polarity option:
'polarity', 'active low/high' are well-understood terms.
- Added comments
Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
|
|
|