from time to time, there are ideas about doing digital sensor reading with SBC (Single Board Computer) machines like the Raspberry Pi or the Beaglebone. However, these systems are actually not suitable for this task at all, while it looks like it “might work” for some of us at the first hand.
By using this thread, we want to shed some more light on this topic.
ah! Are you still running the same setup? If so, you won’t probably care about Arduino drivers anyway.
However, I would like to encourage you to do so! Besides making a humble start with Protect code when accessing shared resources and ESP32 multicore task scheduling, these topics are still underrated in general, so I’d like to take the chance to write some more background information about that topic.
Recommendation to use realtime systems for reading values from digital sensors
Coming from your efforts you are currently putting into the climate chamber thing to get things absolutely right™, you should really consider moving away from Linux to a realtime system to improve data acquisition quality. Or do you actually run any RTOSsy thing on your Pi Zero already? If you are doing so, please forget about the background information I’d like to outline here.
Background
When running an off-the-shelve Linux, you will inevitably run into fishy things, especially when increasing the sampling frequency, as the regular Linux Kernel will not play fair games when it comes to scheduling your measurement task away (it’s a multitasking system at all!) when it’s just about to read from the scale.
This is just bad in both high-frequency and low-frequency sampling scenarios because you will never be able to compensate for that as the task scheduling usually is pretty indeterministic from the perspective of the user-space programs.
While there are chances things can be slightly improved by adjusting the task scheduler of the Linux Kernel appropriately (e.g. by beginning to increase the task priority), it’s still not an RTOS system.
I don’t wont to scare you about these details, but they are there while maybe hidden in plain sight. I just want to be straight on that as others have been burnt by similar issues as well.
Just my two cents and thanks again for the efforts you are putting into that!
Hi,
i am using the pi zero, simply because i started with this setup. I figured out some issues with the DS18B20. The readout is very unstable.
Maybe in a future design i will switch to a RTOS System.
But, my scales are about 50km away from where i live, so i am only there at the weekend.
And it is sooo easy and handy to access the Linux-System per remote SSH.
And i don’t have any idea who to program and access the other systems?!
I am more or less aware of Python, can you program the RTOS systems (Arduino etc,… ) also with Python code?
which also seems to fit this topic very well. The hardware used there is also a SBC like the RaspberryPi, in this case a PICO-PI-IMX6UL, the predecessor of the PICO-PI-IMX7.
As both system are probably running a regular Linux Kernel, each one is lacking the realtime requirements for reading digital sensors, so things might have gone south due to this.
The answer is: Yes! We tried to outline the general direction we are taking here at Introduction to MicroPython for you. Thanks for asking and please let us know if this would be something which could spark your interest.
In this context, I would like to share two interesting articles which evaluate the RaspberryPi 3/4 SBCs using the Linux Kernel 4.14 and 4.19 with Preempt-RT patches by Thomas Gleixner and his team at Linutronix.
Background
Last July (2019),
Linus Torvalds, the Linux Kernel top level maintainer, merged a pull request adding the kernel configuration symbol CONFIG_PREEMPT_RT.