#CircuitPython2023: Better USB and I2C Device Support.

CircuitPython on hardware including Adafruit's boards, and CircuitPython libraries using Blinka on host computers.

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
JohnHind
 
Posts: 27
Joined: Sat Oct 24, 2020 5:58 am

#CircuitPython2023: Better USB and I2C Device Support.

Post by JohnHind »

1. For USB Peripherals, more information could be surfaced to CircuitPython about the host. At simplest, are particular protocols ('keyboard', 'mouse' etc.) connected to a host or not? Also any other information available about the host, what type of computer it is (Mac/Windows/Linux etc.), or just a unique identifier that could be used to set a config profile for that computer. With my CircuitPython keyboard, I have to unplug and replug it every time I boot the computer. I do not have to do this with shop-bought keyboards. I think this is because the USB power comes on before the host is ready to enumerate the keyboard.

2. I would like to be able to make custom I2C devices in CircuitPython. Like SeeSaw, but programmable in Python without special programming hardware or complex tool chains.

User avatar
danhalbert
 
Posts: 4613
Joined: Tue Aug 08, 2017 12:37 pm

Re: #CircuitPython2023: Better USB and I2C Device Support.

Post by danhalbert »

Thanks for your #CircuitPython2023 thoughts!

A few notes:
1. A USB device cannot really find out anything the USB host. It cannot get a UID from the host, or find out what its OS is, etc. A program on the host could send this information down to a particular USB device, but it's not part of the USB standards.
2. Have you tried adding a delay before you create the `Keyboard()` device from `adafruit_hid`? There is a small retry with a delay in there already, but it could longer.
3. You can use `I2CTarget` (formerly called `I2CPeripheral`), which is implemented on several but not all CircuitPython ports, to act as an I2C device. See https://docs.circuitpython.org/en/lates ... index.html.

User avatar
JohnHind
 
Posts: 27
Joined: Sat Oct 24, 2020 5:58 am

Re: #CircuitPython2023: Better USB and I2C Device Support.

Post by JohnHind »

Ah, thanks. Some more thoughts:

1. The trouble with the time delay is that it has to be tuned to the specific situation and may delay the availability of the keyboard unnecessarily. I was hoping I could replace this with a busy loop testing for connection. Commercial keyboards do not have this problem, so there must be some way of doing it. I have considered using CDC and will do this if necessary, but it requires a server implemented on the host computer. Would enable a range of other possibilities though.

2. On the I2C front, I'd missed that, thanks for the tip. It is a pity about the clock stretching requirement, however. It occurs that this could be avoided by making it asynchronous: implement a buffer on the C side for the registers which is what gets returned on a read and so is immediately available. Then have Python functions which update these registers on change at their own pace.

User avatar
dglaude
 
Posts: 12
Joined: Fri Sep 08, 2017 4:27 pm

Re: #CircuitPython2023: Better USB and I2C Device Support.

Post by dglaude »

Maybe there is nothing in the USB standard for the USB device to know about the USB host...
But there could be difference in behavior on what different operating system are doing when they detect a USB device of a certain type.
Here is some hint on how Hak5 detect the operating system: https://www.youtube.com/watch?v=GEyDkd6DS8c
It try to do ethernet over USB, then at the network level check the signature of the host... but that would be overkill for core CP.

User avatar
dglaude
 
Posts: 12
Joined: Fri Sep 08, 2017 4:27 pm

Re: #CircuitPython2023: Better USB and I2C Device Support.

Post by dglaude »

JohnHind wrote: Thu Jan 12, 2023 1:54 pm 1. The trouble with the time delay is that it has to be tuned to the specific situation and may delay the availability of the keyboard unnecessarily. I was hoping I could replace this with a busy loop testing for connection. Commercial keyboards do not have this problem, so there must be some way of doing it. I have considered using CDC and will do this if necessary, but it requires a server implemented on the host computer. Would enable a range of other possibilities though.
Hi, I am revisiting all the #CircuitPython2023.
I know I already replied to this, but I have another idea that could help.

As a USB-HID keyboard, you don't really have a lot of feedback on what is happening on the Host side.
I would love to see your busy loop to better understand how you do it.
My idea for similar problem was to try to send ScrollLock keystroke, and the verify if the ScrollLock LED status in report. My assumption is that when the Host is ready to accept keystroke, I will have the ScrollLock feedback working. I will investigate as I have a usecase where my computer refuse initial keystroke and that is a pain.

Now, that ScrollLock thing is maybe only meaningfull on Windows/Linux PC as I don't think it exist on Mac.
So maybe you could identify that you are NOT connected to a Windows/Linux just with such a check.

There might be another detectable difference of behaviour between Windows and Linux that could help distinguish one from another.

Locked
Please be positive and constructive with your questions and comments.

Return to “Adafruit CircuitPython”