Is the cypress CY7C68013A supported? It is 8501 based 8-bit chip. Keil has a compiler available.
You can check all the upstream supported CPUs on the github repo. It’s not in there, so it’s not supported right now. 8-Bit is also a little tricky. It is supported, but don’t expect too many of the nice features. You just can’t realize them in such an even more constrained environment. 32-Bit is just a better experience in general. Also considering the size of RAM, ROM etc. typicall on 8-Bit processors. I don’t say don’t do it. Just, be aware of the limitations.
1 Like
Hi,
The 8051 architecture is not supported in RIOT and is not trivial to add support for. The stack pointer register of the 8051 architecture is only 8 bit, limiting the stack to 256 bytes. This makes it hard to support applications that need more than 256 bytes of stack for a thread, but also makes it hard to switch between the stack of different threads.
The whole architecture looks in my opinion too constrained for RIOT to support. Do you have a use case for which you need support for RIOT on this architecture and chip?
1 Like
Thanks for the reply. I am thinking of using this in a keyboard. This chip supports High Speed USB and has PHY in the chip. I want usb host to poll at 8khz for updates. Most chips only support Full Speed USB, or are too bulky and power hungry. I can’t find a better alternative. It has Keil compiler support. If I want to stuff QMK which has a bunch of features it is easier if there is OS underneath.
You could take a look at some of the stm32 lines. Those are more than capable to run a keyboard on. For example the stm32f446 (and the stm32f2 line) has USB high speed, but needs an external ULPI phy such as the USB3300. There is also the stm32f730 and stm32f723 which have the USB high speed phy integrated in the MCU, but those might be on the expensive side for what you have in mind.
1 Like
Thanks for the info. There is also a ATSAM3X8E which offers the same capabilities but in a bigger package and more expensive . Repository says sam3 is supported. There is also a arduino board with it. My application is rather simple as you noticed, so cypress one is more than adequate.
I was told by qmk people that they are looking into adding riot to support the Nordic BLE chip. This might tip me in favor of sam3 option.
Also stm32 chips don’t seem to be available anywhere. I will look into them also once I finish reading up on how to setup HS usb. I am unable to evaluate them in detail since my knowledge of USB is limited.
It would be very cool to have keyboards with RIOT-OS in them. It’s a critical peripheral on most computers which gets absolutely no security review, and which is essentially among the most trusted of components. In addition, there is the interesting problem of having n+1 keyboards attached to a desktop when you can only see n of them. It could be very interesting to have a way to create trusted keyboards.
Can you elaborate on how hiding one of the keyboards relates to trust?
@bergzand do you know of any pcb designs (schematics) that incorporate stm32f446 and usb3300 that are open sourced (other than evaluation boards from ST and waveshare)? Any pointers appreciated. This is my first time. From reading documents it appears there are lots of details to pay attention to.
Thinking about a real product here. You can use the nrf52 and make the keyboard a hub. Like for collecting sensor data from a smartwatch and other sensors on the desk. And you can have maybe a little display on it. Or specific commands for the connected sensors etc.
There are a lot of keyboard people into this kind of stuff 
1 Like
One of the ways to attack desktop systems is to attach new “HID” (Human Interface Devices… keyboards and mice and trackpads) to them which the owner is unaware of. One can then type things on what is generally a completely trusted interface. Of course, there also a lot of key loggers that record stuff too.
On X-windows (and I think Mac and Windows), there is no process to onboard a new HID. You just plug in a keyboard or a mouse and it works. Key emulators with a wifi link can be made small enough that they are hard to see when plugged into a USB port. One idea that I’ve had for sometime is that X-windows, when it sees a new input device could ask the user to do something with it. move a mouse, or type something. That would authenticate the new device is really wanted. But, there many systems where stuff gets connected/disconnected randomly… dirty/loose USB connectors that mostly work. So having to do this regularly would annoy people. If we could instead have some kind of keypair in the keyboard device, then we could do the onboarding dance only once, and afterwards do a challenge against the cryptographic keypair when it reconnects.