Project "Multi-Z CPU" Multi-Processing ZX-xx Micro

[zbasicandy]

Project - "Multi-Z CPU"
by ZBasicAndy and neighbor
7-6-06

The included zip files are for the "Multi-Z CPU" Microcontroller PCB.


The "Multi-Z CPU" design has the following features:
1. Contains no surface mount parts and all ICs are socketed for easy troubleshooting.
2. 1 ZBasic ZX-40x microcontroller CPU on each board. (All Multi-Z CPU boards are the same)
3. 1 "on board" (RS232) programming port with 9 pin female DIN connector.
(Front card edge accessible)
4. ATN disable jumper for disabling/enabling the programming port.(Front card edge accessible)
5. Emergency firmware update jumpers (2). (Jumper selectable)
6. 1 red CPU running LED. (uses 1 I/O pin) This LED also flashes at 4 HZ during firmware
updating.
7. 1 red interrupt status LED. (uses 1 I/O pin) (For multi-processing status)
8. 1 multi-processing interrupt/communications connector. (Uses 4 I/O pins)
This connector allows bussing of serial communications/interrupts between 2 other
"Multi-Z CPU's. This allows the "Multi-Z communication CPU" to acquire serial data input
from the two other concurrent running Multi-Z CPU cards.
9. All I/O (except for I/O above) are routed/connected to the 25 pin Din "buss" connector.
10. "Internal" on board 5 VDC input power is routed via external 25 pin Din connector.
(For Multi-Z CPU power/ground bussing)
11. 1 Com3 Tx3/Rx3 TTL to RS232 serial comport signals routed via external 25 pin Din connector.
(uses 2 I/O Pins - for Com3) (Uses RS232 driver/receivers from programming port IC)
12. Multi-Z low cost CPU board can be used as a standalone ZX-40x microcontroller prototyping
card without the backplane. Just add a regulated 5 VDC power supply and a 25 pin female
connector for the I/O point connections.
13. External ZX-40x serial EEprom can be user selectable between 256K or 512K for more
program memory storage. (256K ~8,000 instructions and 512k ~16,000 instructions)
14. Changing to a "New ZX-40x microcontroller" and faster clock crystal takes only a few minutes
to perform.

Please read all docs and view all files for this "Multi-Z project".

The following FREE "Multi-Z CPU" and "Multi-Z BackPlane" schematics and PCB Design can be viewed
by downloading ExpressPCB from ExpressPCB.com. By importing the PCB design you can order 3
"mini-boards" via internet for $59.00 including shipping. (Have several ZBasic community
users/members chip in for cost reduction)
Note: With this mini board service, no solder mask and silkscreen is provided!
Both are not needed for this very simple design project. (Please view assembly drawings)
PLEASE DO NOT MODIFY MY PCB DESIGN! - DO IT AT YOUR OWN RISK!

Also, view the assembly BMP and BOM - Bill of Materials (Parts list via Excel).
Adjust the parts quantity on the size of your needed system.
PLEASE DO NOT SUBSTITUTE ANY BOM PART! - DO IT AT YOUR OWN RISK!

There are three demo software projects/loads for each "Multi-Z CPU" in the software folder.
Note: Loads for Multi-Z CPU Slot 1/J1 & Multi-Z CPU Slot 3/J3 are the same.

A bit of humor ...

******Disclaimer******Disclaimer******Disclaimer*******Disclaimer******
* If your house burns down, your wife and children become *
* homeless, your dog dies or worst yet your ZBasic microcontrollers *
* are torched, PLEASE DO NOT HOLD ME OR MY NEIGHBOR RESPONSIBLE *
* FOR YOUR ACTIONS OR INACTIONS in the construction of this project! *
******Disclaimer******Disclaimer******Disclaimer*******Disclaimer******

This project design is complete and works! Certain skills of electronic component soldering,
schematic reading, electronics troubleshooting and software programming are necessary to
bring this project to final completion.
Please feel free to post your project questions on the ZBasic User Forum.

Please Note: This project design is "as is" and is subject to change at any time!

[zbasicandy]

Here is another zip file for the "Project Multi-Z CPU" ZX-40 microcontroller
buss card. (The compression settings are now set back to normal)

[spamiam]

This is an impressive project. I love the idea of multi-processing. But, I am a little surprised that you did so with the ZX, or any other "stamp" type of device. Do not take this the wrong way. I am not being critical at all but it is so easy to see written questions or comments as a criticism rather than honest interest in the project. I LOVE this project. I love the idea of multiprocessing. I love the philosophy of multiprocessing.

[The philosophical aspect is that I am sure that the path to a real AI system that passes a Turing test will be through a heavily multiprocessed system, not just for the MIPS, but for the fact that actual human brains and minds are actually tightly linked independent subrocessors. But who is to say we NEED to replicate the structural aspects of the brain/mind??]

What advantage do you see to making the ZX multiprocessed, over, say, a single big AVR used in its native mode? Some of them have over 64 pins, most of them for I/O.

Most have over double the number of external interrupts.

Most will run MUCH faster when they run ASM or C code natively.

I do not know how fast a mini-RTOS running in C or ASM is compared to ZBASIC, but not having to get instructions out of EEPROM, and not having to interpret the instruction to create AVR instructions ought to confer a significant speed advantage.

So, overall, I do not see the reason for the ZX selection. This is not a knock on the ZX hardware. I love the stuff. But I use plain old AVR's too. Each has certrain advantages. ZBASIC is wonderful for rapid and simple development. But you have a very advanced project doing advanced stuff. You might have an advantage working at a lower level programming-wise.

In your case with the ZX-40 you have the advantage that the ZX-40 footprint is the same as 1 or more of the AVR processors, and all you need to do is run some of the pin connections to the appropriate type of connector. With bootloader firmware (which I have never used) programmed into an ATMega32, you can then do program updates too, just like ZBasic.

Personally, I see another advantage to your design:

The interesting and useful thing is that most (all?) of your inter-processor hardware is software independent as far as I can tell. Therefore it is a rather simple thing to use a different processor carrier (with the same connectors and maybe the same card size) and have it programmed differently (i.e. a raw AVR or even a DSP or something)

It seems that this multiprocessor support hardware will allow specific task optimization of individual processor cards while leaving the greater collection of nodes intact and functioning.

Keep up the great work. I wonder if your design allows axpandability to add more nodes/backplanes without a specific limit. It would be very cool if you did. It would also be cool if you could have an additional card that allowed backplanes (or individual cards) to communicate wirelessly.

-Tony

[zbasicandy]

But, I am a little surprised that you did so with the ZX, or any other "stamp" type of device.

The Basic Stamp is very resource bound e.g 36 bytes/2k memory blocks with no multi-tasking commands.
We have yet to run out of program flash using ZBasic's microcontrollers.

What advantage do you see to making the ZX multiprocessed, over, say, a single big AVR used in its native mode?

The AVR in its "native node" is far cheaper and faster than a ZX-XX microcontroller using ZBasic. Where most people fail to realize is all the tools and machine code programming takes time and money to produce. ZBasic programming "time to market" or development is by far much quicker.

Most have over double the number of external interrupts.

Rumor has it that there is a variation of the ZX-40 which has more interrupts.... stay tuned.

So, overall, I do not see the reason for the ZX selection.

Three words ... ease of use. Also fast to develop.

The interesting and useful thing is that most (all?) of your inter-processor hardware is software independent as far as I can tell.

All it is serial TTL Rx,Tx and INT0, INT1 signals.

In your case with the ZX-40 you have the advantage that the ZX-40 footprint is the same as 1 or more of the AVR processors, and all you need to do is run some of the pin connections to the appropriate type of connector

Take note the pinouts of the ZX-40 and the Propeller COG. The 40 pin COG can fit on a Multi-Z buss card.

I wonder if your design allows expandability to add more nodes/backplanes without a specific limit.

Since ZBasic has 4 software serial ports then you can talk serially via RS485 to 255 of them. Using the inter-process communication bus and even the backplane is not necessary except for power and I/O distribution.

It would also be cool if you could have an additional card that allowed backplanes (or individual cards) to communicate wirelessly.

Until "mesh transceivers" node price drops to a decent price level and their development tools then you might have to wait for a while.

[mikep]

Take note the pinouts of the ZX-40 and the Propeller COG. The 40 pin COG can fit on a Multi-Z buss card.

Are you sure that is correct? Here is the cog pinout. The differences I see are:

1. VCC on 12/32 instead of 10 (30)
2. GND on 9/29 instead of 11/31
3. Crystal on 30/31 instead of 12/13
4. Reset 11 instead of 9
5. UART TX/RX on 39/40 instead of 14/15
6. hardware I2C on 37/38 instead of 22/23

So I think you will have to redesign the PCB.

[zbasicandy]

Take note the pinouts of the ZX-40 and the Propeller COG. The 40 pin COG can fit on a Multi-Z buss card.

Again you misread statements. The keyword is "a". If I used the word "the" then you might be correct.

I did not say it was PIN TO PIN compatible.

A 40 PIN DIP COG can fit on another 40 PIN DIP (ATmega32) PCB.

I was referring that it will "FIT" on a Buss card. Of course "the Multi-Z CPU" card would have to be redesign to accomidate this new 3.3 VDC chip
along with any additional I/O and special circuits. Do you think the Atmel Mega32 has the same pinouts as the Propeller COG? Any junior electrical engineer or electronic hobbyist who can read electronic schematics and electrical literature can tell you this by reading the specs on both devices.

[stevech]

<zap>

[zbasicandy]

Steve when you "chime in" please be a little more specific and concrete in your statements.

[stevech]

<zap>

[zbasicandy]

Thanks Steve for you insight.

This Link is for users who need "feedback" on the project
"Multi-Z". After all, this forum is a place to discuss Zbasic
and ZX series microcontrollers.

[dkinzer]

After all, this forum is a place to discuss ZBasic and ZX series microcontrollers.

While it is true that that is the primary focus, it is useful and informative to have posts from time to time dealing with non-ZX microcontrollers, electronics, PCB design/fabrication, prototyping techniques, and so on. For example, mentioning the Propeller is certainly acceptable as is discussion of its strength, weakness and possible applications. Comparison with ZX capabilities makes it even more appropriate. If I determine that the discussion is getting too far afield or if the non-ZX topics get out of hand I'll respond in an appropriate manner.

While still on the soapbox, I'd also add that anyone that posts in these fora should do so with the knowledge that posts that contain hypotheses, assertions, opinions, etc. are likely to be challenged by those with different points of view. Posts that contain code, schematics and other design elements are also likely to be challenged by others that have a different perspective on the best way to accomplish a particular task. Some of the responses will be less diplomatic than others, often reflecting the attitude (intended or not) expressed in the original post.

The bottom line is that anyone that posts anything should be prepared to weather the responses. Sometimes, the best counter-response will be no response at all. I do expect all posts to retain a civil tone.

[zbasicandy]

You just created the "Wild West" on this forum. There will be many "unfocused" users talking about Basic Stamps, COGs, Cublocs, BasicX and other totally unrelated subject matter. For a new ZBasic user, having them try to "filter out" this "unrelated subject matter" is doing them a dis-service. They came here to learn about ZBasic.

[JC]

When I ask a ZX specific question I always get a prompt, and accurate reply, sometimes with several perspectives, topic permitting.

I've gotta say, however, that I find the tangentially related topics to be helpful. The discussions on GPS modules, circuit board prototyping, USB interfaces, etc. is useful. One gets the perspective of another's personal experience, not just the hype from a vendor's web site, or advertising claims.

I suspect that many users, like myself, do not have the time or $ to personally purchase and evaluate everything out there, even if they are aware of its existence.

The ZX chips, obviously, are only a paperweight without something being attached!

IMHO the core forum focus should be on ZBasic and the ZX's, while continuing to encompass associated topics.
JC

[spamiam]

IMHO the core forum focus should be on ZBasic and the ZX's, while continuing to encompass associated topics.
JC

You are right, eventhough I am one of the offenders who let the discussion branch out to other devices. I usually try to keep the divergence appropriate to the issues of what the ZX has to offer in comparison to the others.

But, I have had a couple of questions brewing in my hear that are more about programming algorithms (not necessarily ZBasic in particular) and maybe some about the design of supporting ciruitry. None of the current forums (fora?) would apply to these topics exactly.

I think there should be another 1 or 2 forums that are about 1) programming, 2) electronics/wiring/hook-ups.

If the idea is to allow a newbie to separate the wheat from the chaff, then maybe 1 or 2 extra forums will allow us to be more on topic for the forum description.

-Tony

[zbasicandy]

I think there should be another 1 or 2 forums that are about 1)programming, 2) electronics/wiring/hook-ups.

I will second that!