Difference between revisions of "F16: SJone to FPGA wireless integration"
146 user10 (talk | contribs) (→Objectives & Introduction) |
146 user10 (talk | contribs) (→Objectives & Introduction) |
||
| Line 17: | Line 17: | ||
== Objectives & Introduction == | == Objectives & Introduction == | ||
| − | |||
| − | 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 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. | 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. | ||
| − | |||
| − | 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. | + | |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: | Objectives: | ||
Revision as of 11:17, 21 December 2016
Contents
Grading Criteria
- How well is Software & Hardware Design described?
- How well can this report be used to reproduce this project?
- Code Quality
- Overall Report Quality:
- Software Block Diagrams
- Hardware Block Diagrams
- Schematic Quality
- Quality of technical challenges and solutions adopted.
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
Show a simple table or figures that show your scheduled as planned before you started working on the project. Then in another table column, write down the actual schedule so that readers can see the planned vs. actual goals. The point of the schedule is for readers to assess how to pace themselves if they are doing a similar project.
| Week# | Date | Task | Actual |
|---|---|---|---|
| 1 | 10/8 | Task list | Completed? Problems Encountered? |
Parts List & Cost
Give a simple list of the cost of your project broken down by components. Do not write long stories here.
Design & Implementation
The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.
Hardware Design
Discuss your hardware design here. Show detailed schematics, and the interface here.
Hardware Interface
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.
Software Design
Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
Implementation
This section includes implementation, but again, not the details, just the high level. For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash. You can include sub-sections for each of your component implementation.
Testing & Technical Challenges
Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.
Include sub-sections that list out a problem and solution, such as:
My Issue #1
Discuss the issue and resolution.
Conclusion
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
Project Video
Upload a video of your project and post the link here.
Project Source Code
References
Acknowledgement
Any acknowledgement that you may wish to provide can be included here.
References Used
List any references used in project.
Appendix
You can list the references you used.
