[SOLVED] microchip's mchpfsusb framework v2.5b

[eanema]

Hi all,

I am trying to start designing USB devices using the pic18f4550. I would like to figure out how the framework actually hangs together, for example, which files to include, which files to modify and which files are required to be created. Has any one seen a tutorial on how to design a project from scratch. Microchip's documentation is definitely not designed for some one who is not familiar with the framework.

I am hoping for a tutorial type document that explains what the different parts of the code do and what I need to do in order to accomplish my goal.

Any help is much appreciated

 

[serjts]

Hi!

Using the framework is quite simple. Just load it up in MPLAB. Edit the user.c to you content, compile and connect to the PC via serial terminal.

See here for hitech compiler. https://www.microchipc.com/sourcecode/index.php

 

[eanema]

Hi, thanks for the response.

First question:
I have downloaded mchpfsusb framework 2.5b. Inside of the install directory there are several examples, but no "blank project".

\Microchip Solutions\Microchip\
This directory contains a number of subdirectories, but it is all include files and other .c files that will be included in a project.

\Microchip Solutions\USB Host - xxx
\Microchip Solutions\USB Device - xxx
These directories contain examples of devices that do different things, but all of them are members of a specific class lik HID mass storage etc.

Question is this: where is the "blank project"

Second Question:
I will need to change device descriptors to create a device that will respond to bulk transfers, where/how is this done? Is it in user.c?

 

[serjts]

Ok maybe I didn't understand what you wanted to do. The website I mentioned has a package (there is also a official package from microchip but with their compiler) which allows RS232-over-USB very easily, the project file is in MCHPFSUSB\fw\Cdc.HitUSB.mcp.
Other than that I'm affraid I can't help.

 

[eanema]

Sorry for the misunderstanding. I am aware of the premade examples. I am not looking to use the serial emulation, I would like to create a new device that uses bulk transfers (not control transfers).

Essentially i want a control end point for ep0 and and In and OUT end point for bulk transfer of data. Bulk will achieve up to about 1.2 MB/s which is the about the speed im looking for

Any advise is greatly appreciated

 

[elrayes]

i think you can use the custom class example,
another solution i recommend to read the help cause you will find in it how to initiate, send, receive....etc for each class (CDC, HID, custom) and so on, you will find when you install USB framework the header files somewhere inside it which is easy to start a project and guide it to these headers and follow the help then you will get what you want.
however, i recommend to use a ready example and modify on it if you are new to the USB firmware.
good luck.

 

[tomeko]

On a side note CDC DOES use bulk transfer. Install own driver instead of usbser (i.e. libusb) and you have your own "new device".
Also you will not get 1.2 MB/s speed.

 

[eanema]

hi tomeko, thanks for your response. I like this idea of using the CDC class to achieve data transfer. A few questions regarding this:

1) to achieve 1.2 MB/s I am hoping to modify the example "USB Device - CDC - Basic Demo" which is a serial emulation project. I figure that if I modify the descriptors to remove all serial emulation stuff and keep only the bulk IO end points and ep0 I will be able to send data using putUSBUSART at high speed. Is this correct?

2) I guess that was my only question

Any advise on this topic will be very helpful

 

[tomeko]

I don't think modifying anything is necessary. I've mentioned libusb as I used libusb and serial emulation without problems with same device just by pointing to new driver for device. There is also popular WinUSB (some example in mchpusb probably) and few commercial products.
About speed: take a look at this thread:
https://www.microchip.com/forums/tm.aspx?m=94120
I think in real world it's hard to use more than few hundreds kB/s. At 1.2 MB/s you would have 10 instruction cycles per byte top.

 

[eanema]

I think I may be misunderstanding something.
So if I want to use bulk transfers to send data to the PC i can use the serial emulation hardware (right out of the box - only modifying what is being sent/received with the get/putUSBUSART function). The only major change that is required is to use a custom driver?

I haven't looked into using libUSB yet. I was waiting till I figured out the device side of things.

All i need to do to get decent speeds is to use the libUSB driver in combination with the "USB Device - CDC - Basic Demo" and transfer speeds will increase?

 

[tomeko]

So if I want to use bulk transfers to send data to the PC i can use the serial emulation hardware (right out of the box - only modifying what is being sent/received with the get/putUSBUSART function). The only major change that is required is to use a custom driver?

Look at it other way. If you're using CDC example firmware then you're making bulk transfers (unless you violate standard on purpose like CDC using AVR without hardware USB device: **broken link removed**). Transfer type does not depend on what driver you have installed.

Once again, read the thread I mentioned.

<600kB/s transfer>
[note 2] The reason why these speeds/throughputs are useless is the fact that the buffers aren't filled by the firmware, but the previous buffer is just resent to the Host. So in real live I would bet on the 1.5Mbit/s throughput.

I hope you're not confusing bits/s with Bytes/s.

 

[eanema]

The problem I am having is that usually, a serial device would be limited to 115 kbits/s, the maximum speed for RS-232. Is this not the case when using a PIC? It seems that I would not want to use a serial emulation to acquire high speeds.

I'm not really terribly concerned with high through-put, I just don't want to be limited to 115 kbits/s. From the other post that you mentioned the problem occurred because the host was only scheduling one 64 byte packet for every 1 ms frame. I understand the problem that was occurring.

I guess I just don't understand how the driver works. Is the driver for the serial emulation device limiting the transfer speed and setting up the com port? Ie, does the usual driver emulate the comport and limit the transfer speed by not requesting data frequently enough?

If this is the case, then I understand how bulk transfers can be done, with high speed, through the serial emulation example - a custom driver will request a large amount of data from the device.

Am I way off base on this one?

BTW, thank you very much for answering these questions - It is appreciated

 

[tomeko]

The problem I am having is that usually, a serial device would be limited to 115 kbits/s, the maximum speed for RS-232. Is this not the case when using a PIC? It seems that I would not want to use a serial emulation to acquire high speeds.

USB troughput does not depend on bitrate set by driver unless you would limit speed on your own (i.e. "connecting" PIC USB device to slower real UART in firmware).

Is the driver for the serial emulation device limiting the transfer speed and setting up the com port?

From my experience - not. I've tested it sending only 128B each time from PIC (data sized requested from PC were larger to avoid PIC waiting, effective transfer 1Mbit/s), but probably there is no reason why more data could not be scheduled. I've put small and ugly proof of concept some time ago at https://tomeko.net/fastPICCDC.php. Note that this code was taken from older mchpusb, probably using new version would be safer.