Open kbeckmann opened 6 years ago
Hmm, if we want to use two cdcs we need to make the cdcs code more generic ;)
Alternative is probably to use HID but then you can't use minicom/screen/etc to communicate with it, which would be a shame in my opinion.
I dunno, I think having a dedicated tool with readline CLI would be nice as well. Or just with inline one-time calls.
So you can either > xildebug set_gpio 1 1
or start xildebug and have a interactive shell thingy.
I want it to work without any drivers on linux, mac, win. So cdc or hid i guess. cdc is nice because you can use minicom/screen etc.
hid is nice because... reasons?? What are the advantages with hid over cdc? is it simpler?
We have 256k of flash so implementing a CLI should be totally okay.
downside of CDC is you get 2 ttys when you plug and it's annoying :P
true. is it easy to write a cli client with hid?
if we write it using pyusb or something it should be pretty portable
I think so http://www.signal11.us/oss/hidapi/
So is the decision to go with HID?
Where should the application code live? Another repo or should we move the firmware into a separate folder?
i think another repo
So I just remembered that the CMSIS standard supports up to 32 vendor-specific commands and if we wanted we could just use those for the configuration, this way we wouldn't need extra endpoints. Only change that this would require is that the ADC reading would have to be polling instead of streaming, but I think that kinda was gonna be the way anyway cause how else would we have done it, we can't just spam values without end? So if we have a cmsis vendor command to get ADC then we read and return. This way we can keep polling all the time anyway. We can also use the command to configure triggers, calibration, gpios and all that. I think it would be a nice and clean way to implement that.
🤔
Add a simple CDC endpoint that can be used for: