Skip to content

Latest commit

 

History

History
95 lines (77 loc) · 4.36 KB

M01.md

File metadata and controls

95 lines (77 loc) · 4.36 KB
layout title license
default
Serial Communication

Introduction

This lab runs for 2 weeks and covers the use of the mbed serial communication libraries for both blocking and non-blocking I/O.

You may find it helpful to refer to the mbed documentation for

You will need to work with a partner in the labs to complete these exercises. Each partner should connect their FRDM-K64F to a PC, as usual. Place your boards close enough to to each other so that you can connect them using 2 male-male jumper wires. You'll need to remove the application shield from the FRDM-K64F base board in order to connect the jumper wires. You should do this as gently as possible, ensuring that the application board is removed evenly. You will use UART3 for communicating using the FRDM-K64F boards. See FRDM-K64F for the pinouts. You should connect the boards as follows:

  • Board 1 RX-TX Board 2
  • Board 1 TX-RX Board 2

Blocking Serial I/O

  1. You should begin by working with a simple client/server example. One partner will build the server code:

    $ mbed import https://github.com/davidkendall/serial-server
$ cd serial-server
$ mbed compile -t GCC_ARM -m K64F

    The other partner will build the client code:

    $ mbed import https://github.com/davidkendall/serial-client
$ cd serial-client
$ mbed compile -t GCC_ARM -m K64F

    Open a terminal window on each PC and start a minicom session, so that your board can communicate with your PC. Set the minicom parameters to 115200 8N1. Now load and run the server program. Next load and run the client program. You should see some output in your minicom terminal indicating that the boards are communicating. If not, ask your lab tutor for help.

  2. Once you have your boards communicating successfully, try changing the baud rate of RawSerial client to 9600. Build, load and run your programs again. What happens? Explain your observation. Change your RawSerial client back to 115200. Check that everything works again.

  3. Modify your programs to use UARTSerial instead of RawSerial. Use write for output (instead of putc) and read for input (instead of getc). Pay careful attention to the semantics of write and read (read the documentation carefully). You'll need to be particularly careful with read. Build, load and run your new programs. The behaviour should appear to be the same as before.

  4. Try to develop a protocol that makes it possible to start the client program before the server program and still allow the exchange of data, as usual. This requires some thought. Focus on the client program.

  5. Use the technique shown in the lab in week 9 of semester 1 to measure the time taken by the client to receive a complete message from the server. Apply this technique to the original program and to the program that uses UARTSerial. What conclusions do you draw from the results? Given the bit rate of the UART and the length of a message, how long would you expect it to take to receive a message? How does this compare with the value that you have measured? Can you explain the data?

  6. Write a client program that waits for the user to press either SW2 or SW3 and then sends a request message to the server. If SW2 is pressed, the client should request the server to send its accelerometer data; if SW3 is pressed, the client should request the magnetometer data. The server should respond appropriately in each case, and the client should display the result on its minicom terminal.

Non-blocking Serial I/O

  1. Modify the original client and server programs to use asynchronous read for receiving data.

  2. Modify your client program that can be safely started before the server to use asynchronous read for receiving data. This exercise should illustrate the benefits of asynchronous I/O. What do you think is the main benefit?

  3. Modify your solution for 2.6 to use asynchronous reads.