The Cortez project is an embedded controller dedicated to motion control and chemical spotting with piezo jets. It grew out of a previous motion control design, which was based on solenoid valves, filling little vial-carriers. My resume page shows some early stage pics of this project. The hardware back then was still in the early prototype stage.
This page however is dedicated to the final production type controller. It is a multi CPU design, distributed over 3 CPU boards, 2 motor driver carriers and a passive back-plane. The communication between the master (motor controller) and the 2 slaves (piezo controller) is done by high speed clock/data serial loops over the back-plane.
More hardware details of the highly modular design can be found in the following pages :
Modular firmware concept : The software design is implemented in a stand alone OS (operating system), which consists of the kernel itself and the I/O driver shell. The hardware modules are supported by expandable modular driver functions. The entire design can be configured and sized to customer specs in a moderately easy way, without rewriting a lot of firmware. The OS will be the same for any APP (application) configuration, and only the I/O drivers will need some small changes. Any follow up design will benefit from the cost savings for all of the OS and a big part of the firmware development. Other advantages are the already written OS and I/O drivers, which provide a faster development cycle.
Operating System shell : The base for it is a preemptive real time multitasking kernel written by Jean J Labrosse. The source code and user licensing requires the purchase of his book “UCOS, The real time kernel, rev 1.08”. I ported the kernel to the 683xx family of CPUs and revised the source code, written in “C”. I further added some enhancements and debug features, which where not included in his book.
Operating system shell : This consists of some basic startup code and several HW and SW drivers. The startup code is written in assembly and jumps at the end to the “main” function. Two serial drivers support the comm and the debug channel. The comm channel can be used to communicate to the host CPU, which is in most cases a PC running the final application on Win 95/98 or Win NT. Both serial channels have interrupt supported ring buffers on transmit and receive. The max recommended Baud-rate should not exceed 19.200 Bd. This can be increased, depending upon the interrupt supported I/O load activity for the CPU (motors, piezos, dig I/O, etc…). There are several “printf “ functions available for both serial channels, with and without transmit resource locking semaphores. A simple command parser (max 4 chars per command) is being used to process various debug and monitor commands.
Operating system interface : The interface to the OS is through an vector table, which allows the OS to be stand alone in memory and does not need to be linked with the final, also firmware based, control application. The same command parser is available through a parser function vector and a parser help menu vector. This OS is mostly independent of the final control application, except of some timer ISR support function vectors.
Application level support (motors) : There are a max of 6 motors supported by the APP. The programmability is through simple ASCII commands, which echo the command and response in ASCII as well. The acceleration curve is fully user configurable with a step range from full-step up to 12800 micro-steps. Two end-stop limit switches per motor are currently supported with motor enable/disable. Closed loop feedback through a quadrate position sensor is supported by the hardware but is not implemented in the firmware at this time.
Application level support (digital I/O) : There are a max of 80 CPU-board based digital I/Os supported by the APP. The programmability is through simple ASCII commands, which echo the command and response in ASCII as well. The digital output resolution on the CPU-board is 3ms with a guarantee that all of the selected outputs turn on/off at the same time. Additional slave based digital outputs will have a resolution of 12 ms with a synchronized on/off feature for the particular slave I/O serial loop. The slave-board based digital inputs are supported by the hardware, but there is no firmware support at this time.
Application level support (Piezos) : There are
a max of 6 piezos per board, and 2 boards
per system, supported by the APP. The piezo timing resolution is 1 us. The min
pulse width is 20 us. The driving voltage supports 3 programmable pulse levels
within +/- 50 V (8-bit resolution). The burst count is programmable and up to
255 max, followed by a programmable idle period of up to 32k TPU clocks. There
is one sync signal coming from the motor controller, which is being activated
upon the start of any motor. Since the acceleration and speed of the stepper
motor is known, the piezo-period, burst count and idle time determine the
chemical spotting sequence (spacing) on the carrier.
We are sure that You still have some questions or comments, so
please contact us at