https://docs.microsoft.com/en-us/windows/iot-core/tutorials/...
The factory can already flash the pi firmware. What does UEFI solve here?
The Pi4 is powerful enough to run web browsers comfortably, which was a problem on the original Pi. Office programs run no sweat. You can even do light development work.
Even if that would mean I have to "port" the engine to linux/X86. Until now I just had windows/X86 and linux/ARM!
My m1 mac says hi! :)
Now I didn't even mention the App store tie in and how you need to sign the binaries on Apple hardware and how they poach 30%, but you get the picture.
I’f you’re lucky enough to live in a country with consumer protection laws (NZ is one), Apple will fix if for you for 3-4 years. So you pay the fortune you mention and then a bit more to cover this feature.
OpenGL (ES) 3 with VAO was the last feature that really moved any interesting goalpost (to reuse that phrasing since we have a tree structured comment field to move those around) for games.
Most new protocols are just job security.
Edit: Also calling something that just released in hardware (OpenGL ES 3) legacy is kinda weird.
Maybe wait a decade or two?
Performance with the low level APIs are not something that competes with OpenGLs higher level API, they are complementary; eventually there will be OpenGL drivers written in Vulkan!
That said, I have yet to meet anyone that can give me a practial example that affects gameplay where Vulkan (or Metal/DX12) makes a difference!
Also last but not least fragmentation is bad, I rather support OpenGL (ES) 3 on all platforms than port to those 3 new APIs.
edit: the timer is there probably for flamewar prevention. Maybe for general discussion quality too.
The biggest problem with OpenGL is the state. It severely affects CPU usage and limits parallelism options. The second problem is poor handling of buffers.
It hardly matters, anyway. Vulkan, D3D 12 and Metal are very similar and almost always used indirectly through a game engine that can take advantage of them.
Unity and Unreal are so bad. I mean compile for 30 minutes? To use them is to have technical debt way beyond what is healthy.
So why can't you make OpenGL stateless? It seems to me multithreading is really bad on the new APIs too, you'll have to trash memory with a bunch of buffers that then gets submitted by one thread causing motion to photon latency!
RdR2 had like 10 frames of lag! Completely unplayable.
I prefer direct/forward rendering one one thread and make the graphics simpler instead. Graphical fidelity is not important to make a fun game, just look at Nintendo.
For the vast majority of games that compete on graphics, you need to use modern APIs to take advantage of modern GPUs.
http://talk.binarytask.com/task?id=579711216639635462
My server is the first MMO system to handle 10.000 concurrent action players on one machine: http://fuse.rupy.se/about.html
You have to pick your battles.
How will you ever get those 8 seconds back??
8 seconds x 1 million compiles = 92 days!
When you code action games you want to iterate quickly to make the controls and physics as good as possible.
I made a .dll/.so hot-deploy system to be able to work effectively, so I can hot-deploy the game in <1 second on the Raspberry but then on the PC I do it in 100 microseconds!
It just depends on how heavy-duty what you're trying to do is. Scripting in general runs fine on my ARM SBCs. The real trouble is if you've got something that you need to recompile every time you make a change and you don't have a cache set up.
Now touch screen keyboards are a different problem.
You need a keyboard and mouse to be productive, case closed!
Edit: see the toxic high karma downers even got to this one!
I bet you the high karma people click on your profile to see how much karma you have before they push you down.
Eventually the HN database will leak, it's inevitable, I'll make sure to grab a copy then.
I'm barking up the wrong tree, am I? sorry for the misunderstanding
I guess I did write the code from scratch, but it’s just Python, nothing fancy.
https://community.twistedfields.com/t/introducing-acorn-a-pr...
Where is the battery? Lead-acid or Lithium?
What does this even do, I see no arms, cutters or anything?
No battery. It runs directly off of solar power with a supercapacitor bank to provide peak currents. Power draw while driving walking speed on level ground is 20-30 watts with the latest drive system (not shown in the video). Solar panels are 8 100 watt panels.
The project is a work in progress. We just open sourced everything and wanted to start building a community of interested followers who would like to see our progress and share ideas. I do mention this in the blog post but I realized afterwards that understandably a lot of people just watch the video and don’t get the full picture. But we’re adding a vision system now and tools will come in the future. We’re solidifying the base vehicle right now which is what you saw in the video.
Feel free to ask me here or join our community at the first link I shared if you have any more questions!
If you code Python then you really have missunderstood what tools are available.
My recommendations: C or Java.
You need a battery if you want to be able to predict work, we had a whole month of cloudy weather last year!
I missed the video, I'll check it now.
Im embedded/Iot none of that matters, but if we are talking about work, using PI makes no sence when compared to even an old laptop form ebay.
The NUC is an ok alternative with the (for modern unavailable) Streacom NCX cases.
I'll use the Raspberry when the KWh is $1, until them I'm trying to move to Atom.
I have one of these Flirc cases: https://www.adafruit.com/product/4553. It looks fairly nice, acts as a heat sink, so my Pi 4 chugs along fine without having to throttle even when using all cores.
Look here to understand: https://streacom.com/wp-content/uploads/nc1-wy-025-000-b.jpg
THAT is good design, comparatively everything released for the Raspberry looks like turds.
The Flirc in particular has 2 major flaws: It has a plastic lid on the top?! And it has the logo, things that have to put their name on their product always have bad design. The design should be the logo!
The main goal of their foundation is to support education, not to satisfy a "pro" market.
Just because people use them as tools doesn't mean they change the charter of their non-profit foundation
https://en.wikipedia.org/wiki/Raspberry_Pi_Foundation
I'd say the other way around: the "pro" people should go find another board to use, of which there are many.
I interviewed in person at a leading industrial automation company over five years ago. They were looking for someone to work on ARM stuff and I was (naively) proud of the work I'd done with the original Raspberry Pi in school. The hiring manager had never even heard of the Pi...
Industrial IoT does use Pi's a fair bit, but this is IMO a misuse (I'm guilty of it too) and in the long term can be a disservice. The Pi is a great platform for a go-to-market product, but they have many shortcomings that for most use-cases in industry are showstoppers (most notably, Pi's will often fail without warning, or their "disk" will become corrupt). More expensive industrial products are out there and typically are more robust, and designed in a way that they can be more seamlessly integrated to a product - once the upfront costs are paid (both in development and dollars).
What really needs to happen is other manufacturers making the development on their hardware more straightforwards. What the Pi foundation has done is shown that companies and developers want to just be able to run a widely available and minimal linux distribution and not have to muck about with proprietary and poorly documented SDK's behind closed doors.
You get what you pay for. But this is beating a tired horse that I'm skeptical was ever true to begin with. Are the people with SD card corruption just using crap cards to begin with? I've used a pi4 and rock64 and neither had any disk corruption. Plus you can boot on USB today. And fail without warning? Is that really a thing? No sensor saying there is a heat problem?
You can definitely reach for an industrial product with similar specs. But just keep in mind that niche products may have even less market testing than a Pi. There is some truly crap hardware and software out there that people suffer with simply because it's the only player in the niche.
The SD card is probably crap like you say but it can be formatted and passed read/write verification testing when connected to a PC which is a bit weird.
It's much easier for Raspi foundation to release a more industrialized version than it is for another manufacturer to create this support and community. They could still operate on their non-profit mission with the profit.
Industrial microcontroller and embedded companies do need to also make their software and docs better. There seems to be some modernization but it's slow.
Ssssh. That's blasphemy here.
Any other ARM platform mentioned here gets downvoted and shouted down with "But it's not $40!". Let them play with their toys and leave them alone.
https://en.wikipedia.org/wiki/ThreadX
and for the uninitiated, ThreadX RTOS is not the same as Intel's ME. ThreadX is a critical dependency to run any OS on PI. without Intel ME, you can still run an OS.
this virtualization model is still largely why Pi performance is complete garbage compared to pine64, banana pi, beagle, and others.
What you've written above is not even remotely true. You've been corrected on this before, you ought to stop spreading kooky misinformation.
That doesn't sound like virtualization to me. Do have more info?
First off ThreadX on the video core does not run as a hypervisor.
It also does not impede perf on the ARM core.
Additionally, yes, Intel ME is required to run anything on Intel cores. Without it the main cores don't start.
https://www.csoonline.com/article/3220476/researchers-say-no...
To explain this again, it technically is a guest. The GPU cores run a real time operating system called ThreadX. This operating system is closed source and rules the system without the open source Linux Kernel being aware of it.
When the Raspberry Pi starts booting the CPU is completely disconnected (technically in reset state) and the GPU is the one that starts the system. You can have a look at the `/boot` folder and you will see some of the binary blobs used by the GPU to both start the CPU and run its own ThreadX OS (bootcode.bin and start.elf). You can learn more details about the boot process here.
After the GPU has the CPU load the Linux Kernel, it doesn’t just stay there waiting to act as a graphics-processing-unit. The GPU is still in charge.
IME is a different beast entirely.
The document you linked refers to a more technical one that explains they don't disable the ME until after the main OS is booted, because...
"The disappointing fact is that on modern computers, it is impossible to completely disable ME. This is primarily due to the fact that this technology is responsible for initialization, power management, and launch of the main processor."
http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
So, it is serving the same role as the Rpi VideoCore.
Also, interestingly you can swap out the terms on your paragraph and it's still true
> When an Intel CPU starts booting the CPU is completely disconnected (technically in reset state) and the ME is the one that starts the system. You can have a look at the boot flash partitions and you will see some of the binary blobs used by the ME to both start the CPU and run its own ThreadX OS.
Although albeit, on newer MEs they switched from ThreadX to Minix. The ME is very very very similar.
"Technically" it's not a guest relationship, the ARM cores start in EL3 (above hypervisor mode in secure mode).
And none of this show any perf costs to having a management core (except maybe some minimal bandwidth pressure?)
> The GPU is still in charge
Can you explain in specific, concrete terms what this means?
For example: I've read that the undervoltage monitoring happens on the ThreadX process, and that it throttles the ARM cores when low voltage is detected. The vcgencmd has more info on this, including the following bit field returned by vcgencmd get_throttled:
Bit Hex value Meaning
0 1 Under-voltage detected
1 2 Arm frequency capped
2 4 Currently throttled
3 8 Soft temperature limit active
16 10000 Under-voltage has occurred
17 20000 Arm frequency capping has occurred
18 40000 Throttling has occurred
19 80000 Soft temperature limit has occurred
https://igor-blue.github.io/2021/02/04/secure-boot.html#earl...