Thanks to V-USB, software-based USB is all the rage now, with a lot of uses for very small and low power microcontrollers.[ZiB] wondered if it would be possible to implement a USB controller on the STM8 microcontroller (Google translation) in software and succeeded.
The STM8 is a bit of a change from the usual 8-bit micros we see like AVRs and PICs. [ZiB] chose the STM8S103F3, although any chip in the STM8 family will work with this project when a 12MHz crystal is attached.
The build began by generating USB signals with the help of a whole lot of NOPs. This code doesn’t take up much space – only 300 bytes, and the receiving code (Google translation) is similarly sized.
The code isn’t quite there yet, but [ZiB] has proven a software-based USB implementation on the STM8 is possible. All the code is available for download (comments in Russian) and a video demoing the project available below. If anyone cares to translate this project to English, we’ll post a link to your work here.
Insanity, I love it! I have also been itching to do software USB on ARM. A lot of the newer devices have advanced timers that could help with bit-destuffing and other stuff.
On the other hand, there are so many nre controllers with internal USB, that software USB on ARM will be of very limited practical use.
I think the practical use bit comes with the cost. Some usb-enabled avrs start at around 20 bucks, which is cheap to be sure. Generic avr chips, on the other hand, can be had for well under 10 bucks… sometimes as cheap as a dollar a chip.
So if you wanted to do a low production run of a simple usb device, that would sure make it cheaper.
Great, if only sdcc would be a little bit feature-closer to gcc… I really miss gcc’s ‘section’ attribute and ‘gc-sections’ to remove unused code.
Funny that I like SDCC extension of handling different memory types for accessing ROM/FLASH/short pointers based data. None of the usual P_Char() kludges that you have to use to get around GCC’s snobbiness. If you really want to, you could have a single generic routine that access the structure regardless of where it is at the expense of slower and bloated code that SDCC would generate for you. The memory map stuff in SDCC is a lot easier than GCC.
If you are doing embedding, some of the critical code isn’t going to be “portable” to other chips family anyways, so sticking with “standards” is just silly.
Can’t play with the official std lib(STM8S_StdPeriph_Lib) without attribute like ‘-gc-sections’, because of the generated hex file was too big to flash.
Can’t play with the STM8S_StdPeriph_Lib without attribute like ‘-gc-sections’, because of the generated hex file was too big to flash.
I looked into adding a small CPLD to the STM32F0 for handling the PHY and bit stuffing with the SPI. It wouldn’t take a lot to have a USB slave for a full speed USB. I came to the same conclusion that there are plenty of newer chips that have native USB and their prices are cutting into the 8-bit market. :)
There are a few things you can’t do in VUSB due to the USB specs imposed on the low speed device.
Now you can have 8-bit toilet seat with USB connectivity.
No ground plane, ew.
There’s no big price advantage over PIC18F14K50 and future STM32f042.
where is it’s circuit(schematic)?
There are a set of STM8S boards available on ebay for under $1 !!!! They have a USB connector on the boards that is only used for power, but 2 wire mods could connect to GPIO pins and then implementing the virtual USB driver mentioned here, and you have a USB device board ready to go for under a dollar !!!!! e.g. See here… http://www.ebay.com/itm/Development-Board-Minimum-System-Board-ARM-STM8-STM8S103F3P6-Module-for-Arduino-/361245198603?hash=item541be4490b (ignore the ARM comment in the title…that’s an error).
HI Donald,
Have you tried this on the kit u have mentioned above?