In the screen dump above half step mode in forward direction is selected.

Interrupts

Normally interrupts can only be generated on pins 2 and 3 on an Arduino Uno or Nano. However, there are also so-called "PinChangeInterrupts" which allow to hook up an interrupt service routine when a signal level change on a GPIO pin happens. This can be "FALLING" or "RISING" for a falling or rising edge of the signal or it can be "CHANGE" for both edges.

Unfortunately there is a problem when using this with the SoftSerial library because both libraries use the same interrupt vectors. Since for our debugging port we only have to send but to not receive message I use the SendonlySoftSerial library attached to this page:

https://iotworkshop.africa/pub/Embedded_Systems/ImplementingTheArduinoToolbox/SendOnlySoftwareSerial.zip

These are the protocol codes sent to the Arduino:

Iacup: a: attach pin p for c: change mode f: falling edge: r: rising edge, u: updown: u: up-counter, d: down-counter c: clear
Idp: d: detach from interrupt on pin p
Irp: r: read no of counts from interrupt counter

Encoder

The rotary encoder also make use of interrupts. It uses 2 signals: clock and data to see when it is turned and in which direction it has been turned. The clock signal is connected to an interrupt and the interrupt service routine, by looking at the data signal, finds out if the encoder was turned clock-wise (a counter increments) of counter-clock-wise (a counter decrements).

The multi-function board

In order to test digital read/write, analog read/write etc. we need an Arduino to which the corresponding hardware is connected, e.g. a switch to be read with digital read, a potentiometer for analog read or an LED for digital write... An easy solution is to use the multi-function board which has all these connections already done and which must simply be installed as a piggy back board onto e.g. an Arduino Uno.

As can be seen from the photo the multi-function board has

https://iotworkshop.africa/pub/Embedded_Systems/ImplementingTheArduinoToolbox/multiFunctionBoard.pdf

I use GPIO pin 2 as TX line for a SoftSerial port onto which I send debugging messages. There is a problem when using this with the PinChangeInterrupt library because both libraries use the same interrupt vectors. Since for our debugging port we only have to send but to not receive message I use the SendonlySoftSerial library attached to this page:

https://iotworkshop.africa/pub/Embedded_Systems/ImplementingTheArduinoToolbox/SendOnlySoftwareSerial.zip

Reading analog values

The Arduino has several 10 bit ADCs on chip which can be used to read analog voltage levels. Here is the command code:

Ap: reads the voltage level from analog pin p

How to bring the demo system up

A tar archive with a Xcos toolbox containing Digital Write as well as as a basic stepper motor xcos block is attached to this page:

https://iotworkshop.africa/pub/Embedded_Systems/ImplementingTheArduinoToolbox/arduino-linux_1.5-src.tar.gz

This is the original arduino_1.5-src archive downloaded from git which I modified to run on Linux. Only Digital Write and the stepper motor module are working. The other modules are still part of the archive but will most probably not work. In the original archive the stepper motor block was removed from the Arduino palettes. It has been put back. The original Arduino sketches have been moved into arduino.old and a new server sketch developed which you find in the arduino folder.

To install everything please

• create a folder /opt/ucc/scilab
• unpack the above tar archive into this folder.

In arduino/serverTest you will find test programs for the server sketch as well as interface functions in serialLib which interface the XCos block Scilab code to the serial driver. The test program,running on the PC, (have a look at blink2.c) passes through these functions and calls the driver in exactly the same way that Scilab will use. For the moment only 2 such test programs are available:

• blink2.c reading out the server version and blinking the Arduino builtin LED on GPIO pin 13
• stepper.c which make the stepper motor move. The coil pins on the stepping motor controller (N1 .. N4) must be connected to Arduino GPIO pins 2..5

Then start Scilab. Load the macros

• builder.sce
• loader.sce
• unloader.sce

You should see something similar to this:

If the builder exits successfully then you can start the loader adding the Arduino features into the Scilab system. This is what you should see:

Now you can start xcos either by typing xcos in the command window orr by clicking the Xcos icon (the one looking a bit like an oscilloscope). In the palettes box coming up you should see an Arduino entry:

Now you can create a diagram using your new Arduino blocks and run it. The LED should blink or the stepper motor move.

The communication protocol

• version: returns the version number of the protocol server on the Arduino
• digital read or write
  This allows to read the state of a GPIO line defined in the xcos block or to write a high or low state to this GPIO line. Before the xcos simuation (the scilab program on the PC) is started (pre-simulation) the mode of the GPIO line is set.
• stepping motor
  Here we set the GPIO pins associated to the stepping motor pulse to output in the pre-simulation step. The a "do one step" command is sent to the server.

Getting the server version

Controlling a stepper motor

In case of the stepper motor we need a means to define which GPIO pin is connected to which stepper motor coil. This is done with a command:

Sanp: Where "S" identifies for the stepper motor device, "a" stands for "attach" n is the GPIO pin and p is the pulse (N1 .. N4 or the stepping motor driver module) . The command also programs the GPIO pins as output. Sa21 will therefore attach GPIO pin 2 to the first stepping motor driver input (N1 on the driver card).

Sm: moves the stepping motor by 1 step

The Arduino server program and the test procedure

Since the test programs and the xcos toolbox use the same communication code we can be sure that once the server is tested with the test programs it will also work on the toolbox.

Here is a screen dump of the server output when we first read the server version and then blink the builtin LED (on GPIO pin 13) 5 times:

And this is the output from the Arduino server onto /dev/ttyUSB1 when running the stepper motor test:

I decided however to re-implement the Arduino server including better debugging features.

The communication protocol must be as simple and short as possible in order to increase the speed and therefore the maximum possible sampling rate. Here is the basic protocol description:

Setting the analogue reference and getting the server version

R0: sets the analogue reference to default
R1: sets the analogue reference to internal
R2: sets the analogue reference to external
R3: gets the server version code. The server answers with Vx where x is the version number e.g. V4 for version 4

Reading or writing a digital GPIO line

Dan0 or Dan1: attaches GPIO line n. The last character defines if the line in input (0) or output (1). n is the GPIO pin number which can be '1' (0x31) up to '9' (0x39). For higher pin numbers just take the next ASCII characters. Having a look at the ASCII table tells us the pin number 10 will correspond to the ASCII characters with code (0x3A) which is ':', 11 corresponds to ';' and so on.
Drn: Read the state of GPIO line n
Dwn0 or Dwn1 sets the GPIO line n to 0 or 1 respectively.

With this information it is possible to develop the first version of the Arduino server. Since all it needs is input from the serial line we can write a simple C program to test the server. A program asking for the server version (and printing it) as well as the Arduino server are attached to this TWiki page.

The Arduino server uses debugging code which prints each character received as well as the interpretation in makes out of it to a Softserial port with Rx connected to GPIO pin 11 and Tx connected to pin 10. This Softserial port can be attached to a USB to serial adapter and the output observed with a serial emulator program like minicom. The communication between Scilab and the Arduino happens on /dev/ttyUSB0, the debugging port should therefore be connected to /dev/ttyUSB1 (minicom -D /dev/ttyUSB1).

Here is a screen dump of the server output when we first read the server version and then blink the builtin LED 5 times:

Implementing the Arduino toolbox

The program structure

As you would probably expect, the program will consist of three parts

• a server running on the Arduino taking commands from Xcos and accessing the GPIO hardware
• an Xcos client implementing the Xcos blocks
• a protocol defining the communication between client and server

-- Uli Raich - 2019-01-07

Comments

<--/commentPlugin-->