readmodifywrite

The guy owns a rocket company and still hasn't even been to LEO. Katy Perry has spent more time in space than Elon.

Mars isn't happening, at least not on his watch.

They are not. Turbine engines require much higher quality manufacturing and tolerances and operate at much higher speeds and pressures. There is more to it than the perceived number of moving parts.

If you were using TCP, then this is absolutely normal and expected behavior. It is a stream protocol, not packet/message based.

Finally, a use case for blockchain!

Having used Unifi for 10+ years, they really have improved their firmware/software by quite a lot.

One engineer's esoteric is another's daily driver. All 3 of those options are borderline mandatory in embedded firmware development.

Katee Sackhoff did an interview with Ron Moore on her podcast, and one of the topics they discussed was how they would write the "technobabble" in Star Trek (and BSG). Moore said they would write the script and just say things like "they tech the tech with the tech until it techs" and then fill in the actual technobabble words later!

Gibson is such a unique sci-fi author because his fundamental interest is fashion (he’s said this himself)

Check out Pattern Recognition if you're interested in following him down this line of inquiry!

My go to analogy is that conservatives will underfund the assembly of a car, deliver a car that only has two wheels that are both the wrong size, and then say "See? Cars will never work!"

I think it is amazing that in a country as "exceptional" as the US, the answer to "Why can't we provide affordable and accessible healthcare to everyone?" is "We are going deport liberal scum like you".

The PPK2 is one of the best pieces of kit I have and it'd be worth it at 5x the price.

There's an unofficial Python library as well. I have power consumption tests running as part of my automated firmware test suite.

It switches the detection range, but not the actual power supply. You can ramp from <5 uA up to 500 mA and back all you want. I haven't noticed any glitching on the actual supply.

Schematics: https://www.nordicsemi.com/Products/Development-hardware/Pow...

Not to mention the TX power ramps up in microseconds to quite a lot more than 80 mA.

If your supply can't handle the modem sleep mode it definitely isn't going to transmit reliably either.

Also, they are options. Basic pub/sub usage doesn't need any of them, though some are pretty nice to have.

The lack of status bits on the auto-cal is really unfortunate.

Turning it off during a UART transaction definitely "fixes" it.

I'm somewhat tempted to do the manual calibration the HSI instead.

Yup, it's the Hakko Omnivise. They might seem a little pricey, but they are worth every penny.

It really seems like it has to be something like that. The problem is there is no detail in the docs and no status bits in the chip. There's no way to know when the auto-cal runs.

One of the several things I did to eliminate the problem was to disable the auto-cal during a UART reception (the STM32 is the bus master so it knows when it will be receiving) and re-enable it when it is finished. It absolutely confirmed that is the glitch, but I don't think I'll ever get a true why unless an ST engineer wants to chime in!

This is a good resource, however, it didn't apply in my situation because it describes the manual calibration process, not the auto-cal (which the F0 probably doesn't even have).

I still haven't come across anything that explains in detail how the auto-cal works and precautions one needs to take when it is running. The reference manual section is something like one paragraph and can be summarized as: "You can turn this on and it will calibrate your clock. You can also turn it off."

If I had to guess, it probably does something similar to the manual process, but just in the MCU logic. It's the lack of detail that got me: I basically ran out of things to try on the UART itself and started looking around at other parts of the chip to see what could at least be indirectly related.

My guess is that the receiver clock glitches in some way when the MSI auto calibration runs, but it never showed up on the transmitter (and the device on the other side of the connection has never had a reception issue).

I ended up disabling the auto cal feature during a UART reception and then turning it back on when the reception is done.

SPI is definitely better as far as clocking, but MCU support as a SPI receiver is sometimes a lot less convenient to deal with.

A lot of UARTs have a synchronous mode which adds a dedicated clock signal - I've used that before out to a couple MHz.

In this application though, I'm only running 1 MHz so I really didn't think I should need a separate clock (and, it turns out, still don't).

The GIL is not there to prevent data corruption on shared objects - it only protects the interpreter's internal state. The fact that sometimes you can get away with it is an accident of the GIL's implementation, not a feature anyone should rely on. It also means that you cannot rely on that behavior not to change on a successive versions of CPython.

The only safe way to do shared state between threads in CPython is locks/mutexes/message passing/etc. Even things like a simple addition to an integer are absolutely not made thread safe by the GIL.

There are TNG episodes that specifically deal with that, and the problems it causes. I think ENT had a few as well, instances which led them to the creation of the Prime Directive.

That's kind of ironic, considering they don't provide a scheduled reboot feature for their own gear (which often needs it for IoT usage).

The CPU implementation is done by Qualcomm, Apple, and the like. The CPU design is done by ARM, predominantly in the UK. The fact that Softbank (Japan) owns ARM has no bearing on where and who is doing the actual technical work.

I love that the example uses the exact same indentation format that Python already requires.

The issue here is opportunity cost. It has nothing to do with difficulty. The time spent porting to Python 3 has to provide a better return on investment than the same time spent doing something else. For a lot of people for a very long time, continuing to now 12 years later, that opportunity cost was such that porting to Python 3 was always a lower priority.

Languages need to serve their users, not the other way around. A lot of us really didn't care about minor syntax tweaks and we didn't need a lot of the new features. What we needed was better performance and a better deployment story, and we have received neither.

It sounds like you had a project that really benefited from updating, and that's great! Some of mine have as well.

It is not universally applicable, however. There's a lot of old code that, as I said before, is just fine. Adding a 100 line feature in the old version is easier than porting the whole 10,000 lines over. Just ask COBOL programmers what they're up to right now - it's not porting to a modern environment, it's maintaining the old one.

The other major issue is that Python 3 really didn't fix the major issues with Python that persist to this day. Atrocious byte code performance, a really awful deployment story, and perennial favorite: the GIL. Had just one of these been tackled in Python 3, the migration probably would've happened a lot faster. You might not care about those problems or they may not be problems for you, but they are for some of us and they persist to this day.

I will concede that on the whole, Python 3 is a better Python. But it's not 2x or 3x better. It's 10-20% better, and that's a tough sell to a busy engineer who has better things to do. I can't justify spending time on anything that is a mere 10% improvement when I have a pile of 2x improvements to work on.

It is a completely different language - it is syntax incompatible. Human languages are a very poor comparison to computer languages.

It's just a tough sell to manually update a huge pile of code that works just fine as-is. No new features will be introduced. No bugs fixed, while some new ones may pop up. There's a lot of manual work in porting, the automated tools only cover the basics. Your downstream customers receive very little benefit for this effort, which makes it very hard to justify spending the engineering resources on it.

Do you have a link to the paper? I'd love to read it.

The issue there is desalinating the water in an environmentally responsible way. It's hugely energy intensive.

From my experience, and this is compared with AVR and most ARM parts I've worked with.

1) Generally poor documentation. Non-existent at the register level - you are entirely at the mercy of the SDK and what other people have reverse engineered.

2) Crashes on unaligned pointer access. This is something that ARM generally handles with ease (though there are exceptions). Porting code from ARM or 8 bit machines to the ESP8266 can take a fair amount of effort in tracking down all of the unaligned access exceptions that come up. It's extremely frustrating.

3) To that point, the SPI flash access is also beholden to 32 bit alignment. That really complicates things if you port code that relied on a typical SPI flash's ability to access at a 1 byte granularity.

4) Poor compiler support. I think the latest GCC they support is 5.something. It requires a custom backend so it is vendor maintained. Contrast with ARM support in GCC which is generally outstanding.

5) No hardware debug support. You can run GDB over a serial port, but that's no where near as powerful as having an actual JTAG/SWD port.

6) The program memory architecture is complex and difficult to use (poor documentation is part of the issue here). There's no on-chip flash - code streams from a SPI flash into a RAM cache. Some code has to run out of RAM and must be placed by the linker as such.

All that being said - the chip works. The Wifi is excellent (I run dozens of these at a time, they are more reliable than my Unifi routers they connect to). For a $2 FCC certified module it's unbeatable. I have really come around to like this part in spite of its many flaws - it was built to do one thing very well at a price point no one else could touch - and by and large it succeeded.

Over-engineering is indeed fun - that was part of the point of the project, it was (and remains) a labor of love.

Modularity was actually a design consideration I really struggled with, but at the end of the day, I realized I didn't want to do just another Arduino clone where you put the whole thing together yourself. I designed Chromatron under the assumption that you'd eventually end up with a lot of them, in which case the Wifi and live coding are really useful features - I wanted and all-in-one solution. But for most people who only need 1 or 2 projects, it's overkill. I think that's part of the reason it didn't sell that well.