User Manual

Theia lens motor controller instructions
Theia Technologies® motor control
v.180628
4. Software
4.1. Overview
A simple control software example is provided for testing and demonstration. That software is given “as is” in order
to help with getting started and testing.
The user can further integrate communication with the board into your own program. In addition to basic stepping
commands there are commands which set device parameters by writing values to a permanent memory on the
board.
There is the firmware update mechanism. It may be activated during power-up and in that case a new firmware
version can be uploaded, verified and saved to the device memory. Please contact us if there is any questions about
firmware upgrades.
4.2. Different bus behaviors
With exception of the SPI bus the boards have already been used with different serial buses, namely USB, UART and
I2C. In all these cases the commands to a board come from an external source and the board executes them and
answers. But there are limitations depending on the type of bus used. The board may be unable to answer while a
stepping command is being executed and/or the board may be unable to actually process any new command arriving
while currently executing a stepping command. The later most notably disables the usability of the STOP command
which would normally interrupt the execution of a current stepping sequence.
The current firmware only supports the USB bus. We will soon have a version that simultaneously supports all buses,
but for now we will limit the description to USB and add the features of the other buses as soon as they are
integrated.
The USB bus as it is currently handled on those boards include both limitations listed – unable to answer or process
new commands while executing the current one. Commands arriving at such a time will remain in the 512 byte input
buffer until they can be processed. That buffer may overflow so we recommend not to send new commands until
execution of the previous command has finished. In the case of an overflow a partial command will most probably
remain in the buffer. To clean this a byte containing “Carriage Return” (0x0D) needs to be sent.
If commands are being discarded (like a STOP command when no movement is currently executed) the board will
not send the related confirmation. Since via USB any arriving command is being delayed until the end of any
movement this will always happen so the STOP commands becomes useless and “invisible” via USB. Such behavior
may also concern other commands.
4.3. Serial Protocol (version 5.2.0.0.0)
The current protocol is very simple. That makes it suitable for fast commands coming from low-power hardware.
Each command starts with its ID and ends with carriage return CR(0x0D).
The answers coming from the board also end with carriage return CR(0x0D).