I can imagine it very easily, depending on the keyboard.
For example: The Keychron C3 HE I'm typing this on (which I ranted elsehere about lacking the open-source/QMK firmware it is advertised to have) has some peculiar features that it supports. The way they used Hall effect keyswitches lets some fun stuff happen.
That fun stuff includes 3 different modes: One is just a keyboard, and the other two modes let the keyboard behave exactly like a game controller. At least one of those game controller modes even lets keys behave as analog inputs.
I haven't knowingly used this keyboard in game controller mode, but perhaps it is something can be selected by software (in addition to the multi-key combo listed in the book).
> At least one of those game controller modes even lets keys behave as analog inputs.
Now that's a really cool feature I never thought of when considering a Hall-effect keyboard. I knew you could adjust the activation position of each key on some, but analog would be great for games.
It's a pretty neat keyboard and I'm glad that I chose it.
And while I know some of how the Hall effect works, I didn't research how that relates to keyswitches at all before buying it. In terms of use, I just knew that they weren't clicky[1] and that they didn't rely upon electrical contacts that can corrode. It was risky in this way, but I was buying under duress since at the time I needed a new keyboard approximately yesterday.
Having the ability to shift this thing into a bunch of analog inputs was a complete and total surprise. I hope to be able to come up with something unique to do with the this function some day.
[1]: It turns out that my typing style didn't depend upon clicky at all. My hands, forearms, and wrists feel the same as they always have, and my typing speed still tops out at an accurate ~100WPM at times when that's useful. There was no adjustment period, which was a bit of a surprise.
I think this has to do with their 2.4G dongle for their wireless keyboards - it shows up as a DirectInput (but not XInput) controller for me on Windows for whatever reason. The keyboard itself doesn't though.
If someone told me I couldn't call myself an engineer and instead I had to call myself a software developer, I'd turn around and tell them I just forgot all my theoretical computer science, and of course we can do a bubble sort on the multi-terabyte database, LOL.
I can name one.
At my job we do the kind of embedded programming were encoders inside machines send data to each other. Like reading optical sensors and sending bits indicating state to other controllers.
We absolutely do not "need" to know about Unicode, outside of interest about other realms.
> Essentially, the ISO 26262 certification mostly verifies that the compiler release process conforms to a certain standard. It does not create an ISO standard for rust, not does it aim to.
Sorry for a stupid question, but what does this mean?
Is it only that Rust itself (the language) is no use
in a certification, but rather a specific compiler version? I.e. basically leading to the same outcome in the end.
Or does this mean to not get the hopes up (right now) for using Rust in a ISO26262 certified project?
Not your parent, and haven't worked directly in these areas, but this is my understanding.
"certification" is something that is done to a process that produces a software artifact.
So yes, in some sense it is "particular compiler version." The result of certification says "this compiler will do this when given this, and here is how we ensure that that is true, and here's the process for when that's not true, etc etc etc." Users can then use that specific compiler.
> I.e. basically leading to the same outcome in the end.
The difference is pretty important. Getting this certification does not require that the abstract concept of the Rust language is being specified in any specific way. It does require that a specific inputs to the compiler are described, and because compatibility with upstream Rust is desired, those specific inputs happen to map to inputs to rustc that are identical, but it is important to understand that this can happen completely independently of what the Rust Project decides is best for the language; this is a downstream project.
In theory, if the Rust project wanted a specification, starting with some of the work Ferrocene has done would be an option. But the qualification process doesn't require that.
> Or does this mean to not get the hopes up (right now) for using Rust in a ISO26262 certified project?
The opposite, this means you can use Rust in these places. Even though this work does not specify Rust.
> The difference is pretty important. Getting this certification does not require that the abstract concept of the Rust language is being specified in any specific way.
Sorry, I was being vague.
I meant the outcome for "us", the users, creating certified software relying on Ferrocene.
Totally on board with that there is a huge difference for certifying Ferrocene itself.
> The opposite, this means you can use Rust in these places. Even though this work does not specify Rust.
Nice, that's what I was hoping for. We are currently in a project creating safety certified software (in C, as are our other code) and are curiously looking at Rust, partly because of this effort.
The main page for Ferrocene says "ISO 26262 and IEC 61508 qualified" with "DO-178C, ISO 21434, and IEC 62278 in the future," so depending on exactly which things you need, Ferrocene may work, but it also may not.
> all of our computing resources are based on a 100+ year old concept of a file cabinet with folders and files.
While they are based on the same concept, putting things inside of things (in hierarchies) is a pretty solid way of sorting stuff.
There are other ways as well, such as labels/tags. But regardless of technology I feel like folders (in one way or another) is one of the tools you would reach for.
