Yes, let's mention Roman Law in relation to British Common Law. The latter derived from the former, but there's a fair distance of about 1,000 years between our three points in time.
For all intents and purposes, every precedent and matter of jurisprudence can be resolved by referring only to Common Law. It would be rather exhausting and absurd to try and reach back past 1066 AD because things have changed, a lot.
Now in terms of forking Roman Law, there are other legal systems which are not directly related or derived from British Common Law. Especially the Napoleonic Code, which influenced Italy, which in turn influenced Catholic Canon Law. So here we have another lineage and a deeper "fork" from Roman Law where British Common Law doesn't really figure.
Also someone commented with a non sequitir about "antidisestablishmentarianism". I'd just like to point out that that word refers to revocation of things like the 1st Amendment and support for the Established Church laws, because it's "anti-dis" double negative.
If you want to talk about the United States' 1st Amendment, "disestablishmentarianism" is the term used to describe how the Founding Fathers set up the States without those meddling bishops.
I’d be interested to see a re-usable implementation of joe's[0] syntax highlighting.[1] The format is powerful enough to allow for the proper highlighting of Python f-strings.[2]
I've actually made several lexers and parsers based on the joe DFA style of parsing. The state and transition syntax was something that I always understood much more easily than the standard tools.
The downside is your rulesets tend to get more verbose and are a little bit harder to structure than they might ideally be in other languages more suited towards the purpose, but I actually think that's an advantage, as it's much easier to reason about every production rule when looking at the code.
It’s just that nesting them arbitrarily is now allowed, right? That shouldn’t matter much for a mere syntax highlighter then. And one could even argue that code that relies on this too much is not really for human consumption.
Also, you can now use the same quote character that encloses an f-string within the {} expressions. That could make them harder to tokenize, because it makes it harder to recognise the end of the string.
This is a good practical example for the less experienced that just because it’s written in rust doesn’t mean it’s magically more secure. Who’s gonna write up the CVE?
A priori you might think so. I'm just reporting my experience.
To be clear - if I see any of my clubmates out on the roads, which happens a lot, we'll often briefly chat! Acquaintances are nice to have too, for sure. But we aren't inviting each other to our barbeques.
This bug makes these chips practically useless for high-impedance inputs such as touch sensors and multi-drop buses. Basically anything with an impedance above 8,2 kΩ. This is really a problem.
shrug and for those, limited, situations you could insert a buffer chip between signal and Mcu, or add an RP2040 chip, or just use an RP2040. These things are so dirt cheap that even the workarounds aren’t expensive.
And for the vast majority of cases the chip is fine, I2C is fine, the ADC is fine (despite what hackaday says), the SPI is fine, GPIO output is fine, GPIO input-with-pull-up is fine, GPIO input-with-pull-down needs a stronger pull than usual, 4K7 works great.
The use-cases where you have problems are being blown way out of proportion IMHO. All chips have errata, there are workarounds to most of this one’s issues, and there are alternate solutions for the few cases where it can’t be worked around. This is normal.
I’d also point out that there’s a guy on the RPi pico forum who’s successfully linked a touch-sensor input to the RP2350 without problems…
Agreed with the sentiment that this isn't that bad. As far as chip errata go, it's definitely unusually broad impact. So yeah, it's an abnormally bad bug. But for your average Pi Pico user, they still will never notice. The only possible thing I could imagine your average micropython tinkerer needs to know is "use pullups not pulldowns with buttons on the Pi Pico 2". Everything the entry level hobbyist is likely to encounter is a sufficiently strong drive to avoid the issue. Capacitive touch buttons might not work without external components, but I don't know.
Bigger picture, RPi is doing their third ever chip fab. The errata (silicon bug) list for the prior RP2040 is shorter than some I've seen from companies five times their age.[1] This issue isn't a logic error and wasn't going to be found by digital simulation. This is analog weirdness. Their documentation, including of errata, is among the best I (moderately experienced hobbyist) have ever encountered for a microcontroller. RPi is doing an excellent job and this is a but a hiccup. Maybe it's concerning for industrial customers, but as a hobbyist I'm still excited for my Pico 2 to arrive.
[1] Favorite errata warstory: Radio chip will lock up and need to be power cycled if a received packet has a particular corrupt length field, one bit flip away from one we used. Official solution: don't allow packet corruption. Turns out radios don't work like that.
If they hover around 2V, the means no mosfet gates too without an additional pull up/down? Seems like an issue that couldn’t possibly have made it past the first QC test.
If I assign the pin to input like I want to leave a gate floating or not effect it’s pull-up /pull-down or I don’t get to chose because I am in an unprogrammed or reset state… then what happens?
