Ece 341 Lab7

Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

ECE 341

Asynchronous Serial Communications

Lab 7

Submitted By :
Dean Johnson
Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Testing and Verification . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1
Lab 7 Dean Johnson

1 Introduction
The goal of this lab is to communicate with the microcontroller using a terminal
emulation program, or to communicate with the microcontroller using the desktop
keyboard. This is done by establishing a serial link between the Cerebot and the PC.
It is intended that this project models a system that is capable of remote and local
control. This lab will utilize a universal asynchronous receiver/transmitter (UART)
this device is used to translate the data from and to the PIC32. The UART is used
along with an R232 transmit driver that allows serial data to be exchanged. For this
lab will need both the LCDlib.c and LCDlib.H files from the previous lab along with
the comm.c and comm.h files that allow us to use the UART within these files the
UART is configured and provides us with the printf function as well as a handful
of other functions to be used in this lab. The overall goal of the lab is to control
the stepper motor and write to the LCD screen using putty on the PC. For this
lab a plan to utilize code from both the previous lab and lab 5. I will modify the
CN interrupt so that the write to the LCD and the PC. Within the while loop the
program will wait for a string then disable interrupts, clear the LCD, and then the
string will be used to set the control variables and be written to the LCD, then the
CN interrupt will be re-enabled.

2 Implementation
To begin this lab the code from Project 5 is imported into the main file for the lab.
The files from Lab 6 are also included so that the the direction, mode, and speed
can be displayed to the LCD Display. The UART is initialized within the system
init function of the lab setting the baud rate to 19200 and odd parity, the system
init function is shown in the listing below.
Listing 1
1 void system_init ( void ) {
2 C e re b o t_ m x 7c K _ se t u p () ;
3 PMP_init () ;
4 L C D_ C o nt r o ll e r _i n i t () ;
5
6 initialize_uart1 (19200 , ODD_PARITY ) ; // Uart initializeation
7
8 P O R T S e t P i n s D i g i t a l O u t ( IOPORT_B , BIT_2 | BIT_3 | BIT_4 | BIT_7 |
BIT_8 | BIT_9 | BIT_10 ) ;
9 P O R T S e t P i n s D i g i t a l I n ( IOPORT_G , BTN1 | BTN2 ) ;
10 LATBCLR = BIT_2 | BIT_3 | BIT_4 | BIT_7 | BIT_8 | BIT_9 |
BIT_10 ;
11
12 OpenTimer1 ( T1_ON | T1_PS_1_1 , ( T1_TICK -1) ) ;

2
Lab 7 Dean Johnson

13 mT1 SetInt Priori ty (2) ;


14 m T 1 S e t I n t S u b P r i o r i t y (0) ;
15 mT1IntEnable (1) ;
16 cn_init () ;
17 I N T E n a b l e S y s t e m M u l t i V e c t o r e d I n t () ;
18 I N TE n a bl e I nt e r ru p t s () ;
19
20 }

Above the main loop strings are created for each the direction, and mode as well
as a string that holds all of the values. A message is printed to to verify that the
UART is functioning. Within in the project 5 source file the code within the CN
ISR is modified so that the string from the decode buttons is printed using both the
comm file and the LCD files this output is shown in Listing 2.
Listing 2
1 sprintf ( recv_str , "% s % s % d " , dir_str , mode_str , speed ) ;
2 LCD_puts ( recv_str ) ;
3 putsU1 ( recv_str ) ;

A decode string function is created to convert the values received from Putty to
values that are then sent to PIC32 that set the direction mode and step delay from
the speed. This decode function is shown in Listing 3.
Listing 3
1 void decode_string () {
2 if ((!( strcmp ( dir_str ," CW ") ) || (! strcmp ( dir_str ," cw ") ) ) )
3 dir = CW ;
4 else if ((!( strcmp ( dir_str ," CCW ") ) || (! strcmp ( dir_str ," ccw ") ) )
)
5 dir = CCW ;
6 else { };
7 if ((!( strcmp ( mode_str ," FS ") ) || (! strcmp ( mode_str ," fs ") ) ) ) {
8 mode = FS ;
9 step_delay = 60000/( speed *100) ;
10 }
11 else if ((!( strcmp ( mode_str ," HS ") ) || (! strcmp ( mode_str ," hs ") ) )
) {
12 mode = HS ;
13 step_delay = 60000/( speed *200) ;
14 }
15 else { };
16

17 }

Within the main project 7 source file the system initialization function is called and
the ready test message from the UART is printed, once it is shown to be functioning,

3
Lab 7 Dean Johnson

within the while loop the the string is polled low within another while loop, when
this loop exits the change notice ISR is set to false the LCD display is cleared and
the string from Putty is read and decoded, I also checked to make sure that the
speed was below 30 and if not it was it is then set back to 30 RPMs. and the string
is reprinted. the string is then printed to both the LCD screen and the Putty display
and the change notice ISR is enabled. The main loop is shown below in Listing 4.
Listing 2
1 int main () {
2 system_init () ;
3 putsU1 ( rdy_msg ) ;
4 printf (" Dir_mode_speed \ n ") ;
5 while (1)
6 {
7 while (! getstrU1 ( recv_str , sizeof ( recv_str ) ) ) ;
8 mCNIntEnable ( FALSE ) ;
9 clear () ;
10 sscanf ( recv_str , "% s % s % d " , dir_str , mode_str , & speed ) ;
11 decode_string () ;
12 if ( speed > 30)
13 {
14 speed = 30;
15 sprintf ( str_buf , "% s % s % d " , dir_str , mode_str ,
speed ) ;
16 }
17 LCD_puts ( recv_str ) ;
18 putsU1 ( recv_str ) ;
19
20 mCNIntEnable ( TRUE ) ;
21 }
22 return (1) ;}

This is the only code within the main project file. All other parts are included in
other files. The UART’s receive functions are declared in the background, so that
no data that is intended to be processed is missed by the communication between
the UART and the desktop. This is do to the speed of the information transfer and
the time needed for any button debouncing on the boards side. If the UART receive
functions were in the foreground there is the possibility that some data may be lost.
The mon putc function provided within the comm file checks if the UART is busy
and when no longer busy it writes the character using the writeUART function.

3 Testing and Verification


For the beginning of the lab the UART is implemented by including the provided
comm files and then by initializing the UART and setting the baud rate and parity,

4
Lab 7 Dean Johnson

then by using the putsU1 function it can be verified by writing a message to the
Putty display window on the desktop. When the message is seen on the display
this verifies that the UART is working and is communicating with the PIC32. The
motor controls were implemented simply by importing the code from Lab 5 into
the project these were simply tested by verifying that the buttons still control the
motor as expected. The LCD display is incorporated by importing the LCD files
from the previous lab, and then within the change notice ISR the mode, direction,
and speed are written to the LCD Display. Then the ability of writing to the LCD
from the UART is done by having the string decoded and then processed using a
decode string function. This is all tested upon visual inspection, writing a string
to the Putty command window and verifying that it writes to the LCD display and
controls the motor and vice versa.

4 Conclusion
This lab proved to be very practical in using a desktop device to control a mo-
tor implementing the ISR, and the LCD as well as maintaining the original button
functions of Lab 5. The lab also shows the functioning of asynchronous serial com-
munication this is different from parallel communication in that data only flows on
one line in bit by bit either way for reading or writing, whereas in parallel com-
munication multiple lines are used so that data can be written or read on separate
lines. Serial communication tends to be slower than parallel transmission, serial
communication is generally used for long distance communication for this instance
from a desktop to a microcontroller, parallel communication is general used for short
distance communication for example a desktop to nearby devices such a printer. It
is important for a design to be modular since this allows the design to be re-usable
and easier to debug, as well as being less expensive. By being modular a system
is broken down into its individual components for this lab each separate subsystem
has its own file so that it can be called on and reused in other projects.

You might also like