3 ms·

> the complexity of the codebase to talk to the USB device was around the similar level of complexity to the entire preemptive multitasking operating system the

> the complexity of the codebase to talk to the USB device was around the similar level of complexity to the entire preemptive multitasking operating system the students were building For the complete USB stack, that's very likely. However, for minimal code needed to read keys from keyboard USB shouldn't be that bad. These students only need USB 1.1. They don't need to support bulk transfers (USB protocol has 2 distinct transports, one low latency another one high throughput). They don't need to support USB hubs between computer and the keyboard. The only device type they need is HID. USB consortium wouldn't allow to call that protocol USB due to the missing features, but it's good enough for education purposes.

Cthulhu_ 5y ago
It's still a LOT more to think about and that they have to filter out when developing it though.
- Const-me 5y ago
  The professor could implement these boring lower-level pieces in a library which fires couple callbacks, one on connect/disconnect to provide two descriptors for HID device and their reports, another one for handling the HID report packets. BTW, USB specifies a small subset of HID interface called “boot interface”. It’s normally consumed by UEFI firmware who needs mouse and keyboard for the setup GUI which runs before OS launches. The subset only supports basic keyboards and mice.
  - bluGill 5y ago
    Then it isn't write your own OS from scratch. The constraints of the library will force your implementation around it, even if you think you have a better idea.
    - Const-me 5y ago
      This project https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac implements unified keyboard+mouse input API over 3 distinct lower-level APIs: Win32 messages, XCB packets, and Linux raw input. Here’s for raw input: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Linux https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Li... All 3 have unique quirks, yet I would not say they significantly affected the rest of the library. I think for the USB in that OS, a C API with intentionally very narrow scope would be OK for the job. The main reason why the real-life code is so complex is that scope being very wide. We have USB 2 and 3, mass storage, two-way audio, cameras and GPUs, hubs and composite devices, numerous wireless protocols on top, OTG, power delivery, power saving features, and more.
    - xnormal 5y ago
      A well-written library can effectively expose a simpler hardware device with minimal assumptions
      - bluGill 5y ago
        Sure, but even one assumption limits innovation. Even if the innovation is stupid, learning the hard way is useful, so I want at least one student every few years to try that stupid thing and then from personal experience tell the others why it didn't work out. If we were talking about a serious project there are a lot of best practices that should be rarely (and then only carefully) questioned, but for something intended to be thrown away at the end of the semester challenging best practices is a great way to learn. That said, PS/2 is a simplifying assumption as well.

Cthulhu_ 5y ago

It's still a LOT more to think about and that they have to filter out when developing it though.

Const-me 5y ago
The professor could implement these boring lower-level pieces in a library which fires couple callbacks, one on connect/disconnect to provide two descriptors for HID device and their reports, another one for handling the HID report packets. BTW, USB specifies a small subset of HID interface called “boot interface”. It’s normally consumed by UEFI firmware who needs mouse and keyboard for the setup GUI which runs before OS launches. The subset only supports basic keyboards and mice.
- bluGill 5y ago
  Then it isn't write your own OS from scratch. The constraints of the library will force your implementation around it, even if you think you have a better idea.
  - Const-me 5y ago
    This project https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac implements unified keyboard+mouse input API over 3 distinct lower-level APIs: Win32 messages, XCB packets, and Linux raw input. Here’s for raw input: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Linux https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Li... All 3 have unique quirks, yet I would not say they significantly affected the rest of the library. I think for the USB in that OS, a C API with intentionally very narrow scope would be OK for the job. The main reason why the real-life code is so complex is that scope being very wide. We have USB 2 and 3, mass storage, two-way audio, cameras and GPUs, hubs and composite devices, numerous wireless protocols on top, OTG, power delivery, power saving features, and more.
  - xnormal 5y ago
    A well-written library can effectively expose a simpler hardware device with minimal assumptions
    - bluGill 5y ago
      Sure, but even one assumption limits innovation. Even if the innovation is stupid, learning the hard way is useful, so I want at least one student every few years to try that stupid thing and then from personal experience tell the others why it didn't work out. If we were talking about a serious project there are a lot of best practices that should be rarely (and then only carefully) questioned, but for something intended to be thrown away at the end of the semester challenging best practices is a great way to learn. That said, PS/2 is a simplifying assumption as well.