Just sharing an application...

[pjc30943]

Due to Don's excellent service and the ZX24's easy access to relatively advanced capabilities, our team at Stanford used a ZX24 as the central controller of the device described herein. It is being developed for a large silicon-wafer manufacturer. The goal is to measure motion precisely, all with a compact, low-weight, package.

I'm writing this post just to share what we're having a ZX do currently.

Though we're not done yet, here's some of the resources we're using:

--hardware and software SPI (ShiftinEx), total 4 channels
--I2C
--4 (5 including com1) asynchronous bidirectional serial channels, 4.8-9.6kbaud.
--several large tasks in addition to Main, including ones that run handle some of the coms above.

The ZX24 is connected to several high-speed peripherals, including (but not limited to)

--3 axis accelerometer
--1 gyro
--2 optical mice cores
--2 16-bit ADCs (6 channels)
--1 RF transciever
--1 flash card interface board (256Mb)


The nice thing is, we have not yet been close to running out of RAM, consuming about 2/3 at the worst.


A picture our v.3 prototype is enclosed, with the board shown on a presentation style mock-up wafer, instead of a fragile real one.


The point of this post was just to show some of the capabilities of the ZX24, which are quite nice for the simplicity of programming it. We've already ordered a few more zx24s a few months ago, and plan to stick to the zx system...

[ With many things happening simultaneously, faster speeds would be nice...Say a factor 2 or 3 or 10. How about it, Don...HC12 speeds...easy right? ]

[mikep]

It always nice to see stuff like this. Good job.

In terms of performance, ZBasic is somewhat tied to its architecture and the underlying chip capabilities. I have several suggestions for you which I'm sure you have already thought of:

1. What do you mean by it is slow? Would you like your control loop to go faster? Can you define your performance requirements?
   
2. Once requirements are defined then you can test against them to see what is off. Performance analysis can be done to determine what parts of the code need to go faster. Having separate asynchronous tasks as you have certainly helps matters if the main control loop only has to retrieve data from these tasks on demand. Are their specific parts that need to be faster and others are ok? The 80/20 rule definitely applies here too.
   
3. Can you offload some "compute-intensive" function onto a subprocessor such as another ZBasic chip? Communication and synchronization may then become a problem. I'm currently looking at a shared FRAM memory application between multiple ZBasic chips.