I have somehow managed to use the LUFA USB Firmware library to get started in my own Vendor class method to accomplish my goal.
My device involves communicating with a Flash ROM. Reading and writing are the most important tasks here. I was originally doing all communication in the Control Transfers, using LibUSB at the Host-side. MY PROBLEM: The Read routine is always sometimes successful/sometimes not. I will get into detail in a second:
Read Routine
I decided to transfer large amounts of data over a series of control transfers. I have attempted varying methods, here is what I have now:
1) Initiate read command from PC (control transfer), firmware receives start-address
2) Total number of bytes to read is broken into sections on Host-side. For some reason a section size of 8 is more successful than a greater number. Although, errors are generated here too.
3) for all of these 'sections' the host will tell the device via control transfer "hey, get a section for me!" the device will work on reading the ROM.
4) Host polls the device thru control transfers to see if the device has queried the number of bytes from the flash ROM
5) when device replies as READY, host initiates an IN control transaction to receive the bytes from the device.
Now for some reason, my USB descriptor max packet size has to be set to 8 to minimize the errors I am getting (detailed now:)
The errors I am getting are usually PIPE error, or I/O error (error codes -9, -99 in libusb). I have no hardware USB protocol analyzer, however I did try to use usbmon and vusb (see image. NOTE: image will not upload to this forum post. Will try to post later) to reveal something. I cannot tell what that picture means (see attached image). I am still in the dark.
As for the image, here's a brief explanation you can pickup by looking at the data column. When the device returns 0, it means it has gotten all bytes from the ROM, is ready to transfer that section of bytes. Then you will see that it sends a section of 8 bytes subsequently. When I get those strange PIPE and/or I/O errors, Vusb shows that strange status code things as shown in the picture. Without a hardware USB analyzer, or knowledge on this, I am unknown what to do.
The funky thing
The funky thing is that the WRITE routine uses almost an exactly similar, if not exact, method of doing things, with the simple difference that it receives data from PC, and writes to Flash ROM. However, that routine always executes flawlessly!!
Although I have "patched" this faulty read routine to continuously re-send the failed packets, which eventually leads to a successful whole transfer, this causes such a slow transfer speed!! My goal is to use a packet size > 8, or at least data size (terminology may be incorrect. I say data-packet size because I acknowledge that somehow, libusb can send large amounts of data even with a small packet size, due to abstraction of the protocol). Since I am programming from an abstract point of view, it is hard to diagnose the problem. I am waiting for the right time to purchase a hardware USB analyzer, so no word on that.
Note: I tried implementing the IN endpoint with BULK instead of Control, except I am not sure of what I am doing :X. I gave up I guess, that amount of uncertainty involved does not owe to continuing that solution. I would rather learn to write custom drivers from scratch and understand everything to be a true professional.
I plan on performing a number of steps to remedy the situation, including:
1) Prototype PCB so as to eliminate the possibility of breadboard being a problem factor (speed issues etc). Speaking of speed issues, I am not sure if the reading of the ROM, or the speed of the MCU is a problem factor here.
2) Building my own firmware from scratch / device driver (host side) to truly understand
3) Not sure what else.
Anyways, I cannot seem to find as many answers on the topic of USB and Atmel AVR's, or even if the problem could be the speed of my microcontroller (8Mhz). Of course, the PLL on the microcontroller gets 48Mhz through prescaling (i still dont know much about this)).
