Rhys

Ok, I see where you are going with that. The prototype functions I setup assume that you pick one of the three options for the joystick, either AN8, AN16, or Digital. They are meant to allow a simple single x/y axis, 8 button joystick for simple use scenarios. For what you are talking about, that is far more complex than I plan to deal with for simple prototype functions, and is why I will include the ability to build custom HID devices. I haven't decided yet exactly how I'm going to set that up. I will probably create an example program to show how to create a custom HID descriptor, h

Digital Joystick - My bad, that should be a signed int, but the valid range is -1 to 1. If you look at my earlier arcade control panel code, that is what I used. Button toggle code - Your idea makes more sense and makes toggling a button much simpler. Thank you! Multiple simultaneous presses - That would be covered by the *****_report() command, you can feed a full HID report for that device in a single variable array. That is still a work in progress and I may come up with a better solution along the way. multiple device names - I had thought about using a device number rather

I should be able to knock out the wrapper in a few weeks (if I get time to work on it) along with instructions for how to integrate it and usblib into Energia until such time as TI decides to move the usblib to a BSD license. TI's usblib is relatively feature complete as far as I'm concerned. It's not even all that terribly difficult to use if you want pretty decent controls over your device. However, definitely not friendly to use for the Arduino type crowd. I just didn't see the point in reinventing the entire wheel when I could just put training wheels on it lol.... I have a reasonable

I know nothing about MTP, and I don't believe I've seen any reference to it in the TI usblib (may have just missed it). Not really something I'm looking to do at this time. I'm not entirely positive if I am even going to bother with Mass Storage mode at this point anyways. Not something I need for any projects I'm working on. If someone else wants to add it, they are welcome to do so. I'm putting the prototype in place as a placeholder at this point. All I'm looking to do is USB HID and CDC. This is just a start on the header file for a library wrapper to get some semblance of USB suppo

//Standard HID devices //keyboard - Keyboard //mouse_rel - Mouse - Relative x/y axis //mouse_abs - Mouse - Absolute x/y axis // //Choose only one resolution option each when initializing Joystick 1 and 2 // //joy1_AN8 - Joystick 1 - x/y axis 8bit resolution (range -127 to 127) //joy2_AN8 - Joystick 2 - x/y axis 8bit resolution (range -127 to 127) // //joy1_AN16 - Joystick 1 - x/y axis 16bit resolution (range -32767 to 32767) //joy2_AN16 - Joystick 2 - x/y axis 16bit resolution (range -32767 to 32767) // //joy1_DIG - Joystick 1 - x/y axis 1bit resolution (range -1 to 1

I see what you mean now. I can see where that might be useful if you can find host software that supports it. I do not write windows/Linux software however, so I wouldn't be much help with that. I don't believe I had started a thread on here regarding the LCD/AT91SAM9 combo I would like to reverse engineer. I do have a project posted on Hackaday regarding it though. There are pictures and details on the board there. There is also a link to the firmware and host control software packages hosted on my dropbox. I would be happy to donate one of these to someone if they are fairly certai

composite devices (ie. CDC & HID) would be a part I forgot to add to the list. custom mouse types would be included in the custom HID descriptor portion of the code. HID devices are essentially just a descriptor that tells the host how many bytes of data to expect and what to look for in those bytes, and then code to push those packets into the USB FIFO. Any custom HID descriptor code would therefore allow for the end user to design any HID device they would like. Printer would be a class I wouldn't even touch until I had CDC and HID host/device complete, as I can't really see mu

If you want to natively drive an LVDS LCD, your best bet is to take a look at some of the ARM Linux single board computers, ie. cubieboard, o-linuxino, or iTeaduino Plus. I just got an iTeaduino Plus A20 a few days ago, with the intention of using it with an old laptop LCD. I have a ways to go to figure out custom kernels, drivers, and interface, but it is very doable. The AllWinner A10/20 and i.MX6 based SBCs all have native LVDS display functionality built in if you can figure out how to use it. Right now I'm stuck at either needing a custom LVDS cable, or trying to find a supplier for t

Yeah, I'm not thrilled with the Arduino USB API, it doesn't really accomplish much, and definitely not anything I would want to do. I haven't found any others I particular like either. They are all either WAY too basic like Arduino, or way more complex than is appropriate for Energia like the TI usblib. I will probably end up developing my own API based on things people actually might want to do, and throw in Arduino API compatibility for support of existing Arduino sketches. Here's a rough list of things I want to include. I haven't even started planning the actual API itself yet. I

Ok, so I've come to the conclusion my coding skill is not up to par for writing a USB stack, or even modifying an existing one, for the purpose of getting USB support into Energia. I on the other hand, should be able to handle writing a wrapper for the TI usblib to act as a wedge to emulate the USB device functions currently in the Arduino environment. It's not an ideal solution at this point, but if TI is working on opening up the usblib license to BSD, it would be a workable solution. In the mean time, the wrapper can be made available with instructions on how to add the TI usblib and wra

Well, my thought at this point is to start small and see if I can get a USB CDC Serial device library working to start with, and then move on to HID. Unfortunately, I don't have tons of free time to work on it right now, so it may be a bit slow going. Right now I'm working on picking through a handful of OSS USB stacks to see if I can cherry pick out the bits and bobs to put together the CDC library. I also have to do some serious digging into the low level USB HAL in the driverlib. I have to reconcile what the TI USB HAL offers against the HAL layer in the open source stacks before I can

Nada, no response on the e2e forum from TI regarding the licensing I've just started to dig into various open source USB stacks. They all will require significant work to make usable with Energia, and will likely take me months to sift through and start to come up with a workable solution. I have a full time job and a family, I don't have a lot of time to work on it and it's going to be slow going. That's why I was hoping to find a few collaborators willing to help with the project.

I posted on the e2e forum regarding the usblib license and have received no response to date.

VID/PID isn't really an issue. A properly implemented USB library would require the end user to configure a VID/PID combo in their code at time of use. That could be TI's, V-USB's, or your companie's, or whatever one you want to use. Implementing a CMSIS driver library might be a little beyond my skill level. That's more of a silicon vendor sort of thing. TI already has a low level USB hardware library in the driverlib that has a BSD license, I don't really want to reinvent the wheel. I just want to get a stack for the rest of it setup for Energia so the USB can be used there.

@@bluehash - I'm good on hardware at the moment. I have a TM4C123 sitting on my desk, and a TM4C1294 that should be here in a day or two. @@dubnet - I'm not sure if I'm up to the task or not. I'm still relatively new to writing code myself.... I have written a few USB device firmware sets using the TivaWare USB library though, including some modifications to the USB library code itself. @@pabigot - I will look into that, it's definitely an idea that may save starting completely from the usb hardware driver in the driverlib (which is under a BSD license).