It uses WebSerial to communicate with SimpleFOC. No software is required to run it (except a web browser). It supports multiple motors connected to the same controller, display graph of different variables, use slider to set them or number input.
It’s still very raw and there’s a few things I want to improve but I’m happy enough with it to start sharing it with you! Please comment with your suggestions about how I can improve it and I hope it can help people here!
There are naturally different MCUs with different USB specs, so it’s difficult to do a universal implementation without sacrificing performance for top shelf MCUs. However there could exist an optimized USB transfer in parallel to a less improved one, which will involve a choice.
Just trawled the net and found this to refresh my memory. Was looking into this a while back when using SinpleFocStudio the first time.
Basically there are three classes of USB for MCUs. Regular serial with a serial-to-usb IC, Full-speed virtual USB and High Speed virtual USB. The problem for these virtual USB serial lines is, that they try to be serial, when in fact they work with 64bit packets (Full-speed)
Just noticed that your focus is mainly the commands from PC to MCUs, which is awesome, but could introduce further USB overhead. Not that you send lots of command date. I like your handshake approach for USB commands.
Ok, there may be different CDC implementations. It looks like STM32 does send a string in blocks. But haven’t confirmed it. The SAME51 I was working on at the time did not.
The CDC implementation on F103 and F4x uses a transfer block size of 64 bytes. Anything larger than that is broken into pieces of 64 bytes, wherein the last piece can have less than 64 bytes.
Hmm… possibly we can use the USB.send(); directly in the code, bypassing the virtual_serial (SAMD only).
Which MCU are you on?
Could you read a USB package (eg. 64bytes) in your web_program? Possibly with several variables and their descriptor?
I think there’s some misunderstanding, my project is using the same communication system as SimpleFOCStudio: raw serial. Most people use USB directly to communicate through serial but it’s not “raw USB”. When using a dev board (an esp32 dev board in my case), you’re actually not connecting directly to the ESP32 but to a USB-Serial converter. You can then choose whichever serial baud rate which is supported by both your microcontroller and your USB-Serial converter. In my case, I’m using 921600 which is actually 92160bytes/s of usable payload speed. It’s transmitting ASCII characters which adds some overhead but this is not really a problem. You can send a lot of data with 92kB/s!
ESP32-S2 has native USB support, so in theory it can send 64 bytes per block/package. Yes I agree, there is some confusion around this. Could you try to sniff the data stream and let us see what is being sent w. time stamps
Nothing will be sent by your ESP if you’re not programming it to send anything. There’s nothing about USB communication in the ArduinoFOC lib. You could implement it but then you also need to implement a USB driver for whichever OS your using. I really don’t think it’s the road to go for a project like this.
I do recognize that building the String does impose some memory challenge, but in this specific case the logging is not turned on in the final application.
As I see it, this is where the confusion lies:
Like HID, CDC can request bandwidth up to 64 bytes/ms (frame). As each frame is one ms, that means we could potentially pump 64 x 8 x 1000 = 512000 bps
So there is an actual serial to USB converter on your board ?
Usually that’s not the case for mid-range MCUs with native USB, but I guess it all depends. If that is the case, then of course it makes sense to set the baudrate.
What I’m trying to conway is, that many users of SimpleFoc with boards that use emulated USB should have the option the use the bandwidth available (CDC 64byte transfers) IMO.
If you could sniff the data stream it could be quite educational. Does the serial to USB buffer the incoming data and then do a 64byte transfer ? If that is the case, then we can achieve more or less the same by buffering the data on the MCU and then transmit a 64byte block. I know there isn’t much about USB protocol in ArduinoFoc lib. That’s because it’s in the Arduino framework.
Aha, here it is. Bulk transfer can do 19 transfers per frame. That makes the potential even greater.
NB. I’m not trying to take away the awesome work you have done. I’m looking forward to try it out myself. My goal is to improve the overall experience
Ok, let’s get to the point. You asked about ways to improve the web_application.
Knowing that the Arduino framework uses USB CDC to emulate the serial connection, it should not be necessary to write a new driver to expand the actual CDC functionality if you claim it as a USB device.
I know it will be a big expansion of your program, but it could enable lots of users to take full advantage of their MCUs com potential.
Another equally important point is. You know there are reports about serious lag when running SimpleFoc and logging. What if the cause of this “bug” is, that the MCU is trying to push the data through a tiny 19-char per millisecond bottleneck?
Edit: TinyUSB lib works across STM32, ESP32, SAMD etc. and has WebUSB support by Adafruit. IMO this is a viable route to optimize the SFStudio data link for this kind of web-app.
Thank you for taking the time to do this, its an awesome tool and a very good staring point for replacing simplefocstudio or just making it more accessible.
Bonjour @geekuillaume et Merci!
I have tried it - unfortuneately, the Chrome browser (Version 110.0.5481.177,Official Build, Linux 64-bit, updated today) stops working receiving serial data (it says the connection was lost, however I still can send motor commands and that works). What browsers are supposed to work? It would be really nice if you could add a short description (just the steps) to your Github README how to build the web app so one can debug, test and fix any script errors with a browser running the scripts locally? Merci Beacoup
PS: I could manage to build the scripts with npm, and get the same serial receive error with my local build…
(I installed the build tools with: npm init @vitejs/app, npm install react-plotly.js, npm install …etc… for all missing packages )
