Mech - User contributions [en]

NU32: VC0706 Serial Camera

2012-07-14T20:48:46Z

AndrewKessler: /* After you have a picture */

=Using the VC0706 Serial Camera Module=

The VC0706 is a video module originally designed for surveillance purposes. It can be used to stream analog NTSC video to a monitor, or to take a snapshot and spit it out as a JPEG over a serial connection. It also has built in motion detection features. The camera can take pictures at 640x480, 320x240, or 160x200. Since using the module to stream video over an RCA connection is trivial, this tutorial will focus on retrieving snapshots.

Since the VC0706 is its own self-contained serial module, you could just connect the camera directly to a PC using an RS232 cable, and interact with it using some terminal software. A Python script is available to directly interface with the camera over serial. The VC0706 uses 3.3V TTL logic, so if you use a 5V RS232-USB cable, make sure you step down the voltage coming out of the computer using a voltage divider, to avoid frying the camera.
This tutorial focuses on how to interact with the module from the perspective of a PIC32 microcontroller.

==Wiring==
Simply connect the TX and RX pins on the VC0706 to any UART port on the NU32. I used UART2, which uses pins F4 and F5. Make sure you connect the camera’s TX to the PIC’s RX, and visa versa1. Also, connect VCC to 5V and GND to the PIC’s GND.

==Open a UART port==

The default baud is 38400. You can change the default baud rate in code once you have established communication.

==Taking a picture==
The basic flow of events is as follows: freeze the image buffer on the VC0706, transfer data from VC0706 to PIC, thaw image buffer, repeat.

If you don’t thaw the buffer after freezing it, freezing the buffer and transferring data from the buffer will just keep giving you the same picture!

==After you have a picture==
After the picture is on the PIC in some kind of buffer, you can do whatever you want with it. Write it to an SD card, spit it out over serial, whatever (if you choose this route, set your terminal app to record serial output to a text file, then just rename it as a .jpg).
Unfortunately, this camera is not well suited for doing image processing onboard the PIC. The camera exports pictures as compressed JPEGs, meaning that the color values of each pixel (which you would want access to to analyze the image) are heavily compressed and encrypted. It is possible to decompress the JPEG to a bitmap, but the trouble is finding code to do that efficiently on an embedded platform. It would also probably be a time-consuming procedure onboard the PIC, meaning it would be difficult to use it for any sort of real-time application. But you’re welcome to try!

==Issues==
Make sure you handle incoming serial transmissions from the VC0706 in an interrupt with a very large incoming buffer, because the built in UART buffer (about 8 bytes) will quickly be overwhelmed from the camera if you’re polling instead.
You can always make sure your camera is working by hooking it up directly to the PC using an RS232 cable, and using a Windows utility to interact with it.

Microchip PICs

2012-07-14T20:47:54Z

AndrewKessler: /* Using the NU32 (Winter 2012 and on) */

'''Note: Some of the code on the bottom of this page was written using the CCS compiler. All new code is being written using Microchip's MPLAB X.

[http://peshkin.mech.northwestern.edu/pic/code Link to all PIC18F sample code here.]
*[[Sample code for most PIC18F4520 operations]]
*[http://www.ccsinfo.com/forum/ CCS user forum]
 
__TOC__
== The NUScope ==
*[[NUScope]]
== Using the NU32 (Winter 2012 and on) ==
*[[NU32: Introduction to the PIC32]]
**[[NU32: What is in the NU32 Kit]]
**[[NU32: Software to Install]]
**[[NU32: Starting a New Project and Putting it on the NU32]]
**[[NU32: A Detailed Look at Programming the PIC32 on the NU32]]
* Sample Code
**[[NU32: Serial Communication with the PC]]
**[[NU32: 16x2 LCD]]
**[[NU32: Digital Input and Output]]
**[[NU32: Counters and Timers]]
**[[NU32: Interrupts]]
**[[NU32: Output Compare, PWM, and Analog Output]]
**[[NU32: Analog Input]]
**[[NU32: Using the dsPIC33FJ12MC201 QEI to SPI board]]
**[[NU32: Using the MAX9918 current sensor]]
**[[NU32: Using the TB6612 H-Bridge]]
**[[NU32: Driving RC servo motors]]
**[[NU32: Driving a stepper motor]]
**[[NU32: Using the LS7183 Quadrature Clock Converter]]
**[[NU32: Using the L293D H-Bridge]]
**[[NU32: Digital Signal Processing]]
**[[NU32: Input Capture]]
**[[NU32: Flash Self-Programming]]
**[[NU32: UART Asynchronous Serial Communication]]
**[[NU32: I2C Synchronous Serial Communication]]
**[[NU32: SPI Synchronous Serial Communication]]
**[[NU32: Watchdog Timer]]
**[[NU32: VC0706 Serial Camera]]
**[[NU32: Using the MCP42X1 SPI Digital Potentiometer]]

== Using the NU32v2 (Winter 2011) ==
*[[NU32v2: Introduction to the PIC32]]
**[[NU32v2: What is in the NU32v2 Kit]]
**[[NU32v2: Software to Install]]
**[[NU32v2: Starting a New Project and Putting it on the NU32v2]]
**[[NU32v2: Using the Simulator]]
**[[NU32v2: A Detailed Look at Programming the PIC32]]
**[[NU32v2: Benchmark Test]]
* Sample Code
**[[NU32v2: Digital Input and Output]]
**[[NU32v2: Counters and Timers]]
**[[NU32v2: Interrupts]]
**[[NU32v2: Output Compare, PWM, and Analog Output]]
**[[NU32v2: Serial Communication with the PC]]
**[[NU32v2: Nokia 5110 LCD]]
**[[NU32v2: Analog Input]]
**[[NU32v2: Using the LS7183 Quadrature Clock Converter]]
**[[NU32v2: Using the L293D H-Bridge]]
**[[NU32v2: Input Capture]]
**[[NU32v2: Flash Self-Programming]]
**[[NU32v2: UART Asynchronous Serial Communication]]
**[[NU32v2: I2C Synchronous Serial Communication]]
**[[NU32v2: SPI Synchronous Serial Communication]]
**[[NU32v2: Digital Signal Processing]]
**[[NU32v2: Watchdog Timer]]
**[[NU32v2: Simple Analog Input]]

== Using the PIC18F4520 ==
*[[4520 Board intro]]
*[[4520 Board construction]]
*[[4520 Board use]]
*[[Microcontroller PIC18F4520]]
*[[PIC MCUs: Capabilities of PIC18F4520]]
**[[PIC18F4520: PWM Motor Control]]
**[[PIC18F4520: Digital Outputs]]
**[[PIC18F4520: Digital Inputs]]
**[[PIC18F4520: Serial Digital-to-Analog Conversion]]
**[[PIC18F4520: Analog Inputs]]
**[[PIC18F4520: Timers]]
**[[PIC18F4520: Comparator]]

== Example Code in C for PIC18F4520==
*[[C Example: Parallel Interfacing with LCDs]]
*[[C Example: Digital Inputs]]
*[[C Example: PWM Motor Control]]
*[[C Example: Comparators]]
*[[C Example: Digital Outputs]]
*[[C Example: Analog Inputs]]
*[[C Example: Digital Outputs (Ports)]]
*[[C Example: Bi-Directional PWM Motor Control]]
*[[C Example: Serial LCD]]

== Using the PIC32MX Series ==
*[[Introduction to the PIC32]]
*[[Getting Started with PIC32]] (includes NU32 development board)
** Download PIC32 Tutorial Files [[Media: PIC32_TutorialFiles.zip|here]].
** [[ME 333 Lab 2]] - Includes Digital IO, Analog Input, Parallel LCD and RS232 Com
** [[ME 333 Lab 4]] - Includes PWM and Encoder Motor Control
*[[Microcontroller PIC32MX460F512L]]
*[[Programming HID Bootloader on PIC32]]
*[[HelloWorld PIC32|Directions to code HelloWorld]]
*[[Directions to Load Files to PIC32 with HID Bootloader]]

*[[PIC MCUs: Capabilities of PIC32MX]]
**[[Programming HID Bootloader on PIC32 |PIC32MX: Bootloader]]
**Simple Programs
***[[PIC32MX: Digital Inputs]]
***[[PIC32MX: Digital Outputs]]
***[[PIC32MX: Analog Inputs]]
**Communication
***[[PIC32MX: Parallel LCD]]
***[[PIC32MX: RS232]]
***[[PIC32MX: USB Communication with a PC]]
***[[PIC32MX: SPI External RAM]]
***[[PIC32MX: I2C DAC]]
***[[PIC32MX: I2C EEPROM]]
***[[PIC32MX: SPI EEPROM]]
***[[PIC32MX: I2C Communication between PIC32s]]
***[[PIC32MX: SPI Communication between PIC32s]]
**Motor Control
***[[PIC32MX: PWM Motor Control|PIC32MX: PWM Motor Control]]
***[[PIC32MX: Encoder Motor Control|PIC32MX: Encoder Motor Control]]
***[[PIC32MX: Servo Control|PIC32MX: Servo Control]]
***[[PIC32MX: Driving a Stepper Motor]]
***[[Using the LS7166 Quadrature Counter]]
***[[Using the LS7366R SPI Quadrature Counter]]
**Capabilities
***[[PIC32MX: Benchmarking Mathematical Operations]]
***[[PIC32MX: FFT of Analog Input]]
***[[PIC32MX: Sinusoidal Analog Output]]
***[[PIC32MX: XBee Wireless Round-trip Latency]]
***[[PIC32MX: Interfacing with Force Sensors from a Scale]]
***[[PIC32MX: Storing Data in Flash Memory (Run-Time Self Programming)]]

==Other PIC Resources ==

*[[PIC PWM Motor Driver]]
*[[Writing Code with the C18 Compiler]]
*[[Controlling a seven segment display]]
*[[PIC Microcontrollers with C18 Compiler]]
*[[PIC Motor Control and Serial Port Example]]
*[[PIC16F684]]
*[[PIC Microcontrollers with CCS Compiler]]
*[[Stepper motor control with the PIC]]
*[[PIC/C18 Compiler Tips and Troubleshooting]]
*[[CCS C]]
*[[Analog Input]]
*[[PIC MCUs: Hardware and Connections]]
*[[Storing constant data in program memory]]
*[[PIC Analog-Digital-Converter Example]]
*[[PIC Microcontroller]]
*[[Digital inputs & outputs]]
*[[Debugging C on a PIC]]
*[[Analog Output]]
*[[PIC MCUs: Software]]
*[[Interfacing to External EEPROM]]
*[[CCS IDE]]
*[[Interrupts]]
*[[PIC16F684 Registers]]
*[[Waveform Generation with AD9833]]
*[[Waveform Generation with AD9833, and SPI]]
*[[PIC computation time benchmarks]]
*[[PICkit 1]]
*[[PIC MCUs: 4520 Board]]
*[[More debugging tips]]
*[[Example Writeup: Analog Input]]
*[[LED Drivers]]
*[[Embedded Programming Tips for CCS C]]
*[[Wireless PIC bootloading]]
*[[PIC 18f4553]]
*[[I2C Motor Controller]]
*[[Driving a piezo speaker with a PIC]]
*[[PIC Servo Controller]]
*[[Watchdog timer]]
*[[Interfacing PIC with SPI memory]]
*[[Using the LS7166 Quadrature Counter]]

==Programming the PIC with Microchip's MPLAB==

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T20:47:16Z

AndrewKessler: /* Details */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> NU32-F3 (this can be any DIO pin you want, change code accordingly)
* Pot 2-SCK -----> NU32-D10
* Pot 3-SDI -----> NU32-D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> NU32-C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip|MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and manipulate the pots:
<code><pre>

SPI_initPots();

//Setting pots to zero...

setPot(0,0);
setPot(1,0);
//both now at 0

//Setting pots to mid-range (64), or 1/2 the total resistance

setPot(0,64);
setPot(1,64);
// both at 64

//Incrementing both
incPot(0);
incPot(1);
// (now at 65)

//Incrementing both
incPot(0);
incPot(1);
//now at 66

//Decrementing both
decPot(0);
decPot(1);
//now 65

//Decrementing both
decPot(0);
decPot(1);
//now 64

</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T20:46:35Z

AndrewKessler: /* Details */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3 (this can be any DIO pin you want, change code accordingly)
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip|MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and manipulate the pots:
<code><pre>

SPI_initPots();

//Setting pots to zero...

setPot(0,0);
setPot(1,0);
//both now at 0

//Setting pots to mid-range (64), or 1/2 the total resistance

setPot(0,64);
setPot(1,64);
// both at 64

//Incrementing both
incPot(0);
incPot(1);
// (now at 65)

//Incrementing both
incPot(0);
incPot(1);
//now at 66

//Decrementing both
decPot(0);
decPot(1);
//now 65

//Decrementing both
decPot(0);
decPot(1);
//now 64

</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T18:19:11Z

AndrewKessler: /* Sample Code */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip|MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and manipulate the pots:
<code><pre>

SPI_initPots();

//Setting pots to zero...

setPot(0,0);
setPot(1,0);
//both now at 0

//Setting pots to mid-range (64), or 1/2 the total resistance

setPot(0,64);
setPot(1,64);
// both at 64

//Incrementing both
incPot(0);
incPot(1);
// (now at 65)

//Incrementing both
incPot(0);
incPot(1);
//now at 66

//Decrementing both
decPot(0);
decPot(1);
//now 65

//Decrementing both
decPot(0);
decPot(1);
//now 64

</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T18:18:18Z

AndrewKessler: /* Details */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip|MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>

SPI_initPots();

//Setting pots to zero...

setPot(0,0);
setPot(1,0);
//both now at 0

//Setting pots to mid-range (64), or 1/2 the total resistance

setPot(0,64);
setPot(1,64);
// both at 64

//Incrementing both
incPot(0);
incPot(1);
// (now at 65)

//Incrementing both
incPot(0);
incPot(1);
//now at 66

//Decrementing both
decPot(0);
decPot(1);
//now 65

//Decrementing both
decPot(0);
decPot(1);
//now 64

</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T18:17:35Z

AndrewKessler: /* Sample Code */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip|MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>

SPI_initPots();

//Setting pots to zero...

setPot(0,0);
setPot(1,0);
//both now at 0

//Setting pots to mid-range (64), or 1/2 the total resistance

setPot(0,64);
setPot(1,64);
// both at 64

//Incrementing both
incPot(0);
incPot(1);
// (now at 65)

//Incrementing both
incPot(0);
incPot(1);
//now at 66

//Decrementing both
decPot(0);
decPot(1);
//now 65

//Decrementing both
decPot(0);
decPot(1);
//now 64

</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T18:17:00Z

AndrewKessler: /* Sample Code */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip|MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>

SPI_initPots();

//Setting pots to zero...

setPot(0,0);
setPot(1,0);
//both now at 0

//Setting pots to mid-range (64), or 5 kOhm

setPot(0,64);
setPot(1,64);
// both at 64

//Incrementing both
incPot(0);
incPot(1);
// (now at 65)

//Incrementing both
incPot(0);
incPot(1);
//now at 66

//Decrementing both
decPot(0);
decPot(1);
//now 65

//Decrementing both
decPot(0);
decPot(1);
//now 64

</pre></code>

File:MCP42X1 Example.zip

2012-07-14T18:11:06Z

AndrewKessler:

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T18:10:52Z

AndrewKessler: /* Library Functions */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip|MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T18:10:30Z

AndrewKessler: /* Library Functions */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

Full example project: [[Media:MCP42X1_Example.zip]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

File:MCP42X1.h

2012-07-14T18:09:50Z

AndrewKessler:

File:MCP42X1.c

2012-07-14T18:09:31Z

AndrewKessler:

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T17:52:07Z

AndrewKessler: /* Overview */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[image:mcp42x1.png|thumb|300px|MCP42X1 Pinout|right]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

File:Mcp42x1.png

2012-07-14T17:50:17Z

AndrewKessler:

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T17:49:47Z

AndrewKessler: /* Overview */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

[[File: mcp42x1.png]]

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T17:46:53Z

AndrewKessler: /* Details */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v (this pin is inverse-shutdown, so we keep it high)
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T17:41:20Z

AndrewKessler: /* Library Functions */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

* void SPI_initPots() : sets up SPI channel 1, and CS pin
* void incPot(int pot_num) : will increment wiper by one step
* void decPot(int pot_num) : will decrement wiper by one step
* int setPot(int pot_num, int wiper) : sets the given pot to specific wiper value (0 - 127), returns success boolean
* int readPot(int pot_num) : reads the current wiper setting from the pot, returns (0 - 127)
* void testPots() : runs tests of setting, incrementing, decrementing, and reading both channels to confirm pots are working properly

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

Microchip PICs

2012-07-14T17:33:04Z

AndrewKessler: /* Using the NU32 (Winter 2012 and on) */

'''Note: Some of the code on the bottom of this page was written using the CCS compiler. All new code is being written using Microchip's MPLAB X.

[http://peshkin.mech.northwestern.edu/pic/code Link to all PIC18F sample code here.]
*[[Sample code for most PIC18F4520 operations]]
*[http://www.ccsinfo.com/forum/ CCS user forum]
 
__TOC__
== The NUScope ==
*[[NUScope]]
== Using the NU32 (Winter 2012 and on) ==
*[[NU32: Introduction to the PIC32]]
**[[NU32: What is in the NU32 Kit]]
**[[NU32: Software to Install]]
**[[NU32: Starting a New Project and Putting it on the NU32]]
**[[NU32: A Detailed Look at Programming the PIC32 on the NU32]]
* Sample Code
**[[NU32: Serial Communication with the PC]]
**[[NU32: 16x2 LCD]]
**[[NU32: Digital Input and Output]]
**[[NU32: Counters and Timers]]
**[[NU32: Interrupts]]
**[[NU32: Output Compare, PWM, and Analog Output]]
**[[NU32: Analog Input]]
**[[NU32: Using the dsPIC33FJ12MC201 QEI to SPI board]]
**[[NU32: Using the MAX9918 current sensor]]
**[[NU32: Using the TB6612 H-Bridge]]
**[[NU32: Driving RC servo motors]]
**[[NU32: Driving a stepper motor]]
**[[NU32: Using the LS7183 Quadrature Clock Converter]]
**[[NU32: Using the L293D H-Bridge]]
**[[NU32: Using the MCP42X1 SPI Digital Potentiometer]]
**[[NU32: Digital Signal Processing]]
**[[NU32: Input Capture]]
**[[NU32: Flash Self-Programming]]
**[[NU32: UART Asynchronous Serial Communication]]
**[[NU32: I2C Synchronous Serial Communication]]
**[[NU32: SPI Synchronous Serial Communication]]
**[[NU32: Watchdog Timer]]
**[[NU32: VC0706 Serial Camera]]

== Using the NU32v2 (Winter 2011) ==
*[[NU32v2: Introduction to the PIC32]]
**[[NU32v2: What is in the NU32v2 Kit]]
**[[NU32v2: Software to Install]]
**[[NU32v2: Starting a New Project and Putting it on the NU32v2]]
**[[NU32v2: Using the Simulator]]
**[[NU32v2: A Detailed Look at Programming the PIC32]]
**[[NU32v2: Benchmark Test]]
* Sample Code
**[[NU32v2: Digital Input and Output]]
**[[NU32v2: Counters and Timers]]
**[[NU32v2: Interrupts]]
**[[NU32v2: Output Compare, PWM, and Analog Output]]
**[[NU32v2: Serial Communication with the PC]]
**[[NU32v2: Nokia 5110 LCD]]
**[[NU32v2: Analog Input]]
**[[NU32v2: Using the LS7183 Quadrature Clock Converter]]
**[[NU32v2: Using the L293D H-Bridge]]
**[[NU32v2: Input Capture]]
**[[NU32v2: Flash Self-Programming]]
**[[NU32v2: UART Asynchronous Serial Communication]]
**[[NU32v2: I2C Synchronous Serial Communication]]
**[[NU32v2: SPI Synchronous Serial Communication]]
**[[NU32v2: Digital Signal Processing]]
**[[NU32v2: Watchdog Timer]]
**[[NU32v2: Simple Analog Input]]

== Using the PIC18F4520 ==
*[[4520 Board intro]]
*[[4520 Board construction]]
*[[4520 Board use]]
*[[Microcontroller PIC18F4520]]
*[[PIC MCUs: Capabilities of PIC18F4520]]
**[[PIC18F4520: PWM Motor Control]]
**[[PIC18F4520: Digital Outputs]]
**[[PIC18F4520: Digital Inputs]]
**[[PIC18F4520: Serial Digital-to-Analog Conversion]]
**[[PIC18F4520: Analog Inputs]]
**[[PIC18F4520: Timers]]
**[[PIC18F4520: Comparator]]

== Example Code in C for PIC18F4520==
*[[C Example: Parallel Interfacing with LCDs]]
*[[C Example: Digital Inputs]]
*[[C Example: PWM Motor Control]]
*[[C Example: Comparators]]
*[[C Example: Digital Outputs]]
*[[C Example: Analog Inputs]]
*[[C Example: Digital Outputs (Ports)]]
*[[C Example: Bi-Directional PWM Motor Control]]
*[[C Example: Serial LCD]]

== Using the PIC32MX Series ==
*[[Introduction to the PIC32]]
*[[Getting Started with PIC32]] (includes NU32 development board)
** Download PIC32 Tutorial Files [[Media: PIC32_TutorialFiles.zip|here]].
** [[ME 333 Lab 2]] - Includes Digital IO, Analog Input, Parallel LCD and RS232 Com
** [[ME 333 Lab 4]] - Includes PWM and Encoder Motor Control
*[[Microcontroller PIC32MX460F512L]]
*[[Programming HID Bootloader on PIC32]]
*[[HelloWorld PIC32|Directions to code HelloWorld]]
*[[Directions to Load Files to PIC32 with HID Bootloader]]

*[[PIC MCUs: Capabilities of PIC32MX]]
**[[Programming HID Bootloader on PIC32 |PIC32MX: Bootloader]]
**Simple Programs
***[[PIC32MX: Digital Inputs]]
***[[PIC32MX: Digital Outputs]]
***[[PIC32MX: Analog Inputs]]
**Communication
***[[PIC32MX: Parallel LCD]]
***[[PIC32MX: RS232]]
***[[PIC32MX: USB Communication with a PC]]
***[[PIC32MX: SPI External RAM]]
***[[PIC32MX: I2C DAC]]
***[[PIC32MX: I2C EEPROM]]
***[[PIC32MX: SPI EEPROM]]
***[[PIC32MX: I2C Communication between PIC32s]]
***[[PIC32MX: SPI Communication between PIC32s]]
**Motor Control
***[[PIC32MX: PWM Motor Control|PIC32MX: PWM Motor Control]]
***[[PIC32MX: Encoder Motor Control|PIC32MX: Encoder Motor Control]]
***[[PIC32MX: Servo Control|PIC32MX: Servo Control]]
***[[PIC32MX: Driving a Stepper Motor]]
***[[Using the LS7166 Quadrature Counter]]
***[[Using the LS7366R SPI Quadrature Counter]]
**Capabilities
***[[PIC32MX: Benchmarking Mathematical Operations]]
***[[PIC32MX: FFT of Analog Input]]
***[[PIC32MX: Sinusoidal Analog Output]]
***[[PIC32MX: XBee Wireless Round-trip Latency]]
***[[PIC32MX: Interfacing with Force Sensors from a Scale]]
***[[PIC32MX: Storing Data in Flash Memory (Run-Time Self Programming)]]

==Other PIC Resources ==

*[[PIC PWM Motor Driver]]
*[[Writing Code with the C18 Compiler]]
*[[Controlling a seven segment display]]
*[[PIC Microcontrollers with C18 Compiler]]
*[[PIC Motor Control and Serial Port Example]]
*[[PIC16F684]]
*[[PIC Microcontrollers with CCS Compiler]]
*[[Stepper motor control with the PIC]]
*[[PIC/C18 Compiler Tips and Troubleshooting]]
*[[CCS C]]
*[[Analog Input]]
*[[PIC MCUs: Hardware and Connections]]
*[[Storing constant data in program memory]]
*[[PIC Analog-Digital-Converter Example]]
*[[PIC Microcontroller]]
*[[Digital inputs & outputs]]
*[[Debugging C on a PIC]]
*[[Analog Output]]
*[[PIC MCUs: Software]]
*[[Interfacing to External EEPROM]]
*[[CCS IDE]]
*[[Interrupts]]
*[[PIC16F684 Registers]]
*[[Waveform Generation with AD9833]]
*[[Waveform Generation with AD9833, and SPI]]
*[[PIC computation time benchmarks]]
*[[PICkit 1]]
*[[PIC MCUs: 4520 Board]]
*[[More debugging tips]]
*[[Example Writeup: Analog Input]]
*[[LED Drivers]]
*[[Embedded Programming Tips for CCS C]]
*[[Wireless PIC bootloading]]
*[[PIC 18f4553]]
*[[I2C Motor Controller]]
*[[Driving a piezo speaker with a PIC]]
*[[PIC Servo Controller]]
*[[Watchdog timer]]
*[[Interfacing PIC with SPI memory]]
*[[Using the LS7166 Quadrature Counter]]

==Programming the PIC with Microchip's MPLAB==

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T15:29:51Z

AndrewKessler: /* Details */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:MCP42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

File:MCP42X1.pdf

2012-07-14T15:29:18Z

AndrewKessler:

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T15:27:47Z

AndrewKessler: /* Overview */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:mcp42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T15:27:27Z

AndrewKessler:

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (CS). It has two independent potentiometer channels, each with its own wiper.

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer allows provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:mcp42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T15:26:28Z

AndrewKessler: /* Sample Code */

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T15:26:14Z

AndrewKessler: /* More Information */

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T15:25:55Z

AndrewKessler: /* Library Functions */

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (chip select).

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer allows provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:mcp42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:MCP42X1.h|MCP42X1.h]], [[Media:MCP42X1.c|MCP42X1.c]]

MCP42X1.c contains the following functions:

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

Go to the leftmost side of the screen on the second line and write 'Hello'
<code><pre>
gotoXY(0,1);
LcdString("Hello");
</pre></code>

Write the value of a variable:
<code><pre>
char str[5];
sprintf(str, "i=%d", i);
LcdString(str);
</pre></code>

Turn on a pixel at (20,35):
<code><pre>
setPixel(20,35,1);
</pre></code>

== More Information ==
The sample code in [[Media:NU32v2_Nokia5110_example.zip|All example code]] will create the image at the top of this page. Sending the NU32v2 an 'a' over serial will clear the LCD.

NU32: Using the MCP42X1 SPI Digital Potentiometer

2012-07-14T15:23:34Z

AndrewKessler: Created page with " The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digit..."

The MCP42X1 is a 7-bit dual digital potentiometer. It is available in total resistance options of 5, 10, 50 and 100 kOhm. It is controlled using SPI communication and a digital output (chip select).

== Overview ==
A potentiometer is useful in a variety of circumstances when a variable resistance is needed. A digital potentiometer allows provides a variable resistor that can be controlled from a microcontroller. Because the MCP42X1 is a 7-bit device, there are 2^7 = 128 possible resistance "steps". By communicating with the IC over SPI, we can choose what step (and thus, resistance) the potentiometer is set at.

The resistance across the PxB and PxW (the wiper) is governed by
<math>R_{WB} = \frac{5\Omega;}{128} N</math>
where the 5kOhm comes from the total resistance of the pot, depending on the model. The value N is the setting of the pot between 0 and 127.

The pot requires four communication pins from a microcontroller: SPI CLK, SDO, SDI, and one digital output. The pot is powered with 3.3V. This model is a dual pot chip, meaning it has two completely independent potentiometer channels in the same IC, referred to as Pot 0 and Pot 1, respectively.

== Details ==
[[Media:mcp42X1.pdf|Datasheet]]

Example schematic when communicating with the NU32, using SPI channel 1:
* Pot 1-CS -----> F3
* Pot 2-SCK -----> D10
* Pot 3-SDI -----> D0
* Pot 4-VSS -----> GND
* Pot 5-P1B -----> P1+
* Pot 6-P1W -----> P1-
* Pot 7-P1A -----> NC
* Pot 8-P0A -----> NC
* Pot 9-P0W -----> P0-
* Pot 10-P0B -----> P0+
* Pot 11 -WP -----> NC
* Pot 12 - SHDN -----> 3.3v
* Pot 13-SDO -----> C4
* Pot 14-VDD -----> 3.3v

The resistance across PXB and PXW is what changes, labeled above as Px+ and Px-.

== Library Functions ==
Code: [[Media:Nokia5110.h|Nokia5110.h]], [[Media:Nokia5110.c|Nokia5110.c]]

Full example: [[Media:NU32v2_Nokia5110_example.zip|All example code]]

Nokia5110.h sets up control pins on E0, E1 and E2. These may be changed if desired. The file also contains function prototypes, constants, and a 96 x 5 element lookup array of ASCII characters.

Nokia5110.c contains the following functions:
* LcdCharacter - used to write an individual ASCII character
* LcdClear - clears the entire LCD
* LcdInitialize - Initializes SPI3 (can be changed if desired) and sends the startup commands to the LCD
** The second command sent (LCD Vop) sets the contrast of the LCD and can be altered for more or less contrast
* LcdString - writes a string of characters to the LCD
* LcdWrite - sends individual commands to the LCD
** Sending commands before the LCD is ready for them will make the LCD miss them, so 1000 Nop()s are called between commands
* gotoXY - places the cursor at an x pixel (0-84) and y character (0-5)
* setPixel - turns on a pixel at x (0-84) and y (0-48)

== Sample Code ==

Initialize and clear the LCD:
<code><pre>
LcdInitialize();
LcdClear();
</pre></code>

Go to the leftmost side of the screen on the second line and write 'Hello'
<code><pre>
gotoXY(0,1);
LcdString("Hello");
</pre></code>

Write the value of a variable:
<code><pre>
char str[5];
sprintf(str, "i=%d", i);
LcdString(str);
</pre></code>

Turn on a pixel at (20,35):
<code><pre>
setPixel(20,35,1);
</pre></code>

== More Information ==
The sample code in [[Media:NU32v2_Nokia5110_example.zip|All example code]] will create the image at the top of this page. Sending the NU32v2 an 'a' over serial will clear the LCD.

Microchip PICs

2012-05-28T02:01:58Z

AndrewKessler: /* Using the NU32 (Winter 2012 and on) */

'''Note: Some of the code on the bottom of this page was written using the CCS compiler. All new code is being written using Microchip's MPLAB X.

[http://peshkin.mech.northwestern.edu/pic/code Link to all PIC18F sample code here.]
*[[Sample code for most PIC18F4520 operations]]
*[http://www.ccsinfo.com/forum/ CCS user forum]
 
__TOC__
== The NUScope ==
*[[NUScope]]
== Using the NU32 (Winter 2012 and on) ==
*[[NU32: Introduction to the PIC32]]
**[[NU32: What is in the NU32 Kit]]
**[[NU32: Software to Install]]
**[[NU32: Starting a New Project and Putting it on the NU32]]
**[[NU32: A Detailed Look at Programming the PIC32 on the NU32]]
* Sample Code
**[[NU32: Serial Communication with the PC]]
**[[NU32: 16x2 LCD]]
**[[NU32: Digital Input and Output]]
**[[NU32: Counters and Timers]]
**[[NU32: Interrupts]]
**[[NU32: Output Compare, PWM, and Analog Output]]
**[[NU32: Analog Input]]
**[[NU32: Using the dsPIC33FJ12MC201 QEI to SPI board]]
**[[NU32: Using the MAX9918 current sensor]]
**[[NU32: Using the TB6612 H-Bridge]]
**[[NU32: Driving RC servo motors]]
**[[NU32: Driving a stepper motor]]
**[[NU32: Using the LS7183 Quadrature Clock Converter]]
**[[NU32: Using the L293D H-Bridge]]
**[[NU32: Digital Signal Processing]]
**[[NU32: Input Capture]]
**[[NU32: Flash Self-Programming]]
**[[NU32: UART Asynchronous Serial Communication]]
**[[NU32: I2C Synchronous Serial Communication]]
**[[NU32: SPI Synchronous Serial Communication]]
**[[NU32: Watchdog Timer]]
**[[NU32: VC0706 Serial Camera]]

== Using the NU32v2 (Winter 2011) ==
*[[NU32v2: Introduction to the PIC32]]
**[[NU32v2: What is in the NU32v2 Kit]]
**[[NU32v2: Software to Install]]
**[[NU32v2: Starting a New Project and Putting it on the NU32v2]]
**[[NU32v2: Using the Simulator]]
**[[NU32v2: A Detailed Look at Programming the PIC32]]
**[[NU32v2: Benchmark Test]]
* Sample Code
**[[NU32v2: Digital Input and Output]]
**[[NU32v2: Counters and Timers]]
**[[NU32v2: Interrupts]]
**[[NU32v2: Output Compare, PWM, and Analog Output]]
**[[NU32v2: Serial Communication with the PC]]
**[[NU32v2: Nokia 5110 LCD]]
**[[NU32v2: Analog Input]]
**[[NU32v2: Using the LS7183 Quadrature Clock Converter]]
**[[NU32v2: Using the L293D H-Bridge]]
**[[NU32v2: Input Capture]]
**[[NU32v2: Flash Self-Programming]]
**[[NU32v2: UART Asynchronous Serial Communication]]
**[[NU32v2: I2C Synchronous Serial Communication]]
**[[NU32v2: SPI Synchronous Serial Communication]]
**[[NU32v2: Digital Signal Processing]]
**[[NU32v2: Watchdog Timer]]
**[[NU32v2: Simple Analog Input]]

== Using the PIC18F4520 ==
*[[4520 Board intro]]
*[[4520 Board construction]]
*[[4520 Board use]]
*[[Microcontroller PIC18F4520]]
*[[PIC MCUs: Capabilities of PIC18F4520]]
**[[PIC18F4520: PWM Motor Control]]
**[[PIC18F4520: Digital Outputs]]
**[[PIC18F4520: Digital Inputs]]
**[[PIC18F4520: Serial Digital-to-Analog Conversion]]
**[[PIC18F4520: Analog Inputs]]
**[[PIC18F4520: Timers]]
**[[PIC18F4520: Comparator]]

== Example Code in C for PIC18F4520==
*[[C Example: Parallel Interfacing with LCDs]]
*[[C Example: Digital Inputs]]
*[[C Example: PWM Motor Control]]
*[[C Example: Comparators]]
*[[C Example: Digital Outputs]]
*[[C Example: Analog Inputs]]
*[[C Example: Digital Outputs (Ports)]]
*[[C Example: Bi-Directional PWM Motor Control]]
*[[C Example: Serial LCD]]

== Using the PIC32MX Series ==
*[[Introduction to the PIC32]]
*[[Getting Started with PIC32]] (includes NU32 development board)
** Download PIC32 Tutorial Files [[Media: PIC32_TutorialFiles.zip|here]].
** [[ME 333 Lab 2]] - Includes Digital IO, Analog Input, Parallel LCD and RS232 Com
** [[ME 333 Lab 4]] - Includes PWM and Encoder Motor Control
*[[Microcontroller PIC32MX460F512L]]
*[[Programming HID Bootloader on PIC32]]
*[[HelloWorld PIC32|Directions to code HelloWorld]]
*[[Directions to Load Files to PIC32 with HID Bootloader]]

*[[PIC MCUs: Capabilities of PIC32MX]]
**[[Programming HID Bootloader on PIC32 |PIC32MX: Bootloader]]
**Simple Programs
***[[PIC32MX: Digital Inputs]]
***[[PIC32MX: Digital Outputs]]
***[[PIC32MX: Analog Inputs]]
**Communication
***[[PIC32MX: Parallel LCD]]
***[[PIC32MX: RS232]]
***[[PIC32MX: USB Communication with a PC]]
***[[PIC32MX: SPI External RAM]]
***[[PIC32MX: I2C DAC]]
***[[PIC32MX: I2C EEPROM]]
***[[PIC32MX: SPI EEPROM]]
***[[PIC32MX: I2C Communication between PIC32s]]
***[[PIC32MX: SPI Communication between PIC32s]]
**Motor Control
***[[PIC32MX: PWM Motor Control|PIC32MX: PWM Motor Control]]
***[[PIC32MX: Encoder Motor Control|PIC32MX: Encoder Motor Control]]
***[[PIC32MX: Servo Control|PIC32MX: Servo Control]]
***[[PIC32MX: Driving a Stepper Motor]]
***[[Using the LS7166 Quadrature Counter]]
***[[Using the LS7366R SPI Quadrature Counter]]
**Capabilities
***[[PIC32MX: Benchmarking Mathematical Operations]]
***[[PIC32MX: FFT of Analog Input]]
***[[PIC32MX: Sinusoidal Analog Output]]
***[[PIC32MX: XBee Wireless Round-trip Latency]]
***[[PIC32MX: Interfacing with Force Sensors from a Scale]]
***[[PIC32MX: Storing Data in Flash Memory (Run-Time Self Programming)]]

==Other PIC Resources ==

*[[PIC PWM Motor Driver]]
*[[Writing Code with the C18 Compiler]]
*[[Controlling a seven segment display]]
*[[PIC Microcontrollers with C18 Compiler]]
*[[PIC Motor Control and Serial Port Example]]
*[[PIC16F684]]
*[[PIC Microcontrollers with CCS Compiler]]
*[[Stepper motor control with the PIC]]
*[[PIC/C18 Compiler Tips and Troubleshooting]]
*[[CCS C]]
*[[Analog Input]]
*[[PIC MCUs: Hardware and Connections]]
*[[Storing constant data in program memory]]
*[[PIC Analog-Digital-Converter Example]]
*[[PIC Microcontroller]]
*[[Digital inputs & outputs]]
*[[Debugging C on a PIC]]
*[[Analog Output]]
*[[PIC MCUs: Software]]
*[[Interfacing to External EEPROM]]
*[[CCS IDE]]
*[[Interrupts]]
*[[PIC16F684 Registers]]
*[[Waveform Generation with AD9833]]
*[[Waveform Generation with AD9833, and SPI]]
*[[PIC computation time benchmarks]]
*[[PICkit 1]]
*[[PIC MCUs: 4520 Board]]
*[[More debugging tips]]
*[[Example Writeup: Analog Input]]
*[[LED Drivers]]
*[[Embedded Programming Tips for CCS C]]
*[[Wireless PIC bootloading]]
*[[PIC 18f4553]]
*[[I2C Motor Controller]]
*[[Driving a piezo speaker with a PIC]]
*[[PIC Servo Controller]]
*[[Watchdog timer]]
*[[Interfacing PIC with SPI memory]]
*[[Using the LS7166 Quadrature Counter]]

==Programming the PIC with Microchip's MPLAB==

NU32: VC0706 Serial Camera

2012-05-22T22:17:56Z

AndrewKessler: Created page with " =Using the VC0706 Serial Camera Module= The VC0706 is a video module originally designed for surveillance purposes. It can be used to stream analog NTSC video to a monitor,..."

=Using the VC0706 Serial Camera Module=

The VC0706 is a video module originally designed for surveillance purposes. It can be used to stream analog NTSC video to a monitor, or to take a snapshot and spit it out as a JPEG over a serial connection. It also has built in motion detection features. The camera can take pictures at 640x480, 320x240, or 160x200. Since using the module to stream video over an RCA connection is trivial, this tutorial will focus on retrieving snapshots.

Since the VC0706 is its own self-contained serial module, you could just connect the camera directly to a PC using an RS232 cable, and interact with it using some terminal software. A Python script is available to directly interface with the camera over serial. The VC0706 uses 3.3V TTL logic, so if you use a 5V RS232-USB cable, make sure you step down the voltage coming out of the computer using a voltage divider, to avoid frying the camera.
This tutorial focuses on how to interact with the module from the perspective of a PIC32 microcontroller.

==Wiring==
Simply connect the TX and RX pins on the VC0706 to any UART port on the NU32. I used UART2, which uses pins F4 and F5. Make sure you connect the camera’s TX to the PIC’s RX, and visa versa1. Also, connect VCC to 5V and GND to the PIC’s GND.

==Open a UART port==

The default baud is 38400. You can change the default baud rate in code once you have established communication.

==Taking a picture==
The basic flow of events is as follows: freeze the image buffer on the VC0706, transfer data from VC0706 to PIC, thaw image buffer, repeat.

If you don’t thaw the buffer after freezing it, freezing the buffer and transferring data from the buffer will just keep giving you the same picture!

==After you have a picture==
After the picture is on the PIC in some kind of buffer, you can do whatever you want with it. Write it to an SD card, spit it out over serial, whatever (if you choose this route, set your terminal app to record serial output to a text file, then just rename it as a .jpg).
If you were planning on doing some kind of image processing onboard the PIC, then I’ve got
some bad news for you. The camera exports pictures as compressed JPEGs, meaning that the color values of each pixel (which you would want access to to analyze the image) are heavily compressed and encrypted. It is possible to decompress the JPEG to a bitmap, but the trouble is finding code to do that efficiently on an embedded platform. It would also probably be a time-consuming procedure onboard the PIC, meaning it would be difficult to use it for any sort of real-time application. But you’re welcome to try!

==Issues==
Make sure you handle incoming serial transmissions from the VC0706 in an interrupt with a very large incoming buffer, because the built in UART buffer (about 8 bytes) will quickly be overwhelmed from the camera if you’re polling instead.
You can always make sure your camera is working by hooking it up directly to the PC using an RS232 cable, and using a Windows utility to interact with it.

PIC32MX: High-speed Wireless Communication

2010-09-17T16:10:12Z

AndrewKessler: /* Latency and Data Rates */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
[[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]
<code><pre>
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
}
}
</pre></code>

Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.

Throughput tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.

PIC32MX: High-speed Wireless Communication

2010-09-17T16:07:50Z

AndrewKessler: /* Latency and Data Rates */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
<code><pre>
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
}
}
</pre></code>
[[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.

Throughput tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

PIC32MX: High-speed Wireless Communication

2010-09-17T16:06:53Z

AndrewKessler: /* Latency and Data Rates */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

===Latency===
To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
<code><pre>
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
}
}
</pre></code>
[[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]
Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.

===Throughput===
These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

PIC32MX: High-speed Wireless Communication

2010-09-17T16:06:37Z

AndrewKessler: /* =Throughput */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

===Latency===
To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
<code><pre>
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
}
}
</pre></code>

Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
[[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]

===Throughput===
These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

PIC32MX: High-speed Wireless Communication

2010-09-17T16:06:12Z

AndrewKessler: /* Latency and Data Rates */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

===Latency===
To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
<code><pre>
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
}
}
</pre></code>

Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
[[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]

===Throughput==
These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|thumb|Plot of Data Rates]]

PIC32MX: High-speed Wireless Communication

2010-09-17T16:05:31Z

AndrewKessler: /* Latency and Data Rates */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

===Latency===
To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
<code><pre>
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
}
}
</pre></code>

Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
[[Image:nrf-latency.jpg|thumb|Plot of Transmission Latency]]

These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|tumb|Plot of Data Rates]]

File:Nrf-latency.jpg

2010-09-17T16:04:15Z

AndrewKessler:

PIC32MX: High-speed Wireless Communication

2010-09-17T16:03:53Z

AndrewKessler: /* Latency */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

===Latency===
To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like this was used:
<code><pre>
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
}
}
</pre></code>

Three measurements of time to transmit were done for each payload size. It should be noted that these results are completely independent of whether or not the transmission successfully made it to a receiver; in fact, these tests were done without a receiving PIC. The results seem to indicate a latency of 178 microseconds.
[[Image:nrf-latency.jpg|center]]

These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-09-17T15:57:54Z

AndrewKessler: /* Data Rates */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Latency and Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads, as well as the latency involved with transmission.

===Latency===
To measure transmission latency, an oscilloscope was used to time how long it took before transmission was complete. For instance, something like:
[code][pre]
while(1){
if (!swUser){
PIN_D1=1; //raise test pin

nrf24l01_write_tx_payload(dataToSend, width, true); //transmit char array over RF

//wait until the packet has been sent
while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active()));

PIN_D1=0; //lower test pin
nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
[/code][/pre]

These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:41:17Z

AndrewKessler: /* Circuit */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The nrf24L01+ chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:39:23Z

AndrewKessler: /* Initialization Functions */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt(); //interrupts enabled?
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:38:52Z

AndrewKessler: /* Initialization Functions */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>void SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:38:33Z

AndrewKessler: /* Receiver Code */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:38:12Z

AndrewKessler: /* Transmitter Code */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre><code>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre></code>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:37:49Z

AndrewKessler: /* Receiver Code */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</code></pre>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<pre><code>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre></code>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:37:25Z

AndrewKessler: /* Transmitter Code */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</code></pre>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<code><pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre></code>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:37:00Z

AndrewKessler: /* Initialization Functions */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<code><pre>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<pre><code>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</code></pre>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<code><pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre></code>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:35:51Z

AndrewKessler: /* Transmitter Code */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<pre><code>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<pre><code>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</code></pre>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<code><pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre></code>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

PIC32MX: High-speed Wireless Communication

2010-08-26T21:35:28Z

AndrewKessler: /* Initialization Functions */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

If you wish to display information to the screen or receive information from the keyboard, you will have to initialize the RS232 connection as well. This can be done with the following code:

<pre><code>
int pbClk = SYSTEMConfigPerformance(SYS_FREQ);
initUART2(pbClk);

void initUART2(int pbClk) {
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.
ConfigIntUART2(UART_INT_PR2 | UART_RX_INT_EN);
//INTEnableSystemMultiVectoredInt();
}
</pre></code>

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<code><pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre></code>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]

File:Nrf-bidirectional.c

2010-08-24T19:41:32Z

AndrewKessler:

PIC32MX: High-speed Wireless Communication

2010-08-24T17:44:46Z

AndrewKessler: /* Bidirectional Communication */

== Overview ==

[[Image:nrf-pic1.jpg|thumb|nrf24L01+ wireless chip with pins attatched]]
This wiki describes how to wire a [http://www.sparkfun.com/commerce/product_info.php?products_id=691 nRF24L01+ chip] ("wireless chip") to a PIC32 board and includes annotated code describing the functions that facilitate the transmitting and receiving of wireless data. A [[media:Wireless-ppt.pdf|PowerPoint presentation]] covering much of the introductory information available on this page is also available.

To operate the system, you must properly connect the wireless chips to the PIC32s, load the transmitter code onto the PIC that you wish to act as a transmitter, load the receiver code onto the PIC that you wish to act as a receiver, properly connect an RS232 cable to the PIC and open a serial communication program (e.g. HyperTerminal or [http://chiark.greenend.org.uk/~sgtatham/putty/download.html putty]), and turn the NU32 boards on. If you use the c-files provided on this pages (and everything else is set up properly), the transmitting PIC will broadcast any characters received from the PC via RS232, and the receiving PIC will display what it receives from wireless link on the PC via RS232. The payload width can be adjusted using the "[" and "]" keys on both the transmitting and receiving PICs. Both wireless chips must be set to the same payload width in order to communicate. Payload widths may vary from 1 to 32. The transmitting PIC will not transmit until enough characters have been entered to fill a payload. Once enough characters have been entered into the transmitting PIC, the serial display will move to a new line to signal transmission.

==Chip Basics==
The nrf24L01+ Module is a breakout of the nrf24L01+ 2.4 GHz transceiver, with an on board antenna. In order to get a wireless link up and running, the following parameters must be consistent between a transmitter and receiver chip:

===Channels===
The channel of the nrf24L01+ chip is the frequency that it broadcasts and receives data from. The channel can range from 2.4 GHz to 2.525 GHz, at intervals no more than 1 MHz. The exact distance between channels is dependent on the on air data rate. Two wireless chips must be tuned to the same channel in order to communicate. See the Air Data Rate section for necessary channel spacing.

===Air Data Rate===
The air data rate is the rate at which the chip transmits bits wirelessly (and the rate at which it looks for them). The nrf24L01+ chip has three selectable data rates: 250 kbps, 1 Mbps, and 2 Mbps. Faster data rates draw less current, but require a greater distance between channels. Slower data rates give you the option of more channels and better receiver sensitivity, for the obvious trade off of speed. Data rates of 250 kbps and 1 Mbps require channel spacing of at least 1 MHz (allowing for 125 unique channels), and a data rate of 2 Mbps requires spacing of 2 MHz between channels (allowing for 62 channels). Two wireless chips will not be able to communicate if they are not set to the same on air data rate.

===Payload Width===
The payload is the actual data you are trying to send over a wireless link, and the payload width is how many bytes are contained within each payload. The nfr24L01+ is capable of supporting payloads up to 32 bytes. A transmitter and receiver must be set to the same payload in order to communicate. Transmission speeds for different sizes payloads are analyzed below.

===Addresses & Pipes===
Every wireless transmission is preceded by the address of the intended receiver. The nrf24L01+ chip has 6 different receiving pipes, which means it may act as 6 receivers with 6 different addresses. Addresses may be three, four, or five bytes long. The addresses for pipe 0 and 1 may be completely different, but the addresses for pipes 2, 3, and 4 may only differ from the address of pipe 1 by their least significant byte. All active pipes feed into the same 3-packet-deep incoming transmission queue. Each pipe may also be set to a expect a different payload width.

== Circuit ==

[[Image:Wireless-circuit.jpg|thumb|Schematic of the nRF24L01+ connected to the PIC32_NU32 board]]

The wireless chip has 8 pins that need to be wired to the PIC (all I/O are relative to PIC):

*Vcc: +3.3 Vdc supply 
*CE: uC pin C1 (input) 
*CSN: uC pin C2 (output) 
*SCK: uC pin D10, configured as SCK(SPI) (output) 
*MOSI: uC pin D0, configured as SDO(SPI) (output) 
*MISO: uC pin C4, configured as SDI(SPI) (input) 
*IRQ: uC pin B0 (input) 
*GND: common digital ground 

The +3.3V and ground are provided by the NU32 board. The term "uC" above stands for microcontroller, which is the PIC32 in our case.

Descriptions of the wireless chip's pins can be found in Brennan Ball's DIYembedded [http://www.diyembedded.com/tutorials/nrf24l01_0/nrf24l01_tutorial_0.pdf Tutorial 0]. The SCK, MOSI, and MISO pins interface with the SPI on the PIC32 which allows for communication between the PIC and the wireless chip. The GPIO pins will be initialized as digital inputs or outputs in the code to enable/disable the wireless chip and check the wireless data transfer/receive stats.

In order to print information from the PIC to the PC, we need to wire an [[PIC_RS232]] cable's transfer and receive lines to the UART ports of the NU32 board (F4, F5).

==Code==

===Driver===
Besides the main C files for the transmitter and receiver, the project also needs the [[media:Wireless-files.zip|nRF24L01.h header file and C file]]. These driver files were created by Brennan Ball, and are explained in detail in his [http://blog.diyembedded.com/ tutorials]. The following things must be changed in the header file available on his website to make it compatible with the NU32 board:
*pin registers and masks must be set to the appropriate values
*the "HardwareProfile.h" NU32 specific file must be included

These changes are accounted for the the driver available on this page. All of the SPI functions trace back to a single function to send and read a single byte, which must be defined in the main c file.

This function is available here:

<code><pre>

unsigned char spi_send_read_byte(unsigned char byte) {
unsigned short txData, rxData; // transmit, receive characters
int chn = 1; // SPI channel to use (1 or 2)

txData = byte; // take inputted byte and store into txData
SpiChnPutC(chn, txData); // send data
rxData = SpiChnGetC(chn); // retreive over channel chn the received data into rxData

return rxData;
}
</pre></code>
===Initialization Functions===
In order to get a wireless link up and running, you will need to initialize both the wireless chip and SPI communication on the PIC.
To intialize SPI on the PIC, create the following function in your main C file:
<code><pre>oid SpiInitDevice(int chn, int isMaster, int frmEn, int frmMaster) {
unsigned int config = SPI_CON_MODE8|SPI_CON_SMP|SPI_CON_ON; // SPI configuration word
if(isMaster)
{
config|=SPI_CON_MSTEN;
}
if(frmEn)
{
config|=SPI_CON_FRMEN;
if(!frmMaster) {
config|=SPI_CON_FRMSYNC;
}
}
SpiChnOpen(chn, config, 4); // divide fpb by 4, configure the I/O ports. Not using SS in this example
}
</pre></code>
You can then call this function with the call <code> SpiInitDevice(1,1,0,0) </code> to initalize SPI channel 1 on the PIC.

To initialize the nrf24L01+ chip itself, you have to options. You can either use <code> nrf24L01_initialize(..) </code> which gives you the opportunity to manually define every register in the chip right from the start. However, this function has 21 arguments, so it is not the most convenient to use if you don't have to. Instead, you can use <code> nrf24L01_initialize_debug(bool rx, int width, bool auto_ack_on) </code>, which gives you the option to specify whether or not the chip is a receiver or transmitter, what the payload width is, and whether or not to enable auto-acknowledge. However, it limits you to Pipe 0, an air data rate of 2 Mpbs, and RF Channel 2. However, these limitations can be adjusted easily after initialization using additional functions (see the library for all available functions). So, for example, to initialize your chip as a transmitter with a payload width of one byte and no auto-acknowledgement, you could call <code> nrf24L01_initialize_debug(0,1,0)</code>.

===Transmitter Code===

Wirelessly transmitting data requires three steps:

*initialize nrf24L01+ as transmitter
*transmit packet
*wait for payload to be sent

A basic outline for such a procedure would look like:
<code><pre>
char data = 'x'; //data to send
int width = 1; //width of payload

nrf24l01_initialize_debug(false, width, false); //initialize the 24L01 to the debug configuration as TX, 1 data byte, and auto-ack disabled

nrf24l01_write_tx_payload(&data, width, true); //add char to Tx queue, and transmit immediately (char * data, int width, bool transmit_now)

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_tx_ds_active())); //wait until IRQ status tells us that it is done transmitting

nrf24l01_irq_clear_all(); //clear all interrupts in the 24L01
</pre></code>

A fully functional [[media:nrf-tx.c|transmitter c-file]] is available. It is intended to work with the receiving code file, available below, and allows for a variable payload.

===Receiver Code===
Similarly, receiving data from a wireless link requires three steps:
*initialize nrf24L01+ as receiver
*wait for incoming packet
*write packet to memory

That would look like:
<code><pre>
char data; //variable to recieve incoming data
int width = 1; //width of payload

nrf24l01_initialize_debug(true, width, false); //initialize the 24L01 to the debug configuration as RX, 1 data byte, and auto-ack disabled

while(!(nrf24l01_irq_pin_active() && nrf24l01_irq_rx_dr_active())); //wait to receive a packet

nrf24l01_read_rx_payload(&data, width); //get the payload into data

nrf24l01_irq_clear_all(); //clear interrupts
</pre></code>

A fully functional [[media:nrf-rx.c|receiver c-file]] is available. It is intended to work with the transmitter code file, available above, and allows for a variable payload.

===Handling Multi-byte Payloads===
Transmitting and receiving payloads of widths larger than one byte are handled the same exact way as described as above, except that instead of having a a single char data variable, you would have an array of chars as your data variable. Then rather then pass in the memory of address of <code>data </code> you can simply pass in <code>data</code> itself, because in C, the variable representing an array is synonymous with the memory address of its first element. Examples of this are available in the attached C files.

===Bidirectional Communication===
While technically the nrf24l01+ chip can only be in one mode (transmitting/receiving) at a given instant, with some clever programming you can still get a bidirectional link established between two chips. The [[media:nrf-bidirectional.c| full code for bidirectional communication]] is available on this page. Basically, the chip sits in receiver mode, listening for any incoming packets. If it receives one, it displays it to the screen. However, there in the event that a key is pressed on the local terminal, the PIC switches the mode from receiving to transmitting, transmits the data received locally, and then goes back to receiver mode. It is not a perfect system because if a packet reaches a chip while the chip is in the middle of transmitting a packet itself, it will not pick up the packet in the air. However, the chance of this sort of situation happening would be rare, depending on the application of the system.

To establish a bidirectional link, both PICs should have the same bidirectional c-file loaded (but this is not necessary: e.g. one PIC could only be able to transmit, and it would still be a viable one-way link ). If the on air data rate is set to 1 Mbps, then this bidirectional c-file is compatible with the [http://www.sparkfun.com/commerce/product_info.php?products_id=9019 Nordic USB Serial Converter] (note that the Nordic USB-Serial converter is only compatible with a payload width of four bytes). The payload width of the bidirectional link can be adjusted with the "[" and "]" keys, exactly as with the above code.

==Data Rates==

Basic timed tests were done to find out how long it took to transmit and receive different sized payloads. These tests were done by sending a packet wirelessly, then timing how long it took to get it back. A pin was raised to high while waiting and then dropped when it was received. These periods were then measured on an oscilloscope, and then averaged. The times used were only those that had 100% return rate. However, the accuracy of these packets was not checked beyond the built in CRC error-checking within the packets themselves. The rates here are to go send out a transmission and then receive it back, so the rate should be doubled for only transmitting in one direction.
[[Image:bps-nrf24l01.jpg|center]]