What kind of USB would you like?
Please do mini-USB with OTG port
 100%  [ 5 ]
Please do a regular sized USB port. (female)
 0%  [ 0 ]
Please do a regular sized usb port. (male)
 0%  [ 0 ]
Total Votes : 5

So, this is one of the polls for OTARM.

So, let's hear it. Mini-USB (OTG port for both A and B mini ports), or regular USB? Regular usb can be male for like a flash drive, or female. Remember, this is for the ARM OTCalc, not the z80.

Polls end September 17, 2010.
I think that a mini-USB/OTG port would be the best, plus we could use it to help charge the rechargeable battery that the device should have.
KermMartian wrote:
I think that a mini-USB/OTG port would be the best, plus we could use it to help charge the rechargeable battery that the device should have.

Agreed. Although, I think that a miniA to female USB should be provided on a website or In The actual calculator package. 3 cables might be too much, though. Technically, with mini-A to female USB, and mini-B to male USB, you have a calc to calc link cable.
This is true, I could see how such an adapter would be less frustrating to people. Have we decided whether the host part of the OTG stuff is going to actually be implemented, though? I guess the ARM calculator is more likely to have it than the z80 has it, though, right?
KermMartian wrote:
This is true, I could see how such an adapter would be less frustrating to people. Have we decided whether the host part of the OTG stuff is going to actually be implemented, though? I guess the ARM calculator is more likely to have it than the z80 has it, though, right?

Not really. I haven't decided if it's going to be a standard flash drive (probably), or something else. I know that I will open it up for dev. That means you can change a bunch of things, too. I wish I could allow it to change the pid/vid, too. Wink
So in other words you don't think it will be able to act as a USB host out of the box?
KermMartian wrote:
So in other words you don't think it will be able to act as a USB host out of the box?

No, it can be a usb host for another calc, and possibly things like a mouse or a printer. (This is a big maybe, though) But I want people to also be able to do whatever they want with it. It will be able to receive and act on USB as well straight out of the box.
graphmastur wrote:
KermMartian wrote:
So in other words you don't think it will be able to act as a USB host out of the box?

No, it can be a usb host for another calc, and possibly things like a mouse or a printer. (This is a big maybe, though) But I want people to also be able to do whatever they want with it. It will be able to receive and act on USB as well straight out of the box.
Well, "receive and act on USB" means you're describing a slave device. There's very different software and hardware that goes into making a pure USB slave, a pure USB host, and some of both plus extras into something that can be both.
KermMartian wrote:
graphmastur wrote:
KermMartian wrote:
So in other words you don't think it will be able to act as a USB host out of the box?

No, it can be a usb host for another calc, and possibly things like a mouse or a printer. (This is a big maybe, though) But I want people to also be able to do whatever they want with it. It will be able to receive and act on USB as well straight out of the box.
Well, "receive and act on USB" means you're describing a slave device. There's very different software and hardware that goes into making a pure USB slave, a pure USB host, and some of both plus extras into something that can be both.

Well, it can act as both a peripheral and a host, just like a TI device. Although, it should be much easier to use to the average user, it can be changed for the more advanced user.
*will be able to. OK, that answers most of my question: it will have at least the hardware capability to be either a peripheral or a host. What will it have software-wise out of the box, just calc-calc communication and peripheral mode for transferring files to/from it from a computer?
KermMartian wrote:
*will be able to. OK, that answers most of my question: it will have at least the hardware capability to be either a peripheral or a host. What will it have software-wise out of the box, just calc-calc communication and peripheral mode for transferring files to/from it from a computer?

Well, obviously calc to calc communication straight out of the box. Let's see, I'll probably allow usb printing, and other simple stuff like mice and a keyboard. Any other suggestions? Ipod support? I think the majority of stuff will be done with installable libraries with a type of dev toolkit.
I'd say at least allow access to mass storage devices (flash drives, USB HDDs) and HIDs (human interface devices: keyboards, mice) out of the box. Printing sounds like a fun extra too. I hope your mind is boggling as much as mine is, though, at the thought of what exactly this would take. Razz
KermMartian wrote:
I'd say at least allow access to mass storage devices (flash drives, USB HDDs) and HIDs (human interface devices: keyboards, mice) out of the box. Printing sounds like a fun extra too. I hope your mind is boggling as much as mine is, though, at the thought of what exactly this would take. Razz

See, I'm thinking that after doing the kernel, then doing most of the code in C. I'm thinking mass storage is a great idea. I think I'm gonna design the code to be fairly open in how it's used but have a lot of it already set up, so you don't have to do 20 different things just to send a byte. So, simplicity and extensibility should be the motto here.
Right, but for C to work, you still need someone to write all the low-level ASM for accessing USB devices. C doesn't just magically get all the USB bitbanging and timing right with no underlying code. Razz
KermMartian wrote:
Right, but for C to work, you still need someone to write all the low-level ASM for accessing USB devices. C doesn't just magically get all the USB bitbanging and timing right with no underlying code. Razz

Yeah, I know. I'll be writing the kernel in asm, of course.
graphmastur wrote:
KermMartian wrote:
Right, but for C to work, you still need someone to write all the low-level ASM for accessing USB devices. C doesn't just magically get all the USB bitbanging and timing right with no underlying code. Razz

Yeah, I know. I'll be writing the kernel in asm, of course.
Of course. Will you be discussing the features of that anytime soon, or is that still a bit premature?
KermMartian wrote:
graphmastur wrote:
KermMartian wrote:
Right, but for C to work, you still need someone to write all the low-level ASM for accessing USB devices. C doesn't just magically get all the USB bitbanging and timing right with no underlying code. Razz

Yeah, I know. I'll be writing the kernel in asm, of course.
Of course. Will you be discussing the features of that anytime soon, or is that still a bit premature?

Quite a bit premature. I've still got plenty of other things to do. Once I work on TAO, C2I, finish a bunch of projects and other things, I will start planning the kernel. I will have finished TAO, though, first.
That's good, I don't want TAO to get dropped at the wayside anywhere, based on the impressive overview that you mentioned in its topic. It seems to me that even discussing OTARM hardware at all is a bit premature, considering how not-far-off the ground the OTz80 calculator is thus far.
  
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