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

As the title says, vote on either having a 2.5 mm or 3.5 mm link cable!

Consider the options carefully.
2.5 mm = good old cable, also very small, TI-8x compatible, needs adapters for sound
3.5 mm = good cable, not TI-8x compatible, can have headphones = sound

Happy voting! Smile
Personally, I think the 3.5mm is the way to go. I can go the the store and buy new 3.5mm if I need to. 2.5 would be ordered from only TI that I know of.

Also, if you don't plan on having software compatibility with the TI-8x line, then why bother having hardware compatibility that causes more headaches IMO.
rivereye wrote:
Personally, I think the 3.5mm is the way to go. I can go the the store and buy new 3.5mm if I need to. 2.5 would be ordered from only TI that I know of.

Also, if you don't plan on having software compatibility with the TI-8x line, then why bother having hardware compatibility that causes more headaches IMO.

Yeah, what he said. Razz
Note: Exiles says 2.5 mm!
======================
3.5 mm for me Wink
How about not using a stupid 2-wire link cable? If we use USB instead, it's much faster and we can reserve a 3.5mm jack entirely for sound.
willrandship wrote:
How about not using a stupid 2-wire link cable? If we use USB instead, it's much faster and we can reserve a 3.5mm jack entirely for sound.
USB would be nice, but what I would really really like, either instead or in addition, would be an honest-to-god DB9-compatible serial port for all kinds of console, hardware, and communication and modding hijinks.
willrandship wrote:
How about not using a stupid 2-wire link cable? If we use USB instead, it's much faster and we can reserve a 3.5mm jack entirely for sound.
Because USB isn't a 2-wire link cable, is it? Smile (I see what you mean, though).
Quote:
USB would be nice, but what I would really really like, either instead or in addition, would be an honest-to-god DB9-compatible serial port for all kinds of console, hardware, and communication and modding hijinks.
DE-9, and I'd have to disagree - a RS-232 port is not desperately practical due to the silly voltages involved (unless you have voltage inverters/multipliers on both ends). I think I²C would be much more suitable; the physical bus is open collector/drain with pull-ups (like the existing TI link port), it's not sensitive to timing (the standard speed has a clock of "up to" 100kHz, but can run much slower if need be), supports multiple slaves and masters on a single bus (each responding to their own address), has a wide variety of existing slaves and is widely implemented on cheap microcontrollers should you want to develop your own.
benryves wrote:
willrandship wrote:
How about not using a stupid 2-wire link cable? If we use USB instead, it's much faster and we can reserve a 3.5mm jack entirely for sound.
Because USB isn't a 2-wire link cable, is it? Smile (I see what you mean, though).
Quote:
USB would be nice, but what I would really really like, either instead or in addition, would be an honest-to-god DB9-compatible serial port for all kinds of console, hardware, and communication and modding hijinks.
DE-9, and I'd have to disagree - a RS-232 port is not desperately practical due to the silly voltages involved (unless you have voltage inverters/multipliers on both ends). I think I²C would be much more suitable; the physical bus is open collector/drain with pull-ups (like the existing TI link port), it's not sensitive to timing (the standard speed has a clock of "up to" 100kHz, but can run much slower if need be), supports multiple slaves and masters on a single bus (each responding to their own address), has a wide variety of existing slaves and is widely implemented on cheap microcontrollers should you want to develop your own.
Fair enough, I can definitely live with an I2C bus, and it would be trivial to use I2C for inter-calc communication (even networking, since I2C already, as you said, supports multiple devices on a bus). What does everyone else think? I2C is a two-wire protocol though, which might make willrand unhappy. Very Happy
KermMartian wrote:
I2C is a two-wire protocol though, which might make willrand unhappy. Very Happy
As mentioned, USB is a two-wire protocol too. Wink We could always go for the 1-Wire bus, though that has fairly critical timing...
KermMartian wrote:
benryves wrote:
willrandship wrote:
How about not using a stupid 2-wire link cable? If we use USB instead, it's much faster and we can reserve a 3.5mm jack entirely for sound.
Because USB isn't a 2-wire link cable, is it? Smile (I see what you mean, though).
Quote:
USB would be nice, but what I would really really like, either instead or in addition, would be an honest-to-god DB9-compatible serial port for all kinds of console, hardware, and communication and modding hijinks.
DE-9, and I'd have to disagree - a RS-232 port is not desperately practical due to the silly voltages involved (unless you have voltage inverters/multipliers on both ends). I think I²C would be much more suitable; the physical bus is open collector/drain with pull-ups (like the existing TI link port), it's not sensitive to timing (the standard speed has a clock of "up to" 100kHz, but can run much slower if need be), supports multiple slaves and masters on a single bus (each responding to their own address), has a wide variety of existing slaves and is widely implemented on cheap microcontrollers should you want to develop your own.
Fair enough, I can definitely live with an I2C bus, and it would be trivial to use I2C for inter-calc communication (even networking, since I2C already, as you said, supports multiple devices on a bus). What does everyone else think? I2C is a two-wire protocol though, which might make willrand unhappy. Very Happy
I like this idea.
Good, then it's settled! Very Happy I guess we're also agreeing to use a 3.5mm system for the external I2C bus then, based on the poll at the top of this topic.
The only issue I see with i2c is that, iirc, it uses fixed addressing, which creates an issue for hotplugging.
TheStorm wrote:
The only issue I see with i2c is that, iirc, it uses fixed addressing, which creates an issue for hotplugging.
Why would hotplugging be a problem? You'd just need to make the calc-side host smart enough to do some timing out if the remote device doesn't respond in a timely manner. Do you mean something other than hotplugging, perhaps?
I just don't like how pathetically slow the connection of the 2.5mm plugs were. I've never actually heard of i2c, but from what I read on wikipedia, it looks nice. All I wanted to say there is to please not use something so old it's compatible with TI calcs. I don't really have anything against 2 line communications.
willrandship wrote:
I just don't like how pathetically slow the connection of the 2.5mm plugs were. I've never actually heard of i2c, but from what I read on wikipedia, it looks nice. All I wanted to say there is to please not use something so old it's compatible with TI calcs. I don't really have anything against 2 line communications.
The best linking protocols I've heard of for TI calculators can achieve about 2kbps on the 6MHz calculators, or just under 5kbps for the 15MHz calculators. It seems to me that the I2C limit of 100kbps is substantially (almost two orders of magnitude) larger. I see no reason why if people really, REALLY wanted, we couldn't write link drivers compatible with the TI-OS linking protocol, but it's not a necessity.
KermMartian wrote:
TheStorm wrote:
The only issue I see with i2c is that, iirc, it uses fixed addressing, which creates an issue for hotplugging.
Why would hotplugging be a problem? You'd just need to make the calc-side host smart enough to do some timing out if the remote device doesn't respond in a timely manner. Do you mean something other than hotplugging, perhaps?
Each I²C device responds to a 7-bit address. The master usually has to know about this address in advance (though it's quick enough to hammer through every possible address and see if any device acknowledges); I suspect the real issue is connecting multiple devices with the same address to the bus. Most slave device have external pins to let you configure the least significant bits of the address, but this isn't desperately practical if you want a simple plug-and-play approach for (say) multiple calculators on a single bus.

I suppose a slave could assign itself an address by acting as a master, generating a random address, and probing the bus to see if it's currently in use first, but I've never tried that to see how well it would work.

The main advantage of I²C is how widely supported it is, making the development of new peripherals easier.
I like the idea of a slave finding itself an address that way. Smile I don't see too many shortcomings to this general 3.5mm / I2C plan.
Wow.... this topic exploded into a full blown discussion. I'll definitely take note of that. Wink

The I²C bus is a very speedy bus, although I'm not sure if cables can use it. Smile I think it's more for memory chips and such...?
alberthrocks wrote:
Wow.... this topic exploded into a full blown discussion. I'll definitely take note of that. Wink

The I²C bus is a very speedy bus, although I'm not sure if cables can use it. Smile I think it's more for memory chips and such...?
What do you mean if "cables can use it"? You mean if you can connect devices via cables instead of via PCB traces? Of course you can extend it over wires, provided they're decently shielded...
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.
  
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 1 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