Sea Glider Development and Power Characterization

Sean Lastuka

EE542 Final Report

December 8, 2007

University of Washington

Table of Contents1. Sea Glider Background 2

2. Sea Glider Design 3

3. Project Overview 4

a. Linux Installation 5

b. Serial Port Operation 8

c. SD Card Operation 9

d. Power Characterization 9

4. Conclusion and Final Thoughts 11

5. References 13

6. Code Appendix 14

1

Sea Glider Background

The Sea Glider is an autonomous underwater vehicle (AUV). It is used in scientific, military and burgeoning commercial roles. It is used as a mobile platform equipped with sensors that monitor salinity, water temperature, pressure, acoustics and other ocean related characteristics. Some primary considerations in Sea Glider design include mission duration, electrical sensor load, maximum depth rating, forward velocity and cargo capacity.

To travel forward, the Sea Glider must alternatively sink and rise through the water column, see Figure 1. The rising and falling motions create a hydrodynamic effect on the wings of the Sea Glider to promote forward motion. Through this effect, a Sea Glider travels horizontally through the water at a speed of approximately one foot per second. The primary component that enables the sea glider to rise and fall through the water is a variable buoyancy device (VBD). This device is mounted on the Sea Glider’s fuselage as shown in Figure 2. It effectively changes the density of the Sea Glider. When the density of the VBD is reduced, the Sea Glider rises. Alternatively, when the density increases, the Sea Glider sinks... like a rock.

Figure 1: Sea Glider motion. A sinking glider has high density, and a rising glider has low density.

2

To better understand the VBD, compare it to a basketball. The ball has low density compared to water. As you push it under the water, the very buoyant ball wants to return to the water surface, where it more closely matches the density of the surrounding air. However, if the ball is deflated (its density is increased), the less buoyant ball can more easily be pushed underwater and may even sink. In the same way, if the density of a Sea Glider is low, it will tend to float at or near the surface. As the density increases, the Sea Glider will begin to sink. It is the VBD which allows this change is density.

Figure 2: Sea Glider constructionNotice oval-shaped Variable Buoyancy Device near the tail section.

Sea Glider Design

As mentioned earlier, one of the primary considerations in Sea Glider design is mission duration. Most Sea Glider missions involve data collection over wide expanses of ocean. Moving steadily at ¼ knot/hr, the Sea Glider may need two months to collect data over a 1000 nautical mile mission path. Electrical power must be conserved to ensure full glider operation is maintained over such an extended mission. Effective use of sleep modes, power savings modes and low power peripherals are imperative to minimize power consumption during different operating states encountered during a mission.

The current incarnation of the Sea Glider does an excellent job conserving power for its longer mission times. However, it is based on a TT8 68332 32-bit microcontroller. The TT8 runs picoDos as a native operating system. PicoDos is not a true multithreaded operating system. Hence, simultaneous tasks can not be handled at once. As Sea Glider users begin requesting improved autonomous navigation and decision making capabilities, a non-multithreaded architecture will hinder further performance enhancements.

To improve Sea Glider performance, autonomous decision making will need to be improved. During navigation, independent decisions about the surrounding ocean state will help make better use of currents, up-welling and down-welling effects. Onboard processing of acoustic data will allow small uploads of significant environmental data when surfacing. Since processor intensive operations take a significant amount of time, a multi-threaded architecture is useful to perform multiple operations at once. Also, if an operation must be performed in a limited span of time, processor performance should

3

have the ability to step up and quickly produce results. With these requirements in mind, the Sea Glider began evaluating a replacement for its embedded TT8 microcontroller.

The embedded processor market is diverse, with manufacturers such as MicroChip, Atmel, Phillips, TI, Freescale and Marvell. Ultimately, three microprocessors were evaluated the BlackFin, XScale, ARM9. The ARM9 was selected because it was the only one of the three with an onboard Memory Management Unit (MMU). The LPC3180 is also designed with a 1.2V core voltage and can support 0.9V core voltages as long as the MCU is running at a speed of less than 13MHz.

The MMU creates an interface between the physical memory and the microprocessor core. The microprocessor can then address virtual memory, which the MMU will interpret into physical memory locations. The advantages of this architecture include better physical memory organization and utilization, and a simple memory map from the processor standpoint. The disadvantages of an MMU relate to reduced die space for other functions or peripherals and slower absolute memory access speed, at least on the basis of a single word memory access operation. However, the main advantage,for our purposes, of an MMU is that it is able to run a full distribution of Linux. Without an MMU, only uCLinux (an abbreviation for microcontrollerLinux) is available. uCLinux does not require an MMU to run, but therefore, needs special attention to run multiple applications simultaneously. Since the Sea Glider program intends to take advantage of (and contribute to) the full range of the Open Source community’s software the operating system needs to be fully compatible with the standard Linux code base. The decision to run Linux narrowed our selection to the ARM9 based Phillips (now NXP Semiconductor) LPC3180. Phytec, a local embedded system development kit supplier, provided the PHYCore LPC3180 Development Kit.

The Phytec development kit consists of a Single Board Computer (SBC) and a carrier board. The SBC is populated with the LPC3180, a 32MB NAND Flash Memory and a 32MB SDRAM Memory. There are also two RS-232 transceivers, three of UARTs are connected through these transceivers. The carrier board supports two RS-232 Serial connections, SD Card, USB, LEDs, a potentiometer for the A/D and user definable switches. The SBC is connected carrier board through a pair of 100-pin connectors that carry LPC3180 signals to the carrier board peripherals and on to an expansion board.

Project Overview

The full design of the next generation embedded system for the Sea Glider will encompass four phases.

1. Confirm LPC3180 system performance, develop a stable Linux OS and user applications

2. Interface existing sensors and communications hardware with the LPC3180 system

3. Characterize system performance

4. Install the system in the current Sea Glider and test at sea

4

Before starting design, we have attempted to consider possible design roadblocks, but it is possible there may be problems encountered during development. Should this be the case, we may be required to fall back to a previous phase to rectify the issue. Once the previous phase has been corrected, it is important to test all the previous deliverables, to ensure no other system function was mistakenly compromised after the targeted design change.

In the limited time of this project, we will address the first development phase: confirm LPC3180 system performance, develop a stable Linux OS and design the user applications

1. Linux installation and basic memory card interface

2. Serial setup

3. Power mode switching

4. Power characterization of above modes and peripherals

Linux installation

To begin running tests and applications on the LPC3180, an image of the Linux OS and the Linux FileSystem is downloaded via a JTAG interface, into the NAND flash. A bootloader (UBoot) is also loaded into Flash. A secondary bootloader (SIBL) is used to transfer the UBoot and Linux Image and Linux Filesystem into SDRAM where UBoot then boots up Linux. Initially, this caused issues because Linux would boot up successfully, but would constantly refresh making terminal input difficult. Luckily, we had a second LPC3180 available with the same UBoot and Linux Images copied into the Flash, the second system worked and reliably booted Linux.

Serial Port testing

Serial interfaces are the primary method of communications in ocean going embedded systems, including those aboard the Sea Glider. The simplicity in board layout with a serial communications device combined with easier debug is important in a field where power savings, simplicity and reliability dominate the list of design criteria. Frequently, ocean going systems may need field repair and diagnostic analysis. Serial communications can be quickly probed with an oscilloscope or logic analyzer to get an idea of device operation. Where possible, we will layout boards with serial communication break-out pads to be used as test points.

The LPC3180 has seven UARTS. Three UARTS are capable of 921kbps with the remainder at 460kbps. The terminal communications use a standard UART. The auxiliary RS232 port is connected to a high

5

speed UART, which has the same range of frequencies as the regular UARTs, with one extra frequency at 921kbps. We interfaced this second RS232 jack with another terminal window.

With the serial port, we simply wished to perform a serial data transfer. To start, we investigated the file system. The /dev directory displays all available devices. If the user wishes to access a device listed under /dev they reference the file by name through the kernel’s open command. This command returns a file descriptor. The file descriptor is a handle with properties and methods which may be used to access the under lying device. The newser.c file at the end of this report shows examples of operations using file descriptors and kernel commands to execute a serial data transfer.

On our system, before we get to the results from the file transfer, a little background on Linux devices should be discussed. When checking out the dev file, the user can enter the ls –l command on a file such as /dev/ttyPSHS0. The result will show a major and minor number in this form: 274 1. The number 274 indicates the location of the driver in the kernel code and the minor number indicates the driver instance. All drivers of the same device type will have the same major number, as they all use the same driver code, but will have different minor number, to differentiate them by instance. A USB driver, an Ethernet driver and a serial driver will each have a different major number. Their minor numbers will typically start with zero and increment up for each instance of the driver.

The device drivers should be installed as modules. The module can be compiled in the Linux source tree, and added to the system using the command insmod. However, our Linux image had no modules. The Linux Image supplied with the phyCORE system was a monolithic image and couldn’t be tailored using commands such as insmod /rmmod, which add/remove modules. In this case, we rely on the drivers embedded in the development kit to work as is. If they don’t operate correctly, or have all the functionality we need, a time consuming make on a large part of the kernel may be required to make changes.

Assuming the installed Linux image has all the drivers available, the user must figure out which device files will actually write to a physical serial port. There could be a dozen different devices files, so knowing which one to use can quickly be determined through a process of trial and error, usually starting with the file with the lowest number, like tty0, or ttyS0. In our case, we found our available serial port was ttyPSHS0. However, we didn’t know this information immediately, and it took some experimentation to figure this out. There will be more on serial port setup later in this paper.

As mentioned earlier, the newser.c serial transfer program is used to transmit a string of integers to the host system. This serial code will open the selected driver and the driver will handle the setup of the serial port.

A dedicated investigation checked a number of system processes to see if a serial interrupt was being generated with each call of the serial program. Activity was present on the interrupt counters, IRQ addresses and registers, which can be found in the following files:

/proc/tty/driver/serial

6

/proc/tty/driver/ttyPSHS

/proc/interrupts

One important thing to note is that if a serial program doesn’t appear to be working properly (there’s no output on the serial line) with a given driver, every check should be made to ensure that the rest of the system is set up properly. In the case of our development system, a serial port didn’t appear to be working correctly via a probe of the TX pin with the oscilloscope. At this point we began checking to see if the output could internally loopback to the input, so we could check the receive register. This functionality was enabled via the loopback bit in register 0x40054008, the serial port loopback setup register. The serial port schematic indicated that if the loopback bit were enabled, the output TX would loopback to the RX register, while still continuing to propagate onto the TX pin to the RS232 level shifters and physical serial connector.

Figure 3. Serial block diagramThere is a multiplexer where the node indicates a simple wire connection

After continuing to experiment for a handful of days with different serial ports, physical port configurations, C code changes, and internal register modifications to no avail, I demonstrated the problem to my advisor. Up to this point, I had found that the loopback mode disabled output on the serial port. By turning off the loopback mode, the serial port began to function correctly and produce output data. Also, I had found that setting the ‘No Connect’ serial port enable bit would actually enable serial port output. When that bit was cleared, the serial port could not transmit. In my demonstration, I highlighted these findings, but I did it in a newer incarnation of my code, where I ran the correct driver /dev/ttyPSHS0. I set up the oscilloscope on the expansion board where the TX pin was represented and executed the serial binary. To my surprise, the serial port actually worked. The new

7

driver was used, and apparently, had corrected the port enable register despite the improper documentation in the datasheet. Early on, in my serial port debug, I believe I had not originally set up my oscilloscope correctly and used a /dev/ttyS0, and therefore couldn’t see the serial port operating in the first place. Those were the two main variables in not having correct operation. However, during the debug process, I introduced a lot of additional parameters to the problem, which turned out to complicate the process. Of course, this process was an excellent learning experience, no nothing was lost.

After finding the serial port working correctly, we wrote a simple Python program to receive the serial data at the host end to verify correct operation. The Python received the LPC3180 data correctly.

SD Card

The SD Card is important to the development effort. We store executable binaries from the host system onto an SD Card, remove the card from the Host system, and insert it into a slot on the LPC3180 carrier board. The Linux kernel installed on the LPC3180 system has an SD Card driver. The mount command allows access to the SD Card anywhere in the directory tree that we choose to the place the SD Card. However, it is important to umount the SD Card directory before removing it from either the host system or the LPC3180 carrier board. Failure to do so may result in a corrupted superblock on the SD Card. This may be because the latest flash configuration was not properly written to the superblock prior to shutdown. If this happens, an e2fsck command can reassign a secondary, backup superblock to remount the drive. Aside, from when e2fsck is called on the command line, it will also run automatically, after a certain number of flash card insertions. An inexperienced user may be confused by some of the e2fsck messages. While an e2fsck should be periodically run to clean up bad flash memory blocks, its frequency of execution could be reduced on a development system where the number of insertions could be 50-100 a day. Using command line options with tune2fs, the user may select the number of insertions before the e2fsck command issues. Also, there can be some confusion between ext2 and ext3 file systems when the user invokes the fdisk command to format a new flash memory device. Typically, it is ok to use an ext3 file system. The only difference between ext3 and ext2 is the inclusion of journaling in ext3.

Once the SD Card flash drive has mounted and can be accessed, it may be automatically mounted on boot-up. A simple way to change the auto mount is to modify the last boot up file. The boot files are usually numbered sequentially. Check the /etc/rcS.d or /etc/init.d directory. In our case, we have an S90check_sd.sh script where the automatic mounting can take place. You can program in automatic mounting by simply placing a mount command with the correct driver and mount directory in the shell script. Other things we may optionally mount in this file are USB devices and other NAND flash devices.

8

Sleep Mode

The Sea Glider spends at least 75% of its time in sleep mode, as shown in the timing summary in Figure 6. However, it may need to wake up suddenly, perhaps in response to underwater current induced heading changes or communication requests from an acoustic modem. The LPC3180 is ideally suited to this task, as it comes out of sleep in less than one second, via a low power real time clock running at 32KHz. This real time clock is the only on-chip current draw while the LPC3180 is sleeping. Another possible current draw is the 48MHz USB module, but it would, most likely, be disabled in our final system configuration. Another system current draw is the SDRAM. During sleep mode, the SDRAM is placed in an I/O disabled self-refresh mode. SDRAM self-refresh mode, allows the LPC3180 to wake up with the same memory state it had right before shutdown, without having to perform a time consuming state-saving operation on a large, on-board non-volatile memory.

The issue first encountered with the sleep mode was that terminal communications would cease after placing the SDRAM in self-refresh mode. This was because terminal communications relied on reads and writes to the SDRAM. Once the communications terminal was shut off, the final sleep mode command could not be entered. The solution to this problem was to create a compiled C binary to issue all the commands in series. With the binary loaded into the LPC3180 cache, the self-refresh would have no effect on the continued execution of commands, until the final sleep mode command.

Wake-up begins with a Start Interrupt. On our test system, the start interrupt will be generated by the RTC clock. However, it may also be generated by other external interrupts such as serial pins, timers capture inputs, USB or SD card insertion among others. We could successfully wake up after an interrupt from the real time clock. After waking up, the system state was preserved in the SDRAM, and Linux was immediately available. We confirmed this operation by running binaries from the command line on the next command after startup.

Power Characterization

We tested power by replacing the main Vcc jumper with two leads, to which we could connect the current meter contacts. The preferred method to determine this current would have been to use a small .05 or .025 Ohm shunt, whereby we could measure the voltage across the shunt. However, the required shunt was in the 0805 package profile, and an example of such a small shunt was difficult to find in the final days of the project.

Power characterization on this part was complicated by the interaction between our main Vcc test point, the SBC and the other peripherals on the carrier board. However, compared to other available test points, the Vcc input was our most trustworthy option.

Other current test points were available; specifically four jumpers that were located physically close to the LPC3180. These jumpers represented Vdd and Vdd IO supplies on the chip. Since Vdd supplies are

9

the only power supply pins on the LPC3180, it seemed logical that only jumper supplied Vdd should be applied to these pins. However, figure 5 includes a block diagram showing a Vcc input into the chip. Without understanding every termination point for this Vcc input, we could not rely on the Vdd test

Figure 5, Block diagram of LPC3180 mounted on Phytec SBC, interfaced with phyCORE carrier board.

points for our current consumption numbers. However, a quick look at the sum total of the currents passing through the Vdd jumpers was approximately 20mA at 1.2V @ 13MHz. As we will see shortly, it is far lower than the power being consumed through the Vcc jumper at a similar performance setting. This finding holds hope that a properly designed board will yield a very lower power device.

Our final power characterization, detailed in Figure 6 below, relies on placing the chip into a power saving mode, and then disabling a number of carrier board elements. In regular operation after reset, at 208MHz, a 3V supply provides most of the system power and draws 130mA. This is high compared to the estimates in the LPC3180 datasheet (80mA @ 1.2V), and it is obvious that the other board electronics are sinking a significant quantity of current. By dropping the chip from 1.2V to 0.9V on the core and using the minimum frequency of 13MHz (this configuration is called Direct Mode), we bring the current consumption to 47.8mA at 3V. The Direct Mode spec into the device core is 7mA typical at 0.9V,

10

excluding currents to drive the I/O circuitry. Some obvious contributors to the 47.8mA are 4 x 6mA LEDs. After removing the LEDs, the current drops by 23mA. Further reductions are realized by turning off the USB PLL, disconnecting all serial cables and removing the SD Card from its slot. Current reduction work will continue in the upcoming weeks, as we begin to determine the power consumption of each peripheral device.

TT8 (mA @ 10V) LPC3180 (mA @ 3V)

TIME (SECONDS)

SLEEP 2.19 13.1 22771.996DISK ACCESS (WRT) 45.8 ~19.5 755.016ACTIVE 19.8 19.4 (9.6k) 1687.776    est 19.7(115k)  SAMPLE 39.8   3066.738IDLE 19.8 17.9 967.334COMPUTATION (KALMAN) 81.8   33.378

Figure 6, Summary of currents during an average dive (simulated average dive for LPC3180 data, using the code ion the appendix) Time could be considered to represent a percentage of time, where it is obvious the glider is spending most of its time in sleep. At the time of this report, sufficient data during sampling and processor intensive computations was not yet available.

Conclusion

The results are very promising, as active computation uses about 1/3 the power (same current and about 1/3 of the voltage) of the active computation on the legacy TT8. The sleep power consumption number is about twice as high on the LPC3180 compared to the TT8. We hope this can be reduced as we account for the external draws on the LPC3180 power supply. Disk access is quite a bit lower, as LPC3180 running at lowest speed, has plenty of bandwidth to handle the Linux access to an external memory card, while the TT8 is running at full speed to accomplish the same objective. We also hope that the reduce power of the idle and active modes, compared to the TT8 can be taken advantage of, allowing the sea glider to actively compute during a greater portion of its mission. The intelligence gained from active computation may lead to richer more data rich missions.

Finally, the results of the Sea Glider power measurements are relevant to the processor only. They don’t consider the effect of sensing , control and communications electronics. Continued optimization of the power requirements from these systems could have large gains in electrical performance.

11

Final Thoughts

Going forward, the main tasks for this part of the Sea Glider project will involve a better understanding of the external circuitry which is drawing power on the SBC and also on the carrier board. The next task will be development of a functional SPI bus, as many of the existing Sea Glider systems rely on this bus. Then we will begin interfacing these functions with the existing Sea Glider hardware.

12

References

Phytec phyCORE-LPC3180 Hardware Manual, April 2007, L-681e-2.pdf

Phillips LPC3180 Preliminary Datasheet, February 21, 2006, Rev 0.1, lpc3180_DS-1.pdf

Phillips UM10198 LPC3180 User Manual , June 6, 2006, Rev 01, UM10198_1.pdf

ARM926EJ-S Development Chip Reference Manual, 2006, DD10287B_arm926ejs_dev_chip_technical_reference_manual.pdf

Micron Mobile SDRAM datasheet, 2005, MT48H32M16LFm.pdf

Analog Devices Port Transceivers Datasheet, 2006, ADM3307E_3310E_3311E_3312E_3315E.pdf

13

Code Appendix

/* autoslp.c: Sleep code */#include <stdio.h>#include <stdlib.h>#include <unistd.h>#include <string.h>#include <errno.h>#include <signal.h>#include <fcntl.h>#include <ctype.h>#include <termios.h>#include <sys/types.h>#include <sys/mman.h>#include <linux/gpio.h>#include <sys/ioctl.h>

#define FATAL do { fprintf(stderr, "Error at line %d, file %s (%d) [%s]\n", \ __LINE__, __FILE__, errno, strerror(errno)); exit(1); } while(0) #define MAP_SIZE 4096UL#define MAP_MASK (MAP_SIZE - 1)

unsigned long write_mem(off_t target, unsigned long writeval);unsigned long read_mem(off_t target);int led_off(void);

int main(int argc, char **argv) {

unsigned long read_result; int always_zero;

if(argc > 1) {fprintf(stderr, "\nUsage:\t%s\n", argv[0]);

exit(1); }

// always_zero = led_off(); read_result=write_mem(0x40004044, 0x0); // Direct RUN mode in PWR CTRL

read_result=write_mem(0x40004050, 0x142); // Enable 13' Clk (from PLL397)do{

read_result=read_mem(0x40004050); // wait for 13' to stabilize}while (read_result!=0x143);read_result=write_mem(0x40004020, 0x1000000); // enable rtc interrupt to main processorread_result=write_mem(0x4000402C, 0x1000000); // rising edge of start signal read_result=write_mem(0x40004024, 0x1000000); // clear the interrupt

// read_result=write_mem(0x40004030, 0x1000000); // pin int start up is probably unnecessaryread_result=write_mem(0x40024010, 0x10); // reset rtcread_result=write_mem(0x40024010, 0x00); // reset rtcread_result=write_mem(0x40024008, 0xA); // set rtc timer to 10 secondsread_result=write_mem(0x40024010, 0x1); // enable rtc interrupt from rtc module read_result=write_mem(0x40004044, 0x280); // auto exit SDRAM self refresh enable and self

refresh requestread_result=write_mem(0x40004044, 0x380); // self refresh requestread_result=write_mem(0x40004044, 0x80); // self refresh requestread_result=write_mem(0x40004044, 0x81); // enter STOP mode // sleepread_result=write_mem(0x40004044, 0x0); // exit STOP mode and make sure Direct RUN is

startedread_result=write_mem(0x40024008, 0x0); // return match register to 0 secondsread_result=write_mem(0x40024014, 0x1); // clear match interrupt status read_result=write_mem(0x40024010, 0x0); // clear match interrupt status read_result=write_mem(0x40004020, 0x0000000); // disable rtc interrupt to main processorread_result=write_mem(0x40004024, 0x0000000); // clear the interrupt

14

read_result=write_mem(0x40004044, 0x62); // exit STOP mode and make sure Direct RUN is started

return(0);}

unsigned long write_mem(off_t target, unsigned long writeval) {

unsigned long read_result; int fd; void *map_base, *virt_addr;

if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) FATAL; fflush(stdout);

/* Map one page */map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, target & ~MAP_MASK);if(map_base == (void *) -1) FATAL;

fflush(stdout);

virt_addr = map_base + (target & MAP_MASK); read_result = *((unsigned long *) virt_addr);

printf("Value at address 0x%X (%p): 0x%X\n", target, virt_addr, read_result); fflush(stdout);

*((unsigned long *) virt_addr) = writeval; read_result = *((unsigned long *) virt_addr);

printf("Written 0x%X; readback 0x%X\n", writeval, read_result); fflush(stdout);

if(munmap(map_base, MAP_SIZE) == -1) FATAL;close(fd);return read_result;

}

unsigned long read_mem(off_t target) {

unsigned long read_result; int fd; void *map_base, *virt_addr;

if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) FATAL; fflush(stdout);

/* Map one page */map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, target & ~MAP_MASK);if(map_base == (void *) -1) FATAL;

fflush(stdout);

virt_addr = map_base + (target & MAP_MASK); read_result = *((unsigned long *) virt_addr);

printf("Value at address 0x%X (%p): 0x%X\n", target, virt_addr, read_result); fflush(stdout);

if(munmap(map_base, MAP_SIZE) == -1) FATAL;close(fd);return read_result;

}

int led_off(void){ /*

int f_gpio; int j; struct gpio_control leds[4];

*/

15

unsigned long dummy;

printf("Turning LEDs off\n");dummy=write_mem(0x40028008, 0x8C); // clear GPO LED bits

/* leds[0].Pin = GPO_02; // LED1 leds[1].Pin = GPO_03; // LED2 leds[2].Pin = GPO_07; // LED3 leds[3].Pin = GPO_06; // LED4

f_gpio = open("/dev/gpio",1);

for (j = 0; j < 4; j++) { leds[j].Arg = 0; ioctl(f_gpio,GPIO_IOCSPIN,&leds[j]); sleep(2); } close(f_gpio);

printf("LEDs off\n");*/

return 0;}

/* serial communications code */

#include <stdio.h>#include <termio.h>#include <string.h>#include <stdarg.h>#include <stdlib.h>#include <unistd.h>#include <fcntl.h>#include <math.h>#include <sys/time.h>#include <ctype.h>#include <errno.h>

int ConnectSerial(char *portname, int baud, char parity, char databits, char stopbits, char flowcontrol){ int fd; struct termios options; int baudflag;

fd = open(portname, O_RDWR | O_NDELAY | O_NOCTTY); if (fd == -1) { return -1; }

tcgetattr(fd, &options);

switch(baud) { case 110: baudflag = B110; break; case 300: baudflag = B300; break; case 600: baudflag = B600; break; case 1200: baudflag = B1200; break; case 2400: baudflag = B2400; break; case 4800: baudflag = B4800; break; case 9600: baudflag = B9600; break; case 19200: baudflag = B19200; break; case 38400: baudflag = B38400; break;

16

case 57600: baudflag = B57600; break; case 115200: baudflag = B115200; break; case 230400: baudflag = B230400; break; case 460800: baudflag = B460800; break; case 921600: baudflag = B921600; break; default:

baudflag = B9600;printf("Baud rate entered is not available\n");printf("Default will now be 9600bps\n");break;

}

cfsetispeed(&options, baudflag); cfsetospeed(&options, baudflag); options.c_cflag |= (CLOCAL | CREAD); options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); options.c_oflag &= ~OPOST; options.c_iflag &= ~(INLCR | IGNCR | ICRNL);

switch(parity) { case 'e': case 'E': options.c_cflag |= PARENB; options.c_cflag &= ~PARODD; options.c_iflag |= (INPCK | ISTRIP); break; case 'o': case 'O': options.c_cflag |= PARENB; options.c_cflag |= PARODD; options.c_iflag |= (INPCK | ISTRIP); break; default: options.c_cflag &= ~PARENB; options.c_cflag &= ~PARODD; options.c_iflag &= ~(INPCK | ISTRIP); break; }

switch(stopbits) { case 2: options.c_cflag |= CSTOPB; break; default: options.c_cflag &= ~CSTOPB; break; }

switch(databits) { case 7: options.c_cflag &= ~CSIZE; options.c_cflag |= CS7; break; default: options.c_cflag &= ~CSIZE; options.c_cflag |= CS8; break; }

switch(flowcontrol) { case 1: options.c_iflag |= (IXON | IXOFF | IXANY); options.c_cflag &= ~CRTSCTS; break; case 2: options.c_iflag &= ~(IXON | IXOFF | IXANY); options.c_cflag |= CRTSCTS; break;

17

default: options.c_iflag &= ~(IXON | IXOFF | IXANY); options.c_cflag &= ~CRTSCTS; }

tcsetattr(fd, TCSANOW, &options);

return fd;}

int main(int argc, char *argv[]){ int port_fd; int bit, n; int cmd; char buff [80]; int len, ret; int baud; printf("Pick a baud rate between 110 and 115200\n"); scanf("%d", &baud); if ((port_fd = ConnectSerial(argv[1], baud, 'N', 8, 1, 0)) == -1) { perror("Could not open serial port"); fprintf(stderr, "(%d)\n", errno); return 1; }

for(n = 0; n < 63; n++) { sprintf(buff, "This serial port is working just fine, for the %dth time.\n", n+1); len = strlen(buff);

ret = write(port_fd, buff, len);if(len != ret) {

fprintf(stderr, "Cycle %d Tried to write %d, wrote %d\n", n, len, ret); } }

/* bit = TIOCM_DTR; */

/* ioctl(port_fd, TIOCMBIC, &bit); *//* printf("DTR is off\n"); */

/* while (1) { *//* cmd = getchar(); *//* if (cmd == 13 || cmd == 10) *//* continue; */

/* if (cmd != '1' && cmd != '0') *//* break; */

/* if (cmd == '1') *//* ioctl(port_fd, TIOCMBIS, &bit); *//* else if (cmd == '0') *//* ioctl(port_fd, TIOCMBIC, &bit); */ /* n = sprintf(buff, "turning %s\r\n", cmd == '1' ? "on" : "off"); *//* Write(port_fd, buff, n); *//* } */

close(port_fd);

return 0;}

# Python serial receive code

import serial, sys

18

# removed import serial and import sys

#out = serial.Serial(baudrate=115200, timeout=5, port='/dev/ttyUSB0')#inp = serial.Serial(baudrate=115200, timeout=5, port='/dev/ttyUSB1')#test_string = "01234567890123456789012345678901234567890123456789"ser = serial.Serial(baudrate=115200, timeout=5, port='/dev/ttyS1')

sys.stdout.write("Starting\n")

while(1):sys.stdout.write(ser.read(1))

ser.close()

#ser = serial.Serial(baudrate=9600, port='/dev/ttyS1')#print ser.portstr#ser.write("got it")#ser.close()

19