Shorter and more secure alternative with elliptic curve zero-knowledge proof - for example with a 160bit curve you could have a 240bit (30 byte) licence key comprised of a 160bit field element and an 80bit hash.
Making test points for all your testable functions and aligning them to a stripboard really simplified making a testing jig. You can solder some pogo pins to the strip board and just press each board to your jig to program/test it.
Also, I've found renumbering passives to keep the same values in contiguous groups to simplify hand prototyping. You end up having dozens of 0.1uF for example and it's nice to knock them all out instead of switching between different components
For hand assembly I usually break out all of the components into little iFixIt project trays and print out labels that correspond to the board, but when there are a bunch of components with the same value, I just put the value on the label instead, and use highlighters on to point them out on printouts so I don't spend forever hunting where to place them. Then, I just go one by one down each spot in each tray until I've populated a board, then I throw it in the oven and start on the next.
When numbering components, my favorite approach is to group designators by subcircuit. That means one circuit (say, an op-amp circuit) might have U41, R41-R46, C41-C43, and Q41; the next circuit would have U51-U52, R51-54, C51-59, and L51. You get the idea. That way, not only is PCB to schematic lookup made easy (and I find that's the one most in need of optimization), but on a good layout, a subcircuit will be laid out together, so you get PCB designator locality for free! The exception to this is decoupling capacitors; if I'm assembling by hand, I'll usually put them at the end of the list (so, continuing my previous example, they might be C60-C81, if there were only five subcircuits). I only bother with this for hand assembly, though; robots don't care.
We do things a bit like that - we break things up in the schematic by page (between one and a couple of sub-circuits per page), and then the designator is page number plus a sequential ID. So you might have C405 (4th cap on page 4) or C847, etc.
We don’t print designators on silkscreen, so it’s not really a problem with the length (e.g when you get over 10 pages and have a five or more digit long designator. With a page that is subclassed you might have one like R1208B for example!)
The algorithm for the first example reads just like an implementation of a SAT solver. Set a variable, propogate clauses, backtrack on conflict (learn new 'rule' from conflict).
Maybe add a definition of 'risk' in the quick summary. It tends to man different things to different people, and linking back to a definition (e.g. the effect of uncertainty on objectives) helps keep discussions on track.
the same way that if you lift for 3 months, it achieves nothing.
I'm probably missing the point - but that first 3 months of training is where you make the fastest growth and can double the weight you lift (from untrained to novice). Sure - you aren't going to compete at a world level after 3 months, but it doesn't seem right to describe it as 'nothing'.
Agreed. Though re-reading it, I think the point may have been more about quitting after 3 months and not so much that you don't gain anything the first 3 months.
> 5/ if I had only worked on a startup for a year, I would've gotten nowhere, the same way that if you lift for 3 months, it achieves nothing. Everything good in life comes from perseverance, but at the beginning, you're just like "I need to be somebody!!!"
It may be more about persevering beyond that arbitrary time limit and trying to get to a certain real goal instead... maybe.
For some of the unsupported targets there is the Rust->C compiler. Haven't used it myself but I've seen that, for example, the ESP32/ESP8266/Xtensa is supported by it.
That's true, but the issue with it as a real development option is that its job was to bootstrap the compiler, and so it implements Rust 1.19 (I believe...), and nothing further. So you're missing out on a lot of useful stuff.
From memory WeChat verification only allows one verification every few months (and only if your account is old enough). In theory you can get a hostel employee to verify you, but they have usually used up their verification for that quarter.
A useful example project would be an FFT or OFDM accelerator for a microcontroller. Most microcontrollers really struggle with FFT so it is an example where a small uC and a small FPGA can be cheaper than a large uC. Sliding window FFT is going to be another good example where the FPGA option is competitive.
Sometimes 1.1.1.1 is used as a testing value, and can get blocked for reasons. CloudFlare is getting a huge amount of spam IP traffic to 1.1.1.1 from misconfigured equipment, it wouldn't be too surprising if some upstreams have firewalled valid IPs.
When cloudflare resolves addresses, the DNS request is not coming from 1.1.1.1, it's coming from the IP address of the server actually making the request. You can confirm this by looking at the results of a VPN DNS leak test [0] and seeing the IPs being used to resolve the addresses do come from cloudflare, but are not 1.1.1.1
