The PCI bus has nothing to do with the instruction set. Usually it is just a block a designer can add to a chip, and connect to an internal bus like AXI, give or take a few other adjustments on the chip.
You can have PCIe buses without proper CPUs, even: it's quite common to find them paired with FPGAs.
For instance, Rasberry Pis have had a PCI bus for a few generations now, at first used for USB3. The Pi 5 breaks it out on a dedicated connector, making it easy to plug external devices: https://raspberrytips.com/pcie-raspberry-pi5/ (random link).
Of course, discrete GPUs are less ideal from a power efficiency perspective (duplicated memory controller, buses, and power circuits), so they wouldn't fit the Steam Deck. But write a big enough check, and I'm sure that AMD or Intel would be willing to share their iGPU designs. NVidia also makes Tegras.
If you want to be pedantic, the original (and revised) law are definitely about cost. The original formulation was that the number of features (i.e. transistors) on an integrated circuit doubled every two years for the best-priced chips (smallest cost per feature).
> The complexity for minimum component costs has increased at a rate of roughly a factor of two per year (see graph on next page).
And it is formulated in a section aptly titled "Costs and curves". This law has always been an economic law first, some kind of roadmap for fans to follow. But that roadmap drove almost-exponential investment costs as well.
I concede that density still rises, especially if you count " advanced packaging". But the densest and most recent is not the cheapest anymore.
> or even putting thermal mass around the existing oscillator
I was thinking along these lines as well. Put a metal block on the CPU and oscillator for thermal mass (not sure if separate blocks would be better).
Ideally, with a large enough thermal capacity, the block should reach an average temperature and remain there.
Inertia is also good even if the temperature is not constant: clock drift can be measured and compensated. If the temperature rises slowly, the clock speed will increase slowly: the rate can be measured and compensated for. Jitter is the issue here, and thermal inertia should dampen it.
It may also be worth preventing convection from happening on the board. Putting the Pi in a wool sock may not be the best idea depending on its temperature, but an electrically insulating thermal conductor (or an electrical insulation layer + steel wool may do it).
Heatsinks may also be counter-productive (if they have a small thermal capacity), as their temperature depends on room temperature, which changes during the day.
It may have happened. There are already many users saying their "created in" locations were incorrect. Thus the rest of my comment: trust is binary. We can either be 100% certain the data is correct, or we must assume it is never correct.
As far as I know, these don't have programmable IOs (PIO), though, which may make it more difficult if you want fine timing control of your GPIO, such as "bit-banging" (not really with PIO) arbitrary protocols. And they have much lower power consumption.
Fair point though, the price difference isn't much, an the Pi Zero are much more capable.
I was going to suggest solvespace. It is very barebones, but was much easier to use than FreeCad for me. It also has constraints in 3D space, which I use a lot: https://solvespace.com/index.pl
This looks very handy, thank you for working on this and making it open source.
I did submit a feature request for vi keybindings; though I could look into contributing this myself if I find a bit of spare time.
The other thing that surprised me was the size of the binaries: 90MB for a TUI tool (x64 Linux)? I wonder what the bulk of that is? Is there an issue with LTO? An other commenter noticed as well.
It also looks like you are building against a relatively recent glibc (2.34), which limits compatibility with older systems. Building against an older glibc can be hard to do, so I am not faulting you here, and you do provide a musl fallback, which is appreciated (mandatory notice that the musl allocator can dramatically degrade the performance of rust programs, just in case you were not aware of this).
A few more ideas for improvements (you probably already have your own laundry list):
- Mouse support?
- Seeing that you do have graphs, it would be fun to see a scatter plot as well as a distribution plot under statistics in the "Row Groups" tab (though you probably pull these from the metadata, so that would require further processing, which may be out of scope).
