Are there also open-source solutions without dependency on server in the cloud and that depend on internet connection? I am looking for a total home solution where I can communicate with doorbel through laptop with headset.
Is comparing a signed integer with an unsigned integer UB? I resently wrote some code and compiled it with gcc to x86_64 (without optimization) that returned an incorrect answer.
When comparing signed and unsigned integers of same size the signed one will be converted to unsigned. In a reasonably configured project compiler will warn about it.
In case of integers smaller than int, promotion to int happens first.
In case of signed and unsigned integers of different size, the smaller one will be converted to bigger one.
This is one of the most frustrating things as being a software engineer: working on solutions that you feel that are not going to work. In some cases, I was the one saying that a particular solution was not going to work. It did not bring me any good.
Question: I once heard somebody talk about a micro-controller (with a minimal instruction set) where every register could be the program counter. It did not have jump or call instructions. You had 'emulate' those with the instruction (possibly conditionally) that changed the assignment of the program counter to one of the instructions. If I am not mistaken, it had eight registers. Does this ring a bell?
That description does not match the RCA 1802 [1] perfectly, but it is probably the best known microprocessor (not a microcontroller, though) without a dedicated program counter. There are a lot of misconceptions about it floating on the internet, so I would not be surprised to hear it described as you did.
“The ARM architecture provides sixteen 32-bit general purpose registers (R0-R15) for software use. Fifteen of them (R0-R14) can be used for general purpose data storage, while R15 is the program counter whose value is altered as the core executes instructions. An explicit write to R15 by software will alter program flow.”
Similarly, the PDP-11 used R7 for that. https://en.wikipedia.org/wiki/PDP-11_architecture: “The CPU contains eight general-purpose 16-bit registers (R0 to R7). Register R7 is the program counter (PC)”
I’m not aware of any CPU where “every register could be the program counter”. Such a feature also feels weird to me from a design view because I think it complicates the hardware with few (code might be smaller for a limited set of jumps) benefits. Maybe you’re confusing that with the ability to jump to whatever address is in any of the general purpose registers?
“The SEP instruction can select any of the 16 registers to be the program counter. The SEX instruction can select any of the 16-bit registers to be the index register.”
What about privacy? Maybe not everyone wants to share his information with every far relative that you might never have met or twenty years ago when your grandmother died and you already have become a grandparent as well.
I find this a bit disappointing. Why not publish it with the preprint. Now we have no way to establish the quality of the two solutions or whether it is even possible to improve one of the solutions. I wonder why the C variant could not implement a JSON parser without malloc and free, while the RUST variant could.
Really strange the the C JSON parser has to use malloc where the RUST version does not. As if it is not possible to write a JSON parser in C that does use malloc. I presume that the syntax of the commands that the device will accept is known, and than there is no reason why you have to build a DOM of the JSON before you can process it. Apparently, the RUST version can do it. I really begin to question the abilities of two teams if the one team failed to implement a JSON parser solution without using memory allocations.
Part of the C protocol implementation is generated, and that generator chose the JSON parser. As it worked and there was plenty of memory left on the MCU, it was kept.
We're mentioning this in the paper: "The heap is entirely attributable to Parson's dynamic
allocation of JSON tree nodes; as memory usage
minimization was not a key goal, we kept Parson (the JSON
parser used by the PNPL code generator by default), noting
that there are less memory heavy options that do not require
a heap at all."
Wasn't memory one of the key indicators looked at?
> The analysis and measurements on hardware indicate no strong reason to prefer C over Rust for microcontroller firmware on the basis of memory footprint or execution speed.
I admit I have not carefully read the paper, and am collating info from comments here, so I may be fully mistaken. The word "strong" also allows for much interpretation, that I'm not a priori critical of, but am skeptical of.
Yeah, you can comfortably work with JSON in C directly on top of the string buffer containing it. Your representation for any JSON entity will just be const char pointer. It's possible to implement JSON path on top of this, and all kinds of niceties, and it's not slow.
Yes you can pin it to core 1 whilst pinning all other tasks to core 0. Then will never be interrupted or preempted (except by interrupts created on core 1)
reply