- thats true on many systems... nothing special about 0x0 other than NULL happens to be defined as 0 in most toolchains an some functions use NULL to report an error.
- The technical definition of opoerating system is the software that manages the resources of the computer, i.e. RAM, storage, processor time, etc (Typically known as the Kernel).
This usage is more "User Interface" or "shell".
- Never. Do. This...
I was involved in a product with a large codebase structured like this and it was a maintainability nightmare with no upsides. Multiple attempts were made to move away from this to no avail.
Consider that the code has terrible readability due to no syntax-sugar, the compiler cannot see through the pointers to optimise anything, tooling has no clue what to do with it. On top of that, the syntax is odd and requires any newbies to effectively understand how a c++ compiler works under-the-hood to get anything out of it.
On top of those points, the dubious benefits of OOP make doing this a quick way to kill long-term maintainability of your project.
For the devs who come after you, dont try to turn C into a poor-mans C++. If you really want to, please just use C++.
- maybe we could implement a UTCP->REST bridge for another unnecessary abstraction layer..
/s
- there are orders of magnitudes more embedded processor sales than desktop CPUs.... So the answer really is... lots of people will want it.
- K1 (racing) kayaks are unstable and very narrow, most other types are fairly stable tho.
- What they mean is UI, not OS.
The purpose of an OS is to manage the resources of the computer, CPU, RAM, devices, etc. This is simply a UI generated by an NN.
- Stop with the alternatives... just use make for this task.
Seriously. :o)
- There is a long history of CPUs tailored to specific languages:
- Lisp/lispm
- Ada/iAPX
- C/ARM
- Java/Jazelle
Most don't really take off or go in different directions as the language goes out of fashion.
- Correct me if I'm wrong but the next LTS will be 26.04 which would give them 6 months to get maturity and stability... For such an important set of utilities, that seems unlikely.
- Risk.
Contractors get paid for the time they're not in work.
I've been on both sides and have always been lucky in that I've gone from contract to contract but that is certainly not guaranteed.
- Mach was never based on BSD, it replaced it. Mach is the descendant of the Accent and Aleph kernels. BSD came into the frame for the userland tools.
"Mach was developed as a replacement for the kernel in the BSD version of Unix," (https://en.wikipedia.org/wiki/Mach_(kernel))
Interestingly, MkLinux was the same type of project but for Linux instead of BSD (i.e. Linux userland with Mach kernel).
- The correct phrase is "mechanical sympathy" but it means effectively the same. Its relatively well known in software optimisation and means tailoring the design of the software to match the characteristics of the hardware.
- "Pure" JS exists as a concept, not a project.
Having a tiny standard library is also a good thing, not a bad one... I'm not saying its an ideal API but in general, smaller==better (within reason).
- Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other.
More abstraction != easier to use.
- There are similar devices (i.e. SiLabs) that allow multi-protocol use with the radio (I would expect Nordic to have a similar feature set), tho yes, you're right the resource issue would be a major limitation.
- vertical speed likely relied on the barometer rather than the accelerometer for exactly that reason.
- static allocation is the recommended mechanism in embedded code for reliability reasons, you have thought about you worst-case allocation and accounted for it... right? Also fragmentation and dynamic behaviour are bad things when your code has to run "forever".
- packets are sequenced, integrity checked and encrypted to prevent replay attacks so unlikely to be a simple "send packet again" issue. More likely a key debounce issue or driver issue.
- architecture over implementation (for details).
- shyness != introversion
- That was my point.
- "Operating Systems" for microcontrollers such as this are frequently just schedulers as the Application typically contains drivers and hits the hardware itself. e.g. FreeRTOS.
- "OS" in this context means "scheduler", i.e the code that coordinates your application tasks. That description can also apply to VMs such as JS, hence the comparison.
You could consider this type of library OS even more tightly bound to the application than your typical JS app as its actually linked to the user code.
- He was referring to HTTP 1.0 & 1.1
- gcc has "-finstrument-functions". This calls your code on every function entry and exit. I've used this previously for tracing as described here and to move memory-protection windows around based on the running code.
- Is the filesystem the correct abstraction? For most applications, a database-like API is more appropriate, hence SQLite.
- it has secure boot and TrustZone.
- I have to admit, Bazel as a build system would mean it wouldnt even be considered by me, it has to fit in with everything else which typically means Makefiles, like it or not.
TBH, Java + Bazel + Discord makes it seem like its out of step with the embedded world.
- scaling vertically is cheaper to develop
- scaling horizontally gets you further.
What is correct for your situation depends on your human, financial and time resources.