Home

About

Me

Project List

Mail me

Last update: 2013-10-04

Ushabti MM

Abstract

This project is about building an autonomous, mobile hobby robot which is a bit more complex than the typical hobby robot. It features infrared and sonar distance ranging sensors as well as accelerometers and a Kinect sensor. It is powered by five Atmel eight bit AVR controllers and an Intel Atom D2500 dual-core processor. Last but not least it has a strange name. This is work in progress.

Introduction

Project Goals

The project aims at constructing a basic robotic platform. On top of this platform the actual experiments can be conducted. The platform provides rudimentary services such as driving or measuring acceleration while the user software forms the actual guidance system. The user can concentrate on experimenting with neuronal nets, fuzzy logic, expert systems or what ever comes to one's mind. Therefore the platform provides:

A Strange Name

There is always work to be done - even in the afterlife - at least according to ancient Egypt belief. Therefore funerary figurines where placed in one's grave since everybody wanted to enjoy his life after death. Purpose of such a figurine called Ushabti was to serve as a substitute for deceased, should they be called upon to do labor in the afterlife.
The concept of an Ushabti resembles me of the idea behind robots. Even though our approach today is more scientific/technical rather than religious/esoteric as it was back then. Never the less I thought that Ushabti would be a nice and unusual name for a robot.

The suffix MM is the latin symbol for the number 2000. I started that project in 1999. It was intended to be my "millenium" project. However, having a job and founding a family did not leave much time for this hobby. So several years passed by before I could reanimate the project in mid 2012.

Hacking

A great part of hobby robot building is hacking in terms of using things in other ways than they were originally intended to be used. For example:

Sources

All source codes and wiring diagrams can be found at the end of this article for download.

Theory of Function

Overview

The software and electronics is divided into two different parts in order to serve as a flexible robotic platform: superordinate and subordinate control.

Superordinate Control - The superordinate control is almost "empty". Physically it is an Intel Atom D2500 PC that is intended to execute application specific user programs. For that an API is installed that allows the user program to "talk" to the subordinate control.

Subordinate Control - The subordinate control is very closely tied to the robotic platform. It is physically formed by a number of Atmel eight bit AVR microcontrollers. Those microcontrollers read the sensor data and control the actuators. Some sensors, such as the Kinect, have a high bandwidth. These are physically connected to the PC. So logically the subordinate control spans from the microcontrollers to the PC.

An RS-485 bus is used for communication between superordinate and subordinate control in case the subordinate control is located on a microcontroller. In case the subordinate control is located on the main computer (PC) interprocess communication (IPC) is used.

Superordinate and subordinate controls

Communication Architecture

Physically all microcontrollers and the main PC are all connected to one RS-485, half-duplex, singel-master bus (with two wires). According to the RS-485 protocol used, all logical connections are solely between RS-485 bus master (PC) and a single (addressed) bus slave (AVR). The communication takes place via logical point to point connections. There is one exception: Broadcast messages. These go to all microcontrollers at once. But no microcontroller will ever respond to a broadcast message. Broadcast is a oneway road.

The master sends messages to the slaves in order to read sensor data, module status or to make the actuators move (and do something). For that the bandwidth of the bus is sufficient. Messages are typically small (typically about two to four bytes). The bus runs at 115.200 baud.

The software (Windows and AVR) and an RS-232 to RS-485 bridge are introduced here: rs485libWinAVR.

Physical bus structure

Logical bus topology

Superordinate Control in Detail

#### TODO ####

Subordinate Control in Detail

The microcontrollers are directly connected to the sensors and actuators. Thus making precise and close control/regulation possible. Functionality is kept simple, for example the microcontrollers do not make decisions. They only report status to the superordinate control. (The only exception is the motor controller which autonomously shuts down engines in case electric currents exceed a certain level for to long.) The microcontroller software is mainly kept simple because AVR flashing is not as easy as updating PC software. Currently it is required to open the robot and remove the chip from its board in order to program it. For that to become more easy, an RS-485 boot-loader would need to be developed and built into every AVR. Currently it is more convenient to adapt the user program (PC) than the AVR programs. Furthermore debugging PC programs is easier than debugging microcontroller programs.

Every subordinate buffers application error codes in an error buffer. This buffer comes from the libAvrUtils code collection. A buffer is used in order not to loose error information when multiple errors occur. (See the libAvrUtils library for more on that topic.) What is important in this context is that the error information can be read via the RS-485 bus. The RS-485 library rs485libWinAVR itself also uses such an error buffer. That one can also be queried via RS-485, given that the RS-485 stack has recovered from the error situation. Furthermore the subordinate tells us if there was a buffer overflow, that is to many errors. The section on bus messages will come back to this topic.

Last but not least: Be advised that subordinate modules use a watchdog timer for safety reasons. If a subordinate does not receive at least one message every two seconds it goes into a safe state. For example: The motor controller will immediately stop all motors. This error condition (WDT time-out) will also be placed in the error buffer and is available via RS-485. See the section on RS-485 bus commands for more details on this subject.

Modules

Rack and Backplane

Today all microcontroller boards reside in an (shortened) 19 inch rack. (In the future microcontroller boards may also be scattered to other places elsewhere in the robot.) The rack has a backplane with 64 signals according to DIN 41612. Today only a few of the wires are actually used. The chapter on connectors describes the pin-assignment of the backplane connector in detail.

RS-232 to RS-485 Bridge

The PC's RS-232 interface is coupled to the RS-485 bus by using a passive RS-232 to RS-485 bridge. Passive means that RS-232 and RS-485 bus transceivers are connected directly. There is no microcontroller in between which does any magic. The PC directly "talks" to the bus and has to handle the protocol implemented by rs485libWinAVR. (AVR and Windows code is included.) Bridge and battery monitor have been implemented on the same board in order to save space.

RS-232 to RS-485 bridge (circuit board)


RS-232 to RS-485 bridge (wiring diagram)

Power Supply Modules

Power Supply for Microcontrollers

The +5V power supply was taken from an old printing machine. It has two regulators that deliver +5V/2A. One originally was calibrated for +12V. I had to exchange one or two resistors.

The primary +5V supply is used for all microcontroller boards. The sonar sensors draw about 2A peak when firing. Therefore the sonar ranging module uses the secondary +5V supply exclusively for powering the sensor boards.

Microcontroller power supply (circuit board)

Power Supply for Main Computer

The M1-ATX was originally intended as a DC/DC converter for powering car PCs from a 12V car battery. It accepts 8V-30V as input and provides 90W output. The M1-ATX is used to power the robot's Atom board and peripherals. For more details see the manual in the download area.

Power Supply Monitor Module

The robot is powered by two lead acid accumulators. They deliver +12V/24Ah (nominal). Task of the PSM is to monitor the status of the accumulators. The status can be queried via RS-485 bus. Details can be found under mega8battMon. For the robot RS-485 hardware and software has been added. Furthermore an LED connector has been added. The frontpanel of the robot offers three LEDs. Those are to be connected with this connector. They display, from left to right, microcontroller power, PC power and battery status. Bridge and battery monitor have been implemented on the same board in order to save space.


Battery monitor (circuit board)


Microcontroller power supply plus monitor sandwich


Battery monitor (wiring diagram)

Infrared Distance Ranging Module

The robot is equipped with Sharp infrared distance ranging sensors of types GP2D02 and GP2D120. Details on how to read those sensors can be found under mega8irRanger. For the robot RS-485 hardware and software has been added. Furthermore connectors for the sensors have been added. Infrared and sonar ranging modules have been implemented on one circuit board in order to save space.


Infrared ranger (circuit board)


Infrared ranger (wiring diagram)

Sonar Distance Ranging Module

The robot is equipped with Polaroid ultrasonic sound (sonar) distance ranging sensors. Details on how to read those sensors can be found under mega8usRanger. For the robot RS-485 hardware and software has been added. Furthermore connectors for the sensors have been added. Infrared and sonar ranging modules have been implemented on one circuit board in order to save space.


Sonar ranger (circuit board)


Sonar ranger (wiring diagram)

Motor Controller/Motor Driver Modules

The driving motors are controlled by two circuits. Both are stacked as a sandwich and connected via a ribbon cable.
  1. Motor Controller - The motor controller is made up of a microcontroller that reads sensor data from the motors and produces PWM signals for the motors.
  2. Motor Driver - The motor driver module is the power part. It amplifies the microcontroller signals to ±12V/4A per motor. For that power MOSFETs are used. Direction of the motors is controlled by relays since this board is a remainder of my 1999 try.

I wanted to use two accelerometers. These are actually Nunchuk controllers. They all have the same I2C address (0x52). ATmegas typically have only one TWI interface. There are four possible solutions:

  1. Use an Xmega. Xmegas have more TWI interfaces. But I am neither accustomed to Xmega nor can I handle those SMD parts.
  2. Use I2C switches/multiplexers. Again, these are SMD parts and relatively expensive.
  3. Switch one Nunchuks on while the other is off and viceversa. I wanted to avoid that because one has to wait about 100ms and needs to initialize the Nunchuk after power-up.
  4. Use a second ATmega and connect both via SPI.
I went for the latter approach. An ATmega1284P is used as primary controller (or SPI master) because it has four timers, two UARTS and a TWI. An ATmega8 is used as secondary controller (or SPI slave) because it also has an TWI. Furthermore both chips are DIP (non-SMD) and the ATmega8 is cheaper than an I2C switch/multiplexer.

RS232/RS485 Bridge

I could not make the Windows side (the RS485 bus master) stable. The timing was unreliable. (Windows is actually no real-time OS. I am using it because of it's great support for Kinect, text to speech and speech recognition capabilities.) Hence, the microcontrollers had to include delays in order to allow the Windows side to switch direction of the bus.

One solution would possibly be Winows' events, but I did not want that effort.

Instead, I included a bridging functionality here. The ATmega1284 has 2 UARTs. One connected to the RS485 bus, the other is configured as an RS232 interface. The bridge accepts RS485 commands in the form of text messages on the RS232. These are locally processed or forwarded on the RS485 as appropriate. Responses are returned to Windows as text messages via RS232.
This way, we can also send messages via terminal programs like PuTTY. Please note that PuTTY sends CR (\r or 0x0D) upon press of the enter key. C# sends LF (\n or 0x0A) with SerialPort.WriteLine(). This software accepts both as an end-of-line. However, this software terminates each response with an LF, which is accepted by PuTTY and C# ReadLine().
TODO: The RS232 bridge as described at the beginning must be made passive by putting RTS high (5V). Wiring diagrams and documentation need to be adapted.

Accelerometers

The accelerometers are Nunchuk controllers. Details on the Nunchuk/TWI communication can be taken from mega8nunchuk. The circuit bord has a 3.3V regulator to supply the Nunchuks. After powering up a short delay (100ms) is required before initializing the Nunchuk.

SPI Communication

The two controllers are connected via MOSI, MISO, SCK as shown in the datasheets. In order to keep the number of parts low the secondary controller is clocked by the primary controller (CLKO). Furthermore the primary's PB8 is used to reset the secondary controller. The primary keeps the secondary in reset until it has finished its own initialization sequence. The communication follows the following scheme:
  1. The secondary controller reads acceleration data from the Nunchuk via TWI.
  2. Once the TWI transfer is completed it stores the first byte in the SPI output buffer.
  3. I then toggles PC1 to trigger the primary's PCINT7.
  4. The primary controller now starts an SPI transfer by sending four arbitrary bytes.
  5. Withe every byte received the secondary places the next byte in the SPI output buffer.
  6. The secondary continues with Step #1 once all four bytes have been transferred to the primary while the primary passively (not buy) waits for the next PCINT7 to occur.

Primary Controller

The primary controller measures the rotational speed of each motor. It also measures the electric current consumed by each motor. Both motors are getting shut down if at least one motor consumes a too high current for to long. The primary furthermore reads one accelerometer directly via TWI and another one indirectly via SPI. It also handles the RS-485 communication and rapidly puts data out to the second USART. More details can be found in the well documented source code.
As already mentioned the primary (ATmega1284) is clocking the secondary (ATmega8).

Secondary Controller

The secondary controller reads accelerometer data via TWI from a Nunchuk controller. That data is provided to the primary via SPI. The secondary is (at the moment) not connected to the RS-485 bus. More details can be found in the well documented source code.
Be advised that the fuses of the secondary (ATmega8) are set to accept an external clock since the secondary is clocked by the primary. Once the fuses are set, the ATmega8 cannot be reprogrammed without providing an external clock. I am not sure whether that clock needs to be 14.5674MHz (as provided by the primary) or other frequencies (e.g. 8MHz) would do.

Motor Data/Tweaking Program Parameters

#### TODO ####

Wiring Diagram and Board Layout


Motor controller (circuit board)


Motor driver (circuit board)


Motor controller and driver as a sandwich (circuit boards)


Motor controller (wiring diagram)

Head Controller Module

Primary task of the head controller is to produce an appropriate PWM signal for the RC servo that rotates the head. The head can rotate approximately 45° to the left and another 45° to the right. There is no feedback about the actual position. At the time of writing we simply rely on the servo to do its job.

Secondary purpose of the head controller is to read four additional infrared distance ranging sensors mounted at the head. Combining rotation and sensor scan can be used to produce a distance map.

Most controllers are connected to primary +5V supply. The head controller uses secondary +5V supply in order to relieve the primary DC/DC regulator.

#### TODO wiring diagram #### #### TODO picture of PCB ####

Main Computer Module

#### TODO ####

General Wiring

All the above modules are wired as shown below. Please note that the Main switch is used to power the Microcontrollers as well as the PC. But to start or shut down the PC you also need to press the PC push-button. The (drive) engines can be shut down with the Engines emergency switch. This does not shut down the computers. As a result the status of the software can be checked in case of failure (witch has lead you to press the Engines emergency switch).


General Wiring Diagram

Audio Amplifier

For the PC to output speech and simple acoustic signals an audio amplifier is needed. A Kemo M031N mono amplifier is used. A small circuit board is used to integrate the amplifier into the robot.


Audio Amplification Wiring Diagram


Audio Amplification

Kinect Module

The robot is equipped with an Kinect for XBox 360 device. It is a really great toy for measuring depth and do other cool things. I am using a Y-shaped cable to connect the Kinect for XBox to a standard PC USB 2.0 port. Furthermore one end of the cable is connected to the PC's power supply. The power supply has four connectors, hooked up as follows:
  1. ATX connector: Connected to the micro ITX board.
  2. Serial ATA connector: Connected to the hard drive.
  3. 5.25" Molex connector: Connected to the audio amplifier (only +12V are used).
  4. 3.5" Molex connector: Connected to the Kinect sensor (only +12V are used). The white wire is the GND line, the brown wire is the +12V line.
The Y-shaped cable was bundled with an power supply by Microsoft. It is needed to supply the Kinect device with additional power (12V/1.08A). I simply cut of the 230V power converter (european standard) and just used the cable.


Kinect power connector

Software Versions

#### TODO windos, visual studion, kinect sdk, speech sdk etc. ####

RS-485 Bus Command Examples

All bus addresses and commands are defined in addrs_and_cmds.h. Be referred to this well documented file. Nevertheless some example messages shall be explained here. This is because they are prototypic and help understanding the message structure in general.
Command ID Description Addressee Example Request/Response
ID Module
BROAD_CMD_MSTR_UP (0x00) Tells all subordinate control modules that the superordinate control is online (alive). Subordinate modules do not perform action until superordinate control is online. This command does not have to be sent necessarily. Any other command received tells the subordinate control that the superordinate is online. However, if no "real" messages need to be sent to the subordinate one can use this one in order to prevent watchdog timer reset. A better approach would be that the superordinate regularly pulls the status of each super ordinate. That way the superordinate sees if there is any error and the subordinates know that the superordinate is alive. BROADCAST_ADDR (0x00) all Request
0x00 Address
0x00 Command
0x00 Number of parameter bytes (no parameters)

Respose

- none -
BROAD_CMD_MSTR_DOWN (0x01) Tells all subordinate control modules that the superordinate control is about to be shut down. Subordinate modules do then perform safety actions, e.g. top driving. This command has to be sent when the superordinate control (PC) is about to be shut down in order to secure all subordinate modules. BROADCAST_ADDR (0x00) all Request
0x00 Address
0x01 Command
0x00 Number of parameter bytes (no parameters)

Respose

- none -
BATTMON_CMD_STATUS (0x00) Request application and RS-485 driver status. This command (0x00) is common. All subordinate modules support this request to their address. Most other commands are application specific.

Each request will remove the latest status entry from the error buffer. "OK" will be returned once the buffer is empty. Therefore this request should be repeated until "OK" is returned and all errors pending have been considered by the superordinate.

BATTMON_ADDR (0x01)
|
RESPONSE_IS_EXPECTED (0x80)
Battery Monitor Request
0x81 Address
0x00 Command
0x00 Number of parameter bytes (no parameters)

Respose

0x03 Number of return bytes
enum BattMonStatus Application error code
enum AvrRs485Error RS-485 error code
enum BattMonToManyErrors Two flags for application and RS-485 overflow/to many errors
MOTOR_DRIVER_CMD_SET_SPEED_DIRECTION (0x01) Set new speed and direction of both drive motors. MOTOR_DRIVER_ADDR (0x04)
|
RESPONSE_IS_EXPECTED (0x80)
Motor Controller Request
0x84 Address
0x01 Command
0x04 Number of parameter bytes
0...100 New target speed left motor
MOT_DIR_AHEAD (0x00), MOT_DIR_BACKWARD (0x01) New target direction left motor
0...100 New target speed right motor
MOT_DIR_AHEAD (0x00), MOT_DIR_BACKWARD (0x01) New target direction right motor

Respose

0x01 Number of return bytes
MOTOR_DRIVER_STAT_OK (0x00), MOTOR_DRIVER_CANT_SET_SPEED (0x05) "OK" if speed/direction could be taken over, "ERROR" else

Some selected bus command examples

List of Connectors

This section lists and explains all connectors. Most of the connectors are located on one of the circuit boards mentioned above. See the corresponding section for details.

Rack and Backplane

Pin Description
A1, C1, A2, C2 0V/GND
A3, C3, A4, C42 +12V directly from the battery (can be up to +14.8V when charging, can be less than +12V when discharged).
A5, C5 RS-485 bus, line A.
A6, C6 RS-485 bus, line B.
A27, C27, A28, C28 Secondary +5V supply, up to 2A, regulated by DC/DC switch.
A29, C29, A30, C30 Primary +5V supply, up to 2A, regulated by DC/DC switch.
A31, C31, A32, C32 GND/0V
Backplane connector

RS-232 to RS-485 Bridge

#### TODO: RS232 connector

Pin Description
1 Error - Rightmost LED displays power failure.
2 0V/GND
3 PC power - PC has been switched on.
4 0V/GND
5 MC power - Main power switch on, microcontrollers are supplied with power.
6 0V/GND
7 n.c. - Leave unconnected.
8 n.c. - Leave unconnected.
9 n.c. - Leave unconnected.
10 n.c. - Leave unconnected.
LED connector to front panel

Infrared Distance Ranging Module

The sensors of connector 1 are placed at the foots of the robot. Left is Sensor1, mid is Sensor2 and right is Sensor3.
Pin Description
1 Sensor1 analog output.
2 Sensor1 GND/0V.
3 Sensor1 +5V supply.
4 Sensor2 analog output.
5 Sensor2 GND/0V.
6 Sensor2 +5V supply.
7 Sensor3 analog output.
8 Sensor3 GND/0V.
9 Sensor3 +5V supply.
10 n.c. - Leave unconnected.
Connector to infrared sensors at foot of robot

The sensors of connector 2 are placed at the lower belly of the robot. Leftmost is analog Sensor4, right most is analog Sensor5, left is digital Sensor6 and right is digital Sensor7.

Pin Description
1 Sensor4 analog output.
2 Sensor4 GND/0V.
3 Sensor4 +5V supply.
4 Sensor5 analog output.
5 Sensor5 GND/0V.
6 Sensor5 +5V supply.
7 Sensor6 GND/0V.
8 Sensor6 clock input.
9 Sensor6 +5V supply.
10 Sensor6 digital, serial data output.
11 Sensor7 GND/0V.
12 Sensor7 clock input.
13 Sensor7 +5V supply.
14 Sensor7 digital, serial data output.
Connector to infrared sensors at lower belly of robot

Sonar Distance Ranging Module

The sensors are placed at the top of the robot body. Left is Sensor1, mid is Sensor2 and right is Sensor3. The connector and cable allow for connecting two additional sensors. Currently that is not made use of. This can easily be enabled in the software by setting s_sensorsToBeUsed to 5 instead of 3. (A future version may allow for configuration via RS-485.)
Pin Description
1 Sensor1 +5V supply.
2 Sensor1 GND/0V.
3 Sensor1 digital ECHO output.
4 Sensor1 digital INIT input (starts measurement).
5 Sensor2 +5V supply.
6 Sensor2 GND/0V.
7 Sensor2 digital ECHO output.
8 Sensor2 digital INIT input (starts measurement).
9 Sensor3 +5V supply.
10 Sensor3 GND/0V.
11 Sensor3 digital ECHO output.
12 Sensor3 digital INIT input (starts measurement).
13 Sensor4 +5V supply.
14 Sensor4 GND/0V.
15 Sensor4 digital ECHO output.
16 Sensor4 digital INIT input (starts measurement).
17 Sensor5 +5V supply.
18 Sensor5 GND/0V.
19 Sensor5 digital ECHO output.
20 Sensor5 digital INIT input (starts measurement).
Connector to sonar sensors at top of robot body

Motor Controller Module

The pinout of this connector still originates in my 1999 work. Today I probably would choose a different pinout. But I wanted to keep changes/effort small.
Pin Description
1 Motor1 DIR (direction) input.
2 Motor2 DIR (direction) input
3 Not connected.
4 Not connected.
5 Not connected.
6 Not connected.
7 Motor1 I (electric current) output.
8 Motor2 I (electric current) output.
9 Motor1 HALL (impulse from hall sensor) output.
10 Motor2 HALL (impulse from hall sensor) output.
11 Motor1 PWM (speed) input.
12 Motor2 PWM (speed) input.
13 Not connected.
14 Not connected.
15 +12V supply (no high power, just for switching the MOSFETs).
16 Not connected.
17 +12V supply (no high power, just for switching the MOSFETs).
18 GND/0V
19 +5V supply
20 GND/0V
Connector to motor driver board

Pin Description
1 Sensor1 GND/0V.
2 Sensor1 serial data in/out (TWI/I2C).
3 Sensor1 serial clock in (TWI/I2C).
4 Not connected.
5 Sensor1 +3.3V supply.
6 Sensor2 GND/0V.
7 Sensor2 serial data in/out (TWI/I2C).
8 Sensor2 serial clock in (TWI/I2C).
9 Not connected.
10 Sensor2 +3.3V supply.
Connector to Nunchuk (accelerometer) sensors

Pin Description
1 GND/0V.
2 GND/0V.
3 GND/0V.
4 GND/0V.
5 RS485 bus B.
6 RS485 bus A.
7 Primary +5V supply (2A).
8 Primary +5V supply (2A).
9 Secondary +5V supply (2A).
10 Secondary +5V supply (2A).
11 Battery +12V.
12 Battery +12V.
13 Battery +12V.
14 Battery +12V.
Connector to RS485 controllers outside 19" rack

This connector is intended for additional microcontrollers that do not reside in the 19" rack. Therefore power supply and RS485 bus lines are bundled in a 14 pin connector.

#### TODO: RS232 connector

Operations Manual

Integrating all Components

Mechanical Assembly

#### TODO ####

Electrical Assembly

#### TODO ####

Starting Up

Charging Battery

#### TODO ####

Turning On the Robot

#### TODO ####

Developing User Programs

Organisation of Source Code

#### TODO ####

The Subordinate Control API

#### TODO ####

Example User Program (Test Aid)

#### TODO ####

Another Example User Program (Drive Around)

#### TODO ####

Pictures and Screen Shots

How my daughter sees it... ...and how it actually looks.
An old shot of the robot
Robot in laboratory today
Inside the (almost empty) robot
Sensor bay for IR distance sensors (rubber cable feedthrough protecting the wires)
IR distance sensors with protective cover
Fan (standard PC component, without sensors, to be connected to mainboard)

Version History

Version Date Change
1.0.0 1999 Initial version. Case and head finished. Power supply integrated. Included one Siemens SAB80C527 microcontroller with Intel AN82527 CAN controller and second Atmel AT89S52 controller. 3 sonar sensors and 3 infrared sensors.
2.0.0 2003 Replaced AT89S52 by Conrad C-Control II controller board based on Infineon C164CI with CAN controller.
3.0.0 2012-10-07 Replaced all 8051/C164CI based controllers by Atmel AVRs. CAN bus replaced by RS-485 bus for ease of use. Added 4 more infrared sensors. 2 accelerometers added. Now also reads electric current of motors as well as battery status. 2013-09-01 added audio amplifier. 2013-10-04 added head controller and Kinect sensor.
3.1.0
2016-03-04
Windows (master) program does not communicate to microcontrollers via RS485 directly. Window's timing was to bad. Instead, Windows sends commands to a microcontroller via RS232. The microcontroller "translates" to RS485. This works very stable so far. Also, C# part simplified a great deal.

Copyright Statement

Ushabti MM Copyright (C) 1999-2017 Holger Zahnleiter

These programs and circuits come with ABSOLUTELY NO WARRANTY. This is free software and free hardware, and you are welcome to redistribute it under certain conditions. The programs and their source codes as well as the circuits and their wiring diagrams are published under the GNU General Public License (GPL). See http://www.gnu.org/licenses/gpl-3.0.txt for details.

References/Links

#### TODO ####

Downloads

#### TODO ####


Disclaimer

The information on this web site and the documents downloadable from here have been carefully reviewed and is believed to be reliable, but I do not assume any liability arising out of the application or use of any documents, programs or circuit described herein.
Furthermore I want to declare that I'm not responsible in any way for the content of other web pages, books and other sources I'm refering to.