Orange Pi 5, "plus" version also has 2gen 1-lane pci-e (M.2 wifi), and 3gen 4-lane pci-e (M.2 SSD) and 2x2.5Gbit ethernet.
8nm, pretty power efficient. I've measured it to run at 0.7A@5V idle and 1.2A@5V with all 8 cores loaded with md5sum /dev/zero; iirc it had 1 ethernet connected, no other periphery. Running on Armbian.
How is the software support? That’s the main thing keeping me on rPi. I tried Pine64 and it was terrible. Never could get my PineBook Pro to boot reliably.
There are always little things. As far as I know, desktop works pretty well and there are people running PS2 emulation on it, which has always been super heavy.
arm64 has come a long way for that use case.
It's been solid as the VM host so far. I wrote an Armbian SD card and it just worked. Once a VM is booted though, many things become irrelevant outside of arm64 support.
I haven't tried again since February, so there's a decent chance my issues are fixed, but ZFS wouldn't build and VLAN support was disabled for the NIC. Not blockers, but it did make me rethink some ideas I had.
You'd need to spend at least 110kWh to convert CO2 back to propane, maybe much more. No matter what you do, LPG -> CO2 -> LPG cycle has to be energy-negative.
MMU allows linux to provide a "flat" memory space to each userspace process. This memory space is assembled from 4KB pages that can be randomly dispersed throughout physical memory. Say, you want to malloc() 1MB of memory on a system that's been up for some time. Physical memory may not have a fitting continuos chunk of memory, but virtual memory of a newly created process will always have one, provided that there is enough free pages available.
In other words without MMU all programs share the same memory space, and if it get fragmented, generally you'd have to reboot. With MMU fragmentation can still be an issue, but it's greatly reduced, since each process has its own memory map. And if memory of the process gets framgmented, you can just restart it. If runtime supports object compaction/relocation, then fragmentation may be not an issue at all.
Re access to memory locations -- mostly any direct access to instruction or data memory in userspace program automatically goes through MMU remapping.
Thanks. I realized that there are several types of MMU. I was thinking of the simple MMU (on 32bit MCU) that limit memory access. Not the one that provides the illusion of virtual addressing.
I've yet to see a voltage regulator IC with built-in caps. DC-DC modules sure, but author argues that this kind of info (module / ic) should be present in schematics. BTW, some linear regulators can't handle ceramic and low-ESR capacitors at output, and may be better with none if that's the choise.
I hate to maybe be proving his point by showing that I'm not into the EE field and thinking of a board mounted DCDC-converter as a voltage regulator (which it is but not what you usually call it in english?)
I would still argue that logic IC have alot of internal pull ups. Or that eg. "Reset sequence of digital component is wrong" is a bad whiteboard question.
I believe that without qualification "linear regulator" could be just anything that regulate voltage. Usually you can easily tell from schematics around it if it's some switching IC, an LDO or a module. And if you have layout or 3d render of the board it'd be almost certain.
Otherwise the person may just ask: "where are caps, or is this thing a module or what?"
In my experience, "linear regulator" refers specifically to voltage regulators which drop from a high voltage to a lower voltage by burning all of the power in between (e.g. the venerable 7805).
They're useful if the voltage drop isn't too large and/or if you need a particularly stable output voltage; contrast them with switching regulators, which are more efficient but have some amount of output ripple.
One design that I worked on used a switching regulator to generate 5V, then linear regulators to generate something like 3.7V and 2.9V for various sensitive analog circuits.
No, switchers aren't “linear.” And on a schematic the regulator isn't going to be a box labeled “regulator”! It will have a part number, probably a familiar one.
ICs with multiple power domains have a boot sequence that must be followed or the IC isn't in the proper state. Many interview questions fall into the "assumed assumptions" category. Simply saying, "lets reset to a known good state and modify one variable at time disqualifies many candidates". Because we don't teach science like we should. We should be teaching the scientific method before we teach the three Rs.
Um, I'm actually worried that I or other person will be punished for something that they didn't do. In the third world country I live in you'd have to accuse someone and then bribe the judge. Turns out that in US one don't even have to bribe anyone, mob will lynch them. You just need to accuse them of right things; e.g. stealing and homicide won't do. Is that the progress that humanity has made?
Let's see:
- judged by angry mob -- yes,
- no ability to defend oneself -- yes,
- killed -- no (though seeing polarization and level of anger here it's possible that he'll be eventually physically assulted),
- person demolished, life ruined -- yes (Stallman got removed from the org he created, got fired from his work. Another poster here written that his friend got accused, defended in court with hard evidence, life is still ruined).
Comparison with lynching seems fair to me.
All of this got me thinking about creating, you know, accepting tech community where everyone is free to express their own opinions. I'm personally fine with my code being called shit and me being called dumbass for a good measure, just tell me what you really think and we'll sort things out faster instead sugar-coating stuff to not hurt my ego.
Lynching has a specific context in the United States; it has the history and connotation of racist terrorism.
No one dislikes Stallman on the basis of the color of his skin, and no one is murdering him. The use is a grossly inappropriate metaphor that diminishes the real meaning of the word.
Well racism connotations permeat everything in US, it's overheated/taboo topic there. Not so much in the rest of the world, see two top dictionary definitions from google:
To punish (a person) without legal process or authority, especially by hanging, for a perceived offense or as an act of bigotry.
(Law) (tr) (of a mob) to punish (a person) for some supposed offence by hanging without a trial.
Nothing about racism here. The only thing that doesn't apply to Stallman is that he has not been hanged. That's quite important one. Though words are sometimes used not in their literary meaning (like "I'm killing it" -- well hopefully not).
BTW from what I've gathered this entire thing happened because Stallman was pedantic and has written something along "let's be precise with words, I think what happened was not rape, but statuatory rape because of such and such".
I don't have US cultural background and it looks insane to me, about level of witch hunts or lynch mobs. Like one accusation of peadophilia is enough to ruin a life, and lives of others that dare to voice opinions counter to that. Same thing with rape. It doesn't matter if it happened or not. Court of law? Nah, why? Clearly if they are accused then they are guilty.
Absolutely this. The same price and the Bluepill has much more powerfull CPU.
The problem is HAL support. Some periphery is supported, other is not. ADC and DMAs for UARTs were merged just recently. Stuff like SPI / I2C slave modes is missing, I think HAL interface is not fleshed out yet. Stuff like usb stack would probably take a lot time to complete.
How does it work to call C for the missing peripherals?
For instance using the exiting vendors libraries. The book in question does not seem to cover this, unfortunately.
I think for a long time we will have to accept that Rust and C are going to co-exist on these devices. So that story should be workable.
My embedded code tends to have a strong split between application logic (in platform-independent, data-driven functional code, with automated tests) and underlying hardware-dependent "app host" (as little custom code as possible), with a data-based interface.
I would be quite happy doing C for the hardware layer and Rust for the application logic layer.
I'm not sure how well it would work, the rust embedded HAL crates like to be in control of all peripherals in order to give nice guarantees of things being properly initialised.
Calling C would also have to touch the same structures which would, if nothing else, change the state of some peripherals to something that will break the rust guarantees.
I haven't tried it, but it should be doable. A lot of linux-based rust libs wrap C libs and link to them, or compile their own embedded version during build. Same thing here too, though there could be some problems regarding what C compiler is used and where it expects to find its libs.
