I can't test it today, but I will definitely test it tomorrow.
Working out pretty well on my end. Not without it's flaws but I believe all have been mentioned. Thank you KermM, Jonimus, Shaun/Merth, and all who contributed.
I'm headed to sleep now, thank you very much to everyone who is helping test! I'd imagine that the main problem is stemming from one fundamental difference between I/O and USB. With I/O CALCnet, a calculator can simply choose to not receive frames that it doesn't have the resources to deal with yet (ie, the receive buffer is full). The sender will just keep trying until the receiver acknowledges the incoming frame with a checksum. With USB, though, ignoring data is much less clean. I can only imagine that something is getting disturbed, either the calculator is getting confused when USB data is ignored, or perhaps the client PC-side is dropping frames that time out, which it shouldn't. Any ideas? Jonimus and the other PC side experts, any thoughts?
Well I found one thing that may help with getting the connection to work the first time around. Haveing the hub drop packets until a calc has sent a proper calcnet broadcast. It shouldn't hurt to do this since the calc will be ignoring these packets anyway. Right now it seems as soon as there has been one timeout in usb_bulk_write they continue to happen. Once in a while it will recover from them but it seems to have a better chance of recovering if the timeout occurred after the calcnet program was started.
I also started to look into some code to detect cable disconnects sooner which I can share with you in the morn as well as a few other changes I started to make.
As to the other issues, I haven't had a chance to dig into them much but I will when I get a chance.
I also started to look into some code to detect cable disconnects sooner which I can share with you in the morn as well as a few other changes I started to make.
As to the other issues, I haven't had a chance to dig into them much but I will when I get a chance.
"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown
"If you've done something right no one will know that you've done anything at all" -Futurama
<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.
Well, we actually do want it to be able to time out when the calc-side interrupt is unable to handle a new packet, but it shouldn't turn into an infinite timeout. I actually need to test with the two classical types of gCn bridge to make sure they still work and that I haven't done any overall breaking. The other thing that I don't like is that it doesn't seem to work to start the gCnClient program once CALCnet2.2 is already active, for some reason, which I definitely don't want to be the case.
CALCnet (and gCn through an Arduino / HID bridge) could work, unless the processor is clocked definitely too low (but I don't think so).
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Lionel Debroux wrote:
CALCnet (and gCn through an Arduino / HID bridge) could work, unless the processor is clocked definitely too low (but I don't think so).
I think the 86 has a 6Mhz processor, like the 83+.
That's what it seemed to me, thanks for the confirmation
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
I know 83+ have different connection than 84+, but is there a hope that is possible ?
(or a 84+ could be like a modem ?)
(or a 84+ could be like a modem ?)
As Souvik said, that's what the Arduino bridge and the $10 Bridge are for! This is to connect TI-84+/SE calculators over USB without needing any extra hardware. Elfprince, Merth, and I are all together IRL now, and we're going to work on Direct USB!
KermMartian wrote:
As Souvik said, that's what the Arduino bridge and the $10 Bridge are for! This is to connect TI-84+/SE calculators over USB without needing any extra hardware. Elfprince, Merth, and I are all together IRL now, and we're going to work on Direct USB!
You'd better. >
But seriously in response to your response to my earlier comment....
I think the calc is having issues recovering from write timeouts. Maybe you are not handling them properly, I'm not sure. In any case its better if your code is handling all of them so you have a better idea of the hardware state, hence why I was saying you should just drop packets until the calc has enumerated itself in order to not have the OS do things you don't want it to, at least in the DUSB case. This would also help with the calc once in a while freezing while trying to open DCS and then said calcnet program.
"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown
"If you've done something right no one will know that you've done anything at all" -Futurama
<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.
OK, that would certainly make a lot of sense, and I'll add that to the gCnClient in the morning. And I just asked Merth to help me remember. However, this does not fix the issue of why we can't plug in the cable while CALCnet2.2 is running (assuming that fails for you guys as well). And I agree that I need a better way of ignoring the incoming USB than just not handling it. Perhaps I could not run the interrupt again until the receive buffer got emptied? But I wouldn't want some kind of potential receive/send deadlock to occur. Argh.
I think that issue is unsolveable, you need the OS to handle descriptor requests and the like which it doesn't seem to do while your code is running. I think that the current setup for starting up the client is most likely the best way to do it sadly.
"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown
"If you've done something right no one will know that you've done anything at all" -Futurama
<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.
TheStorm wrote:
I think that issue is unsolveable, you need the OS to handle descriptor requests and the like which it doesn't seem to do while your code is running. I think that the current setup for starting up the client is most likely the best way to do it sadly.
Psh, I refuse to accept defeat that easily. I use detection of VUSB+ to decide when to start running the OS interrupt and thus to let the OS start USB initialization. I can only assume that something's going wrong in that process? Perhaps BrandonW could advise me on that issue.
I have a question: might you make the connecter just an exe prog? I cant run batch files @ school
thanks in advance!
thanks in advance!
And if your school allows you to run EXEs but not BATs, it's retarded.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
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
» Go to Registration page
» Goto page Previous 1, 2, 3, 4, 5, 6 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 4 of 6
» 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
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