| 2.5 mm or 3.5mm link cable? |
| 2.5 mm link cable |
|
10% |
[ 1 ] |
| 3.5 mm link cable |
|
90% |
[ 9 ] |
|
| Total Votes : 10 |
|
alberthrocks wrote:
I thought you guys were talking about integrating I²C for use in calc to calc communication via I/O cable and such... but I just skimmed the topic.
Yeah, that's exactly what we were saying. Take a few minutes and read through it more carefully. 
they were
willrandship wrote:
they were
For calc to computer linking we should use USB. the cables are much more widely available.
souvik i2c chips are very commonly available, a USB to i2c cable should be fairly straight forward to make and could even be included if we opt to not include a USB port.
TheStorm wrote:
souvik i2c chips are very commonly available, a USB to i2c cable should be fairly straight forward to make and could even be included if we opt to not include a USB port.
Yeah, that's more or less what I was thinking as well. 
2.5 mm. The adapter is cheap, and you'd need one anyway to talk with ur other calculators. I guess you could use USB on the new ones, but the old link port still works on EVERY calc I own!
adept wrote:
2.5 mm. The adapter is cheap, and you'd need one anyway to talk with ur other calculators. I guess you could use USB on the new ones, but the old link port still works on EVERY calc I own!
The adapter may be cheap, but it's not always easy to find, particularly for people who live in the middle of nowhere and don't want to order it online. And if we used a 2.5mm jack, we'd have to have the calculator come with a 2.5mm link cable (or at least offer them) instead of just using audio patch cables.
Yeah. People can make their own 3.5mm to 2.5 mm for emus, but we aren't planning direct calc compatibility to TI's stuff. That's probably illegal anyways, because we'd probably be copying patented methods.
willrandship wrote:
Yeah. People can make their own 3.5mm to 2.5 mm for emus, but we aren't planning direct calc compatibility to TI's stuff. That's probably illegal anyways, because we'd probably be copying patented methods.
Well, the DMCA has an exception clause for reverse-engineering for the sake of compatibility (the same or a similar clause to the one that protected Ben Moody, Brandon Wilson, et alia from TI's frivolous C&D orders. I think the biggest issues is the work that would be required to write in backwards-compatibility to TI calculators. I'm almost positive that someone would do it at some point if this project was completed and manufactured, but it shouldn't be the focus of the interface design.
Wouldn't there be a slight problem with using I2C when it comes to giving calcs addresses? Less of a problem if it's just two calcs, but if you ever wanted to join three or more, and hot plug them to a "network"...
I agree that I2C is the right choice, though.
calcdude84se wrote:
Wouldn't there be a slight problem with using I2C when it comes to giving calcs addresses? Less of a problem if it's just two calcs, but if you ever wanted to join three or more, and hot plug them to a "network"...
I agree that I2C is the right choice, though.
Not at all! As Ben Ryves and I were saying, each new calc could just probe the addresses of the bus, wait for an address with no response, and sit itself down on that.
Ah, ok. I doubt you'd connect so many that it would become a problem. (Who has the hardware and the money to connect 101 calcs?
(The maximum allowed by I
2C unless you want to use 10-bit addressing))
calcdude84se wrote:
Ah, ok. I doubt you'd connect so many that it would become a problem. (Who has the hardware and the money to connect 101 calcs?
(The maximum allowed by I
2C unless you want to use 10-bit addressing))
Edit: Wikipedia wrote:
The I²C reference design has a 7-bit address space with 16 reserved addresses, so a maximum of 112 nodes can communicate on the same bus.
I see. It's a 7-bit address space.
Oh, 16 reserved, oops. Idk where I got 27...
At any rate, it's a lot of calcs
calcdude84se wrote:
Oh, 16 reserved, oops. Idk where I got 27...
At any rate, it's a lot of calcs
It's sounding like I2C is almost definitely the way to go; are we agreed?
Is there any reason to hook that many together by cable? At that point it would be so much more practical to get something like TI's Wireless cradle instead, like a usb dongle in each calc.
willrandship wrote:
Is there any reason to hook that many together by cable? At that point it would be so much more practical to get something like TI's Wireless cradle instead, like a usb dongle in each calc.
Oh, there would definitely need to be some kind of helper hardware on a 112-calculator network. I seriously doubt one calculator could ground a line on 111 other calculators.
Exactly. I don't think we need to heavily consider these extremes in the calc design.
willrandship wrote:
Exactly. I don't think we need to heavily consider these extremes in the calc design.
I don't think so either. I think a normal use case of one calculator to another calculator or one calculator to one peripheral should be the main things we consider, and I think an I2C bus would be appropriate for that.
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
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
