Well, you can't exactly make software without hardware being available to test with Razz
If you can get a version of this software that works on an actual computer, then u can just use a USB cable to connect your calc to your computer, and to the internet, that would be cool.
@WillRandShip: I most certainly can; I modified my existing gCnClient program source to have a space to set up the USB connection instead of the serial connection, and broke apart the places where serial input/output is performed to be able to plug in USB code conditionally. That's irrelevant anyway, because I had the hardware working on my breadboard. The only new thing was moving it from a temporary solderless breadboard to soldered onto perfboard. Ben, if you happen to see this, can you clarify if USB HID specs require you to send all the way to the device whenever you want to read, or if the device can asynchronously write to the host to be buffered and later read? The documentation I'm finding seems to conflict about this.

@Anthony: You mean the firmware? There are pages and pages of posts in topics here where I've explained to Sonlen why that's not possible. However, if you read carefully, I have a direct-USB solution for TI-84+/SEs in the planning stage.
Sounds close enough to what I meant. lol.
ACagliano wrote:
Sounds close enough to what I meant. 0x5.
If you want to see more about why you can't trivially eliminate the gCn bridging hardware, then read this topic.
I understand now. It must get frustrating for you with people asking the same thing over and over because they either don't read or don't understand.
ACagliano wrote:
I understand now. It must get frustrating for you with people asking the same thing over and over because they either don't read or don't understand.
Something like that. Wink
*bump* Here's an image of the hardware build. I'm quite embarrassed about the wire routing on the PCB; if there's a lot of interest in these, I may have to design a custom board. Anyway, I've also made some progress on the software side. I ripped out the guts of the UsbStream Arduino class as wholly inadequate, and I'm writing code to directly interface with the V-USB libraries. I had to reconfigure (and then debug) some of the standard Arduino bridge code, since the Arduino and USBHID/$10 bridge firmware is built from the same source code file, but a handful of Obliterate games in which Merth owned me convinced me that it's working, so I'll press on with both software and firmware. Once I get both working and release the gCnClient v1.0, it'll be Direct USB time!

I'm looking forward to the Direct USB stuff, because then I can test CnT over gCn. Very Happy
Well, I'll probably use the standard Arduino route, since I have one Razz
willrandship wrote:
Well, I'll probably use the standard Arduino route, since I have one Razz
Good, that's the one method that's end-to-end complete. During HCWP yesterday, I realized that there's nine different pieces of software that I've written that work together to transport frames every time your calculator sends or receives to/from gCn
KermMartian wrote:
*bump* Here's an image of the hardware build. I'm quite embarrassed about the wire routing on the PCB; if there's a lot of interest in these, I may have to design a custom board. Anyway, I've also made some progress on the software side. I ripped out the guts of the UsbStream Arduino class as wholly inadequate, and I'm writing code to directly interface with the V-USB libraries. I had to reconfigure (and then debug) some of the standard Arduino bridge code, since the Arduino and USBHID/$10 bridge firmware is built from the same source code file, but a handful of Obliterate games in which Merth owned me convinced me that it's working, so I'll press on with both software and firmware. Once I get both working and release the gCnClient v1.0, it'll be Direct USB time!



Will the Direct USB solution rely on using a single calculator as a dedicated bridge? Or will that calculator still be able to engage in games as well?
On the contrary, I'll be first implementing a direct USB solution in which the single calculator can only itself participate. I will later consider the opposite, in which that calculator can bridge other calculators but cannot itself participate.
Sounds excellent =)
elfprince13 wrote:
Sounds excellent =)
Thanks! I'm still working on the $10 hub at the moment and loving/hating the tribulations of writing USB drivers. Benryves is being his usual invaluable self.
So, just to clarify. Will the Direct USB project enable you to connect your calculator directly to the USB port on a computer? Or will there still be the necessity of some sort of bridge?
ACagliano wrote:
So, just to clarify. Will the Direct USB project enable you to connect your calculator directly to the USB port on a computer? Or will there still be the necessity of some sort of bridge?
If it works, it will allow you to connect your calculator directly to the USB port on a computer.
*bump* So, with the following feature descriptor, Windows happily installs the gCnBridge and declares it ready for use:


Code:
PROGMEM char usbHidReportDescriptor[USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH] = {    //USB report descriptor
    0x06, 0x00, 0xff,              // USAGE_PAGE (Generic Desktop)
    0x09, 0x01,                    // USAGE (Vendor Usage 1)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x01,                    //   REPORT_COUNT (1)
    0x09, 0x00,                    //   USAGE (Undefined)
    0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
    0xc0                           // END_COLLECTION
  };
However, if I switch to my proper descriptor, Windows claims that the drivers failed to install:


Code:
  PROGMEM char usbHidReportDescriptor[USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH] = {    //USB report descriptor
    0x06, 0x00, 0xff,              // USAGE_PAGE (Generic Desktop)
    0x09, 0x01,                    // USAGE (Vendor Usage 1)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 134,                    //   REPORT_SIZE (8)
    0x95, 2,                    //   REPORT_COUNT (1)
    0x09, 0x00,                    //   USAGE (Undefined)
    0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
    0xc0                           // END_COLLECTION
  };
Does anyone know what I might be missing?
More fun ahead! :p
http://developer.apple.com/library/mac/#qa/qa2004/qa1370.html

Maybe I'll have to make another trip to NYC Wink
elfprince13 wrote:
More fun ahead! :p
http://developer.apple.com/library/mac/#qa/qa2004/qa1370.html

Maybe I'll have to make another trip to NYC Wink
Oh dear, it looks like Mac OS doesn't follow the USBHID standard as I had hoped. Sad What do you know about C# and Mac OS? Merth wanted to write the direct USB bits in C#, but I don't know how portable that is.

Edit: So apparently some edits ended up in the wrong file or something; my 8/268 firmware loads and installs, but no luck chatting with it yet.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement