What IO/sound port do you want?
3.5 mm link port for sound.
 100%  [ 5 ]
2.5 mm link port
 0%  [ 0 ]
Total Votes : 5

So, this is one of the polls for OTARM.

So, let's hear it. 3.5 mm for sound, 2.5 mm, or none at all? Remember, this is for the ARM OTCalc, not the z80.

Polls end September 17, 2010.
Other - 3.5mm port for I2C, and 3.5mm port for audio via an actual AC97 codec, or even just a simple DAC.
KermMartian wrote:
Other - 3.5mm port for I2C, and 3.5mm port for audio via an actual AC97 codec, or even just a simple DAC.

I2C? Can you show that in a calc diagram. Also, kermM, the IO port will be like the Ti one if it's 2.5 mm. If it's 3.5 mm a codec will probably be used. The only thing I can think of for 2.5 is cbl/cbr.
I'm suggesting two separate stereo 3.5mm ports. Wait, did you miss the whole I2C discussion? If so, let me link you; we more or less decided that that would be the best link protocol to use for a serial-type port.
KermMartian wrote:
I'm suggesting two separate stereo 3.5mm ports. Wait, did you miss the whole I2C discussion? If so, let me link you; we more or less decided that that would be the best link protocol to use for a serial-type port.

Missed it. I googled it, but don't really understand it.
graphmastur wrote:
KermMartian wrote:
I'm suggesting two separate stereo 3.5mm ports. Wait, did you miss the whole I2C discussion? If so, let me link you; we more or less decided that that would be the best link protocol to use for a serial-type port.

Missed it. I googled it, but don't really understand it.


Ah, then start reading here and then keep reading:

http://www.cemetech.net/forum/viewtopic.php?p=106394#106394
Okay, so how do you hook up 3 calcs via i2c? Is there a cable that would have to be modified?
Special cables or star hubs, I'd think.
graphmastur wrote:
Okay, so how do you hook up 3 calcs via i2c? Is there a cable that would have to be modified?
No, just like CALCnet, it's a shared-line protocol, so it's simply putting the three lines of each device in parallel. It's a bus.
I'm not sure it would be technically possible to implement I²C fully according to the standard (the calculators would need to be able to respond to a 100kHz clock when acting as slave devices) so it may be prudent to give it a different name, but keep it as a "slow" form of I²C internally. (This is assuming the protocol is being bit-banged by the Z80). There is also the issue of how new devices of the same type (e.g. calculators) assign themselves slave addresses in a vaguely elegant manner.
Oh, that would loose some of its appeal if we can't plug-and-play I2C hardware. Didn't MV pull off I2C on a TI-83+ though; wouldn't that make it viable on an "OTz80" calculator?
A master generates the clock signal. Slave devices will respond to clock speeds down to 0Hz, so in a single-master bus, or bus where all masters only ever run at a calculator-friendly low speed, it doesn't matter if you're running at a much lower clock speed. I²C is, however, a multi-master bus, so a compliant I²C arrangement would need to work if someone connected a "standard" 100kHz master to the bus. I'm not sure a calculator bit-banging the protocol would be able to keep up with such a clock speed.

Most I²C peripherals (memories, clocks, displays etc) are slave devices so the slow clock won't be an issue there, and yes it does work. MV has done it successfully on the calculator, and my previous Z80 computer design running at a whopping 2MHz used an I²C EEPROM for storage and a DS1307 for timekeeping. However, neither of these had to cope with a 100kHz master trying to muscle in on the action.

(Any thoughts on supplying power over the bus? Using TRRS would seem logical but mixing TRRS and TRS would result in short circuits. It's a shame 1-Wire is so picky about timing).
Ah, that makes sense. Do multi-master arrangements require new masters to look for existing masters, and is there any way for an original master to nack a new master either off the bus or into a slave mode? That's still hacky and a bit restrictive, though. You don't think we should abandon the I²C plan entirely though, correct, just not label it as I²C for the terms of features (maybe "partially I²C-compatible" or something equally bet-hedging)?

I didn't consider power; too bad there's not a TRS-shaped TRRS jack and plug (but longer!) so that inserting a TRS plug will touch TRS to RRS, and a TRRS plug to TRRS, so that the tip could be used for +5v. Added bonus, you wouldn't short +5v against random contacts during insertion or extraction.
Communication is always initiated by a master addressing a slave (the least significant bit of the address byte denotes the direction of subsequent data - from master to slave or from slave to master). As such "masters" do not have addresses, only slaves do (of course, a single device could act as both master and slave, which I imagine we'd want the calculators to do). I recommend taking a look at the I²C specification 2.1 for more information. All data transfers are surrounded by simple "start" or "stop" conditions, so the main time things could get tricky is if two masters see the bus is idle and attempt to initiate a data transfer at the same time. Arbitration is relatively simple owing to the wired-AND nature of the bus; see the above specification for more details.

The newer version 3 of the specification has some ideas on how to assign addresses in section 3.13 ("General call address").

One thing 1-Wire got right was assigning each device with a unique 64-bit code. A 64-bit address space is rather more spacious than a 7-bit one!
Thanks for that, I'm reading through that now. And I'll say that a 64-bit address space is better than a 7-bit one. :/
So, is this decided? I really don't like the idea of I2C, as I see it as unnecessary. I actually plan to have a wireless add on, or something.
graphmastur wrote:
So, is this decided? I really don't like the idea of I2C, as I see it as unnecessary. I actually plan to have a wireless add on, or something.
Why do you see it as unnecessary, and what would you prefer? I think the biggest objections to wireless are:

1) power consumption
2) acceptability for testing, even if it's just homeroom / in-school tests, not even standardized SAT-type tests
3) complexity of coding
4) use of I/O power and hardware
Well, I think that the majority of users won't splice their cables for a calculator network. I just don't see it as something that most users would use. I'm also thinking that if you can use a usb hub, then you could do the same thing without splicing cables. (Well, Almost the same thing. It would be slightly different, but either way...)

I don't know, I just think the average user wouldn't do that. I don't think they would have a need for multiple calculators. And calc<->calc can be done via usb.
Well yeah, but a USB hub doesn't work that way, it can only distribute one host to multiple (almost always four) peripherals. You can't have multiple hosts on a USB hub. I2C, by contrast, could be used with a simple parallel-socket hub, just like CALCnet.
  
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 1
» 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