Mithun_K_Das
Advanced Member level 3
- Joined
- Apr 24, 2010
- Messages
- 899
- Helped
- 24
- Reputation
- 48
- Reaction score
- 27
- Trophy points
- 1,318
- Location
- Dhaka, Bangladesh, Bangladesh
- Activity points
- 8,254
But I'm confused, How can I use these 16FUSB to communicate between USB and Serial port?
Note: I know USB communication, Serial Communication well so don't ask any odd questions.
That's the basic idea, but I have seriously no idea if it will be an easy or rather hard job. I only traced the software USB concepts out of general interest but wasn't yet tempted to implement it.all I need to do to make a virtual COM port with these 16FUSB core
You can, if you restrict the interface to slow 1.5MBit/s USB, that's what the said 16FUSB and respective ATmega software libraries do. If you think it's a weird idea, I won't disagree...You cannot emulate USB in firmware unless you have a significantly faster processor and for full compatibility, a faster UART port as well.
But PIC16F is available. So I was looking for if there is any way to use PIC16F73 instead of FTDIs.
India and Bangladesh are not a same country.
AVR has single clock cycle instructions, so it's faster. But 16F628 used in the original 16FUSB project is a 20 MHz processor as well, so it's apparently possible somehow. It's pure assembler code, I guess you won't have fun to add CDC or just port it to a different PIC16 processor.
The development of such a firmware really isn't a trivial thing, especially taking into account the limitations of a
simple microcontroller, such as the PIC16F628/628A, especially with regard to its speed.
A PIC16F628/628A can work with frequencies up to 20MHz. However, each instruction cycle takes four clock cycles.
This means that, in fact, with a 20MHz crystal we have our PIC running on 5MHz (20 / 4 = 5). Doing a little overclock,
with a 24MHz crystal, we can run programs on 6MHz (or 6Mips). Since the speed of the USB low-speed is 1.5 Mbps,
we can obtain a total of four instructions (6 / 4 = 1.5) to treat each bit of data during transfer. That is, each bit of the
USB bus takes the time of four instructions of our PIC.
As it's not hard to see, with only four instructions to encode/decode the NRZI, insert/remove the bit stuffing and even
check the end of packet (EOP), the work becomes impossible. Fortunately using a few more tricks we can work around
this problem, as we shall see.
The default endpoint, EP0, treats every control transfer messages. Although this transfer type is more used to the
device setup, we can use it for general purposes too. Additionally, it's possible to use IN and OUT interrupt transfer
enabling respectives endpoints on config file (def.inc). Interrupt endpoints are EP1 IN and EP1 OUT. If you're afraid
about using a device driver (libusb in our case), you may enable HID option, write your own Report Descriptor or use
the default one.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?