261–270 of 270 posts
For me the main issue has been the storage reliability. But what if there was a "Pi" that would boot from the network. Not local, but from Internet. With some tinkering, you could add a small network mounted drive for persisting things like configuration information. Bootup times would be long, but quite often these type of devices are not constantly turned on and off.
Earlier quoted context omitted.
The feeling of waste when I'm running a 20 watt laptop in the corner 365/24/7.
20 watt is very little. Are you sure it's more of a waste than buying a brand new energy-efficient device?
Earlier quoted context omitted.
So I am the opposite of an expert here, but I don’t follow. If I have control over the interrupts (which I do) and I have high precision timers (which I have), why can I not drive a gpio pin high for X microseconds accurately? What’s going to stuff it up?
As I mentioned in the previous reply, the CPU caches and the MMU to begin with. You're probably running your application from SDRAM and an SD card. The caches and page tables result in nondeterminism, because the timing depends upon existing cache state, and how long it takes to do a lookup in the page tables. And as soon as you have multiple cores, the cache coherency requirements can cause further subtle effects. T…
Having said that, I think some of the concerns have fairly simple mitigations. Because of the high clock speed, I can’t see that disabling cache and MMU is required. The maximum “stall times” from either of these components should still fall well below what would be needed. It’s bounded non determinism. That’s completely different to running things under Linux.
Secondly, having multiple cores allows for offloading non-deterministic operations. The primary core can be used for real-time, while still allowing non-deterministic operations on others. The only thing to consider is maximum possible time for synchronization (for which there are some helpful tools).
As I said, I’m far from an expert. It was close to 20 years ago when I last did embedded development for a job, and I was a junior back then anyway. Still, I’d be interested to know if you think I’m way off beam.
Having worked on safety-critical, custom circuitry and programming, particularly in the entertainment engineering field, I find the prolific use of Arduinos, RPis, and ESPs, to be concerning. You pay more for an equivalent industrial board, but there's been a lot more QA/QC done on it. Don't get me wrong, I started with Basic Stamps from Parallax back in the 90s to control window display animatronics in NYC departmen…
> I [...] found a state that would be unsafe. That seems separate from the hardware issue with the raspi, like something that would happen with better hardware as well. It feels like this needs to be handled in the dev tools where going into a dangerous state is automatically followed up by exiting it once an operation is performed and you can't mistakenly stay in the dangerous state. And then have an exhaustive anal…
I am more concerned with hardware issues, since the plethora of ESPs and Arduinos being made do not go through a Six Sigma type process to control the process. Also, the piece I pointed out did not have other separate hardware or other safety watchdogs in the box, like a Pilz unit supervising Beckhoff i/o. It was an Arduino with some relays off of its GPIO pins. High-integrity systems need to include both the hardware and software. There are actually standards for high-integrity systems aside from the usual aerospace stuff that applies to show control or machinery control. Safety-Related Control Systems (SRCS) are being addressed more and more in ASTM F24 for Amusement Rides and Devices.
I loved my Basic Stamp, Pic-chip, and Propeller chip days. Fun, but I am glad I progressed beyond the hobby level before anyone let me put a piece of kit up! Window displays were fairly innocuous!
I've always tried to add actual physical, mechanical interlocks on some of the stage machinery I've designed where a flipped bit or faulty i/o would cause harm or death! See my Arduino reference below.
I wish SPARK2014 would get more love. It has been around for a while with real-world applications, but Rust is the darling of the tech crowd now. AdaCore and Ferrous Systems are teaming up to bring some Ada goodness to Rust along with the legacy experience and apps.
Cool article on drones and SPARK2014: https://blog.adacore.com/how-to-prevent-drone-crashes-using-...
Cubesats: https://www.cambridge.org/core/books/building-high-integrity...
Arduino and Safety-Critical Circuit: https://forum.arduino.cc/t/safety-critical-circuit/319986/2
Having worked on safety-critical, custom circuitry and programming, particularly in the entertainment engineering field, I find the prolific use of Arduinos, RPis, and ESPs, to be concerning. You pay more for an equivalent industrial board, but there's been a lot more QA/QC done on it. Don't get me wrong, I started with Basic Stamps from Parallax back in the 90s to control window display animatronics in NYC departmen…
> I [...] found a state that would be unsafe. That seems separate from the hardware issue with the raspi, like something that would happen with better hardware as well. It feels like this needs to be handled in the dev tools where going into a dangerous state is automatically followed up by exiting it once an operation is performed and you can't mistakenly stay in the dangerous state. And then have an exhaustive anal…
SPARK2014 the programming language and the dev tools include a verification toolset, automated proofs, and unit testing. Rust may eventually catch up ;)
I typically see two kinds of raspi hate, and only one of them is reasonable imo. The first is stuff like this article, where you can probably get something better than a raspi these days for about the same price (especially when you consider scalper pricing) or just run a docker image in a server you can make with an old computer. This is very good advice, especially now that getting a raspi at MSRP is borderline imp…
> I typically see two kinds of raspi hate, and only one of them is reasonable imo. The first is stuff like this article, where you can probably get something better than a raspi these days for about the same price (especially when you consider scalper pricing) or just run a docker image in a server you can make with an old computer. This is very good advice, especially now that getting a raspi at MSRP is borderline i…
An RPI uses as much power as charging a phone. Your old junk PC probably uses an order of magnitude more, and most people don't need the extra CPU power. Why waste electricity? I bought all of mine at MSRP, and at that price its likely covered by the savings on power quickly.
That said, I've also used a few "thin client" PCs to build a cluster when I got the space. As much as I've wanted it, I can't convince the better half to let me install a full server rack in our guest bedroom (or pay for electricity).
On top of all this, it's small, so it can fit anywhere. I ran a few hanging with zipties under the bed frame in my dorm room years ago. My first apartment was 400sqft - I threw out my "server" PC I built and used a few Pis. When not in use they fit in a shoebox or drawer, so it's easy to have extras.
Earlier quoted context omitted.
> I [...] found a state that would be unsafe. That seems separate from the hardware issue with the raspi, like something that would happen with better hardware as well. It feels like this needs to be handled in the dev tools where going into a dangerous state is automatically followed up by exiting it once an operation is performed and you can't mistakenly stay in the dangerous state. And then have an exhaustive anal…
Just caught your "curtain puller" reference. I have designed a stage lift that travels at 4 ft/s from below stage after a sloat moves 6 ft/s out of its way to reveal 7 performers on stage after a poof of smoke. A sloat is the piece of the stage floor that needs to run down and under the stage to make an opening. I put some beefy metal flags that would only release the lift to go up after the sloat had cleared the ope…
I agree with the hardware safety interlocks, which I guess is why I don't think so much about the software - because I imagine it was programmed by a monkey (perhaps myself, late the previous night) and I don't trust it anyways. It's like a switch an untrained stagehand might hit which needs to be safe regardless.
(I've never made anything to be around a performance, but some of my things could certainly have hurt me or friends if we weren't careful.)
> SPARK2014 the programming language and the dev tools include a verification toolset
This is something that third-party FSM libraries often lack, decent controls and verification.
The cubesats are cool. Usually I can walk over and kick my creations when they need a reset, that's a whole 'nother level.
Earlier quoted context omitted.
As I mentioned in the previous reply, the CPU caches and the MMU to begin with. You're probably running your application from SDRAM and an SD card. The caches and page tables result in nondeterminism, because the timing depends upon existing cache state, and how long it takes to do a lookup in the page tables. And as soon as you have multiple cores, the cache coherency requirements can cause further subtle effects. T…
This is something that could only really be proven by actually testing and I don’t have a fast enough scope to really prove things. Having said that, I think some of the concerns have fairly simple mitigations. Because of the high clock speed, I can’t see that disabling cache and MMU is required. The maximum “stall times” from either of these components should still fall well below what would be needed. It’s bounded…
There are certainly multi-core MPUs and MCUs with a mixture of cores. The i.MX series from NXP have multi-core A7s with an M4 core for realtime use. Some of the ST H7 MCUs have dual M7 and M4 cores for partitioning tasks. There are plenty of others as well, these are the ones I've used in the past and present.
Earlier quoted context omitted.
Strongly agree here. Local SD storage IO aside, a Pi 4B 8GB is basically on par with a high end desktop I had in the mid-2000s. That’s an insane amount of compute on something that can be sub-2W over POE, or 1.3W on WiFi. Though for all the homelabbers out there, you probably have a NAS. Use Log2RAM, and present some ISCSI volumes to the Pi, and you’d be staggered with the very real work a Pi can do when not saddled…
Distro/stack recommendations for a Pi? Intrigued by your usage with Log2RAM and ISCSI volumes!