High reliability and functionality

[Erroneous]

I would like to fork the BrewPi project which uses a Raspberry Pi connected to an Arduino to use as a temp controller. It seems like a huge waste to use the Arduino as a controller, though I understand why they did it. They coupled the Arduino with a Raspberry Pi because of the high functionality you get from a complete Linux system (chiefly file system, ethernet/wifi, ssh, ntp, apache/php, and a BrewPi daemon) along with the high reliability you get to dedicated hardware. They could of course decouple from the Pi and poll the Arduino from any linux variant if they would just make a more standard package that is not reliant on Raspian.

BrewPi uses an Arduino because it is highly reliable and realtime (not that they need realtime except for standard things like SPI and OneWire). They actually had to move from Arduino to Spark because they wanted more memory. I've thought about this for a while, and I think the best solution might be to make a temperature controller kernel module and interact with that instead. This way, even if the daemon dies, the filesystem is full, etc, as long as the kernel is running then the temperature is still being controlled.

My idea is to write a kernel module that does the following:
Each instance of the module would use between 1 and 2 switches (1 for heating, 1 for cooling), use a DS18B sensor for determining temperature, and work as a PID controller (for compensating overshoots). I'd want to be able to do the following things with an instance of the module:
get/set the controller pin(s) and heating/cooling mode
get/set a controller pin(s) to be normal or inverse (high means on or off)
get/set variables in the PID (including target temperature, Kp, Ki, and Kd)
get/set the pin for OneWire and serial
get the last temperature reading

Would my approach be feasible? Is there a better approach I could take while maintaining high reliability on a RPi? I could go bare metal, but I'd like to have many features that linux gives and it seems like it'd be a huge time suck. This would be my first kernel module, though I am comfortable in C and have built and configured Linux kernels in the past. For interacting with OneWire I likely wouldn't reinvent the wheel in my module when there is already the 1-wire module. I know that there is a project called Fuscus that implements the Arduino side of BrewPi as a python library, but then you lose the reliability if the process dies or never gets started.

[joan]

I can't see the point of writing a kernel module, I can see downsides but no upsides.

Why not just use a normal userland program?

[Erroneous]

I can't see the point of writing a kernel module, I can see downsides but no upsides.

Why not just use a normal userland program?

If you use a userland program you rely on the init system or some subsystem to keep it running. As a kernel module, it could be loaded faster and should be more reliable (unless I'm wrong about reliability). There would still need to be a userland program that handles logging and setting up the PID, but say you run out of storage and you are logging to a file and the process dies, the init system might not start it because it can't log anymore, and your refrigerator freezes anything you had in there because it happened to be cooling at the time unless the controller was not part of the dead/unable to start process.

Basically I'm trying to get as close to bare metal as possible without having to go bare metal. Do you think this would be the way to go about doing this? I could always make 2 userland daemons that communicate with each other, 1 controlling the PIDs and 1 doing all the logging, but couldn't I just move the PID daemon into the kernel and be sure it will keep running just about no matter what? The downsides I see for the kernel module would be that it would be a more difficult to implement, the module would need to be rebuilt any time the kernel is upgraded, and any coding error could bork the system.

[joan]

I think you are starting from a false premise that kernel modules are more reliable than userland programs. In general they may be, but that will almost certainly be down to the amount of testing they have had. A kernel module written from scratch will be no more reliable than a userland program written from scratch.

I see nothing in your application which would make me consider implementing any part of it as a kernel module. However I have never worked in refrigeration so may be missing some nuances.

[steveb4pi]

Yeah, the Pi plus 'clever micro controller chip' is total over kill ..

As is any C++ code and even Python ... all you actually need is a simple Temp sensor and a Shell script ..

If you are worried about 'reliability', unless you need to sample temps at mS intervals, you can 'moniotor' the first script using a second script (CRON trigger) eg. have the first script update a log file every cycle of X seconds, the second then just needs to check the log file is being updated and if not assume first has crashed so kill it and relaunch ...

If you worry about the whole Pi 'locking up' , just add your scripts to the boot-up sequence write a 'watch dog' script (say pulls some GPIO lo for 1 second in every 10) and have some external system cycle the Pi power if not itself reset every 10s ...

[Heater]

Erroneous,

Why do you assume a Linux system is unreliable?

Huge proportion of the worlds servers run on Linux and are expected to be very reliable.

A lot of embedded systems run on Linux and are expected to be reliable. An example close to home for me is that I was part of a group that convince the company I worked for to move all their embedded systems development to Linux a decade or more ago. As a result all the traffic lights in Scandinavia are running on Linux.

For such systems you are going to be running a minimalist Linux system, say Raspbian Lite. You are going to ensure there are no services running except the ones you need. You will use the watchdog. You will the boot media is mounted read only.

In the extreme you will employ an external hardware watchdog and or safety monitoring system. For example traffic light controllers have a safety system that checks the system does not command conflicting red green lights and shuts the whole thing down if so. Force amber flashing in hardware.

That external "guardian" could well be an Arduino I guess.

If your program is logging data and fills the storage so that the think can't reboot then that is buggy code on your part.

[Erroneous]

You are probably correct on my assumption; I'm mostly going on the assumption BrewPi made about throwing out the idea of using a RPi for controlling the refrigeration. It is all fairly simple stuff, no real time needed, just check the temp on a DS18B, see if your algorithms need to change the current pins from low or high and do it, rinse, repeat. I know BrewPi went to pretty long lengths to make sure their logging process kept going (they use a cron job set to go off every minute and start the daemon if it isn't already running) and I think their disappointment with the reliability of that steered them away from using the RPi as the temp controller in the first place. They also redirect stdout and stderr to log files, which I could see being issues if the file system was full.

I do think of Linux as reliable, though the hardware watchdog is probably more reliable. Since these systems aren't life threatening, the overhead and cost of using an Arduino is overkill for this project imo, but I'm wondering if I can achieve something closer to a hardware watchdog by making a kernel module.

Perhaps it would be best to simply start the userland daemon(s) with a sh script with an infinite loop. Keep one daemon to have only the essential bits that keep the refrigerator running, and communicate with that daemon using another daemon for logging.

[Heater]

You can start your program with a systemd service file. Google it. Such a service run by systemd can be restarted by by systemd if it ever exits.

There is a watchdog feature in the kernel. Google it. That watchdog can be made to reboot the entire machine if your program fails to write to the watchdog at regular intervals.

You could add an external watchdog hardware that resets the machine if your program does not wiggle a GPIO pin at some regular interval.

There are even little watchdog chips you can buy. But a 555 timer would do.

Nothing helps reliability more than simplicity. So perhaps a Pi is over the top for what you want to do and a simple MCU like the Arduino would do.

But if you need data logging, web communication, a display etc there is a lot you can do to make a Pi very reliable.

[Heater]

steveb4pi,

As is any C++ code and even Python ... all you actually need is a simple Temp sensor and a Shell script ..

Please explain how a "simple shell script" is anymore reliable than a simple program in C++ or Python?

[Erroneous]

You can start your program with a systemd service file. Google it. Such a service run by systemd can be restarted by by systemd if it ever exits.

I've made a few of these, and have ones that auto restart, but what I don't like is how if (by default 60 seconds, I know you can specify this in the service file) if you try restarting too many times in a row it will never try to restart it again until you reboot or restart the service. I even made one for BrewPi for Arch Linux Arm.

There is a watchdog feature in the kernel. Google it. That watchdog can be made to reboot the entire machine if your program fails to write to the watchdog at regular intervals.

You could add an external watchdog hardware that resets the machine if your program does not wiggle a GPIO pin at some regular interval.

There are even little watchdog chips you can buy. But a 555 timer would do.

This would prove to be awesome, will look into it.

Nothing helps reliability more than simplicity. So perhaps a Pi is over the top for what you want to do and a simple MCU like the Arduino would do.

But if you need data logging, web communication, a display etc there is a lot you can do to make a Pi very reliable.

Indeed I do need the last bit for the first bit to be more useful than say an aquarium heater or johnson temperature controller. I think by simplifying the bits needed to be reliable and eliminating failure points for that process (like writing to disk) it should be as reliable as an MCU connected to the serial port.

Yeah, the Pi plus 'clever micro controller chip' is total over kill ..

As is any C++ code and even Python ... all you actually need is a simple Temp sensor and a Shell script ..

I'm quite comfy in C++ and the complexity of a PID controller makes doing a shell script difficult. PID controllers estimate over and under corrections using derivatives. I haven't tested to see if the PID model is any better than simple above/below and cool off timers, but BrewPi has always been within about 1 degree F of the target temperature. Also, my fork would make use of a database.