Of course we need some way to send data and control signals to the OHSC for setup and direct control of important parameters.
A good option would be a serial port. This would make it usable in programs and in a terminal for human users.
It already has a hardware uart interface planned that could always be used to control everything important. But this needs a uart interface so in normal operation it would be nice to just use one usb port.
As it is planned that the device can also be used as a HID gamepad for FFB we need some way to control it when HID is active. One option would be to use a hardware uart for that or HID feature reports that would make it impossible for a human user to control without a pc application.
The best option would be to have hardware uart pins open and in hid mode setup a composite usb device with HID and CDC com port at the same time and if you don' need HID it just enables the CDC part.
This is pretty hard to do with STs HAL libraries but should be the most compatible and usable option.
So this is what i tried to setup and kind of succeeded until i found the reason why it would never transmit via CDC or break the HID part depending on the used endpoints.
It turns out that the F4 only has 4 usb endpoints and HID needs two, CDC needs two or 3 with CMD and then there is EP0... So i need at least 5 endpoints.
I could have spotted this by reading the datasheet more carefully which advertises "4 bidirectional usb endpoints". I thought that meant 4 IN and 4 OUT each but that is ~~not~~ the case. *it is. i had the buffers set incorrectly.*
Now there are some options for the next iteration:
- Stay with F4 (Limited endpoints but should still work)
- Hardware uart interface and have 2 usb ports and F4
- STM32F103RC without HW float (not really needed but nice to have)
- STM32F7 (much more expensive, way faster and generally overkill)
- STM32F2? Still a cortex M3 like the F1 but a bit more capable in terms of usb and speed.
At the moment i would probably try the slower and cheaper F1 to stay in budget and keep the board small as there are some more modifications needed for the next iteration like braking resistors and anti backfeed.
The pinouts are compatible and only the usb resistors would have to be changed to switch to an F7 or stay with the F4. Everything else is software configuration.
The F1 would cost around 4.50€ in single quantities and very easy to get, the F4 almost the same with 5€ and the F7 would be about 8€ and make the device a bit more expensive.
The F411 has a usable clock speed of 96MHz and the F1 only 72MHz but that is still more than enough. The F7 clocks at over 200MHz and is pretty overkill for the rather slow usage as most of the time is already spent waiting on spi and usb and the encoder is managed by a HW timer.
I chose the F103RC for the second version because of the usb features and low price.
This allows for a more versatile and user friendly configuration. Hardware float is not strictly needed because most if not all calculations can be done in fixpoint.
The second version still retained the possibility for both F1 and F4 but was built with the F1.
The F1 also has separate ADCs which could provide some separation for voltage measurement and analog inputs for gamepad axes and control signals.
The next version will feature separate control and motor driver boards. And i might get back to the F411 as it seems like the endpoints would be sufficient and it costs the same as the F103.