I just switched all my stuff to Particle Photon in the past several days after a couple weeks of contemplating the potential for issues like you’re describing. I’m still using a Rasberry Pi to control it, but I’m not trying to do timing sensitive stuff on the Pi.
Based on what I read, and on my own evaluation of the Pi’s design, my sense was that using 1-Wire or I2C kernel drivers on Raspberry Pi would lead to a less stable system compared to using a Photon. Raspberry Pi GPIO support seems optimized for the time scale of human response times–button presses, LED blinking, relays on and off, etc.–rather than on the scale of microseconds or nanoseconds like you need for software implementations of inter-circuit serial protocols. The Raspberry Pi’s I2C pins have built in 1.8kΩ pullups that seem designed for 400kHz short distance I2C. For longer cable runs inside a food computer, regular slow 100kHz I2C is more suitable. A lot of I2C sensor breakout boards–like Sparkfun or Adafruit’s stuff–have their own built in pullups that would lead to out of spec current levels on the I2C bus if wired in parallel with the built in pullups. Using those sensor breakout boards with Raspberry Pi I2C would require delicate soldering to disable all the extra pullups.
The old Raspberry Pi power supply issues seem to have been mostly resolved, and my sense is the platform can be very stable if you use robust techniques–lots of people are using Pis successfully for embedded and industrial stuff. The catch is that you have to approach it as an embedded system design.
I’ve been running 24/7 data logging on different combinations of a Pi Zero W and Pi 3 for about the last five weeks. So far, I’ve had no problems, but I’m using several techniques to keep things stable and be kind to the SD card:
- Use high quality 2.5A usb power supplies. From what I read, lots of of Raspberry Pi problems trace back to inadequate power.
- Save my initial camera images to a ramdisk so only my final cropped and scaled images get written to disk.
- Use big, high quality SD cards so the wear leveling algorithms have lots of spare flash to use beyond the capacity I need for images and sensor logs.
- Change a few things with Raspbian’s default configuration to reduce chatty logging
- Use a modest sensor logging interval, and cluster disk writes to happen at the same time. I started with a two minute interval, but that gave me way more data than I needed. Now I’ve switched to 20 minute intervals.
- Use a lightweight software stack that’s conservative about logging and other disk activity–ROS and CouchDB are the opposite of this (e.g. frequent api polling that generates HTTP access logs).
My sense is that OpenAg’s experiences with Arduino and Raspberry Pi are probably not representative of what’s possible with a lighter-weight software stack designed to conserve disk use and offload timing-sensitive I/O tasks to dedicated hardware. In particular, using automatic code generation for firmware seems outside the norm for embedded designs. Arduino sensor libraries aren’t uniformly high quality, and even the good ones can’t just be arbitrarily combined or instantiated multiple times. If you want it to work, you have to read the docs, check the all the resource requirements, and balance a lot of constraints from the different components. Also, you can’t trust library and example code for sensors to follow the datasheets or implement robust error handling. If you have serial buses operating at or beyond their rated electrical specs–and the PFC designs very well may–poor error detection and recovery can lead to major headaches.
- Particle Photon is great. It works a lot like Arduino, but it’s faster. It’s easier to flash. And, their ecosystem isn’t burdened with lots of cheap, unreliable clone boards.
- Rasberry Pi is great, but it’s questionable to rely on linux kernel modules to do a good job of high speed GPIO. Offloading the timing-critical stuff to dedicated processors can be more reliable as long as the firmware is written carefully.
[UPDATE (17 June 2018): The comments above accurately reflect my perspective from last year. But, in 2018, I’m less enthusiastic about Particle Photon. See my comment below for details.]