*one-year necro-bump*

So, I'm trying to clear out the bug/fix/feature list for Doors CS 7.2 Beta 2 so I can perhaps get to Doors CS 7.2 Beta 3, or RC 1, or something resembling a final release of Doors CS 7.2. Please, oh please, tell me detailed things that work well and do not work well as far as direct USB globalCALCnet goes.

Soon as my CALCnet axiom comes to working I am sure that we will get a lot more "willing" beta testers lol,but for now I am waiting on ti-concurs contest to end so that my beta tester will well test it :<

CALCnet testing, yes, but things like Gossamer or CALCnet Chat should be sufficient to test Direct USB. Currently I know of a segfault that happens during timeout when the client tries to reconnect to a stalled calculator, and problems with connecting direct USB when inside a CALCnet program.

Had the calc out. Figured I would try some Chat over DirectUSB. Got one message out then got this http://pastebin.com/zYi78wzB

I believe this is a common error with DirectUSB.

It doesn't look like it ever said something about finding the calculator. Would you mind trying again with the -r flag?

*bump* In addition to whatever ParkerR is reporting there, I was able to get this issue this evening:


Code:


I'm not sure what's causing it. Other issues are sporadic connections when the USB cable is plugged in while a program is running, and making it properly reconnect while a program is running.

*bump* For geekboy:

1) The issue in the previous post happens spontaneously.
2) Debugging connecting inside the program: Launch CHAT (or another program), then connect the USB cable and start the gCnClient
3) Reconnection: Disconnect and reconnect the USB cable during CHAT.
4) Reconnection #2: Stop and start the gCnClient during CHAT.

things that "hotplugging" works for

these were all tested with sandpaper and gossamer

It follows the order of such
1) plug calc into computer
2)start gcn client

that's really it as long as gcn client starts after the calc is connected it seems to be happy.
Calcside the problems happen when it is in the middle of sending or recving a data frame. But the tios seems to recover from this rather gracefully. OR completely crap it self and freeze. not to sure on that one honestly.

There are a few problems with the gcn client at the moment. handling the unplugged usb device. It likes to error out back to the command line with out an attempt to reconnect. I think this is more of the libusb driver bug then your code but i'm sure you can case it to, on d/c or errors ,to attempt re-connection maybe?

I often have a problem connecting. The client works magnificently for me, but when I try to connect with other calcs, it often crashes.
Me and Sorunome took like 10 tries to use SandPaper.
Does gCn act as a literal physical connection between calcs?

was this over i/o? or usb? and define crashes please use the -v flag and paste the output its hard to understand how it is breaking with it just crashes ^^

Yeah, details in a bug report are rather vital.

*bump* Thanks to geekboy's nagging and BrandonW's and Jonimus's prodding during HCWP, I was able to make great strides with both the client and the on-calculator USB code. The only problem that appears to be remaining happens when I unplug and replug the cable in the middle of a program. My debug pixels show that the code is correctly detecting the cable's absence and later presence, but the OS code doesn't seem to bother re-initializing things. On BrandonW's suggestion, I tried variations on _KillUSBDevice, _RecycleUSB, and _InitUSB, with varying success. In one particularly "amusing" case, I got it to work exactly every even hotplug attempt (0th, 2nd, 4th, ...).

Edit: Note to self: Not only does letting the OS interrupt run on every Cn2.2 interrupt cycle not help, you also get random RAM clears. And the client still can't reconnect all the time. So something else is getting messed up. What the heck state do I need to fix?

brandonw poped up with this. may be helpful

Well, I don't seem to get any more RAM clears, but the reconnection still seems to be sporadic. If the cable has just changed state (plugged out or plugged in), and the cable is now unplugged, I run the following code:
Code: