F16: SJone to FPGA wireless integration - Revision history

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

2016-12-21T15:14:06Z

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

2016-12-21T15:10:32Z

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

2016-12-21T15:09:15Z

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

2016-12-21T13:52:31Z

‎Project Video

2016-12-21T13:50:33Z

‎Appendix

2016-12-21T13:50:22Z

‎Appendix

2016-12-21T13:50:05Z

‎References

2016-12-21T13:40:08Z

‎Software Design

2016-12-21T13:39:55Z

‎Software Design

2016-12-21T13:39:25Z

‎Design & Implementation

@@ Line 185: / Line 185: @@
 === 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:SPIwaveforms.jpeg|500px|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]]
+[[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.

@@ Line 185: / Line 185: @@
 === 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:SPIwaveforms.jpeg|250px|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]]
+[[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.

← Older revision		Revision as of 15:09, 21 December 2016
Line 184:		Line 184:

	=== The most significant issue was getting the SPI_Master module to work with the Microchip unit ===		=== 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.		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.

@@ Line 192: / Line 192: @@
 === Project Video ===
-Upload a video of your project and post the link here.
+No video media at this time.
 === Project Source Code ===

@@ Line 208: / Line 208: @@
 === Appendix ===
 [[File:MRF24WG0MA.pdf]]
 [[File:nexys4ddr_rm.pdf]]
 [[File:S6BUserManual.pdf]]

@@ Line 199: / Line 199: @@
 == References ==
 === Acknowledgement ===
-Any acknowledgement that you may wish to provide can be included here.
+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 ===
-List any references used in project.
+*Microchip MRF24WG0MA Datasheet
 === Appendix ===
-You can list the references you used.
+[[File:MRF24WG0MA.pdf]]

@@ Line 175: / Line 175: @@
 :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.
-<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
+<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
 == Testing & Technical Challenges ==

@@ Line 159: / Line 159: @@
 :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.
-<br /><br />
+<br /><br /><br /><br /><br /><br />
 === Software Design ===
-=== Implementation ===
+[[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]]
 == Testing & Technical Challenges ==