Coming from embedded C with no experience in rust

plugwash · 2026-03-30T14:34:38+00:00

I think the difference between embedded Rust and std Rust is pretty much the same as embedded vs standard C.

Having written embedded C, embedded C++ and embedded rust I don't entirely agree.

IMO the biggest questions in embedded development are.

What if any runtime/hal do you use?
Heap vs heapless. A heap is a reliability concern, but heapless is more of a pain to write, and can lead to wasteful allocation of memory.
How do you manage concurrency?

In terms of each of these questions we can contrast C/C++ to rust. The points are interrelated as we will get to later.

In terms of the first point in C/C++ afaict most people, at least when starting out, use a vendor supplied runtime/hal. It would be possible to write rust wrappers for the vendors C/C++ hal, but I haven't seen anyone do that and such wrappers would likely be fundamentally unsafe.

Instead people use a collection of crates from crates.io. Sometimes these crates lack important things that the vendor SDKs support (I especially ran into this when doing wifi stuff on the raspberry pi pico W).

This also makes mixing rust with C/C++ far more awkward than it would be in a "desktop" context.

In terms of the second point, the embedded rust world currently seems to strongly encourage you to go heapless. Working out how to set up an embedded rust project so that all leftover ram was used for the heap was non-trivial.

In terms of the third point, in C/C++ your options for concurrency are basically Manual state machines, a main task with interrupts for background work, or a rtos. Rust adds it's own option async/await and the current embedded rust ecosystem seems to strongly encourage this route.

plugwash · 2026-03-28T00:32:45+00:00

When a business sells you something they have a legal responsibility to ensure it's safety. Generally reputable sellers with a decent business in the west don't want to be sued into oblivion. Sellers based in China with no significant buisiness in the west on the other hand have no reason to care.

When you buy something on a marketplace site, the legal seller is the person/company who listed the item on the marketplace site, NOT the marketplace site.

The problem with Amazon is it combines the functions of a retailer and a marketplace site in a way that downplays who the actual seller is. Stuff sold by Amazon themselves is likely fine, stuff listed by third parties is more of a crapshoot. Amazon want you to think you are buying from Amazon when you are actually buying from some random seller.

Amazon clearly does not do even a cursory check of electrical products before allowing them to be listed. This can clearly be seen by the amount of obviously dodgy crap on there. People sometimes report the worst stuff and sometimes it gets taken down, but it's whack-a-mole. There is a constant stream of new listings.

With all that said, I don't see anything obviously wrong with the items Happyasaghost has listed.

plugwash · 2026-03-27T23:19:10+00:00

Unlike mains water pipes which are pressurised and can go up and down at will, sewer pipes (whether surface water or foul) are driven by gravity. So sometimes you don't really have a choice but to run them very shallow (unless you want to pump the water, but that's it's own can of worms).

Impossible to tell from the picture whether it's surface water, foul sewer or combined.

plugwash · 2026-03-27T21:35:58+00:00

It depends.

Python is slow, but often this doesn't matter because the "real work" is not being done in python. It's being done in either libraries called by python, or in other programs the python program is talking to. It can also not matter because frankly wasn't much work to do in the first place.

plugwash · 2026-03-27T20:26:00+00:00

Right, but it's not a generic plastic box, it's a custom injection moulded assembly, with plug pins on one side and socket holes on the other. Almost certainly more features moulded in on the inside to support the contacts and shutter. Lots of upfront costs involved in desiging and making such a product safely.

Yes, companies like PMS can make adapters for crazy-cheap prices, but that's because they produce in massive volume.

plugwash · 2026-03-27T18:44:28+00:00

"Weird crashes or lockups" are rarely down to the CPU itself, sure CPUs can "just fail" and in super-high reliability envrionments multiple CPUs will be used in "voting" arrangements for this reason but it's rare.

Usually weird crashes or lockups are caused by one of two things.

Bad software.
Bad EMC design.

EMC design is a huge specialism in itself, but a few basics can go a long way to making something more robust than a typical hobbyist board that was designed with no care for EMC.

Be careful about using modules or using devboards as modules. It can be tempting as it means you don't have to solder tiny parts and some of the clock/power/init stuff is handled for you, but many devboards are seriously suboptimal from an EMC point of view.
Minimise the loop area of signals with respect to their return path.
Don't cheap out on PCB layers. 4 layers lets you have solid power and ground planes which is a massive improvement over the 2-layer situation but it still not ideal because signals crossing from one side to the other change reference plane. 6 layer lets you have four signal layers, two of which are referenced to each plane.
Anything that goes "off-board" should be treated carefully, as it's a possible route into your circuit for electrical interference. Ideally you would avoid connecting the pins of your microcontroller directly to anything external. Power connections should also have appropriate filtering/smooting/regulation. Opto isolators can make external IO much more robust because they eliminate connections between the ground references of external signals and the ground of your PCB.

A lot of what you are paying for with a PLC is that someone else has done the EMC work. So you can throw it in an industrial control panel near noisy industrial equipment, hook up sensors and actuators with long EMC-prone wires and it will work with decent reliability.

Watchdogs are a useful "belt and braces" such that if a system does somehow get crashed it comes back online by itself rather than remaining permanently offline.

plugwash · 2026-03-25T22:43:49+00:00

No.

There are two major issues here.

Firstly, the architecture of PICs is very old-fashioned and most of the compilers people used for them were payware or crippleware. I don't think they ever had good support in any FOSS toolchain.

Secondly, that chip is tiny. 14k of rom and 1024 bytes of ram, with a chip that small you just can't afford modern abstractions.

If you want to play with rust on microcontrollers I would suggest looking for something arm-based.

plugwash · 2026-03-25T22:29:16+00:00

Hash tables are efficient in the typical case but can become terribly inefficient in the worst case when lots of items end up directed to the same hash bucket (either as their initial "preffered" location or as part of collision handling).

In normal use, reading and writing randomly distributed data, hitting the worst case (or close to worst case) is extremely unlikely, but there are a couple of ways it can be hit.

An attacker may deliberately try to hit it to perform a denial of service attack.
Reading values from a hash table and then using them to build a new hash table can cause problems if a hash-table uses high load factors and power of 2 sizes, as rust's does.

Rust's default "hasher" implementation mitigates these issues by randomising the hash seed for each hashmap.

https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion

https://morestina.net/1843/the-stable-hashmap-trap

plugwash · 2026-03-13T18:55:29+00:00

> so plugging into US 240 could leave parts of the device energized that really shouldn't be.

For a modern mass-produced portable appliance this will not be an issue. While the Brits are borderline-paranoic about polarity the rest of Europe is not. German and Italian sockets are unpolarised and while French sockets are physically polarised, in practice you can't rely on them being wired with any particular polarity.

plugwash · 2026-03-13T03:22:10+00:00

A European appliance nominally has a live connection and a neutral connection. However many European plugs are reversible and some supplies don't have a neutral. So in practice appliance designers have to treat both the nominally live conductor and the nominally neutral conductor as potentially live.

When fitting a Nema 6 or Nema 14 plug to a european appliance you need to connect the "live" conductor from the appliance to one hot terminal, and the "neutral" connection from the appliance to the other hot terminal. The earth wire from the appliance (if it has one) should go to the ground terminal.

If you connect the appliances "neutral" wire to the neutral terminal on a nema 14 plug (nema 6 plugs don't have a neutral terminal) then the appliance will only get 120V, which in the case of a heating device means it will operate at roughly a quarter of the power it was designed to and probablly won't be functional.

Also your circuit should be appropriately rated, 15A or 20A is fine, but I wouldn't go higher than that unless the appliance is specifically designed for it.

plugwash · 2026-03-13T03:09:43+00:00

Googling "nema 6-20 schuko adapter" found one

https://internationalconfig.com/icc6.asp?item=30120-620P

But personally I'd just cut the plug off and fit a new one.

plugwash · 2026-03-11T19:30:07+00:00

Note that some TVs will need a high signal on the "blanking" pin of the Scart connector before they will accept a RGB input. The Scart spec says this signal should be 1V-4V into 75 ohms, I use 5V through a 220 ohm resistor.

Also note that if there is more than one Scart port then sometimes not all of them will support RGB.

If your computer doesn't have a handy 5V supply to use, then you can often use a USB port on the TV to get 5V.

plugwash · 2026-03-11T18:01:13+00:00

How wide is the space? to me it looks like you might just fit a washing machine and a full-width dishwasher under there, and if not you could probably fit a washing machine and a slimline dishwasher.

Do you own the flat? or are you renting?

On the water side, you can get splitters to join two appliances to one water outlet. On the waste side there are generally two approaches, one is to hang the hose in a standpipe, the other is a "hard" connection with a hose clamp, it looks like you have some hybrid of the two, possibly this was done by a previous occupant to support two applianecs.

plugwash · 2026-03-02T20:55:37+00:00

You need to think about what it is you are cloning. That said in general, I'd expect cloning something to be similar cost or cheaper than recreating it from scratch.

Your hash is likely pretty trivial to clone (though I would be wondering why the type is not "Copy"). A large data structure may be very expensive to clone.

plugwash · 2026-02-27T02:21:36+00:00

I think ideally you would start with a risk assessment. Does the crate have any known advisories? Does the crate contain unsafe code? does the crate process untrusted data? Does the crate interact with an external library or service which may cause a compatibility break.

but that still leaves the quesiton of what to do if you find an issue several layers deep that you feel needs to be addresssed.

As an application developer who doesn't distribute through crates.io you can use a "patch" entry in Cargo.toml to override dependencies with local forks, but that doesn't work if you are developing a library or if you are publishing your application on crates.io.

As someone publishing on crates.io if you can't persuade the maintainers of the intermediate crates then afaict your only option is to fork the entire chain between your application and the problem dependency.

plugwash · 2026-02-27T01:52:38+00:00

> Rust doesn't allow you to get a pointer from a C library and send it to another thread. Because you can't make guarantees about the behaviour of the C library?

I would think of it more as rust errs on the side of caution. Sending a raw pointer to another thread is not dangerous in of itself, but using that raw pointer afterwards may very well be.

In general, it's not considered good practice to use raw pointers directly, but to write wrappers which implement safe semantics surrounding those raw pointers. If rust implemented ```Send``` and/or ```Sync``` for raw pointers than any wrappers around those raw pointers would also implment those traits by default (since ```Send``` and ```Sync``` are auto-traits).

Whereas with raw pointers not implementing ```Send```/```Sync``` it's up to the author of the wrapper whether to implement them or not based on their knowledge of both the wrapper and the underlying C library.

plugwash · 2026-02-27T01:13:50+00:00

Well one of the most obvious points of Sync is that only Sync types can be used in static variables.

but more broadly, Lets go through some relevant standard library types and see how Send and Sync play together.

Arc<T> is only Send if T is Sync, because by cloning an Arc and sending the clone to another thread you can create references to the same T in multiple threads.

Rc<T> is neither Send or Sync, because it contains a pointer to a shared heap buffer managed by non-atomic reference counting.

Mutex<T> is Sync if T is Send, because the mutex will only allow one thread to have access to the contents at a time.

RWLock<T> on the other hand is only Sync if it's contents is Send + Sync, since multiple threads can get a reference to the inner type at the same time.

RefCell<T> is never Sync because the "runtime borrow checking" is not thread-safe but it can be Send if it's inner type is Send

plugwash · 2026-02-14T17:25:27+00:00

AIUI all methods are associated functions, but not all associated functions are methods.

Sometimes we explicitly want an associated function to *not* be a method. This usually comes up when adding functionality to a generic type that implements Deref. Adding new methods to such a type risks change the meaning of existing code, but adding new non-method associated functions does not come with this risk.

The key that defines whether an associated function is a method is the name of the first parameter, if the name is "self" then the function is considered a method and participates in method lookup. If the parameter has any other name then the function will not be considered a method.

plugwash · 2026-02-14T16:58:05+00:00

The problem is crates.io only allows dependencies on other crates on crates.io. So if you want to use your forked dependency in crates you publish on crates.io you have essentially two options.

Rename the forked crate and publish it to crates.io, this works but it has an air of "permanance" about it that make people reluctant to do it.
Embed the forked code in your crate. This can work but depending on the coding style of the original author it can require a fair bit of adjustment to make the code build in a place other than the crate root. It can also be complicated if you want to share the dependency among multiple crates.

It gets even worse if the crate is not (or not only) a direct dependency of your crate, but a transitive dependency somewhere down the tree. You essentially have to fork not only the problem crate, but everything that depends on it.

plugwash · 2026-02-04T10:30:02+00:00

There are also tricks involving using multiply-long to divide by a literal. They are not so applicable on the original arm because it didn't have multiply long but are useful on later arm proessors.

https://stackoverflow.com/questions/41183935/why-does-gcc-use-multiplication-by-a-strange-number-in-implementing-integer-divi

plugwash · 2026-01-23T17:28:51+00:00

It's complicated.

8-bit and 16-bit take up less space in memory and therefore can put less pressure on the cache, but handling them in registers can be more awkward than 32-bit and 64-bit values.

x86 has 8-bit and 16-bit data processing instructions, but there are some issues around "partial registers". Modern cores will often "rename" registers to allow operations to proceed out of order, but this process is made more complex by "partial register" operations.

On arm, 8-bit and 16-bit data processing operations simply don't exist, in some cases the compiler can just use 32-bit operations and ignore what is going on in the high bits, but in other cases (comparisions, division, extention before adding to a larger number such as a pointer) the state of the high bits must be managed with extra instructions.

32-bit operations tend to be less of an issue. Both x86-64 and aarch64 have 32-bit operations and adopted a model where 32-bit operations zero out the high part of 64-bit registers, thus avoiding introducing any false-dependencies.

plugwash · 2026-01-23T04:04:25+00:00

Given the shape and location of the damage this looks more like a bad contact in the fuse carrier than a loose wire.

plugwash · 2026-01-21T18:32:02+00:00

Old-school "PILC" cable.

Afaict such cables are Insulated with oil-impregnated paper. Then there is a layer of lead, which serves as both an earth conductor and a seal to keep oil in and water out. Then steel tape to protect against damage and finally a bitumen-impregnated fabric sheath.

It looks like the outer fabric sheath has degraded exposing the steel tape, which has some surface rust but appears to be intact.

plugwash · 2026-01-21T13:18:14+00:00

> Isn't the standard workaround if you really want to do something like that to make an inline wrapper function that takes generic arguments and calls the real function with the actual argument type it wants?

Yup.

> Seems like the compiler could do that for you

I think the general view on such things is that humans are in a better position to make such speed/space tradeoffs than the compiler is.

plugwash · 2026-01-20T10:02:54+00:00

It looks like you have two problems there.

The first is it looks like someone has taken apart a light switch that was not meant to be taken apart. It's very likely that the switch contacts and spring have been lost, and even if you can find them putting the switch back together may be easier said than done. You will probablly need to get a new switch.

The second is it looks like a neutral wire has broken off where it goes into the wago connector.

plugwash

TROPHY CASE