modul / tinypid Goto Github PK

run the algorithm from within the sampling interrupt

What happens now on controller startup? (starts in manual mode with output being zero, I think)
How should it act on boot and what can be configured for startup?

E.g.: Configure it to start in automatic mode with a given setpoint.
or configure to start in manual mode with a given output

Idea:
sbaX – set boot to automatic mode with setpoint being X
sbmX – set boot to manual mode with output being X
gb – get boot options (return mX or aX)

Should some commands be locked and only be unlocked with a passphrase or sth else?
Should I lock the whole controller so any configuration (even setpoint) can only be made after unlock?
Feature?

test with lower baudrate

softuart sometimes adds 1 MSB to the received byte, causing tinyPID to not understand it. ATM there’s a dirty kinda workaround.

• s/scale_pv/pid_scale_pv/g
• s/LSB,MSB/Lo, Hi/g

get rid of them in gui,
don't use them in frontend class, leave the converting functions for convenience.

merge tinyPIDmonitor with tinyPIDqt!
rewrite some things and make it pretty
think about starting QwtPlotter project first.

implement serial echo or any kind of acknowledge/error code – so that frontend can check if tinyPID understood everything, and what it understood.

what about crc?

add license, author, description to source files

clean it up and think about getting it more straight forward
try to strip it down, if possible. the important thing is PID calculation.

somehow the connection should be supervised.
what if the device doesn't respond? retry? after n retries disconnect?

class to wrap connection, holding connection state, making retries and disconecting if needed?

class to wrap communication, pushing new values to registered objects?

add math foo description
add license
add more description (usage of frontends maybe)

parameters, factors – coefficients.