For a school project, I wish to use my calculator to drive a miniature car. The point of the project is to have a gear train system (Like a 2-3 speed transmission) in order to provide some sort of mechanical advantage. I have access to many rapid prototyping and CAD systems, however I have insufficient knowledge of general electrical hardware.

I would like to know what kind of components I would need to drive a multitude of motors and gather input from devices from the serial IO port. I have a few ideas, but I don't want to display my ignorance just yet.

Welcome to Cemetech, Kaslai! Let me ask that you Introduce Yourself if you get a chance, tell us about your programming and hardware background, etc. This is an excellent question, by the way, and I hope you follow through. You have a bunch of options for yourself. Since you want to do both input and output, you would need something that has a lot of I/O and can speak something the calculator understands. I for one have written the CALCnet networking protocol for inter-calculator communication, which the Arduino board can speak, and have also written routines to speak the standard TI link protocol for the Arduino. You could then use all the analog and digital inputs and outputs on the Arduino to talk to your hardware and send data to and from the calculator, and your "intelligence" could run on the calculator, since it is much more powerful than an ATMega microprocessor. There are some simpler solutions as well, but but they would require more hardware on the order of 74-series logic for the tradeoff of needing to write less software. What do you know in terms of programming languages, out of curiosity?

Well, I am most comfortable developing in C++, and I know enough z80 to get by. What would the cheapest Arduino solution be? Most of them seem to hover around $30, which is a bit much for me, though I might buy one anyways.

All I really need is a way to control a drive motor, a clutch, a small gear shift, (Probably a motor, solenoid and a stepper motor) and be able to collect pulses (One pulse per fraction of wheel rotation).

I'll write more after I get home.

Sounds good, look forward to your updates. The trick is whether to use software and an external microcontroller (which can be as cheap as a $4 ATMega AVR, but then you need power, a crystal, and a few other sundries, not to mention a programmer) or if you can get away with a bit more complex hardware. With two bidirectional data lines, you'd need a way to either use one as input and figure out how to multiplex address and data to all your outputs on one line, or switch both lines between input and output in some way. It's a hard problem, to be sure. Or perhaps one line toggles if you're in input or output, and the other line first pulses an address (0-2) and then data? Still would ideally use a microcontroller there.

I'd agree with Kerm that a microcontroller would be the most flexible option, and for what it's worth you don't need a crystal for AVRs (they have an internal 8MHz oscillator) or a dedicated programmer (you can bit-bang the programming protocol over a parallel port with avrdude, so cutting the end off a parallel cable would be sufficient). You would need a motor driver of some description (e.g. the L293D) in addition to the AVR, however.

Ah, I always forgot about the on-board oscillator, thanks for the reminder. And I've gotten to the point of assuming people don't have legacy ports anymore, sadly enough. He mentioned on IRC that he has a bunch of relays at his disposal, although those still would require a solid-state component for the uC to drive the relay, and would increase the delay between detecting a stop state and making the motor stop.

I could say that C programming for z80 calcs is an option using SDCC, but TIOS isn't too C-friendly...

Especially if you want to mess with low-level hardware; does it even have a way to play with ports without inline ASM?

yup

Code:


See http://glassos.svn.sf.net/svnroot/glassos/trunk/src/include/global.h for port declarations.

It works well enough to support all hardware access including the USB driver (no asm in it, ty Linky)

Very nice, Ahelper; thank you for that clarification. If my programs didn't always stress the boundaries of speed and memory so much as it is, I would totally give that a try, and perhaps I will for a game some day anyway.

It is possible to use SDCC for TIOS if you provide glue functions that do b_calls, but floats can't be done by doing 3.5f/.123f and other large functions. Hardware stuff isn't too slow, as GlaßOS's direct LCD drawing was done in C with few exceptions.

Oh, really? I'd love therefore to benchmark them again Doors CS's hand-optimize iFastCopy routine some time to satiate my curiosity on how well SDCC has been improved since the days when I was frustrated with its bloated generated code.

direct drawing, not buffered. libgfx, the collection of buffered drawing routines, is all-asm. The only parts that are asm in the direct drawing are the delays of push/pop, and register -> stack conversion functions.

Direct drawing renders individual sprites faster than a buffer copying routine as it only issues a few lcd port writes. Doing heavy drawing _will_ be slow.

Ahh, my flub for not reading carefully enough; thanks for making that distinction. I'm actually slightly surprised that there aren't more sprite routines in pure ASM that simultaneously update the graph buffer and the LCD rather than updating the buffer and then slathering the whole thing onto the screen. Although maybe it's better to amortize the cost of many sprites at once if a lot of things change per frame.

Which was why libgfx was made once the kernel was established and more visual programs were made that weren't text-based. The direct drawing is useful for updating tiny parts of the lcd and for text-based programs, which was what GlaßOS used to be. But enough of off-topic GlaßOS thread takeovers, back to driving motors with a calc. The OS isn't even able to send programs over USB.... yet...

Indeed, let's talk about this thread's actual topic. This is perhaps something for another thread if we so choose to discuss it. Hopefully Kaslai will let us know his thoughts on the various things you, I, and benryves suggested.

I've been reflecting on these thoughts, and I have come to the conclusion that, seeing as I have but a rudimentary knowledge of electronics, but I know quite a bit about software, I am going to use a controller board.

I believe I mentioned this in IRC, but my engineering program has a FischerTechnik unit, and so we have a ton of FT boards and parts. I will probably just use usb8x to write a FT driver for my calculator for my project. Unless someone's willing to provide me with an itemized list of components along with a circuit diagram (which I do not expect from you), this is likely the route that I will go since I have such little experience.

Thanks for your help so far, and I'm still open to suggestions.

Can you tell us more about this FischerTechnik board, and the role you see it playing? Will you basically be using it as a fan-out from/to your calculator? Does it not have sufficient onboard processing power to do the controlling itself, as loath as I am to suggest taking the calculator out of the equation?

FischerTechnik is a company that creates little plastic toys, but they also have a robotics line that can interface with the toy components, controlled by their "ROBO Interface." This interface is a control board that relays instructions from a computer to a multitude of modular devices over a serial port or USB port. They do have on-board memory, but ours are quite old and cannot handle large programs (No more than 40 or so commands), nor do they have on-board error handling or multitasking support (I could write a time sharing system on my calculator).

If I recall correctly, a ROBO Interface can handle up to 2 analog inputs, 8 digital inputs, 4 motors and 4 lights simultaneously, plus a few more things which we didn't use. Along with these boards, we also have a large array of compatible components, such as solenoids, incandescent lights, thermistors, potentiometers, and photo-resistors.

It's quite a nice system; it just needs to be tethered to a computer to get anything productive done.

Heh, GlaßOS could be an option if you are doing USB stuffs and want to code in C. I am assuming that your board must act as a USB peripheral, so the host-mode driver is there, but untested.

Seems like COS (starter C OS) could be used as it can be fitted with usb and stuffs in 1 page, and more pages for code. But this will replace tios and clear the ram, as well with GlaßOS. Other than that, usb8x works afaik, but if your board is a host for some reason (I don't have any specs on it), then usb8x will not help.