Embedded Systems Learning Academy - User contributions [en]

F16: SJone to FPGA wireless integration

2016-12-21T15:14:06Z

146 user10: /* The most significant issue was getting the SPI_Master module to work with the Microchip unit */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===

[[File:SPIwaveforms.jpeg|500px|Figure 1: SPI datasheet ideal wave forms indicating timing sequence]]

[[File:waveforms.jpeg|500px|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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ 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]]

F16: SJone to FPGA wireless integration

2016-12-21T15:10:32Z

146 user10: /* The most significant issue was getting the SPI_Master module to work with the Microchip unit */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===

[[File:SPIwaveforms.jpeg|250px|Figure 1: SPI datasheet ideal wave forms indicating timing sequence]]

[[File:waveforms.jpeg|200px|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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ 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]]

F16: SJone to FPGA wireless integration

2016-12-21T15:09:15Z

146 user10: /* The most significant issue was getting the SPI_Master module to work with the Microchip unit */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===

[[File:SPIwaveforms.jpeg|250px|thumb|left|Figure 1: SPI datasheet ideal wave forms indicating timing sequence]]

[[File:waveforms.jpeg|200px|thumb|right|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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ 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]]

F16: SJone to FPGA wireless integration

2016-12-21T13:52:31Z

146 user10: /* Project Video */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===
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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ 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]]

F16: SJone to FPGA wireless integration

2016-12-21T13:50:33Z

146 user10: /* Appendix */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ 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]]

F16: SJone to FPGA wireless integration

2016-12-21T13:50:22Z

146 user10: /* Appendix */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ 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]]

F16: SJone to FPGA wireless integration

2016-12-21T13:50:05Z

146 user10: /* References */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ 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]]

F16: SJone to FPGA wireless integration

2016-12-21T13:40:08Z

146 user10: /* Software Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:39:55Z

146 user10: /* Software Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:39:25Z

146 user10: /* Design & Implementation */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146Hardware-Page1.jpeg|300px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|300px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:30:12Z

146 user10: /* Hardware Interface */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146Hardware-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|200px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

=== Hardware Interface ===
: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== Implementation ===

== 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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:29:50Z

146 user10: /* Hardware Interface */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146Hardware-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|200px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

=== Hardware Interface ===
: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== Implementation ===

== 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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:29:32Z

146 user10: /* Hardware Interface */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146Hardware-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|200px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

=== Hardware Interface ===
: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== Implementation ===

== 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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:27:24Z

146 user10: /* Hardware Interface */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146Hardware-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|200px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

=== Hardware Interface ===
: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== Implementation ===

== 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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:26:50Z

146 user10: /* Hardware Interface */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146Hardware-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|200px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

=== Hardware Interface ===
: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.
<br\ ><br\ ><br\ ><br\ ><br\ ><br\ ><br\ ><br\ ><br\ ><br\ >

=== Software Design ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== Implementation ===

== 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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:21:23Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146Hardware-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master to Microchip Wifi module diagram]][[File:146Hardware-Page2.jpeg|200px|thumb|right|Figure 2: LPC1758 to XBee UART diagram]]

=== Hardware Interface ===
: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== Implementation ===

== 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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:13:01Z

146 user10: /* Implementation */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

=== Hardware Interface ===
: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== Implementation ===

== 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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T13:10:15Z

146 user10: /* Software Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

=== Hardware Interface ===
: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 ===

[[File:146ASM-Page1.jpeg|250px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]][[File:146ASM-Page2.jpeg|200px|thumb|right|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.

=== 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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:52:32Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:50:58Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146ASM-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]]
[[File:146ASM-Page2.jpeg|200px|thumb|right|Figure 2: UART task Logic Flow diagram]]
 

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:50:26Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146ASM-Page1.jpeg|200px|thumb|left|Figure 1: SPI_Master Control Unit ASM Chart]]
[[File:146ASM-Page2.jpeg|200px|thumb|right|alt text]]
 

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:49:35Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146ASM-Page1.jpeg|200px|thumb|left|alt text]]
[[File:146ASM-Page2.jpeg|200px|thumb|right|alt text]]
 

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

File:146ASM-Page1.jpeg

2016-12-21T12:46:47Z

146 user10: 146 user10 uploaded a new version of File:146ASM-Page1.jpeg

Figure 1: SPI_Master Control Unit ASM Chart

File:146ASM-Page1.jpeg

2016-12-21T12:45:49Z

146 user10: Figure 1: SPI_Master Control Unit ASM Chart

Figure 1: SPI_Master Control Unit ASM Chart

F16: SJone to FPGA wireless integration

2016-12-21T12:44:50Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146ASM-Page1.jpeg|200px|thumb|left|alt text]]
[[File:146ASM-Page2.jpeg|200px|thumb|right|alt text]]

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:41:05Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146ASM-Page1.png|200px|thumb|left|alt text]]
[[File:146ASM-Page2.png|200px|thumb|right|alt text]]

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:37:59Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===

[[File:146ASM-Page1.png|200px|thumb|left|alt text]]
[[File:146ASM-Page2.png|200px|thumb|left|alt text]]

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

File:146ASM-Page2.jpeg

2016-12-21T12:34:03Z

146 user10: Figure 2: UART task Logic Flow diagram

Figure 2: UART task Logic Flow diagram

F16: SJone to FPGA wireless integration

2016-12-21T12:32:31Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146ASM-Page1.jpeg]]
[[File:146ASM-Page2.jpeg]]

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

File:146ASM-Page1.jpg

2016-12-21T12:30:22Z

146 user10: Figure 1: ASM for FPGA Control Unit

Figure 1: ASM for FPGA Control Unit

F16: SJone to FPGA wireless integration

2016-12-21T12:28:43Z

146 user10: /* Hardware Design */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
[[File:146ASM-Page1.jpg]]

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:07:06Z

146 user10: /* Conclusion */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
Discuss your hardware design here. Show detailed schematics, and the interface here.

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ===
Upload a video of your project and post the link here.

=== Project Source Code ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:06:24Z

146 user10: /* Testing & Technical Challenges */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
Discuss your hardware design here. Show detailed schematics, and the interface here.

=== Hardware Interface ===
: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 ===
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 ==
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 ===
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 ==
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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:03:13Z

146 user10: /* Design & Implementation */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
Discuss your hardware design here. Show detailed schematics, and the interface here.

=== Hardware Interface ===
: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 ===
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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T12:00:09Z

146 user10: /* Parts List & Cost */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
|
|
| 290.99
|
|-
|}

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T11:59:36Z

146 user10: /* Parts List & Cost */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
! scope="row"| Total
| Nexys 4 DDR Artix-7 FPGA
| 1
| 290.99
| unk
|-
|}

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T11:56:57Z

146 user10: /* Parts List & Cost */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== Parts List & Cost ==

{| class="wikitable"
|-
! scope="col"| Item#
! scope="col"| Nomenclature
! scope="col"| Qty
! scope="col"| Cost($)
! scope="col"| Details (mfr, pn, etc.)
|-
! scope="row"| 1
| WiFi / 802.11 Modules
| 1
| 29.00
| XB2B-WFPT-001
|-
! scope="row"| 2
| SJOne Development Board
| 1
| 80.00
| unk
|-
! scope="row"| 3
| Pmod WiFi: WiFi Interface 802.11g
| 1
| 22.99
| Microchip MRF24WG0MA
|-
! scope="row"| 4
| Nexys 4 DDR Artix-7 FPGA
| 1
| 159.00
| unk
|-
|}

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T11:48:32Z

146 user10: /* Schedule */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T11:47:50Z

146 user10: /* Schedule */

=== 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 ==
{| class="wikitable"
|-
! scope="col"| Week#
! scope="col"| Date
! scope="col"| Task
! scope="col"| Actual
! scope="col"| Comments
|-
! scope="row"| 1
| 11/2
| Perform research on FreeRTOS resources. Layout the required applications. Apply the FreeRTOS concepts to these applications. Begin hardware/circuit design. Specify parts required.
| Completed 11/18
| This process was up and down as other tasks occupied time. Also, project ideas swirled.
|-
! scope="row"| 2
| 11/11
| Design the System State Machine including, states, conditions, transitions, and control signals. Order parts and materials. Layout software logic diagram, and pseudocode.
| Completed 12/8
| Once the new concept was established, this step was first to be completed.
|-
! scope="row"| 3
| 11/18
| Begin software development.
| Late 12/8 
| Milestone flag for progress check.
|-
! scope="row"| 4
| 11/25
| Begin manufacturing. Continue with software development.
| Late 12/14
| Milestone flag for progress check.
|-
! scope="row"| 5
| 12/02
| Complete manufacturing. Begin software testing. Begin Presentation development.
| Late 12/14
| Manufacturing became a simple task of plug and play WiFi units.
|-
! scope="row"| 6
| 12/09
| Complete software testing and development. Complete presentation production
| Incomplete 12/20
| Only incomplete task as FPGA development became more demanding than expected.
|-
! scope="row"| 7
| 12/16
| Rehearse final demonstration. Revise and edit any presentation material needed.
| Completed 12/20
| ...
|-
! scope="row"| Last Day
| 12/20
| Demonstrate full system functionality. Present project.
| Completed 12/21
| ...
|-
|}

== 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 ===
* [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]

== 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.

F16: SJone to FPGA wireless integration

2016-12-21T11:33:53Z

146 user10: /* Schedule */

F16: SJone to FPGA wireless integration

2016-12-21T11:30:26Z

146 user10: /* Abstract */

F16: SJone to FPGA wireless integration

2016-12-21T11:30:04Z

146 user10: /* Objectives & Introduction */

F16: SJone to FPGA wireless integration

2016-12-21T11:17:13Z

146 user10: /* Objectives & Introduction */

F16: SJone to FPGA wireless integration

2016-12-21T11:12:46Z

146 user10: /* Objectives & Introduction */

F16: SJone to FPGA wireless integration

2016-12-21T11:11:46Z

146 user10: /* Objectives & Introduction */

F16: SJone to FPGA wireless integration

2016-12-21T10:57:38Z

146 user10: /* Abstract */

F16: SJone to FPGA wireless integration

2016-12-21T10:56:54Z

146 user10: /* Project Title */

F16: SJone to FPGA wireless integration

2016-12-21T10:55:47Z

146 user10: Created page with "=== Grading Criteria === * How well is Software & Hardware Design described? * How well can this report be used to reproduce this project? * Code Quali..."

Realtime OS on Embedded Systems

2016-12-21T10:50:37Z

146 user10: /* Fall 2016 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===
=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* Add Your Group on Here, then follow the link to add more to your template *
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: SJone to FPGA wireless integration]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]

Realtime OS on Embedded Systems

2016-12-21T10:49:41Z

146 user10: /* Fall 2016 */

== Program History ==
My contribution in Embedded System courses started with CmpE146. This course teaches students on how to write UART, SPI, and I2C Drivers and interface their drivers to peripherals. There are about 8 weekly labs in which students not only write drivers, but also learn the core of Real-time Operating Systems including threading (tasks), and inter-task communication using Queues and Semaphores. FreeRTOS is the operating system used with C/C++ Compiler based on GNU.

When the course was started by Dr. Ozemek @ SJSU (sometime before 2005), not many resources were out there. Still, with helpful guidance from Dr. Ozemek, interesting projects were created. This is when I started to help out in Embedded System Courses, and by collecting and sharing knowledge, we've raised the bar at SJSU!

There have been many great projects at SJSU, but since no one knew about them, the hard work went to a waste for anyone but the creator. But now we've got the infrastructure to share the projects, which turn out as great references for future students. Here is my project that started around 2007, and turned into Bachelor's Senior Design Project: 
[http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp YouTube Video of Self-Navigating Car]

As of 2013, I have broadened my contribution to other embedded system courses like CmpE240, CmpE243 and CmpE244.

== Lab Assignments ==
This article contains laboratory assignments and resources. The assignments are under construction as we move towards SJ-One development board.
* [[Embedded System Tutorial GPIO | Lesson 1 : GPIO]]
* [[Embedded System Tutorial UART | Lesson 2 : UART]]
* [[Embedded System Tutorial SPI | Lesson 3 : SPI]]
* [[Embedded System I2C Tutorial | Lesson 4 : I2C]]
* [[Embedded System Tutorial Interrupts | Lesson 5 : Interrupts]]
* [[Embedded System Tutorial FreeRTOS | Lesson 6 : FreeRTOS Tasks]]
* [[Embedded System Tutorial File I/O | Lesson 7 : FreeRTOS Application Programming]]

==Other reference articles==
* [[Bitmasking Tutorial]] (+ GPIO Example)
* [[ LPC17xx Memory Map & Interrupts]]

 
== Senior Design Projects ==

 
== Semester Projects ==
Every semester, students are given about 7-10 weeks to complete their projects. During this short time-span, students form groups, order parts, and begin working on their projects. The work performed during the semester is documented at this Wiki.

Here is the list of Preet's documented projects: 
* [[Preet's Relay Controller Project]]
* [[Nordic Low Powered Mesh Network stack]]
* [http://www.youtube.com/watch?v=QEadXdRl3ws&feature=plcp Senior Design Project (MS-CmpE) Video]

Here is another resource for good project references :
[http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/ Cornell EE476 Projects]

 
<HR>
=== Appendix ===
=== [[Fall 2016 | Fall 2016]] ===

CMPE146:
* Add Your Group on Here, then follow the link to add more to your template *
* [http://www.socialledge.com/sjsu/index.php?title=F16:_Seismograph F16: Seismograph]
* [[F16: Piano Glove]]
* [[F16: Object Detector]]
* [[F16: Autonomous Nautical System]]
* [[F16: Autonomous Fire Extinguishing Vehicle]]
* [[F16: Autonomous Runaway Alarm Car]]
* [[F16: E-Bike]]
* [[F16: NotifyBox]]
* [[F16: Wireless Tilt Controlled Camera Arm]]
* [[F16: OBD2 Reader]]
* [[F16: Micro Watch Monitoring System]]
* [[F16: Door Alarm System]]
* [[http://www.socialledge.com/sjsu/index.php?title=F16:_I2Coffee F16: UART Coffee]]
* [[F16: ''WiFi'' Modular]]

=== [[Spring 2016 | Spring 2016]] ===
* [[S16: Fantastic Four]]
* [[S16: Simpsons]]
* [[S16: Mars 1]]
* [[S16: OpenSJ Bluz]]
* [[S16: Motion Copy Bot]]
* [[S16: Biker Assist]]
* [[S16: Helios]]
* [[S16: Sound Buddy]]
* [[S16: Warriors]]
* [[S16: Expendables]]
* [[S16: Ahava]]
* [[S16: Number 1]]
* [[S16: SkyNet]]
* [[S16: SmartDoorLock]]

Cmpe 146:
* [[S16: Camera Gimbal]]
* [[S16: Laser Harp]]
* <strike>[[S16: Laser Cutter Motor Controller]]</strike>
* [[S16: Sprinkler]]
* [[S16: The Jatrick Car]]
* [[S16: Dan]]
* [[S16: Robolamp]]
* [[S16: Pinball]]
 
<HR>

=== [[Fall 2015 | Fall 2015]] ===

CmpE146:
* [[F15: Autonomous Mobile]]
* [[F15: Car Report]]
* [[F15: Electronic Piano]]
* [[F15: Doorknock over Bluetooth]]
* [[F15: Smart Car]]
* [[F15: Plant Control]]
* [[F15: Laser Security System]]

 
<HR>

=== [[CmpE244 Spring 2015 | Spring 2015]] ===

 
* [[S15: Quadcopter - It flies]]
* [[S15: Remote Learner]]
* [[S15: Protocol Interface: I2C - CAN Bridge]]
* [[S15: Vision RC Car]]
* [[S15: SJeight Octocopter]]
* [[S15: Swarm Robots]]
* [[S15: Smart Sparta Parking System]]
* [[S15: Touch Navigator]]
* [[S15: Wizard's Chess System]]
* [[S15: Bug Rider]]
* [[S15: Real Time Brake Assist (RTBA)]]
* [[S15: Wireless Mesh Network]]
* [[S15: Wireless Power Transfer System]]
* [[S15: Drone]]
* [[S15: Tree Node using Google Protocol Buffers]]
* [[S15: Multi-media Car]]
* [[S15: Hand Gesture Recognition using IR Sensors]]
* [[S15: CAN controlled RGB LED cubes]]
* [[S15: Rubik's Cube Solver]]
* [[S15: RFID Security Box]]
* [[S15: Automated Meeting Room Reservation]]
* [[S15: Patient Buddy System (PBS)]]

CmpE146:
* [[S15: Hovercopter]]
* [[S15: Triclops: Smart RC Car]]
* [[S15: Connect Four - Robotic Player]]
* [[S15: Self-Balancing Robot]]
* [[S15: MP3 Player with Graphic Equalizer Display]]
* [[S15: Motion-Controlled RC Car]]
* [[S15: MENL (Monster Encounter Night Light) ]]
* [[S15: Tilt Motion Controlled LED Alarm Clock]]
* [[S15: Alarm Based Coffee Maker]]

=== [[CmpE244 Spring 2014 | Spring 2014]] ===

 
* Senior Project: [[Project Advising: Remote Security System]]

 
* [[S14: Quadcopter]]
* [[S14: Smart Weather Clock]]
* [[S14: Divine WINd]]
* [[S14: Data Acquisition using CAN bus]]
* [[S14: E-Ink Display for Shopping Tags]]
* [[S14: Spectrum Analyzer for Audio Frequency Signals]]
* [[S14: CAN Firmware Uploader]]
* [[S14: Asset Management and Location System]]
* [[S14: Location Tracker]]
* [[S14: Androbot]]
* [[S14: Virtual Dog]]
* [[S14: Android based Automation]]
* [[S14: FaceTime Robo]]
* [[S14: Wireless Control Car]]
* [[S14: Power Efficient Security Door System for Light-rail using CAN Bus]]
* [[S14: Android based home monitoring system]]
* [[S14: Need For Speed]]

CmpE146
* [[S14: Hyperintelligent NFC Locker of the Future]]
* [[S14: Smart Planter]]
* [[S14: Modular Security System]]
* [[S14: Autonomous Control System]]
* [[S14: Anti-Crash Car]]
* [[S14: Tricopter]]

=== [[CmpE240 Fall 2013 | Fall 2013]] ===

* [[F13: POV Display]]
* [[F13: Line Following Robot]]
* [[F13: LED Display]]
* [[F13: Bulb Ramper]]
* [[F13: Garage Parking Assistant]]
* [[F13: Quadcopter]]
* [[F13: BarkMaster2000]]
* [[F13: Remote Control Car]]
* [[F13: Obstacle Avoidance Robot]]
* [[F13: Vehicle On Board Diagnostics]]

=== [[CmpE146 Spring 2013 | Spring 2013]] ===

* [[S13: 2D Plotter]]
* [[S13: Smart Cube]]
* [[S13: Garage Parking Aid]]
* [[S13: Smart Security]]
* [[S13: Door Alarm System]]
* [[S13: Solar Panel Tracker]]

=== [[CmpE146 Fall 2012|Fall 2012]] ===

* [[F12: Evil Watchdog]]
* [[F12: Smart Bulb]]
* [[F12: All Your Base are Belong to You]]
* [[F12: Android Controlled MP3]]
* [[F12: Unified Wireless Health Monitoring System]]
* [[F12: OBD-II Android Monitor]]
* [[F12: Self-Driving GPS Following Car]]
* [[F12: Android Door Lock]]

=== [[CmpE146 Spring 2012|Spring 2012]] ===
* [[S12: FreeRTOS based QuadCopter]]
* [[S12: Web-based MP3 Player]]
* [[S12: Self Drive Car]]
* [[S12: VAndroid]]
* [[S12: Traffic Light Sensing Vehicle]]
* [[S12: Sound Reader]]
* [[S12: Remote Controlled MP3 Player]]
* [[S12: Android Controlled Robot]]
* [[S12: Eyes-Free GPS]]

 

== Handy References ==
* [[Sample Project Report]]
* [[Project Proposal Guidelines]]
* [[CmpE146 Lab. Resources]]