Skip to main content
Topic: honkens' open source usb stack (Read 54305 times) previous topic - next topic

Re: honkens' open source usb stack

Reply #45
I'm using HW-group Hercules utility:
http://www.hw-group.com/products/hercules/index_en.html
Got a question? Please ask in the forum for the fastest answers.

Re: honkens' open source usb stack

Reply #46
[quote author="honken"]
Woke up this morning and had an epiphany, I set the wrong receive buffer length on the OUT-endpoints (8 bytes as for EP0 instead of 32 bytes as advertised in the descriptor) that account for the only-echos-8-chars.
[/quote]
Yes, that was it... also :)
I also declared the rx/tx buffers as 32 bytes while stating in the device descriptor that the maximum endpoint buffer size was 8 bytes. So somewhere all bytes in excess of 8 got lost.
But that is fixed now.

[quote author="honken"]
About the 20 chars kill I believe the problem is with my "clear to send" test that busy waits.
[/quote]
No, that wasn't it. Do not actually know what went wrong before. But it works now. See attached image, 33 bytes sent and received a number of times.

I added some of Ian's changes but moved the VID/PID defines to the top of the usb_config.h file. I really like them there and at the top they are more visible.
I suppose I should be better at commenting the code if I would want others to be able to use and extend it. It'll be on my TODO list.

I made some refactoring, and turned the stack "the other way around". Mainly to accommodate making it into a on chip lib. Now the App or Class using it is responsible for initializing the stack and there are more access methods.

I found and corrected a handful of portability problems, but I don't expect the stack to run on pic24 yet. The storage qualifiers are still wrong and there need to be a linker script defining the section for the descriptor tables (usb_bdt[] must be mapped correctly). On the pic18 this is solved with pragmas a section definition in the added linker script.

 

Re: honkens' open source usb stack

Reply #47
I have been reading this thread with interest.

very good work btw.

One question i have is does the stack support USB serial number (unique ID?) ?
So that it stops the issue that i have with the microchip stack that creates a new serial port every time the device is plaugged into a different usb port.

Re: honkens' open source usb stack

Reply #48
Good question.
I know that in mass storage devices there is a string descriptor with serial number.
I havn't considered it with a cdc-acm device, but as I'm experiencing the same symptoms I'll look into it.


Re: honkens' open source usb stack

Reply #50
Thanks! I updated the IR Toy code, but I haven't gotten it to work yet. I'm sure it's something on my end. I added the descriptor settings to the linkers, and re-integrated the IR Toy interrupt stuff. I think it's a descriptor problem (maybe because I used the Microchip descriptor). I'll do a little digging after some soldering.

The attached firmware is quite amazing. It instantly reboots my Windows XP machine.
Got a question? Please ask in the forum for the fastest answers.

Re: honkens' open source usb stack

Reply #51
[quote author="ian"]
The attached firmware is quite amazing. It instantly reboots my Windows XP machine.
[/quote]
Ahh, room for some usb fuzzing. I heard there were some security flaws in the windows HID-parser in sp2, but in the enumerator as well is fun.

I've ordered a usbtoy for chistmas to myself and will be able to use that for dev when it arrives, should lessen the burden of those minor changes to get it to run.
I also ordered an ols, thinking theres room for a vendor (ie our own) protocol with less overhead and thereby greater bandwith. Found a libusb wrapper for java on sourceforge that could be used for client conduit instead of rxtx. At least one less layer of abstraction.

Re: honkens' open source usb stack

Reply #52
[quote author="Scorpia"]One question i have is does the stack support USB serial number (unique ID?) ?
So that it stops the issue that i have with the microchip stack that creates a new serial port every time the device is plaugged into a different usb port.[/quote]The USB Device Serial Number is not part of the stack programming, but is rather just a matter of putting the right data in the first Descriptor.  All USB classes, CDC or other, have a Device Descriptor which includes a Serial Number.  The Serial Number is a little different than VID or PID, since it is really an index that points to a separate String Descriptor which can be anything.  Provided that the USB stack properly implements String Descriptors, then placing a non-zero index in the Serial Number should work.

Caveat: I have not looked at the source code for this USB stack to see how it supports Device Descriptors and String Descriptors - I am speaking purely from the perspective of the USB Specification.

Re: honkens' open source usb stack

Reply #53
I have implemented usb string descriptors, and there is a iSerial (byte index to string with serial number), and there is a serial string.
Currently the serial string is "00000001" in utf-16le as it should be according to the usb standard.
The Mass Storage Device (usb-stick) mandates a 12 character hexadecimal serial number, but I haven't found any specs for other devices yet.

Perhaps it is something with the .inf first used installing the device.
Also, in my last update there is an extra interface in the device with a dfu descriptor. No software to support it only a "fake" announcement on the devices part. That extra descriptor can possibly confuse windows thinking it haven't seen the device before.

Re: honkens' open source usb stack

Reply #54
Hi all,

Been busy taking care of the family but have recently found some tinkering time.
Since last I have "reversed" my stack so I will be able to make a lib out of it.
Ie. the call tree is now rooted in the class or vendor implementation (CDC-ACM in our case).

In that process I also implemented a interrupt driven stack and this or the other broke everything.
It took me several late nights to make it work again. I have tinkered so much I don't really know what made it work.
I have started to consider a custom prebuild step of committing to version control (Then I could also brag of "Build 2345" like micro-soft ;-) )

Well, I have it running again. So I started to shoehorn it into the USBIRtoy source, replacing the Microchip one.
When I finally edited the lot I hit a corner case in the cof2hex stage of the build.
The linker runs well and produces .map and .cof but "MP2HEX 4.14" fails with the message
Quote
A language-plugin exception occurred and was logged.

Have anyone seen this before?

I actually get a .hex file, but need ideas on how to check if it is all in there, ie usable.

Attached is my modifications, VID and PID are those of the USBIRtoy, bcdDEV = 0x0002.

Re: honkens' open source usb stack

Reply #55
I got the same error, and I eliminated it by removing the .map file from the other files. Not sure if that is permissible though. I'll test it out now. My version of C is newer than yours:

Quote
Release build of project `C:Documents and SettingsianDesktopdownloadsUSBIRtoyIRtoyUSBIRToy.mcp' succeeded.
Language tool versions: mpasmwin.exe v5.37, mplink.exe v4.37, mcc18.exe v3.36, mplib.exe v4.37
Got a question? Please ask in the forum for the fastest answers.

Re: honkens' open source usb stack

Reply #56
It doesn't enumerate without or without the .map, I get the 'device has malfunctioned error'. I'll try to do a little debugging later and see where it get hung up.
Got a question? Please ask in the forum for the fastest answers.

Re: honkens' open source usb stack

Reply #57
The usb interrupt service doesn't play nice with the others.
I placed USB in the lower priority, but if the GIE/GIEH is set to zero somewhere it'll also shutdown usb communication.

I added a couple of calls to the usb_handler function in place of the old calls to ...TxService... something.
When the stack isn't running as an interrupt, there is some problem with the putc function, but as the old implementation does its own buffering I went with that path.

The project is set to Debug build and wont probably fit together with the bootloader. The first thing I did when I received my irtoy was to flash my own firmware directly with pickit2.

Now the board answer "V110" upon sending "t", but the IRToySelfTest.exe gives this
Quote
C:Documents and SettingsTomasMina dokumentProjektdp-svnUSBIRtoysoftware
RToySelfTest>IRToySelfTest.exe -d COM10
-------------------------------------------------------------------------

 IR TOY SELF TEST utility v0.1 (CC-0)
 http://dangerousprototypes.com

-------------------------------------------------------------------------

 Parameters used: Device = COM10,  Speed = 115200

 Press Esc to exit, any other key to start the self-test


 Hold the IR Toy very close to something white for the self-test

 Starting test!
 Opening IR Toy on COM10 at 115200bps...
 Starting IR TOY self-test...
 Getting self-test result...
 Error: IR Toy doesn't have a reply for version command
 Test no: 1 of 1
 IR Toy Self Test Reply: V110
 V110


 ERROR: test FAILED! :(

 Invalid response from IR Toy
  Press any key to continue...

 Connect another IR Toy  and press any key to start the self-test again
 Or hit ESC key to stop and end the test.

Is that supposed to happen?

Ian: If you decide to run with my stack, perhaps I could be given svn access instead of posting zips.

Re: honkens' open source usb stack

Reply #58
I added your current email in this forum to the dangerous prototypes SVN. There should already be a few different 'honken stacks' floating around.

That reply is correct (V110), maybe the self-test app is looking for a certain version of the firmware. I'll check it out.
Got a question? Please ask in the forum for the fastest answers.

Re: honkens' open source usb stack

Reply #59
I ran it under debug. Here's a look at my tests:
http://www.whereisian.com/files/h-irstack.swf

If I test the interface from herculese (v for version, t for self test, r for RC5 (and OK), 0x02 for SUMP (and 1ALS)), many of the commands work.

I also get a failure on the self-test app, but only if I don't run herculese first. The self-test app might be sending garbage or funny control channel settings when it starts.
Got a question? Please ask in the forum for the fastest answers.