Teensy++ avr has hardware high speed USB virtual com port example code in c and open source licenced if that feature was avalable so the maple could send serial data to my linux machine as fast as the usb port can handle it instead of hardware com port speeds I would buy 2 today.
Teensy++ avr has hardware high speed USB virtual com port example code in c
(9 posts) (4 voices)-
Posted 5 years ago #
-
Why does it have to be "serial data"?
I'm about to experiment with isochronous burst (using libmaple and native code) to send time sensitive video data at 11Mbps.
If all you want to do is send ASCII data, then you could use a continuous isochronous stream to achieve 1.7 million (7-bit) or 1.5 million (8-bit) characters per second.
Posted 5 years ago # -
wow realy can you show some exaples of your results somewhere???
Posted 5 years ago # -
MessiahAndrw - I'm impressed.
Would you please describe how you are doing that?
Are you implementing a USB device? Which device class are you using?
What drivers are you using on the PC, and what OS on it?
Posted 5 years ago # -
the usb client hardware on stm32 supports bulk, isochronous, interrupt and ctrl endpoints. The difficulty would be in making these other endpoints play nice with the build in serial device thats part of libmaple. Of course, if youre willing to throw out the serial port (or write some custom host side drivers) the problem would go away. I havnt ever tried isoch. endpts before, and am psyched to see the results!
One of the projects that has been discussed around here is porting the LUFA (myUSB) library to stm32. That project is quite mature and has lots of code for implementing various usb device types and different endpoints. If youre interested in seeing this happen or helping out, let us know!
Posted 5 years ago # -
I'd might be interested in helping on a LUFA to STM32F project, but timing is looking bad 'till mid September :-(
My ideal is to avoid installing any host-side device drivers. I'd prefer to use existing host USB drivers, and avoid the need for a Maple USB driver. I've observed serious problems with the Arduinos' FTDI driver on Windows and some Linux's.
I'd like to have a single USB mechanism for upload and Serial.read/print to further reduce problems. I'd be willing to help (if we go STM32F for our project).
I don't have a USB sniffer, but I have used the Mac's DTrace to debug connections, which was useful.
GB
Posted 5 years ago # -
if youre in linux, theres usbdevfs...some kernels have it, other times you have to compile it in, but there are good probe programs for analyzing the usbdevfs dumps. I used it a lot it debugging the DFU and serial firmwares. The Maple Serial and DFU drivers in windows are usbser.sys (built in) and libusb (supported nearly everywhere but not vista...). the "maple driver" for serial is really just an INF that points to usbser.sys. We have thought a lot about a monolithic approach where uploading and serial are in one driver and run simultaneously, but then wed have to write custom drivers, which is another mess entirely. one might suggest that we could do compound USB, or USB IAD, check this: http://leaflabs.com/docs/maple-bootloader/
Posted 5 years ago # -
Sorry, I may have mislead you.
I am happy to upload over the *same* USB device, e.g. USB CDC, as is used to support the library Serial.print/read.
I don't need USB DFU.
I'd read the maple-bootloader explanation, and compound USB, etc. sound like a nightmare.
Just a USB CDC, or other simple USB device, whatever makes most sense, which is adequately supported on the main host platforms.I realise this is *not* trivial. I know a guy who developed the SunSpot firmware, and he said it was very hard to get it working on all their target platforms using the platforms native drivers. He said each of the different platforms approach to USB compliance were 'rather different'. He did say Linux is the closest to the USB standard specs.
He used a USB sniffer for debugging. He helped me do some USB debugging using it, and it was brilliant. If I were doing more USB work, I'd get one.
Posted 5 years ago # -
linux usb stack FTW! I wont try and make some douchey comment on the OS debate here, but I will say that what took zero time to get working in *nix (cdc and dfu) was weeks of trials in other environments.
Posted 5 years ago #
Reply
You must log in to post.