Arduino. Serial Communications and Debugging

When a computer program becomes more than a few lines long, or when you need to understand a complicated statement, you need to pause the program and somehow see what it is doing. One way of doing this is simply to use the debugging tools inside the development environment. Normally, these tools will allow you to step through the program a statement at a time and allow you to see variable values in a window. They will also allow you to step over functions, and breakpoints can be used so you don’t have to follow each statement in a loop.

Very often, this all comes at a price – you have to make a “debug” version of your program containing references to symbols for the debugger to track, with the result that the debug version can be very large.

In the case of the PIC TRIX – you have to step through the code in an emulator, which is very limiting, but even that is better than the Arduino IDE which has no debugger at all (as far as I can see).

The designers of the Aduino IDE (Integrated Development Environment) were probably wise to omit the debugger, since most sketches/programs are quite short.

One time-honoured method of debugging is to use a soft pencil and write down the results of what you expect each program statement to do. If you get a colleague to do this for you .. the results can be quite instructive for both parties. (A pen doesn’t work, because there’s lots of erasing.)

But, if you have no friends and no debugger, then you might have to resort to printing out the result of any statements you are somewhat unsure about. In a normal programming environment – this is what many programmers do. (In Windows and Javascript this means popping up little message boxes.) In this environment, we send messages down a piece of wire to a serial or USB port connected to a glass teletype. – I used to have a real computer terminal, but it “blew up” last month and it was taking up too much space anyway.

Serial Communications to the Arduino

There is nothing to do. The arduino has its own little terminal emulator built-in to the IDE. This makes Arduino programming much easier.

Serial Communications to the PIC TRIX

The PIC16F877(A) has an on-chip USART (Universal Synchronous-Asynchronous Receiver Transmitter). This is a gadget that simply translates characters given to it and converts them to a series of voltage levels. So, if you send the value 10011111 to the chip, it will send pulses of electricity down the transmit wire corresponding to that value. Conversely, it will receive pulses and convert them to a value along the receive wire. The third wire is ground. The speed at which the transmission is sent is the baud rate. I think this is synonymous with bits/sec.

You will hear of other complications, like parity, stop bits and so on in connection with serial communications, and of course, the speed. The PIC TRIX board is simple – it just sends at 9600 baud, no parity (see the page on the talk program. )

One complication of using “traditional” serial commuications, is the amplitude of the pulses. This is +-12 Volts. To handle the conversion, a venerable chip called the MAX232 is used.

The first step is to wire a short length of cable, in accordance with the instructions on the CD provided. Be careful to insulate the soldered joints at the DB-9 connectors – otherwise they may short (as happened to me) and the cable won’t work. Also, mark the cable to show which end plugs into the PIC TRIX and which end plugs into the computer. Next use the PIC Kit programmer to burn the sample serial program. The program source code is on the CD – but it’s in assembly language. The binary for download has a .hex extension. (test3.hex). in the DevBoard directory. You might have to assemble it using the microchip IDE.

If all goes well (There should be no problems), your terminal will display “MICROCHIP IS TOPS!”.

What if it doesn’t work? Well,the program works, so it must be something else.

Check:

• The serial cable connections carefully – is it the right way round?
• The protocol – baud rate, data bits, stop bits – should be as per the program header,
• Does it work with hyperterminal but not with DOS (or vice versa)?
• Check the correct com port is being used – the DOS program uses COM1, with hyperterminal you have 16 or more ports,
• Check the PIC TRIX board for shorts or poor solder joints
• Check the MAX232 is correctly oriented,
• Check the PIC16F877 is the right way round (my favourite mistake), and
• Did you wire the programme correctly – I’m sure you did.
• If you really get stuck – then its time to “phone a friend” – at least let someone else look at your setup.

A ‘C’ testbed framework for PIC TRIX

The Arduino doesn’t need this sort of thing – its all built-in. You just write your sketch and do a Serial.write ( .. ) . This simple statement works because the inner workings are hidden from you.

The ‘C’ program for the PIC is almost as simple, but before you can issue a

printf("Hello World!\n");

there’s a bit of preparatory work to be done. This is illustrated in the following program:

The “Testbed” Program

#include 
#include 
#include 
#include "usart.h"

__CONFIG(XT & WDTDIS & PWRTDIS & BORDIS & LVPDIS &
 DEBUGDIS & DUNPROT & UNPROTECT);
/* A simple demonstration of serial communications which
 * incorporates the on-board hardware USART of the Microchip
 * PIC16Fxxx series of devices. */

void main(void){
/* Code to initiallise communications */
 INTCON=0; // purpose of disabling the interrupts.

 init_comms(); // set up the USART - settings defined in usart.h
/* Don't change the above code */
/* Declare the variables you are going to use */
 unsigned char input;  
 double var;
 char buf[80];
/* Variables declared ! */
/* Now Output a greeting message */
 
 printf("\rEnter a number and I will echo it back:\n");

/*  This is the program loop   */
 while(1){

/*  Put your repetitive loop code here */  
  gets(buf);   // Read the input string into buf
  var=atof(buf);   // Convert it to a float
  printf("\rI detected [%f]",var);// echo it back
/* End of loop code */

 }
/* The above braces signify end of the loop */
}

One more snag – ‘C’ s printf, scanf etc. routines are very heavy in terms of program memory use. This is not helped by the free compiler’s lack of optimisation.. Of course, once you have used “printf” once, then you can use it quite a few more times.

The program also needs two other files – namely “usart.c” and “usart.h”. These are supplied as part of the Microchip compiler – take a look inside them, especially if youare using a clock frequency other than 4MHz.