Monday, September 04, 2006

 

Using RS232

So, after researching a bit, I've discovered it will be easiest to send the RS232 signals thru a line buffer to condition it to voltage levels more suitable for the Z8. I've ordered some MAX232 chips to handle this. I'm hoping to get them around the end of the week.

I've also raided the electronic junkyard at my father in-law's, and was able to scavange 4 opto-mechanical mice. These will have the cords removed to be used for serial line comm (hopefully, this works), and I am going to experiment using the optical devices as shaft encoders; I'm going to wait until I get serial comm up first, before I do anything serious on that front.

In the meantime, I've started to explore some of the capabilities of the little 8K EZ8. In some ways, I'm pretty impressed:

~(lots) INT16 additions per second.
~125K INT32 additions per second.
~60K INT16 multiplications per second.
~20K INT32 multiplications per second.
~15K FLOAT32 additions per second.
~11K FLOAT32 multiplications per second.
~9K INT16 divisions per second.
~4K FLOAT32 divisions per second.
~3.5K INT32 divisions per second.
~500 ATAN() calculations per second.

It was actually a bit faster than I thought for the floating point, and a little slower than I expected for the INT32 divisions. All tests were performed on a 5MHz processor. I could add a 20MHz crystal and get effectively 4x the performance, but I'm going to avoid doing that right now, since I think I should have enough power to do what I want (I'll only be doing INT32 addition initially.) I couldn't get a good benchmark for the INT16 additions. My timings were based on a loop of 1000000, 100000, or 10000 operations, but even with the loop overhead, the 1000000 INT16 additions didn't seem to be adding anything over an empty loop that my rough measurements could detect (I.E, start the program, watch for the LED to light up to indicate it is started, then watch a second hand on a clock as the LED goes off to indicate it was done. Yes, very, very low tech performance benchmark timings here.)

The reason I decided to try this benchmark is I wanted to see how much of a hit I might take if I decide to try using ADC channels on an analog shaft encoder, rather than a digital shaft encoder. It appears I'm not going to be doing exact calculations if I go this route, but an atan lookup table with 255 entries should work and be accurate enough for my purposes.

Another purpose to my madness is that I've been thinking more about splitting the control out to separate Z8's. I should have plenty of horsepower to do some fairly good heuristics, even using floating point if i need to. My plan would be to use a master controller chip to synchronize everything. It will wait for an output from each motor driver to toggle to an "I'M DONE AND READY TO STEP TO THE NEXT POSITION", and when all motors are done, it will toggle the "OKAY, STEP TO THE NEXT POSITION" that will be sent to an input on each of the slave drivers. The nice aspect of this kind of system is that it will be as fast as the slowest component. No timing is necessary. I think I'm going to think a little more on this; If I decide to move forward, I'll probably blog some additional schematics (I'll include the power supply and serial line schematics with this..)

Comments:
Wow! You have floating point capability, too!

Do I have it right that you don't need a formal programming board to use the Z8?

I'm really looking forward to following your work with the Z8. It looks to be having some huge advantages over the PIC chips.
 
*** Wow! You have floating point capability, too! ***

Actually, I was suprised at how many standard library functions are included. I've tried printf, scanf, strtok, etc; it's all there, but you wouldn't want to use these on a small chip -- they consume lots of program rom -- A main() program that does one floating point addition, one floating point multiplication, and the atan method consumed 2K of program memory. You'd want to be really careful about too much loose and free programming. :) I think a lot of these functions are targeted more for use on the 64K model.

*** Do I have it right that you don't need a formal programming board to use the Z8? ***

Correct. The Z8 has in-circuit flash programming. The DBG line is effectively a serial line into the built in debugger circuitry. You can send it commands to erase or write the flash memory (in addition to others). There is a nice schematic included with the smart cable to show you the minimum pin configuration in order to hook the smart cable to an in the wild Z8. (see sample schematic on page 4 of http://www.zilog.com/docs/z8encore/devtools/um0162.pdf -- you don't need the crystal if your using the internal clock.)

With my circuit, I put a 4 pin debug port right on the finished board. I can change the program just by plugging in the smartcable, and pressing a few toolbar buttons from within the development environment. You could even let it drive the motors while it's hooked up, and single step thru the code as it sends signals to turn the motor on and off (Better be able to press the 'next' button really fast if there is any RT criteria! :)
 
Post a Comment

Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]