Difference between revisions of "F16: SJone to FPGA wireless integration"

Latest revision as of 15:14, 21 December 2016

Grading Criteria

Project Title: Wifi Modular

Abstract

The contents of this report discuss the concepts, design methods, hardware, software, verification methods, and results from an embedded systems design project focused on the 802.11g band wireless communication between a micro-controller and FPGA. SPI and UART protocols were exercised as a means to exchange data between chip and wireless transceiver modules whilst a common networking protocol was used to exchange data between reference’s. All state machine, logic, and hardware diagrams are included to support the design and analysis of the project. Further test cases are presented to aide the results and remaining tasks of implementation.

Objectives & Introduction

The initial idea was to somehow bring two powerful aspects of computer engineering, digital design using FPGA and FreeRTOS API software implementation on a microcontroller to create one useful embedded system. Motivation to design such a system comes from the need to use sensors and communications to measure, analyze, and control the physical elements of our world. Combined with this, is our ever changing evolution of CPU architecture and optimization. Furthermore, the benefit of having control over your sensory functionality from a remote location and being able to reconfigure your host CPU is in essence a flexible capability.

The purpose of WiFi Modular is to provide a means of wireless communication between a microcontroller and FPGA unit. To do this, a Nexys4 DDR development board with an Artix-7 was chosen for the FPGA platform. It also contains the dipswitches, pushbuttons, 7-segments and I/O port needed for the objectives. An add-on to the board is the Microchip MRF24WG0MA pmod wireless card. On the other hand, the SJone development board with an LPC1758 microcontroller was supplemented with an XBee S6B wireless card. With these two boards, a wireless communication can be established and data can be exchanged for use in various applications.

The goal for this project is to successfully exchange bytes between the Nexys 4 and SJone board and display the characters on the 7-segment display and output console, respectively. The bytes should be entered via an 8-dipswitch configuration for the Nexys4, and a Hercules console user input for the SJone. Each signal should be exchanged upon the Start button being depressed to initiate the idling state of the FPGA to look for incoming bytes. Bytes are exchanged between the SPI module, designed in Verilog HDL, and the Microchip wifi unit. Each state was designed to respect the timing diagram of the SPI bus provided by the wifi unit datasheet. Startup, control signal setup times, and read/write cycles were accounted for through the ASM design. Further details can be derived from the source code supplied in later sections.

Moreso, the SJone board was supplied with an XBee SB6 unit that essentially plugs directly into the conveniently placed headers of the host board. It lands directly into the DIN and DOUT lines which are inherently either UART2 or UART3 RX/TX depending on the position of the bus select switch. For this project, the UART2 channel was chosen. To utilize the bus, a UART2 object was instantiated in software. The UART_DEV class is built on the C language, and implemented the main.cpp of a FreeRTOS API powered project. To to do this, a scheduler task was created using the ASM chart found in the later section. The basic functionality is to prioritize the task, run the routine, and break out of it entering a delay of 3 seconds to allow any other tasks to run thereafter. The program then continues to loop looking for bytes to send and receive.

System testing will require a series of different checks. For the FPGA, a simulator test bench is required to verifiy that the SPI_Module is generating the expected outputs to all inputs. Then once the module is verfied, it must be synthesized, generated, and loaded into the FPGA. From there, dipswitch positions should be set to the desired byte to be exchanged. The SPI_Module is loaded with the value during the exchange byte operation, and sent over the MOSI line to the wifi. On the other side, the SJone has already taken an input from the user to the txC variable. This byte is sent over UART to the XBee for transmission. Afterwards, the receive function looks for the incoming byte from the FPGA. FreeRTOS allows the task to run for 3 seconds while it waits, and then exits if timeout occurs. When the program does receive a byte, it prints it to the console. This test completes when the FPGA has receive the SJone byte, vice versa, and each byte value is displayed on the others 7-segment display and output console.

Objectives

• Learn and incorporate the various RTOS resources for overall system design
• Map out the software state machine diagram
• Design WiFi Modular physical layer
• Compile a Bill of Materials (BOM)
• Manufacture the prototype and test for reliability
• Record and document results for analysis and reports
• Develop product proposal presentation (Powerpoint, Video, Website/Report)

Team Members & Responsibilities

Brian Josefowicz

B.S. Computer Engineering

San Jose State University 2016

• Overall concept and methodology
  
• Hardware and Software Design
  
• FGPA Implementation and testing
  
• Micro-controller programming
  
• Report and Analysis
  

Schedule

Parts List & Cost

Design & Implementation

For the FPGA, a datapath and control unit are required the SPI_Master module to operate properly. The overall system can be seen in the following diagrams. The control signals generated by the state machine manage how each byte is written into memory off of the SPI bus one bit at a time. This is required due to the simplicity of the SPI bus only having two lines in which to exchange data. This data is then extrapolated out into two BCD values, and passed into a 7-segment LED MUX that then generates control signals for the proper decimal output.

For the LPC, the UART2 object initialized the baud rate 9600 bps and the UART2 RX/TX for operation out of pins 50 and 49. On top of the headers, the XBee is placed. Keep in mind, the XBee configuration settings were set by default. Any configuration updates it needs can be update through the proper command signal followed by the data byte value needed.

Hardware Design

Communication between the FPGA and Microchip Wifi is carried out over an SPI protocol. It makes sense as it contains its own flash memory on board, and when bytes are communicated through it, it stores them and reads them as needed. As mentioned previously, the SJone communicates with the XBee via UART at a 9600 bps rate. The two wifi daughter boards communicate with each other over the IEEE 802.11/g frequency band. With rates up to 54Mb/s, there is no issue sending one byte at a time across the network.

Software Design

Figure 1: SPI_Master Control Unit ASM Chart

Figure 2: UART task Logic Flow diagram

When designing in Verilog, the developer must understand system timing and output control. There is a difference between synthesizing and compiling. As you can see, the state machine for the control is largely different due to the nature of Verilog versus C programming. Also, these are two different hardware communication protocols. SPI in Verilog, and UART in C using FreeRTOS. The FreeRTOS scheduler allows the system to run off of the tick task. Other interrupts that are high priority may also utilize CPU during the tick taskDelay. This is where the UART task is able to run its functions, and then turn the CPU back over to the rest of the system.

Testing & Technical Challenges

The primary challenges to the project were: creating an application that is feasible given the time constraints, withdrawing information from the base class files and implementing it in an inherited class, and getting the FPGA to properly function the correct way for sampling byte information from the SPI bus.

UART communication was transmitting to the XBee module, and output console was skipping application

Followed the UART_Dev .h and .cpp file for useful helper functions. Designed a UART function using the helpers putChar() and getChar(). Then set the priority to high from medium, but included a taskDelay to allow the user time to input their byte as well as see what is happening on the console.

The most significant issue was getting the SPI_Master module to work with the Microchip unit

Figure 1: SPI datasheet ideal wave forms indicating timing sequence

Figure 2: Simulation wave forms indicating a that all tests passed but Rx_In missing data

At first, the module was laid out as a hybrid control unit and data path, but unfortunately this architecture does not function properly as seen in the timing diagrams. There needs to be a data path with D-type registers to store and send bits one after the other, and then output as a single byte once the exchange state is complete. This timing would allow the bits to be transferred no the bus lines from MSB to LSB.

Conclusion

To recap, the purpose of the design was to integrate an FPGA development board with a micro-controller board to establish a simple communication between platforms on a common wireless network. Overall, the results did not prove the intended design implementation to be achievable, although further testing and development would return successful results. Making some state timing changes on the SPI_Master control unit and then further implementing a datapath would solve the issue of a broken communication bus.

Some further ideas to expand on this platform would be integrating the micro-controller into a Real Time Traffic Control System (RTTCS). With the given need for traffic optimization, environmental sensory information, data collection and analysis, and the emergence of self driving cars, we must find a way to control the lights more efficiently. To have the wireless capability of gathering real time information, and optimizing the controller unit with no lapse in coverage is a powerful tool for the near future.

Project Video

No video media at this time.

Project Source Code

• Sourceforge Source Code Link

References

Acknowledgement

I would like to thank Dr. Haluk Ozemek for taking the time to educate and regulate, and also our mentor/lab instructor Preetpal Kang for delivering one heck of a series on embedded systems. Although the time has been limited, we have been introduced to so many new topics and barely even begun to scratch the surface.

References Used

• Microchip MRF24WG0MA Datasheet
• Nexys4 DDR FPGA Development Board Reference Manual
• Digi XBee Wi-Fi RF Module - User Guide

Appendix

File:MRF24WG0MA.pdf

File:Nexys4ddr rm.pdf

File:S6BUserManual.pdf