iCricket

 

Introduction

 

The  i  in the name above stands for “Internet controlled” or more specifically “IP controlled”. This project deals with making the HandyCricket web-enabled. This would be very useful to remotely or IP-ly control any robotic application created using the HandyCricket. There would be some amount of driver logo code to be imported into the user code to be able to correctly understand the incoming requests and generate appropriate responses. This web enabling is achieved throught use of the HandyCricket’s bus interface that will communicate with a low-power web interface. This web interface comprises of an ultra low-power microcontroller, the TI-MSP430, and an Ethernet controller, the CS8900A.

 

 

 

Details

 

The following diagram displays the various components of the proposed system along with their interfaces to each other

 

The application consists of a Web Server (available as an open source application) running on the MSP430. This Web Server will be used to communicate with the Cricket. An Ethernet LAN controller offers the physical connection to the Internet. A downsized TCP/IP protocol stack is used. Its functionality is encapsulated by an easy-to-use application programming interface (API).

 

The low-power microcontroller MSP430F149 features are follows:

·        Basic Clock System (on-chip DCO + one or two crystal oscillators)

·        Watchdog Timer/General Purpose Timer

·        Timer_A3 (16-bit timer with 3 capture/compare registers and PWM output)

·        Timer_B7 (16-bit timer with 7 capture/compare registers and PWM output)

·        I/O Port1, 2 (8 I/O’s each, all with interrupt)

·        I/O Port3, 4, 5, 6 (8 I/O’s each)

·        Comparator_A (precision analog comparator, ideal for slope A/D conversion)

·        ADC12 (12-bit A/D)

·        USART0

·        USART1

·        Hardware Multiplier

·        60KB +256B Flash, 2KB RAM

 

The functional block diagram for the MSP430 family of microcontrollers is as follows:

 

 

 

 

Our Work

 

·       The Approach

We first tried to understand the CricketBus signaling protocol. This allowed us to design the appropriate driver routines to understand and generate these signals, on the MSP430-side. We already had an open-source non-concurrent (one tcp/ip connection at a time) web-server code for immediate testing on this system (MSP430 + CS8900A). Because of its non-concurrency, the web-server POLLS a particular set of I/O pins connected to the ethernet controller (CS8900A) for any ethernet activity. For the CricketBus signal reception, we could simply add extra code to this web-server's POLLING LOOP to also POLL the appropriate MSP430 port-pin connected to CricketBus wire, and capture any incoming signal information. This obviously would keep the CPU busy doing practically nothing but consuming power. Our approach has been to keep the complete system low-power by utilizing the interrupt-driven-fast-recovery-to-full-power-mode feature of the MSP430, to handle both the incoming CricketBus serial signal, and any network event (eg. valid packet reception) generated by CS8900A.

 

The interrupt vector table for the MSP430 is as follows:

 

o       CricketBus driver

The MSP430 has 6 I/O ports for building various embedded control applications. Connecting the CricketBus serial wire to one of the MSP430 I/O port pins was a no-brainer, but which pin should we use? The CricketBus serial protocol is proprietary and requires bit-banging at the receiving end in the driver code to understand them. Since our approach on the MSP430 side was interrupt-driven processing, we were looking to see if any hardware pins were associated with any of the MSP430 interrupt vectors. We found out that Ports 1 and 2, both had separate interrupt vectors associated with them. We have chosen to go with Port 1 to interface with the CricketBus wire. The signal reception part of the driver would thus be interrupt-driven, allowing the MSP430 to go into low-power when no signaling information is available. The generation of the CricketBus signal, will be done when needed by the output portion of the driver. The requirement here would be, generating a correct 100 usec active low, before a 10 usec start bit followed by 8 data bits in pulses of 10 usec each plus the final 10 usec command pulse.

 

o       Ethernet driver

The existing web server constantly POLLS a set I/O lines connected to the CS8900A for data. We plan on using the interrupt feature available in CS8900A, to interrupt the MSP430 to read packet data. This interrupt feature on the CS8900A is fully controlled through software.

 

 

 

·       Current Status

As of now, we have successfully ported the web server on the MSP430 microcontroller. Using the CS8900A Ethernet controller users can access the iCricket web page over the internet. We are working on the USART peripheral interface on MSP430. This will give the user a serial-line-RS-232 Command line interface (CLI prompt).

 

 

·       Future Work

We have now assigned ourselves the following goals for the rest of the semester:

 

1.     Interface the Handy Cricket device with the MSP430 microcontroller.

2.     To augment the web server with the handy cricket bus driver API. A set of controls will be provided to maneuver the different controls of the cricket over the internet.

3.     We would also like to make the web server concurrent. This would allow different users to control different parts of the Handy Cricket controls (motors & sensors).

4.     We have decided to come up with a technical paper summarizing our project.

5.     If time permits, we would also like to implement a DHCP stack for the web server. This would free us from the need of assigning a static IP to our device.