Mech - User contributions [en]

USB communication with PC

2010-05-27T07:30:04Z

Gregory McGlynn:

Some PIC models have built-in USB transceivers that make it simple to connect the PIC to a computer via USB. One such PIC is the [[PIC 18f4550]], which is similar to the 18f4520 in almost all respects, except that it has hardware support for USB built into it. The 18f4550 will work just fine in one of the [[4520_Board_intro|PIC protoboards]].

USB software for the PC tends to be OS-specific. '''This article currently assumes you're running Windows.'''

== The USB protocol ==
USB is a pretty complex protocol with a long specification, but it's not necessary to understand every part of it to use it. It's enough to know what wires to hook up and what software libraries to include in your code.

Wikipedia has a detailed and informative [http://en.wikipedia.org/wiki/Usb page on USB].

=== Connectors ===
USB connectors have four leads; the pictures on Wikipedia show which is which on standard connectors. If you cut open a USB cable, the colors will also tell you which wire is which:
* +5V (red): the host (computer) provides up to 500mA of current at 5V that you can use for power. If your PIC is self-powered, though, make sure you don't connect the two +5V sources or bad things may happen.
* GND (black): ground; make sure you do connect this to your PIC's ground.
* D+ (green) and D- (white): data is transmitted on these lines. The exact protocol is complicated and you probably don't need to know the details.

== USB with the PIC 18F4550 ==
=== Hardware ===
On the 18f4550, the D+ line connects to pin RC5 and the D- line to pin RC4. The ground line of course connects to ground.

Additionally pin 18 on the PIC, called Vusb, should have a capacitor to ground. Try 220 or 470nF.

=== Software ===
On the software side you have some choices. Probably the simplest thing to do is use a preexisting software library that makes the USB connection look like an [[PIC RS232|RS232 connection]]. The CCS compiler has a CDC library that provides functions like ''usb_cdc_getc'' or ''usb_cdc_putc'' that work over USB exactly like regular ''getc'' and ''putc'' work over RS232. CCS also provides a Windows driver for the PC that creates a virtual COM port that you can open in Matlab, Hyperterminal, or any other RS232-capable program and use to talk to the PIC. See [[USB communication with CCS]].

Microchip provides a [[Microchip USB Framework|USB framework]] that works with its C18 compiler and its MPLAB development environment. See [[USB communication with C18 and MPLAB]].

CCS also has an example where the PIC registers itself as a Human Interface Device (HID). USB mice and keyboards use HID. The advantage of this is that doesn't require the user to install a special driver. The disadvantages are (a) the connection doesn't look like a simple RS232 link and (b) bandwidth is limited. A HID can only send messages to the computer once every millisecond, and can only send 64 bytes in each message, so the maximum data transfer rate is 64K bytes/second. In theory, USB can go up to 12M bits/second, so HID is fairly slow in comparison.

It's also possible to create one's own setup from scratch or by modifying a preexisting library. This probably takes some effort.

== See also ==
[[USB Bootloading]]

USB communication with C18 and MPLAB

2009-06-11T13:28:13Z

Gregory McGlynn:

Microchip publishes a USB Framework that consists of a number of files that contain code to handle the tedious parts of USB communication, with a few spots where user code can be included to build USB programs.

This code uses Microchip's CDC library to create a virtual COM port on the computer. Opening this COM port in Hyperterminal or some other terminal program should show numbers appearing once every second or so. The PIC is reading analog voltages from AN0 and writing them out to the terminal.

CDC communication requires a driver on the PC end. You'll need to download these two files and put them in a folder together somewhere: [[Media:Mchpcdc.inf]] and [[Media:Mchpcdc.cat]]. The first time you run this program on the PIC and plug in into the PC, Windows will need to set up a driver to be able to talk to the PIC. It will probably flounder around a bit and fail to find the driver. When you can, point it to the folder containing these two files and it should find them and set up the driver.

CDC programs can operate in two modes: polling or interrupt. This choice comes from the fact that USB devices must continually monitor the connection to the host, looking for incoming data and handling the sending of data in the output queue. There are two ways to accomplish this: the program can either explicitly call a function periodically to handle USB tasks, or this can be done by a regularly scheduled interrupt.

The framework provides two slots in which user code can be placed: the functions UserInit and ProcessIO. UserInit is called once at the beginning of the program to allow you to do some initialization. ProcessIO is called in a loop; each iteration should be very short and must be non-blocking, if you are using the polling structure.

Below is an example program using the polling structure, showing just the UserInit and ProcessIO functions.

You can download the full MPLAB project here. In the example project the UserInit and ProcessIO functions are jumbled in with a ton of other code in main.c, but you could move them off to their own .c file. Note: this MPLAB project is configured to work with the [[USB Bootloading|USB HID bootloader]]. Using it without a bootloader or with another bootloader will require changes.

The MPLAB project includes code for lots of other setups; Microchip sells demo boards with a variety of chips in them and this code is designed to be able to run on all of them by flipping a few compiler switches. So you'll see stuff like "#if defined(PIC18F87J50_PIM)" or whatever; the only relevant one is PIC18F4553_SCOPE, and the include file "HardwareProfile - PIC18F4553 Scope.h", which assume a [[PIC 18f4550|PIC18F4550 or 4553]]

'''UserInit'''
<pre>void UserInit(void)
{
mInitAllLEDs();

//USER CODE!
//ADC initialization:
TRISAbits.TRISA0 = 1; //A0 is input
ADCON0 = 1; //enable ADC
ADCON1 = 0b00001110; //only AN0
ADCON2 = 0b00010111; //4 Tad, RC clock
}//end UserInit</pre>

'''ProcessIO'''
<pre>char output_buffer[100];

int count = 0;
void ProcessIO(void)
{
BYTE numBytesRead;

//Blink the LEDs according to the USB device status
BlinkUSBStatus();
// User Application USB tasks
if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1)) return;

//Check if we're ready to send more data. If not, we can't wait until we are,
//because blocking would screw up the rest of the USB tasks that are going on
//in the background. If we're not ready, we just return from this function and
//we'll loop back around in a bit.
if(mUSBUSARTIsTxTrfReady()) {
count++;
if(count == 10000) { //this happens every second or so
ADCON0bits.GO_DONE = 1; //initiate ADC conversion
while(ADCON0bits.GO_DONE); //wait for ADC to finish

//put the result of the ADC conversion in a string:
sprintf(output_buffer, (const rom far char *)"%u\r\n", ADRESH);

//queues our message up to be sent
putsUSBUSART(output_buffer);
}
}

//this needs to be called periodically in order for stuff to get sent out:
CDCTxService();

} //end ProcessIO</pre>

File:Mchpcdc.inf

2009-06-11T13:25:32Z

Gregory McGlynn:

File:Mchpcdc.cat

2009-06-11T13:25:22Z

Gregory McGlynn:

USB communication with C18 and MPLAB

2009-06-11T13:22:23Z

Gregory McGlynn:

Microchip publishes a USB Framework that consists of a number of files that contain code to handle the tedious parts of USB communication, with a few spots where user code can be included to build USB programs.

This code uses Microchip's CDC library to create a virtual COM port on the computer. Opening this COM port in Hyperterminal or some other terminal program should show numbers appearing once every second or so. The PIC is reading analog voltages from AN0 and writing them out to the terminal.

CDC programs can operate in two modes: polling or interrupt. This choice comes from the fact that USB devices must continually monitor the connection to the host, looking for incoming data and handling the sending of data in the output queue. There are two ways to accomplish this: the program can either explicitly call a function periodically to handle USB tasks, or this can be done by a regularly scheduled interrupt.

The framework provides two slots in which user code can be placed: the functions UserInit and ProcessIO. UserInit is called once at the beginning of the program to allow you to do some initialization. ProcessIO is called in a loop; each iteration should be very short and must be non-blocking, if you are using the polling structure.

Below is an example program using the polling structure, showing just the UserInit and ProcessIO functions.

You can download the full MPLAB project here. Note: this MPLAB project is configured to work with the [[USB Bootloading|USB HID bootloader]]. Using it without a bootloader or with another bootloader will require changes.

The MPLAB project includes code for lots of other setups; Microchip sells demo boards with a variety of chips in them and this code is designed to be able to run on all of them by flipping a few compiler switches. So you'll see stuff like "#if defined(PIC18F87J50_PIM)" or whatever; the only relevant one is PIC18F4553_SCOPE, and the include file "HardwareProfile - PIC18F4553 Scope.h", which assume a [[PIC 18f4550|PIC18F4550 or 4553]]

'''UserInit'''
<pre>void UserInit(void)
{
mInitAllLEDs();

//USER CODE!
//ADC initialization:
TRISAbits.TRISA0 = 1; //A0 is input
ADCON0 = 1; //enable ADC
ADCON1 = 0b00001110; //only AN0
ADCON2 = 0b00010111; //4 Tad, RC clock
}//end UserInit</pre>

'''ProcessIO'''
<pre>char output_buffer[100];

int count = 0;
void ProcessIO(void)
{
BYTE numBytesRead;

//Blink the LEDs according to the USB device status
BlinkUSBStatus();
// User Application USB tasks
if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1)) return;

//Check if we're ready to send more data. If not, we can't wait until we are,
//because blocking would screw up the rest of the USB tasks that are going on
//in the background. If we're not ready, we just return from this function and
//we'll loop back around in a bit.
if(mUSBUSARTIsTxTrfReady()) {
count++;
if(count == 10000) { //this happens every second or so
ADCON0bits.GO_DONE = 1; //initiate ADC conversion
while(ADCON0bits.GO_DONE); //wait for ADC to finish

//put the result of the ADC conversion in a string:
sprintf(output_buffer, (const rom far char *)"%u\r\n", ADRESH);

//queues our message up to be sent
putsUSBUSART(output_buffer);
}
}

//this needs to be called periodically in order for stuff to get sent out:
CDCTxService();

} //end ProcessIO</pre>

USB communication with PC

2009-06-11T13:07:17Z

Gregory McGlynn:

Some PIC models have built-in USB transceivers that make it simple to connect the PIC to a computer via USB. One such PIC is the [[PIC 18f4550]], which is similar to the 18f4520 in almost all respects, except that it has hardware support for USB built into it. The 18f4550 will work just fine in one of the [[4520_Board_intro|PIC protoboards]].

USB software for the PC tends to be OS-specific. '''This article currently assumes you're running Windows.'''

== The USB protocol ==
USB is a pretty complex protocol with a long specification, but it's not necessary to understand every part of it to use it. It's enough to know what wires to hook up and what software libraries to include in your code.

Wikipedia has a detailed and informative [http://en.wikipedia.org/wiki/Usb page on USB].

=== Connectors ===
USB connectors have four leads; the pictures on Wikipedia show which is which on standard connectors.
* +5V: the host (computer) provides up to 500mA of current at 5V that you can use for power. If your PIC is self-powered, though, make sure you don't connect the two +5V sources or bad things may happen.
* GND: ground; make sure you do connect this to your PIC's ground.
* D+ and D-: data is transmitted on these lines. The exact protocol is complicated and you probably don't need to know the details.

== USB with the PIC 18F4550 ==
=== Hardware ===
On the 18f4550, the D+ line connects to pin RC5 and the D- line to pin RC4. The ground line of course connects to ground.

Additionally pin 18, called Vusb, should have a capacitor to ground. Try 220 or 470nF.

=== Software ===
On the software side you have some choices. Probably the simplest thing to do is use a preexisting software library that makes the USB connection look like an [[PIC RS232|RS232 connection]]. The CCS compiler has a CDC library that provides functions like ''usb_cdc_getc'' or ''usb_cdc_putc'' that work over USB exactly like regular ''getc'' and ''putc'' work over RS232. CCS also provides a Windows driver for the PC that creates a virtual COM port that you can open in Matlab, Hyperterminal, or any other RS232-capable program and use to talk to the PIC. See [[USB communication with CCS]].

Microchip provides a [[Microchip USB Framework|USB framework]] that works with its C18 compiler and its MPLAB development environment. See [[USB communication with C18 and MPLAB]].

CCS also has an example where the PIC registers itself as a Human Interface Device (HID). USB mice and keyboards use HID. The advantage of this is that doesn't require the user to install a special driver. The disadvantages are (a) the connection doesn't look like a simple RS232 link and (b) bandwidth is limited. A HID can only send messages to the computer once every millisecond, and can only send 64 bytes in each message, so the maximum data transfer rate is 64K bytes/second. In theory, USB can go up to 12M bits/second, so HID is fairly slow in comparison.

It's also possible to create one's own setup from scratch or by modifying a preexisting library. This probably takes some effort.

== See also ==
[[USB Bootloading]]

USB bootloading

2009-06-11T13:04:16Z

Gregory McGlynn:

Compiling for a bootloader in MPLAB

2009-06-11T13:02:45Z

Gregory McGlynn:

Compiling a program that will be loaded using a bootloader requires a lot of extra code in MPLAB. Basically this code is doing two things:
*''Vector remapping:'' Resets, high-priority interrupts, and low-priority interrupts usually make the PIC start executing code at addresses 0x00, 0x08, and 0x18 respectively. However, this is the domain of the bootloader, which is sitting in this first region of memory. So some "remapping" goes on, as explained in the comments to the first chunk of code below.
*''Linker script:'' When a hex file is compiled from a source, it contains information about where in program memory it should be written. By default it starts at address 0x00 and continues as far as it needs to go, but this would overwrite the bootloader. So you need something to tell MPLAB where in memory it ''can'' put code; this is done by a '''linker script'''. There's an example of one below.

'''All this code assumes you are using the HID bootloader found [[USB bootloading|here]].''' That bootloader takes up memory up to address 0x10FF (hexadecimal). User code starts at 0x1100. If you are using a bootloader that takes up a different amount of space, such as the CDC bootloader (which only takes up to 0x7FF), you will need to change some numbers. All mentions of numbers like 0x10FF, 0x1100, 0x1108, or 0x1118 will need to be replaced by numbers like 0x7FF, 0x800, 0x808, and 0x818 respectively.

==Vector Remapping==
This code goes at the top of your code, or in an include file, and accomplishes the first bullet point above. Note the functions where you should place your interrupt-handling code, if you have any!
<pre>//The following lengthy and involved incantation sets things up so that resets and interrupt
//handling operate as they should, given the presence of the bootloader.
//Omitting this incantation will make the code stop working.
//If you are generating absolutely no interrupts, you can probably leave out just the stuff
//referring to interrupts.
//Comments are by Microchip.

//On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
//the reset, high priority interrupt, and low priority interrupt
//vectors. However, the current Microchip USB bootloader
//examples are intended to occupy addresses 0x00-0x7FF or
//0x00-0xFFF depending on which bootloader is used. Therefore,
//the bootloader code remaps these vectors to new locations
//as indicated below. This remapping is only necessary if you
//wish to program the hex file generated from this project with
//the USB bootloader.
#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

//If the output hex file is not programmed with
//the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
//As a result, if an actual interrupt was enabled and occured, the PC would jump
//to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space). This
//executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
//(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup". This
//would effective reset the application.

//To fix this situation, we should always deliberately place a
//"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
//"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18. When the output
//hex file of this project is programmed with the bootloader, these sections do not
//get bootloaded (as they overlap the bootloader space). If the output hex file is not
//programmed using the bootloader, then the below goto instructions do get programmed,
//and the hex file still works like normal. The below section is only required to fix this
//scenario.
#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie fast", since this is in a #pragma interrupt section

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie", since this is in a #pragma interruptlow section

//End incantation</pre>

Here's a shorter version of the same thing, stripped of most explanatory comments:
<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void) { _asm goto _startup _endasm }

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void) { _asm goto YourHighPriorityISRCode _endasm }

#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void) { _asm goto YourLowPriorityISRCode _endasm }

#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void) { _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm }
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void) { _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm }

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode() {
//high priority interrupt code
}

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode() {
//low priority interrupt code
}

If you wish to use the CDC bootloader with MPLAB source code, you only need to change three lines of the above, where the REMAPPED_VECTOR_ADDRESS constants are defined:
#define REMAPPED_RESET_VECTOR_ADDRESS 0x800
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x808
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x818</pre>

==Linker Script==
Here is a sample linker script. Save it in a file with a ".lkr" extension and include it in your MPLAB project. All MPLAB projects have a linker script. Often it's just the default one provided by the C18 compiler, which this one replaces.
<pre>// Sample linker script for the PIC18F4550 processor

LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f4550.lib //change if you're not using the 4550

//non-bootloader lines:
CODEPAGE NAME=boot START=0x0 END=0x10FF PROTECTED //don't overwrite the bootloader
CODEPAGE NAME=vectors START=0x1100 END=0x1129 PROTECTED //put reset/interrupt vectors here
CODEPAGE NAME=page START=0x112A END=0x7FFF //code goes after bootloader

//the reset of these lines do something unrelated to the bootloader:
CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED
CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED
CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED
CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED

ACCESSBANK NAME=accessram START=0x0 END=0x5F
DATABANK NAME=gpr0 START=0x60 END=0xFF
DATABANK NAME=gpr1 START=0x100 END=0x1FF
DATABANK NAME=gpr2 START=0x200 END=0x2FF
DATABANK NAME=gpr3 START=0x300 END=0x3FF
DATABANK NAME=usb4 START=0x400 END=0x4FF PROTECTED
DATABANK NAME=usb5 START=0x500 END=0x5FF PROTECTED
DATABANK NAME=usb6 START=0x600 END=0x6FF PROTECTED
DATABANK NAME=usb7 START=0x700 END=0x7FF PROTECTED
ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF PROTECTED

SECTION NAME=CONFIG ROM=config

STACK SIZE=0x100 RAM=gpr3</pre>

Compiling for a bootloader in MPLAB

2009-06-11T13:01:47Z

Gregory McGlynn:

Compiling a program that will be loaded using a bootloader requires a lot of extra code in MPLAB. Basically this code is doing two things:
*''Vector remapping:'' Resets, high-priority interrupts, and low-priority interrupts usually make the PIC start executing code at addresses 0x00, 0x08, and 0x18 respectively. However, this is the domain of the bootloader, which is sitting in this first region of memory. So some "remapping" goes on, as explained in the comments to the first chunk of code below.
*''Linker script:'' When a hex file is compiled from a source, it contains information about where in program memory it should be written. By default it starts at address 0x00 and continues as far as it needs to go, but this would overwrite the bootloader. So you need something to tell MPLAB where in memory it ''can'' put code; this is done by a '''linker script'''. There's an example of one below.

'''All this code assumes you are using the HID bootloader found [[USB bootloading|here]].''' That bootloader takes up memory up to address 0x10FF (hexadecimal). User code starts at 0x1100. If you are using a bootloader that takes up a different amount of space, such as the CDC bootloader (which only takes up to 0x7FF), you will need to change some numbers. All mentions of numbers like 0x10FF, 0x1100, 0x1108, or 0x1118 will need to be replaced by numbers like 0x7FF, 0x800, 0x808, and 0x818 respectively.

==Vector Remapping==
This code goes at the top of your code, or in an include file, and accomplishes the first bullet point above. Note the functions where you should place your interrupt-handling code, if you have any!
<pre>//The following lengthy and involved incantation sets things up so that resets and interrupt
//handling operate as they should, given the presence of the bootloader.
//Omitting this incantation will make the code stop working.
//If you are generating absolutely no interrupts, you can probably leave out just the stuff
//referring to interrupts.
//Comments are by Microchip.

//On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
//the reset, high priority interrupt, and low priority interrupt
//vectors. However, the current Microchip USB bootloader
//examples are intended to occupy addresses 0x00-0x7FF or
//0x00-0xFFF depending on which bootloader is used. Therefore,
//the bootloader code remaps these vectors to new locations
//as indicated below. This remapping is only necessary if you
//wish to program the hex file generated from this project with
//the USB bootloader.
#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

//If the output hex file is not programmed with
//the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
//As a result, if an actual interrupt was enabled and occured, the PC would jump
//to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space). This
//executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
//(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup". This
//would effective reset the application.

//To fix this situation, we should always deliberately place a
//"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
//"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18. When the output
//hex file of this project is programmed with the bootloader, these sections do not
//get bootloaded (as they overlap the bootloader space). If the output hex file is not
//programmed using the bootloader, then the below goto instructions do get programmed,
//and the hex file still works like normal. The below section is only required to fix this
//scenario.
#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie fast", since this is in a #pragma interrupt section

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie", since this is in a #pragma interruptlow section

//End incantation</pre>

Here's a shorter version of the same thing, stripped of most explanatory comments:
<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void) { _asm goto _startup _endasm }

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void) { _asm goto YourHighPriorityISRCode _endasm }

#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void) { _asm goto YourLowPriorityISRCode _endasm }

#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void) { _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm }
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void) { _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm }

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode() {
//high priority interrupt code
}

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode() {
//low priority interrupt code
}

If you wish to use the CDC bootloader with MPLAB source code, you only need to change three lines of the above, where the REMAPPED_VECTOR_ADDRESS constants are defined:
#define REMAPPED_RESET_VECTOR_ADDRESS 0x800
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x808
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x818</pre>

==Linker Script==
Here is a sample linker script. Save it in a file with a ".lkr" extension and include it in your MPLAB project:
<pre>// Sample linker script for the PIC18F4550 processor

LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f4550.lib //change if you're not using the 4550

//non-bootloader lines:
CODEPAGE NAME=boot START=0x0 END=0x10FF PROTECTED //don't overwrite the bootloader
CODEPAGE NAME=vectors START=0x1100 END=0x1129 PROTECTED //put reset/interrupt vectors here
CODEPAGE NAME=page START=0x112A END=0x7FFF //code goes after bootloader

//the reset of these lines do something unrelated to the bootloader:
CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED
CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED
CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED
CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED

ACCESSBANK NAME=accessram START=0x0 END=0x5F
DATABANK NAME=gpr0 START=0x60 END=0xFF
DATABANK NAME=gpr1 START=0x100 END=0x1FF
DATABANK NAME=gpr2 START=0x200 END=0x2FF
DATABANK NAME=gpr3 START=0x300 END=0x3FF
DATABANK NAME=usb4 START=0x400 END=0x4FF PROTECTED
DATABANK NAME=usb5 START=0x500 END=0x5FF PROTECTED
DATABANK NAME=usb6 START=0x600 END=0x6FF PROTECTED
DATABANK NAME=usb7 START=0x700 END=0x7FF PROTECTED
ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF PROTECTED

SECTION NAME=CONFIG ROM=config

STACK SIZE=0x100 RAM=gpr3</pre>

Compiling for a bootloader in MPLAB

2009-06-11T13:01:06Z

Gregory McGlynn:

Compiling a program that will be loaded using a bootloader requires a lot of extra code in MPLAB. Basically this code is doing two things:
*Resets, high-priority interrupts, and low-priority interrupts usually make the PIC start executing code at addresses 0x00, 0x08, and 0x18 respectively. However, this is the domain of the bootloader, which is sitting in this first region of memory. So some "remapping" goes on, as explained in the comments to the first chunk of code below.
*When a hex file is compiled from a source, it contains information about where in program memory it should be written. By default it starts at address 0x00 and continues as far as it needs to go, but this would overwrite the bootloader. So you need something to tell MPLAB where in memory it ''can'' put code; this is done by a '''linker script'''. There's an example of one below.

'''All this code assumes you are using the HID bootloader found [[USB bootloading|here]].''' That bootloader takes up memory up to address 0x10FF (hexadecimal). User code starts at 0x1100. If you are using a bootloader that takes up a different amount of space, such as the CDC bootloader (which only takes up to 0x7FF), you will need to change some numbers. All mentions of numbers like 0x10FF, 0x1100, 0x1108, or 0x1118 will need to be replaced by numbers like 0x7FF, 0x800, 0x808, and 0x818 respectively.

==Vector Remapping==
This code goes at the top of your code, or in an include file, and accomplishes the first bullet point above. Note the functions where you should place your interrupt-handling code, if you have any!
<pre>//The following lengthy and involved incantation sets things up so that resets and interrupt
//handling operate as they should, given the presence of the bootloader.
//Omitting this incantation will make the code stop working.
//If you are generating absolutely no interrupts, you can probably leave out just the stuff
//referring to interrupts.
//Comments are by Microchip.

//On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
//the reset, high priority interrupt, and low priority interrupt
//vectors. However, the current Microchip USB bootloader
//examples are intended to occupy addresses 0x00-0x7FF or
//0x00-0xFFF depending on which bootloader is used. Therefore,
//the bootloader code remaps these vectors to new locations
//as indicated below. This remapping is only necessary if you
//wish to program the hex file generated from this project with
//the USB bootloader.
#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

//If the output hex file is not programmed with
//the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
//As a result, if an actual interrupt was enabled and occured, the PC would jump
//to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space). This
//executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
//(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup". This
//would effective reset the application.

//To fix this situation, we should always deliberately place a
//"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
//"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18. When the output
//hex file of this project is programmed with the bootloader, these sections do not
//get bootloaded (as they overlap the bootloader space). If the output hex file is not
//programmed using the bootloader, then the below goto instructions do get programmed,
//and the hex file still works like normal. The below section is only required to fix this
//scenario.
#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie fast", since this is in a #pragma interrupt section

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie", since this is in a #pragma interruptlow section

//End incantation</pre>

Here's a shorter version of the same thing, stripped of most explanatory comments:
<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void) { _asm goto _startup _endasm }

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void) { _asm goto YourHighPriorityISRCode _endasm }

#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void) { _asm goto YourLowPriorityISRCode _endasm }

#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void) { _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm }
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void) { _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm }

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode() {
//high priority interrupt code
}

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode() {
//low priority interrupt code
}

If you wish to use the CDC bootloader with MPLAB source code, you only need to change three lines of the above, where the REMAPPED_VECTOR_ADDRESS constants are defined:
#define REMAPPED_RESET_VECTOR_ADDRESS 0x800
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x808
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x818</pre>

==Linker Script==
Here is a sample linker script. Save it in a file with a ".lkr" extension and include it in your MPLAB project:
<pre>// Sample linker script for the PIC18F4550 processor

LIBPATH .

FILES c018i.o
FILES clib.lib
FILES p18f4550.lib //change if you're not using the 4550

//non-bootloader lines:
CODEPAGE NAME=boot START=0x0 END=0x10FF PROTECTED //don't overwrite the bootloader
CODEPAGE NAME=vectors START=0x1100 END=0x1129 PROTECTED //put reset/interrupt vectors here
CODEPAGE NAME=page START=0x112A END=0x7FFF //code goes after bootloader

//the reset of these lines do something unrelated to the bootloader:
CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED
CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED
CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED
CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED

ACCESSBANK NAME=accessram START=0x0 END=0x5F
DATABANK NAME=gpr0 START=0x60 END=0xFF
DATABANK NAME=gpr1 START=0x100 END=0x1FF
DATABANK NAME=gpr2 START=0x200 END=0x2FF
DATABANK NAME=gpr3 START=0x300 END=0x3FF
DATABANK NAME=usb4 START=0x400 END=0x4FF PROTECTED
DATABANK NAME=usb5 START=0x500 END=0x5FF PROTECTED
DATABANK NAME=usb6 START=0x600 END=0x6FF PROTECTED
DATABANK NAME=usb7 START=0x700 END=0x7FF PROTECTED
ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF PROTECTED

SECTION NAME=CONFIG ROM=config

STACK SIZE=0x100 RAM=gpr3</pre>

USB bootloading

2009-06-11T12:46:04Z

Gregory McGlynn:

'''This article assumes you are using Windows. The provided code is intended to be run on a [[PIC 18f4550|PIC18F4550 or 4553]] with a 20Mhz oscillator.'''

Bootloading allows you to reprogram your PIC without the need for an expensive hardware programmer like an ICD.

Bootloading works like this:
* You compile your program on the computer, which generates a file with a .hex extension. This is the compiled code for your program, which you want to get onto the PIC.
* You connect the PIC to the computer, in this case with a simple USB cable.
* You fire up a PC program that takes your hex file and sends it to the PIC.
* Sitting on the PIC there is a small program called a bootloader. It takes the hex file that is coming from the computer and writes it into memory.
* You reset the PIC, and your program starts running!

USB bootloading is bootloading over a USB cable. To do this you need to be working with a PIC that talks USB, like a [[PIC 18f4550]]. Then you need to have a bootloader on the PIC. The only way to put a bootloader in place is with a hardware programmer like an ICD, but you only need to do this once: afterwards, all you'll need is a regular USB cable. See [[USB communication with PC|here]] for how to connect a USB cable to a PIC.

'''Note: if you're going to load programs onto a PIC with a bootloader, you need to put some special instructions in the PIC code to make it work. See the "Compiling for a bootloader" section.'''

== CDC Bootloader ==

=== Loading the bootloader ===
Here is a USB bootloader hex file that works for the 18f4553 with a 20Mhz oscillator: [[Image:FW_B_20.hex]]. It comes from http://www.schmalzhaus.com/UBW , where you can find the source it was built from, if you're interested. The bootloader is a slightly modified version of one supplied by Microchip; the changes allow the compiled hex file to fit within the first 0x800 bytes program memory.
To load this precompiled hex file onto the PIC using the CCS ICD, use the icd.exe program in the C:\Program Files\PICC directory. Now the bootloader is itself loaded.

=== The PC software ===
There needs to be a program on the PC that sends your hex files to bootloader on the PIC. This bootloader uses a program from the Microchip USB Framework. You can download the framework installer [http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_Setup_v1.3.exe here]. It will create some folders in the C:\ directory. The loader program is at C:\MCHPFSUSB\Pc\Pdfsusb\PDFSUSB.exe.

=== Required circuitry ===
You need some sort of button or switch hooked up to pin RC2 so that it is normally high. If you reset the PIC and pin RC2 is high, the bootloader will run whatever program you've loaded onto it. But if RC2 is low, because you're pressing the button, the bootloader will run, allowing you to load a new program onto the PIC. You don't need to keep holding the button down, C2 just has to be low at the time the PIC resets. So whenever you want to put the PIC into bootloader mode, press and hold the reset button, then press your bootloading button, then release the reset button, then release the bootloading button. You can attach an LED to pin RC1 and the bootloader will flash it when it runs. These pins can be easily changed in the bootloader source code.

=== Installing Drivers ===
When you first connect the PIC to the PC and make the bootloader run, Windows will need to install a driver. Point it to "C:\MCHPFSUSB\Pc\MCHPUSB Driver\Release" and it will install the right driver. Now you're all set up.

=== Bootloading ===
Now that everything's set up, here are the steps to load your program onto your PIC:

* Compile your program with the two lines mentioned above.
* Fire up PDFSUSB.exe.
* Put your PIC into bootloading mode. You should now be able to select "PICDEM FS USB 0" from the PDFSUSB.exe drop-down list.
* Click "Load Hex File" and go find the hex file that you created when you compiled your program.
* Click "Program Device" to load your program.
* Reset your PIC and your program should run.

== HID Bootloader ==

A HID (Human Interface Device) bootloader has the advantage that it doesn't require any driver installation on the programming computer. Once the bootloader is programmed onto the PIC and the PIC is plugged into the PC, your computer should be able to handle the rest of the setup automatically. A HID bootloader is supplied with the [[Microchip USB Framework]]. This is a slightly modified version of the original HID bootloader project from Microchip. The original project is designed to fit within the first 0x1000 bytes of program memory, but due to changes in the compiler will no longer compile into that space; the modified version goes int he first 0x1100 bytes.

=== PIC software ===

You can download the PIC hex file here: [[Media:HID_Bootloader_PIC18_Non_J.hex]].

You can download the full MPLAB project for the PIC program here: [[Media:Mplab-usb-bootloader.zip]].

=== PC software ===

You can download the PC program here (it comes as part of the [[Microchip USB Framework]]): [[Media:HIDBootLoader.zip]]. Unzip the downloaded .zip file to get the HIDBootLoader.exe executable. Running this requires a sufficiently recent version of the .NET Framework, which you may not have if you are running XP or earlier versions of Windows. You can download a sufficiently recent version here (the install takes a while): [http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en .NET Framework download].

When the program is running it should automatically detect when you attach the PIC (if the PIC has been properly programmed). To program the PIC click "Open Hex File," and browse your compiled hex file. Then click "Program/Verify" and the bootloader should, after a few seconds, report that it has successfully erase, programmed, and verified the PIC. After that you can reset the PIC and it should run your program.

=== Required circuitry ===
Like the CDC bootloader, you must have a button wired up to indicate when the PIC should start up in bootloader mode. This bootloader looks at pin RC4; if RC4 is low on reset, the bootloader starts, otherwise the user program starts. The bootloader will use pins D0 and D1 to indicate connection state: leds hooked up to these pins will flash alternately when the connection has been established with the PC. Again, these pins can easily be changed in the bootloader source code.

Note that the first time you plug the PIC into the PC and start it up in bootloader mode, it will take a few seconds for the PC to initialize everything before the lights start flashing, but after that the process should be pretty fast.

== Compiling for a bootloader ==
A bootloader takes up part of the available program memory, and you need to take this into account when you write your program. Generally, the bootloader takes up a small chunk of memory at the beginning of space available for program memory. You need to tell the compiler to place your code just after the bootloader (rather than overwriting it). The CDC bootloader takes up the memory from 0x000 to 0x7FF (the first two kilobytes of program memory), while the HID bootloader goes from 0x0000 to 0x10FF (these are hexadecimal numbers). Your program therefore needs to start at address 0x800 or 0x1100, depending on which bootloader you're using, and not touch the memory from 0x000 to 0x7FF.

With CCS you can accomplish this by adding the following two lines at the top of your code:

'''CDC bootloader with CCS:'''
<pre>#build (reset=0x800, interrupt=0x808) //code starts right after the bootloader
#org 0, 0x7FF {} //don't overwrite the bootloader</pre>

'''HID bootloader with CCS:'''
<pre>#build (reset=0x1100, interrupt=0x1108) //code starts right after the bootloader
#org 0, 0x10FF {} //don't overwrite the bootloader</pre>

With MPLAB/C18 the required code is a bit longer. So as not to clutter up this page, it's on a separate one: see [[Compiling for a bootloader in MPLAB]].

'''HID bootloader with MPLAB:'''
<pre>//The following lengthy and involved incantation sets things up so that resets and interrupt
//handling operate as they should, given the presence of the bootloader.
//Omitting this incantation will make the code stop working.
//If you are generating absolutely no interrupts, you can probably leave out just the stuff
//referring to interrupts.
//Comments are by Microchip.

//On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
//the reset, high priority interrupt, and low priority interrupt
//vectors. However, the current Microchip USB bootloader
//examples are intended to occupy addresses 0x00-0x7FF or
//0x00-0xFFF depending on which bootloader is used. Therefore,
//the bootloader code remaps these vectors to new locations
//as indicated below. This remapping is only necessary if you
//wish to program the hex file generated from this project with
//the USB bootloader.
#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

//If the output hex file is not programmed with
//the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
//As a result, if an actual interrupt was enabled and occured, the PC would jump
//to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space). This
//executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
//(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup". This
//would effective reset the application.

//To fix this situation, we should always deliberately place a
//"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
//"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18. When the output
//hex file of this project is programmed with the bootloader, these sections do not
//get bootloaded (as they overlap the bootloader space). If the output hex file is not
//programmed using the bootloader, then the below goto instructions do get programmed,
//and the hex file still works like normal. The below section is only required to fix this
//scenario.
#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie fast", since this is in a #pragma interrupt section

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie", since this is in a #pragma interruptlow section

//End incantation</pre>

Here's a shorter version of the same thing, stripped of most explanatory comments:
<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void) { _asm goto _startup _endasm }

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void) { _asm goto YourHighPriorityISRCode _endasm }

#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void) { _asm goto YourLowPriorityISRCode _endasm }

#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void) { _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm }
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void) { _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm }

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode() {
//high priority interrupt code
}

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode() {
//low priority interrupt code
}</pre>

If you wish to use the CDC bootloader with MPLAB source code, you only need to change three lines of the above, where the REMAPPED_VECTOR_ADDRESS constants are defined:

<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x800
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x808
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x818
</pre>

== See also ==
[[USB communication with PC]]

[[Wireless PIC bootloading]]

File:Mplab-usb-bootloader.zip

2009-06-11T12:43:15Z

Gregory McGlynn:

File:HID Bootloader PIC18 Non J.hex

2009-06-11T12:41:43Z

Gregory McGlynn:

USB bootloading

2009-06-11T12:40:36Z

Gregory McGlynn:

'''This article assumes you are using Windows. The provided code is intended to be run on a [[PIC 18f4550|PIC18F4550 or 4553]] with a 20Mhz oscillator.'''

Bootloading allows you to reprogram your PIC without the need for an expensive hardware programmer like an ICD.

Bootloading works like this:
* You compile your program on the computer, which generates a file with a .hex extension. This is the compiled code for your program, which you want to get onto the PIC.
* You connect the PIC to the computer, in this case with a simple USB cable.
* You fire up a PC program that takes your hex file and sends it to the PIC.
* Sitting on the PIC there is a small program called a bootloader. It takes the hex file that is coming from the computer and writes it into memory.
* You reset the PIC, and your program starts running!

USB bootloading is bootloading over a USB cable. To do this you need to be working with a PIC that talks USB, like a [[PIC 18f4550]]. Then you need to have a bootloader on the PIC. The only way to put a bootloader in place is with a hardware programmer like an ICD, but you only need to do this once: afterwards, all you'll need is a regular USB cable. See [[USB communication with PC|here]] for how to connect a USB cable to a PIC.

'''Note: if you're going to load programs onto a PIC with a bootloader, you need to put some special instructions in the PIC code to make it work. See the "Compiling for a bootloader" section.'''

== CDC Bootloader ==

=== Loading the bootloader ===
Here is a USB bootloader hex file that works for the 18f4553 with a 20Mhz oscillator: [[Image:FW_B_20.hex]]. It comes from http://www.schmalzhaus.com/UBW , where you can find the source it was built from, if you're interested. The bootloader is a slightly modified version of one supplied by Microchip; the changes allow the compiled hex file to fit within the first 0x800 bytes program memory.
To load this precompiled hex file onto the PIC using the CCS ICD, use the icd.exe program in the C:\Program Files\PICC directory. Now the bootloader is itself loaded.

=== The PC software ===
There needs to be a program on the PC that sends your hex files to bootloader on the PIC. This bootloader uses a program from the Microchip USB Framework. You can download the framework installer [http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_Setup_v1.3.exe here]. It will create some folders in the C:\ directory. The loader program is at C:\MCHPFSUSB\Pc\Pdfsusb\PDFSUSB.exe.

=== Required circuitry ===
You need some sort of button or switch hooked up to pin RC2 so that it is normally high. If you reset the PIC and pin RC2 is high, the bootloader will run whatever program you've loaded onto it. But if RC2 is low, because you're pressing the button, the bootloader will run, allowing you to load a new program onto the PIC. You don't need to keep holding the button down, C2 just has to be low at the time the PIC resets. So whenever you want to put the PIC into bootloader mode, press and hold the reset button, then press your bootloading button, then release the reset button, then release the bootloading button. You can attach an LED to pin RC1 and the bootloader will flash it when it runs. These pins can be easily changed in the bootloader source code.

=== Installing Drivers ===
When you first connect the PIC to the PC and make the bootloader run, Windows will need to install a driver. Point it to "C:\MCHPFSUSB\Pc\MCHPUSB Driver\Release" and it will install the right driver. Now you're all set up.

=== Bootloading ===
Now that everything's set up, here are the steps to load your program onto your PIC:

* Compile your program with the two lines mentioned above.
* Fire up PDFSUSB.exe.
* Put your PIC into bootloading mode. You should now be able to select "PICDEM FS USB 0" from the PDFSUSB.exe drop-down list.
* Click "Load Hex File" and go find the hex file that you created when you compiled your program.
* Click "Program Device" to load your program.
* Reset your PIC and your program should run.

== HID Bootloader ==

A HID (Human Interface Device) bootloader has the advantage that it doesn't require any driver installation on the programming computer. Once the bootloader is programmed onto the PIC and the PIC is plugged into the PC, your computer should be able to handle the rest of the setup automatically. A HID bootloader is supplied with the [[Microchip USB Framework]]. This is a slightly modified version of the original HID bootloader project from Microchip. The original project is designed to fit within the first 0x1000 bytes of program memory, but due to changes in the compiler will no longer compile into that space; the modified version goes int he first 0x1100 bytes.

=== PIC software ===

You can download the PIC hex file here.
You can download the full MPLAB project for the PIC program here.

=== PC software ===

You can download the PC program here (it comes as part of the [[Microchip USB Framework]]): [[Media:HIDBootLoader.zip]]. Unzip the downloaded .zip file to get the HIDBootLoader.exe executable. Running this requires a sufficiently recent version of the .NET Framework, which you may not have if you are running XP or earlier versions of Windows. You can download a sufficiently recent version here (the install takes a while): [http://www.microsoft.com/downloads/details.aspx?FamilyId=333325FD-AE52-4E35-B531-508D977D32A6&displaylang=en .NET Framework download].

When the program is running it should automatically detect when you attach the PIC (if the PIC has been properly programmed). To program the PIC click "Open Hex File," and browse your compiled hex file. Then click "Program/Verify" and the bootloader should, after a few seconds, report that it has successfully erase, programmed, and verified the PIC. After that you can reset the PIC and it should run your program.

=== Required circuitry ===
Like the CDC bootloader, you must have a button wired up to indicate when the PIC should start up in bootloader mode. This bootloader looks at pin RC4; if RC4 is low on reset, the bootloader starts, otherwise the user program starts. The bootloader will use pins D0 and D1 to indicate connection state: leds hooked up to these pins will flash alternately when the connection has been established with the PC. Again, these pins can easily be changed in the bootloader source code.

Note that the first time you plug the PIC into the PC and start it up in bootloader mode, it will take a few seconds for the PC to initialize everything before the lights start flashing, but after that the process should be pretty fast.

== Compiling for a bootloader ==
A bootloader takes up part of the available program memory, and you need to take this into account when you write your program. Generally, the bootloader takes up a small chunk of memory at the beginning of space available for program memory. You need to tell the compiler to place your code just after the bootloader (rather than overwriting it). The CDC bootloader takes up the memory from 0x000 to 0x7FF (the first two kilobytes of program memory), while the HID bootloader goes from 0x0000 to 0x10FF (these are hexadecimal numbers). Your program therefore needs to start at address 0x800 or 0x1100, depending on which bootloader you're using, and not touch the memory from 0x000 to 0x7FF.

With CCS you can accomplish this by adding the following two lines at the top of your code:

'''CDC bootloader with CCS:'''
<pre>#build (reset=0x800, interrupt=0x808) //code starts right after the bootloader
#org 0, 0x7FF {} //don't overwrite the bootloader</pre>

'''HID bootloader with CCS:'''
<pre>#build (reset=0x1100, interrupt=0x1108) //code starts right after the bootloader
#org 0, 0x10FF {} //don't overwrite the bootloader</pre>

With MPLAB/C18 the required code is a bit longer:

'''HID bootloader with MPLAB:'''
<pre>//The following lengthy and involved incantation sets things up so that resets and interrupt
//handling operate as they should, given the presence of the bootloader.
//Omitting this incantation will make the code stop working.
//If you are generating absolutely no interrupts, you can probably leave out just the stuff
//referring to interrupts.
//Comments are by Microchip.

//On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
//the reset, high priority interrupt, and low priority interrupt
//vectors. However, the current Microchip USB bootloader
//examples are intended to occupy addresses 0x00-0x7FF or
//0x00-0xFFF depending on which bootloader is used. Therefore,
//the bootloader code remaps these vectors to new locations
//as indicated below. This remapping is only necessary if you
//wish to program the hex file generated from this project with
//the USB bootloader.
#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

//If the output hex file is not programmed with
//the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
//As a result, if an actual interrupt was enabled and occured, the PC would jump
//to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space). This
//executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
//(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup". This
//would effective reset the application.

//To fix this situation, we should always deliberately place a
//"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
//"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18. When the output
//hex file of this project is programmed with the bootloader, these sections do not
//get bootloaded (as they overlap the bootloader space). If the output hex file is not
//programmed using the bootloader, then the below goto instructions do get programmed,
//and the hex file still works like normal. The below section is only required to fix this
//scenario.
#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie fast", since this is in a #pragma interrupt section

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie", since this is in a #pragma interruptlow section

//End incantation</pre>

Here's a shorter version of the same thing, stripped of most explanatory comments:
<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void) { _asm goto _startup _endasm }

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void) { _asm goto YourHighPriorityISRCode _endasm }

#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void) { _asm goto YourLowPriorityISRCode _endasm }

#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void) { _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm }
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void) { _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm }

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode() {
//high priority interrupt code
}

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode() {
//low priority interrupt code
}</pre>

If you wish to use the CDC bootloader with MPLAB source code, you only need to change three lines of the above, where the REMAPPED_VECTOR_ADDRESS constants are defined:

<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x800
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x808
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x818
</pre>

== See also ==
[[USB communication with PC]]

[[Wireless PIC bootloading]]

File:HIDBootLoader.zip

2009-06-11T12:35:26Z

Gregory McGlynn: Unzip this to obtain HIDBootLoader.exe, the bootloader executable. This is a Windows program and requires a sufficiently recent version of the .NET Framework to run. If you are running XP you may need to download and install a newer version; see the [[USB

Unzip this to obtain HIDBootLoader.exe, the bootloader executable. This is a Windows program and requires a sufficiently recent version of the .NET Framework to run. If you are running XP you may need to download and install a newer version; see the [[USB Bootloading]] page.

USB communication with C18 and MPLAB

2009-06-11T12:26:37Z

Gregory McGlynn:

Microchip publishes a USB Framework that consists of a number of files that contain code to handle the tedious parts of USB communication, with a few spots where user code can be included to build USB programs.

When using the Microchip USB Framework, programs can operate in two modes: polling or interrupt. This choice comes from the fact that USB devices must continually monitor the connection to the host, looking for incoming data and handling the sending of data in the output queue. There are two ways to accomplish this: the program can either explicitly call a function periodically to handle USB tasks, or this can be done by a regularly scheduled interrupt.

The framework provides two slots in which user code can be placed: the functions UserInit and ProcessIO. UserInit is called once at the beginning of the program to allow you to do some initialization. ProcessIO is called in a loop; each iteration should be very short and must be non-blocking, if you are using the polling structure.

Below is an example program using the polling structure, showing just the UserInit and ProcessIO functions. You can download the full MPLAB project here. Note: this MPLAB project is configured to work with the [[USB Bootloading|USB HID bootloader]]. Using it without a bootloader or with another bootloader will require changes.

PIC USB

2009-06-11T12:19:14Z

Gregory McGlynn:

During the spring quarter of 2009, Greg McGlynn worked on USB communication and bootloading with PICs as a 399 project with professors Lynch and Peshkin.

== Project Documentation ==
[[PIC 18f4550]] -- only certain PICs are USB-capable, and the 18F4550 is probably the simplest one to transition to from the 4520.

[[USB communication with PC]] -- including example code for both the CCS and C18 compilers.

* [[USB communication with CCS]]
* [[USB communication with C18 and MPLAB]]

[[USB Bootloading]] -- loading programs onto PICs using just a simple USB cable as opposed to an ICD or other programmer.

[[USB communication between PICs]] -- requires a more powerful PIC than the 4550.

[[Microchip USB Framework]] -- A collection of example MPLAB/C18 USB projects, published by Microchip.

=== See Also ===

[[PIC_Microcontrollers_with_C18_Compiler]]

USB communication with PC

2009-06-11T12:16:45Z

Gregory McGlynn:

Some PIC models have built-in USB transceivers that make it simple to connect the PIC to a computer via USB. One such PIC is the [[PIC 18f4550]], which is similar to the 18f4520 in almost all respects, except that it has hardware support for USB built into it. The 18f4550 will work just fine in one of the [[4520_Board_intro|PIC protoboards]].

USB software for the PC tends to be OS-specific. '''This article currently assumes you're running Windows.'''

== The USB protocol ==
USB is a pretty complex protocol with a long specification, but it's not necessary to understand every part of it to use it. It's enough to know what wires to hook up and what software libraries to include in your code.

Wikipedia has a detailed and informative [http://en.wikipedia.org/wiki/Usb page on USB].

=== Connectors ===
USB connectors have four leads; the pictures on Wikipedia show which is which on standard connectors.
* +5V: the host (computer) provides up to 500mA of current at 5V that you can use for power. If your PIC is self-powered, though, make sure you don't connect the two +5V sources or bad things may happen.
* GND: ground; make sure you do connect this to your PIC's ground.
* D+ and D-: data is transmitted on these lines. The exact protocol is complicated and you probably don't need to know the details.

== USB with the PIC 18F4550 ==
=== Hardware ===
On the 18f4550, the D+ line connects to pin RC5 and the D- line to pin RC4. The ground line of course connects to ground.

Additionally pin 18, called Vusb, should have a capacitor to ground. Try 220 or 470nF.

=== Software ===
On the software side you have some choices. Probably the simplest thing to do is use a preexisting software library that makes the USB connection look like an [[PIC RS232|RS232 connection]]. The CCS compiler has a CDC library that provides functions like ''usb_cdc_getc'' or ''usb_cdc_putc'' that work over USB exactly like regular ''getc'' and ''putc'' work over RS232. CCS also provides a Windows driver for the PC that creates a virtual COM port that you can open in Matlab, Hyperterminal, or any other RS232-capable program and use to talk to the PIC. See [[USB communication with CCS]].

Microchip provides a USB framework that works with its C18 compiler and its MPLAB development environment. See [[USB communication with C18 and MPLAB]].

CCS also has an example where the PIC registers itself as a Human Interface Device (HID). USB mice and keyboards use HID. The advantage of this is that doesn't require the user to install a special driver. The disadvantages are (a) the connection doesn't look like a simple RS232 link and (b) bandwidth is limited. A HID can only send messages to the computer once every millisecond, and can only send 64 bytes in each message, so the maximum data transfer rate is 64K bytes/second. In theory, USB can go up to 12M bits/second, so HID is fairly slow in comparison.

Microchip provides a USB framework for use with its [[PIC Microcontrollers with C18 Compiler|C18 compiler]].

It's also possible to create one's own setup from scratch or by modifying a preexisting library. This probably takes some effort.

== See also ==
[[USB Bootloading]]

PIC USB

2009-06-11T12:15:29Z

Gregory McGlynn:

During the spring quarter of 2009, Greg McGlynn worked on USB communication and bootloading with PICs as a 399 project with professors Lynch and Peshkin.

== Project Documentation ==
[[PIC 18f4550]] -- only certain PICs are USB-capable, and the 18F4550 is probably the simplest one to transition to from the 4520.

[[USB communication with PC]] -- including example code for both the CCS and C18 compilers.

[[USB Bootloading]] -- loading programs onto PICs using just a simple USB cable as opposed to an ICD or other programmer.

[[USB communication between PICs]] -- requires a more powerful PIC than the 4550.

[[Microchip USB Framework]] -- A collection of example MPLAB/C18 USB projects.

USB bootloading

2009-06-07T14:40:13Z

Gregory McGlynn:

'''This article assumes you are using Windows. The provided code is intended to be run on a [[PIC 18f4550|PIC18F4550 or 4553]] with a 20Mhz oscillator.'''

Bootloading allows you to reprogram your PIC without the need for an expensive hardware programmer like an ICD.

Bootloading works like this:
* You compile your program on the computer, which generates a file with a .hex extension. This is the compiled code for your program, which you want to get onto the PIC.
* You connect the PIC to the computer, in this case with a simple USB cable.
* You fire up a PC program that takes your hex file and sends it to the PIC.
* Sitting on the PIC there is a small program called a bootloader. It takes the hex file that is coming from the computer and writes it into memory.
* You reset the PIC, and your program starts running!

USB bootloading is bootloading over a USB cable. To do this you need to be working with a PIC that talks USB, like a [[PIC 18f4550]]. Then you need to have a bootloader on the PIC. The only way to put a bootloader in place is with a hardware programmer like an ICD, but you only need to do this once: afterwards, all you'll need is a regular USB cable. See [[USB communication with PC|here]] for how to connect a USB cable to a PIC.

'''Note: if you're going to load programs onto a PIC with a bootloader, you need to put some special instructions in the PIC code to make it work. See the "Compiling for a bootloader" section.'''

== CDC Bootloader ==

=== Loading the bootloader ===
Here is a USB bootloader hex file that works for the 18f4553 with a 20Mhz oscillator: [[Image:FW_B_20.hex]]. It comes from http://www.schmalzhaus.com/UBW , where you can find the source it was built from, if you're interested. The bootloader is a slightly modified version of one supplied by Microchip; the changes allow the compiled hex file to fit within the first 0x800 bytes program memory.
To load this precompiled hex file onto the PIC using the CCS ICD, use the icd.exe program in the C:\Program Files\PICC directory. Now the bootloader is itself loaded.

=== The PC software ===
There needs to be a program on the PC that sends your hex files to bootloader on the PIC. This bootloader uses a program from the Microchip USB Framework. You can download the framework installer [http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_Setup_v1.3.exe here]. It will create some folders in the C:\ directory. The loader program is at C:\MCHPFSUSB\Pc\Pdfsusb\PDFSUSB.exe.

=== Required circuitry ===
You need some sort of button or switch hooked up to pin RC2 so that it is normally high. If you reset the PIC and pin RC2 is high, the bootloader will run whatever program you've loaded onto it. But if RC2 is low, because you're pressing the button, the bootloader will run, allowing you to load a new program onto the PIC. You don't need to keep holding the button down, C2 just has to be low at the time the PIC resets. So whenever you want to put the PIC into bootloader mode, press and hold the reset button, then press your bootloading button, then release the reset button, then release the bootloading button. You can attach an LED to pin RC1 and the bootloader will flash it when it runs. These pins can be easily changed in the bootloader source code.

=== Installing Drivers ===
When you first connect the PIC to the PC and make the bootloader run, Windows will need to install a driver. Point it to "C:\MCHPFSUSB\Pc\MCHPUSB Driver\Release" and it will install the right driver. Now you're all set up.

=== Bootloading ===
Now that everything's set up, here are the steps to load your program onto your PIC:

* Compile your program with the two lines mentioned above.
* Fire up PDFSUSB.exe.
* Put your PIC into bootloading mode. You should now be able to select "PICDEM FS USB 0" from the PDFSUSB.exe drop-down list.
* Click "Load Hex File" and go find the hex file that you created when you compiled your program.
* Click "Program Device" to load your program.
* Reset your PIC and your program should run.

== HID Bootloader ==

A HID (Human Interface Device) bootloader has the advantage that it doesn't require any driver installation on the programming computer. Once the bootloader is programmed onto the PIC and the PIC is plugged into the PC, your computer should be able to handle the rest of the setup automatically. A HID bootloader is supplied with the [[Microchip USB Framework]]. This is a slightly modified version of the original HID bootloader project from Microchip. The original project is designed to fit within the first 0x1000 bytes of program memory, but due to changes in the compiler will no longer compile into that space; the modified version goes int he first 0x1100 bytes.

=== PIC software ===

You can download the PIC hex file here.
You can download the full MPLAB project for the PIC program here.

=== PC software ===

You can download the PC program here. It also comes as part of the [[Microchip USB Framework]]. When the program is running it should automatically detect when you attach the PIC (if the PIC has been properly programmed). To program the PIC click "Open Hex File," and browse your compiled hex file. Then click "Program/Verify" and the bootloader should, after a few seconds, report that it has successfully erase, programmed, and verified the PIC. After that you can reset the PIC and it should run your program.

=== Required circuitry ===
Like the CDC bootloader, you must have a button wired up to indicate when the PIC should start up in bootloader mode. This bootloader looks at pin RC4; if RC4 is low on reset, the bootloader starts, otherwise the user program starts. The bootloader will use pins D0 and D1 to indicate connection state: leds hooked up to these pins will flash alternately when the connection has been established with the PC. Again, these pins can easily be changed in the bootloader source code.

Note that the first time you plug the PIC into the PC and start it up in bootloader mode, it will take a few seconds for the PC to initialize everything before the lights start flashing, but after that the process should be pretty fast.

== Compiling for a bootloader ==
A bootloader takes up part of the available program memory, and you need to take this into account when you write your program. Generally, the bootloader takes up a small chunk of memory at the beginning of space available for program memory. You need to tell the compiler to place your code just after the bootloader (rather than overwriting it). The CDC bootloader takes up the memory from 0x000 to 0x7FF (the first two kilobytes of program memory), while the HID bootloader goes from 0x0000 to 0x10FF (these are hexadecimal numbers). Your program therefore needs to start at address 0x800 or 0x1100, depending on which bootloader you're using, and not touch the memory from 0x000 to 0x7FF.

With CCS you can accomplish this by adding the following two lines at the top of your code:

'''CDC bootloader with CCS:'''
<pre>#build (reset=0x800, interrupt=0x808) //code starts right after the bootloader
#org 0, 0x7FF {} //don't overwrite the bootloader</pre>

'''HID bootloader with CCS:'''
<pre>#build (reset=0x1100, interrupt=0x1108) //code starts right after the bootloader
#org 0, 0x10FF {} //don't overwrite the bootloader</pre>

With MPLAB/C18 the required code is a bit longer:

'''HID bootloader with MPLAB:'''
<pre>//The following lengthy and involved incantation sets things up so that resets and interrupt
//handling operate as they should, given the presence of the bootloader.
//Omitting this incantation will make the code stop working.
//If you are generating absolutely no interrupts, you can probably leave out just the stuff
//referring to interrupts.
//Comments are by Microchip.

//On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
//the reset, high priority interrupt, and low priority interrupt
//vectors. However, the current Microchip USB bootloader
//examples are intended to occupy addresses 0x00-0x7FF or
//0x00-0xFFF depending on which bootloader is used. Therefore,
//the bootloader code remaps these vectors to new locations
//as indicated below. This remapping is only necessary if you
//wish to program the hex file generated from this project with
//the USB bootloader.
#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

//If the output hex file is not programmed with
//the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
//As a result, if an actual interrupt was enabled and occured, the PC would jump
//to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space). This
//executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
//(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup". This
//would effective reset the application.

//To fix this situation, we should always deliberately place a
//"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
//"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18. When the output
//hex file of this project is programmed with the bootloader, these sections do not
//get bootloaded (as they overlap the bootloader space). If the output hex file is not
//programmed using the bootloader, then the below goto instructions do get programmed,
//and the hex file still works like normal. The below section is only required to fix this
//scenario.
#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie fast", since this is in a #pragma interrupt section

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie", since this is in a #pragma interruptlow section

//End incantation</pre>

Here's a shorter version of the same thing, stripped of most explanatory comments:
<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void) { _asm goto _startup _endasm }

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void) { _asm goto YourHighPriorityISRCode _endasm }

#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void) { _asm goto YourLowPriorityISRCode _endasm }

#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void) { _asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm }
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void) { _asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm }

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode() {
//high priority interrupt code
}

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode() {
//low priority interrupt code
}</pre>

If you wish to use the CDC bootloader with MPLAB source code, you only need to change three lines of the above, where the REMAPPED_VECTOR_ADDRESS constants are defined:

<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x800
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x808
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x818
</pre>

== See also ==
[[USB communication with PC]]

[[Wireless PIC bootloading]]

USB bootloading

2009-06-07T14:36:48Z

Gregory McGlynn: /* Compiling for a bootloader */

'''This article assumes you are using Windows. The provided code is intended to be run on a [[PIC 18f4550|PIC18F4550 or 4553]] with a 20Mhz oscillator.'''

Bootloading allows you to reprogram your PIC without the need for an expensive hardware programmer like an ICD.

Bootloading works like this:
* You compile your program on the computer, which generates a file with a .hex extension. This is the compiled code for your program, which you want to get onto the PIC.
* You connect the PIC to the computer, in this case with a simple USB cable.
* You fire up a PC program that takes your hex file and sends it to the PIC.
* Sitting on the PIC there is a small program called a bootloader. It takes the hex file that is coming from the computer and writes it into memory.
* You reset the PIC, and your program starts running!

USB bootloading is bootloading over a USB cable. To do this you need to be working with a PIC that talks USB, like a [[PIC 18f4550]]. Then you need to have a bootloader on the PIC. The only way to put a bootloader in place is with a hardware programmer like an ICD, but you only need to do this once: afterwards, all you'll need is a regular USB cable. See [[USB communication with PC|here]] for how to connect a USB cable to a PIC.

'''Note: if you're going to load programs onto a PIC with a bootloader, you need to put some special instructions in the PIC code to make it work. See the "Compiling for a bootloader" section.'''

== CDC Bootloader ==

=== Loading the bootloader ===
Here is a USB bootloader hex file that works for the 18f4553 with a 20Mhz oscillator: [[Image:FW_B_20.hex]]. It comes from http://www.schmalzhaus.com/UBW , where you can find the source it was built from, if you're interested. The bootloader is a slightly modified version of one supplied by Microchip; the changes allow the compiled hex file to fit within the first 0x800 bytes program memory.
To load this precompiled hex file onto the PIC using the CCS ICD, use the icd.exe program in the C:\Program Files\PICC directory. Now the bootloader is itself loaded.

=== The PC software ===
There needs to be a program on the PC that sends your hex files to bootloader on the PIC. This bootloader uses a program from the Microchip USB Framework. You can download the framework installer [http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_Setup_v1.3.exe here]. It will create some folders in the C:\ directory. The loader program is at C:\MCHPFSUSB\Pc\Pdfsusb\PDFSUSB.exe.

=== Required circuitry ===
You need some sort of button or switch hooked up to pin RC2 so that it is normally high. If you reset the PIC and pin RC2 is high, the bootloader will run whatever program you've loaded onto it. But if RC2 is low, because you're pressing the button, the bootloader will run, allowing you to load a new program onto the PIC. You don't need to keep holding the button down, C2 just has to be low at the time the PIC resets. So whenever you want to put the PIC into bootloader mode, press and hold the reset button, then press your bootloading button, then release the reset button, then release the bootloading button. You can attach an LED to pin RC1 and the bootloader will flash it when it runs. These pins can be easily changed in the bootloader source code.

=== Installing Drivers ===
When you first connect the PIC to the PC and make the bootloader run, Windows will need to install a driver. Point it to "C:\MCHPFSUSB\Pc\MCHPUSB Driver\Release" and it will install the right driver. Now you're all set up.

=== Bootloading ===
Now that everything's set up, here are the steps to load your program onto your PIC:

* Compile your program with the two lines mentioned above.
* Fire up PDFSUSB.exe.
* Put your PIC into bootloading mode. You should now be able to select "PICDEM FS USB 0" from the PDFSUSB.exe drop-down list.
* Click "Load Hex File" and go find the hex file that you created when you compiled your program.
* Click "Program Device" to load your program.
* Reset your PIC and your program should run.

== HID Bootloader ==

A HID (Human Interface Device) bootloader has the advantage that it doesn't require any driver installation on the programming computer. Once the bootloader is programmed onto the PIC and the PIC is plugged into the PC, your computer should be able to handle the rest of the setup automatically. A HID bootloader is supplied with the [[Microchip USB Framework]]. This is a slightly modified version of the original HID bootloader project from Microchip. The original project is designed to fit within the first 0x1000 bytes of program memory, but due to changes in the compiler will no longer compile into that space; the modified version goes int he first 0x1100 bytes.

=== PIC software ===

You can download the PIC hex file here.
You can download the full MPLAB project for the PIC program here.

=== PC software ===

You can download the PC program here. It also comes as part of the [[Microchip USB Framework]]. When the program is running it should automatically detect when you attach the PIC (if the PIC has been properly programmed). To program the PIC click "Open Hex File," and browse your compiled hex file. Then click "Program/Verify" and the bootloader should, after a few seconds, report that it has successfully erase, programmed, and verified the PIC. After that you can reset the PIC and it should run your program.

=== Required circuitry ===
Like the CDC bootloader, you must have a button wired up to indicate when the PIC should start up in bootloader mode. This bootloader looks at pin RC4; if RC4 is low on reset, the bootloader starts, otherwise the user program starts. The bootloader will use pins D0 and D1 to indicate connection state: leds hooked up to these pins will flash alternately when the connection has been established with the PC. Again, these pins can easily be changed in the bootloader source code.

Note that the first time you plug the PIC into the PC and start it up in bootloader mode, it will take a few seconds for the PC to initialize everything before the lights start flashing, but after that the process should be pretty fast.

== Compiling for a bootloader ==
A bootloader takes up part of the available program memory, and you need to take this into account when you write your program. Generally, the bootloader takes up a small chunk of memory at the beginning of space available for program memory. You need to tell the compiler to place your code just after the bootloader (rather than overwriting it). The CDC bootloader takes up the memory from 0x000 to 0x7FF (the first two kilobytes of program memory), while the HID bootloader goes from 0x0000 to 0x10FF (these are hexadecimal numbers). Your program therefore needs to start at address 0x800 or 0x1100, depending on which bootloader you're using, and not touch the memory from 0x000 to 0x7FF.

With CCS you can accomplish this by adding the following two lines at the top of your code:

'''CDC bootloader with CCS:'''
<pre>#build (reset=0x800, interrupt=0x808) //code starts right after the bootloader
#org 0, 0x7FF {} //don't overwrite the bootloader</pre>

'''HID bootloader with CCS:'''
<pre>#build (reset=0x1100, interrupt=0x1108) //code starts right after the bootloader
#org 0, 0x10FF {} //don't overwrite the bootloader</pre>

With MPLAB/C18 the required code is a bit longer:

'''HID bootloader with MPLAB:'''
<pre>//The following lengthy and involved incantation sets things up so that resets and interrupt
//handling operate as they should, given the presence of the bootloader.
//Omitting this incantation will make the code stop working.
//If you are generating absolutely no interrupts, you can probably leave out just the stuff
//referring to interrupts.
//Comments are by Microchip.

//On PIC18 devices, addresses 0x00, 0x08, and 0x18 are used for
//the reset, high priority interrupt, and low priority interrupt
//vectors. However, the current Microchip USB bootloader
//examples are intended to occupy addresses 0x00-0x7FF or
//0x00-0xFFF depending on which bootloader is used. Therefore,
//the bootloader code remaps these vectors to new locations
//as indicated below. This remapping is only necessary if you
//wish to program the hex file generated from this project with
//the USB bootloader.
#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

//If the output hex file is not programmed with
//the bootloader, addresses 0x08 and 0x18 would end up programmed with 0xFFFF.
//As a result, if an actual interrupt was enabled and occured, the PC would jump
//to 0x08 (or 0x18) and would begin executing "0xFFFF" (unprogrammed space). This
//executes as nop instructions, but the PC would eventually reach the REMAPPED_RESET_VECTOR_ADDRESS
//(0x1000 or 0x800, depending upon bootloader), and would execute the "goto _startup". This
//would effective reset the application.

//To fix this situation, we should always deliberately place a
//"goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS" at address 0x08, and a
//"goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS" at address 0x18. When the output
//hex file of this project is programmed with the bootloader, these sections do not
//get bootloaded (as they overlap the bootloader space). If the output hex file is not
//programmed using the bootloader, then the below goto instructions do get programmed,
//and the hex file still works like normal. The below section is only required to fix this
//scenario.
#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie fast", since this is in a #pragma interrupt section

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
} //This return will be a "retfie", since this is in a #pragma interruptlow section

//End incantation</pre>

Here's a shorter version of the same thing, stripped of most explanatory comments:
<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x1100
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x1108
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x1118

void YourHighPriorityISRCode();
void YourLowPriorityISRCode();

extern void _startup (void); // See c018i.c in your C18 compiler dir
#pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
void _reset (void)
{
_asm goto _startup _endasm
}

#pragma code REMAPPED_HIGH_INTERRUPT_VECTOR = REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS
void Remapped_High_ISR (void)
{
_asm goto YourHighPriorityISRCode _endasm
}
#pragma code REMAPPED_LOW_INTERRUPT_VECTOR = REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS
void Remapped_Low_ISR (void)
{
_asm goto YourLowPriorityISRCode _endasm
}

#pragma code HIGH_INTERRUPT_VECTOR = 0x08
void High_ISR (void)
{
_asm goto REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS _endasm
}
#pragma code LOW_INTERRUPT_VECTOR = 0x18
void Low_ISR (void)
{
_asm goto REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS _endasm
}

#pragma code

#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//high priority interrupt code
}

#pragma interruptlow YourLowPriorityISRCode
void YourLowPriorityISRCode()
{
//low priority interrupt code
}</pre>

If you wish to use the CDC bootloader with MPLAB source code, you only need to change three lines of the above, where the REMAPPED_VECTOR_ADDRESS constants are defined:

<pre>#define REMAPPED_RESET_VECTOR_ADDRESS 0x800
#define REMAPPED_HIGH_INTERRUPT_VECTOR_ADDRESS 0x808
#define REMAPPED_LOW_INTERRUPT_VECTOR_ADDRESS 0x818
</pre>

== See also ==
[[USB communication with PC]]

[[Wireless PIC bootloading]]

USB bootloading

2009-06-07T14:29:29Z

Gregory McGlynn:

Microchip USB Framework

2009-06-07T14:06:17Z

Gregory McGlynn:

Microchip provides a USB Framework free for download, which includes MPLAB/C18 projects to get you started with USB programming for PICs. These projects are generally intended to be run on one of Microchip's many demo boards, but most of the code can be taken and used for any USB project. The framework also includes both PIC and PC software for [[USB Bootloading|two USB bootloaders]].

You can download the framework from Microchip as one part of the "Microchip Applications Libraries," bundled with some other stuff like a "Graphics Library" and a "Memory Disk Drive Library": [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en540668 framework download]

USB communication between PICs

2009-06-07T13:56:31Z

Gregory McGlynn:

The USB protocol identifies two sides of a communication: the host and the device. The host controls the communication and does more work than the device. Generally the host is a computer, and the PIC is the device. However, if you configure a PIC as a host you can do certain new things:

* Plug in a flash drive USB device to use as storage.
* Configure another PIC as a USB device and use USB to communicate between them.

The [[Microchip USB Framework]] includes an embedded host stack that provides code for running a PIC as a USB host. The [[PIC 18f4550]] is '''not''' able to run as an embedded host: to run the embedded host stack requires a 16-bit or 32-bit PIC. The 4550 is a mere 8-bit chip.

PIC USB

2009-06-07T13:48:20Z

Gregory McGlynn:

During the spring quarter of 2009, Greg McGlynn worked on USB communication and bootloading with PICs as a 399 project with professors Lynch and Peshkin.

== Project Documentation ==
[[PIC 18f4550]] -- only certain PICs are USB-capable, and the 18F4550 is probably the simplest one to transition to from the 4520.

[[USB communication with PC]] -- including example code for both the CCS and C18 compilers.

[[USB Bootloading]] -- loading programs onto PICs using just a simple USB cable as opposed to an ICD or other programmer.

[[USB communication between PICs]] -- requires a more powerful PIC than the 4550.

PIC USB

2009-06-07T13:35:44Z

Gregory McGlynn:

Projects and miscellaneous

2009-06-07T13:31:02Z

Gregory McGlynn:

*[[ME 333 final projects]]
*[[PIC Motor Control with EEPROM and Interactive Menu Example]]
*[[Machine Vision Localization System]]
*[[Swarm Robot Project]]
*[[Swarm Project E-puck Code]]
*[[Swarm Robot Project Documentation]]
*[[Machine Vision Localization System]]
*[[Indoor Localization System | Indoor Localization System (Obsolete)]]
*[[Robot Helicopter Project]]
*[[E-Puck Color Sensing Project]]
*[[Guitar Tuning Project]]
*[[Mohr's Circle]]
*[[E-puck Mobile Robot]]
*[[Bearings]]
*[[Indoor Localization System]]
*[[Using the Basic Stamp Microcontroller]]
*[[Basic Stamp]]
*[[Solderboard]]
*[[Battery disaster]]
*[[LIMS Air Hockey Table]]
*[[Rotational Stiffness]]
*[[Swarm E-puck Quickstart Guide]]
*[[High Speed Vision System and Object Tracking]]
*[[PIC USB]]

USB bootloading

2009-06-07T01:33:03Z

Gregory McGlynn:

'''This article assumes you are using Windows.'''

Bootloading allows you to reprogram your PIC without the need for an expensive hardware programmer like an ICD.

Bootloading works like this:
* You compile your program on the computer, which generates a file with a .hex extension. This is the compiled code for your program, which you want to get onto the PIC.
* You connect the PIC to the computer, in this case with a simple USB cable.
* You fire up a PC program that takes your hex file and sends it to the PIC.
* Sitting on the PIC there is a small program called a bootloader. It takes the hex file that is coming from the computer and writes it into memory.
* You reset the PIC, and your program starts running!

== USB Bootloading with the [[PIC 18f4553]] ==
USB bootloading is bootloading over a USB cable. To do this you need to be working with a PIC that talks USB, like an 18f4553. Then you need to have a bootloader on the PIC. The only way to put a bootloader in place is with a hardware programmer like an ICD, but you only need to do this once: afterwards, all you'll need is a regular USB cable. See [[USB communication with PC|here]] for how to connect a USB cable to a PIC.

== HID Bootloader ==

A HID (Human Interface Device) bootloader has the advantage that it doesn't require any driver installation on the programming computer. Once the bootloader is programmed onto the PIC and the PIC is plugged into the PC, your computer should be able to handle the rest of the setup automatically. A HID bootloader is supplied with the Microchip USB Framework. You can download the PC program here. You can download the PIC hex file here. You can download the full MPLAB project for the PIC program here. This is a slightly modified version of the original HID bootloader project from Microchip. The original project is designed to fit within the first 0x1000 bytes of program memory, but due to changes in the compiler will no longer compile into that space; the modified version goes int he first 0x1100 bytes.

== CDC Bootloader ==

=== Loading the bootloader ===
Here is a USB bootloader hex file that works for the 18f4553 with a 20Mhz oscillator: [[Image:FW_B_20.hex]]. It comes from http://www.schmalzhaus.com/UBW , where you can find the source it was built from, if you're interested. The bootloader is a slightly modified version of one supplied by Microchip; the changes allow the compiled hex file to fit within the first 0x800 bytes program memory.
To load this precompiled hex file onto the PIC using the CCS ICD, use the icd.exe program in the C:\Program Files\PICC directory. Now the bootloader is itself loaded.

=== The PC software ===
There needs to be a program on the PC that sends your hex files to bootloader on the PIC. This bootloader uses a program from the Microchip USB Framework. You can download the framework installer [http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_Setup_v1.3.exe here]. It will create some folders in the C:\ directory. The loader program is at C:\MCHPFSUSB\Pc\Pdfsusb\PDFSUSB.exe.

=== Required circuitry ===
You need some sort of button or switch hooked up to pin RC2 so that it is normally high. If you reset the PIC and pin RC2 is high, the bootloader will run whatever program you've loaded onto it. But if RC2 is low, because you're pressing the button, the bootloader will run, allowing you to load a new program onto the PIC. You don't need to keep holding the button down, C2 just has to be low at the time the PIC resets. So whenever you want to put the PIC into bootloader mode, press and hold the reset button, then press your bootloading button, then release the reset button, then release the bootloading button. You can attach an LED to pin RC1 and the bootloader will flash it when it runs.

=== Installing Drivers ===
When you first connect the PIC to the PC and make the bootloader run, Windows will need to install a driver. Point it to "C:\MCHPFSUSB\Pc\MCHPUSB Driver\Release" and it will install the right driver. Now you're all set up.

=== Compiling for a bootloader ===
A bootloader takes up part of the available program memory, and you need to take this into account when you write your program. Generally, the bootloader takes up a small chunk of memory at the beginning of space available for program memory. You need to tell the compiler to place your code just after the bootloader. Our bootloader takes up the memory from 0x000 to 0x7FF (the first two kilobytes of program memory). Your program therefore needs to start at address 0x800 and not touch the memory from 0x000 to 0x7FF. You can accomplish this by adding the following two lines at the top of your code:

<pre>#build (reset=0x800, interrupt=0x808) //code starts right after the bootloader
#org 0, 0x7FF {} //don't overwrite the bootloader</pre>

=== Bootloading ===
Now that everything's set up, here are the steps to load your program onto your PIC:

* Compile your program with the two lines mentioned above.
* Fire up PDFSUSB.exe.
* Put your PIC into bootloading mode. You should now be able to select "PICDEM FS USB 0" from the PDFSUSB.exe drop-down list.
* Click "Load Hex File" and go find the hex file that you created when you compiled your program.
* Click "Program Device" to load your program.
* Reset your PIC and your program should run.

== See also ==
[[USB communication with PC]]

[[Wireless PIC bootloading]]

USB communication with C18 and MPLAB

2009-06-07T00:56:56Z

Gregory McGlynn:

Microchip publishes a USB Framework that consists of a number of files that contain code to handle the tedious parts of USB communication, with a few spots where user code can be included to build USB programs.

When using the Microchip USB Framework, programs can operate in two modes: polling or interrupt. This choice comes from the fact that USB devices must continually monitor the connection to the host, looking for incoming data and handling the sending of data in the output queue. There are two ways to accomplish this: the program can either explicitly call a function periodically to handle USB tasks, or this can be done by a regularly scheduled interrupt.

The framework provides two slots in which user code can be placed: the functions UserInit and ProcessIO. UserInit is called once at the beginning of the program to allow you to do some initialization. ProcessIO is called in a loop; each iteration should be very short and must be non-blocking, if you are using the polling structure.

Below is an example program using the polling structure, showing just the UserInit and ProcessIO functions. You can download the full MPLAB project here.

USB communication with PC

2009-06-06T23:57:29Z

Gregory McGlynn:

Some PIC models have built-in USB transceivers that make it simple to connect the PIC to a computer via USB. One such PIC is the [[PIC 18f4550]], which is similar to the 18f4520 in almost all respects, except that it has hardware support for USB built into it. The 18f4550 will work just fine in one of the [[4520_Board_intro|PIC protoboards]].

USB software for the PC tends to be OS-specific. '''This article currently assumes you're running Windows.'''

== The USB protocol ==
USB is a pretty complex protocol with a long specification, but it's not necessary to understand every part of it to use it. It's enough to know what wires to hook up and what software libraries to include in your code.

Wikipedia has a detailed and informative [http://en.wikipedia.org/wiki/Usb page on USB].

USB connectors have four leads; the pictures on Wikipedia show which is which on standard connectors.
* +5V: the host (computer) provides up to 500mA of current at 5V that you can use for power. If your PIC is self-powered, though, make sure you don't connect the two +5V sources or bad things may happen.
* GND: ground; make sure you do connect this to your PIC's ground.
* D+ and D-: data is transmitted on these lines. The exact protocol is complicated and you probably don't need to know the details.

== USB with the PIC 18F4550 ==
=== Hardware ===
On the 18f4550, the D+ line connects to pin RC5 and the D- line to pin RC4. The ground line of course connects to ground.

Additionally pin 18, called Vusb, should have a capacitor to ground. Try 220 or 470nF.

=== Software ===
On the software side you have some choices. Probably the simplest thing to do is use a preexisting software library that makes the USB connection look like an [[PIC RS232|RS232 connection]]. The CCS compiler has a CDC library that provides functions like ''usb_cdc_getc'' or ''usb_cdc_putc'' that work over USB exactly like regular ''getc'' and ''putc'' work over RS232. CCS also provides a Windows driver for the PC that creates a virtual COM port that you can open in Matlab, Hyperterminal, or any other RS232-capable program and use to talk to the PIC. See [[USB communication with CCS]].

Microchip provides a USB framework that works with its C18 compiler and its MPLAB development environment. See [[USB communication with C18 and MPLAB]].

CCS also has an example where the PIC registers itself as a Human Interface Device (HID). USB mice and keyboards use HID. The advantage of this is that doesn't require the user to install a special driver. The disadvantages are (a) the connection doesn't look like a simple RS232 link and (b) bandwidth is limited. A HID can only send messages to the computer once every millisecond, and can only send 64 bytes in each message, so the maximum data transfer rate is 64K bytes/second. In theory, USB can go up to 12M bits/second, so HID is fairly slow in comparison.

Microchip provides a USB framework for use with its [[PIC Microcontrollers with C18 Compiler|C18 compiler]].

It's also possible to create one's own setup from scratch or by modifying a preexisting library. This probably takes some effort.

== See also ==
[[USB Bootloading]]

PIC 18f4550

2009-06-06T23:48:21Z

Gregory McGlynn:

The PIC 18F4550 is a chip very similar to the 18f4520, differing in one important respect: it has a built-in USB transceiver, so you can do USB communication with it. See [[USB communication with PC]] or [[USB Bootloading]].

== PIC 18F4553 ==

The PIC 18F4553 is different from the 4550 in only one respect: it has a 12-bit analog-digital converter (ADC) as opposed to a mere 10-bit one. Code written for the 4550 will likely run without changes on the 4553, and vice versa.

== Programming the 18f4553 ==
If your version of the CCS compiler does not list the 4553 as a supported device, you can just program for the 4550, which is almost exactly the same except that it has only a 10-bit ADC. However you will need to update your ICD firmware so that it recognizes the PIC. Save this file to your "C:\Program Files\PICC" directory: [Image:icd-images-firmware-02-51.fw]. Then plug in your ICD and run "C:\Program Files\PICC\icd.exe". Click "Update Firmware", then select "Other" and browse to the file you save. Then hit "Ok" to update the firmware.

If you're programming for the 18f4550, when you hit Program in CCS you'll need to confirm that it's OK that the code wants a 18f4550 while the detected target is a 18f4553.

PIC 18f4553

2009-06-06T23:45:19Z

Gregory McGlynn: PIC 18f4553 moved to PIC 18f4550

#REDIRECT [[PIC 18f4550]]

PIC 18f4550

2009-06-06T23:45:19Z

Gregory McGlynn: PIC 18f4553 moved to PIC 18f4550

The PIC 18f4553 is a chip very similar to the 18f4520, differing in two important respects:
*It has a built-in USB transceiver, so you can do USB communication with it.
*It has a 12-bit analog-digital converter (ADC) as opposed to a mere 10-bit one.

== Programming the 18f4553 ==
If your version of the CCS compiler does not list the 4553 as a supported device, you can just program for the 4550, which is almost exactly the same except that it has only a 10-bit ADC. However you will need to update your ICD firmware so that it recognizes the PIC. Save this file to your "C:\Program Files\PICC" directory: [Image:icd-images-firmware-02-51.fw]. Then plug in your ICD and run "C:\Program Files\PICC\icd.exe". Click "Update Firmware", then select "Other" and browse to the file you save. Then hit "Ok" to update the firmware.

If you're programming for the 18f4550, when you hit Program in CCS you'll need to confirm that it's OK that the code wants a 18f4550 while the detected target is a 18f4553.

== See Also ==
[[USB communication with PC]]

[[USB Bootloading]]

USB communication with CCS

2009-05-12T07:45:46Z

Gregory McGlynn:

A sample program using CCS's CDC library is shown below. The program waits for some input and then responds to it. When you first plug in the PIC to the computer, Windows will need to install a driver to talk to it. If you're running XP or earlier, point it to the directory C:\Program Files\PICC\Drivers, where it will find what it needs. If you're running Vista the driver may not be there; download [[Image:Cdc_NTXPVista.inf]], save it somewhere, and point Windows to it. Once the driver is installed a virtual COM port will be created (it will be visible in the device manager) and you'll be able to talk to the PIC in Hyperterminal, Matlab, or anything else that communications over RS232.

<pre>#include <18f4550.h> //if your version of the compiler doesn't support the 4553, you can put the 4550 in your code, which is almost exactly the same.
#use delay(clock=48000000) //because of tricky fuses a 20Mhz oscillator will make the PIC run at 48Mhz
#fuses HS, NOWDT, NOLVP, NOPROTECT //standard fuses

//these fuses are critical. they assume a 20Mhz oscillator:
#fuses PLL5 //The USB module must run at 48Mhz. This tells the PIC to take the oscillator, divide the frequency by 5, then multiply by 12. The result must be 48Mhz.
#fuses HSPLL //I'm not exactly sure what this fuses does, but it's probably necessary.
#fuses VREGEN //The USB module must run at 3.3V. This tells the PIC to accomplish this by using an internal voltage regulator.
#fuses CPUDIV1 //This tells the PIC to run at a frequency of 48Mhz / 1 = 48Mhz. It may or may not be necessary.

#include <usb_cdc.h> //Include the USB CDC library. If you want to see all the functions available look at usb_cdc.h and usb.h.

void main() {
int c;

//these lines do some initialization, obviously:
usb_cdc_init();
usb_init();
usb_wait_for_enumeration();

while(true) {
usb_task(); //handles connections to and disconnections from the computer, registering the PIC with the computer, etc. call this pretty often so that the PIC responds to being plugged in.

if(usb_cdc_kbhit()) { //did we get some incoming data?
c = usb_cdc_getc(); //get one character of input
printf(usb_cdc_putc, "you typed: %c\r\n", c); //print out a response over usb
}
}
}</pre>

USB communication with CCS

2009-05-12T07:43:48Z

Gregory McGlynn:

A sample program using CCS's CDC library is shown below. The program waits for some input and then responds to it. When you first plug in the PIC to the computer, Windows will need to install a driver to talk to it. If you're running XP or earlier, point it to the directory C:\Program Files\PICC\Drivers, where it will find what it needs. If you're running Vista the driver may not be there; download [[Image:Cdc_NTXPVista.inf]], save it somewhere, and point Windows to it. Once the driver is installed a virtual COM port will be created (it will be visible in the device manager) and you'll be able to talk to the PIC in Hyperterminal, Matlab, or anything else that communications over RS232.

<pre>#include <18f4550.h> //if your version of the compiler doesn't support the 4553, you can put the 4550 in your code, which is almost exactly the same.
#use delay(clock=48000000) //because of tricky fuses a 20Mhz oscillator will make the PIC run at 48Mhz
#fuses HS, NOWDT, NOLVP, NOPROTECT //standard fuses

//these fuses are critical. they assume a 20Mhz oscillator:
#fuses PLL5 //The USB module must run at 48Mhz. This tells the PIC to take the oscillator, divide the frequency by 5, then multiply by 12. The result must be 48Mhz.
#fuses HSPLL //I'm not exactly sure what this fuses does, but it's probably necessary.
#fuses VREGEN //The USB module must run at 3.3V. This tells the PIC to accomplish this by using an internal voltage regulator.
#fuses CPUDIV1 //This tells the PIC to run at a frequency of 48Mhz / 1 = 48Mhz. It may or may not be necessary.

#include <usb_cdc.h> //Include the CCS USB library. If you want to see all the functions available look at usb_cdc.h and usb.h.

void main() {
int c;

//these lines do some initialization, obviously:
usb_cdc_init();
usb_init();
usb_wait_for_enumeration();

while(true) {
usb_task(); //handles connections to and disconnections from the computer, registering the PIC with the computer, etc. call this pretty often so that the PIC responds to being plugged in.

if(usb_cdc_kbhit()) { //did we get some incoming data?
c = usb_cdc_getc(); //get one character of input
printf(usb_cdc_putc, "you typed: %c\r\n", c); //print out a response over usb
}
}
}</pre>

USB communication with PC

2009-05-12T07:43:23Z

Gregory McGlynn: /* Software */

USB communication with PC

2009-05-12T07:42:59Z

Gregory McGlynn:

SPI communication between PICs

2009-05-05T07:53:29Z

Gregory McGlynn:

__TOC__
== Overview ==
SPI or [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Serial Peripheral Interface] is a communication method that was once used to connect devices such as printers, cameras, scanners, etc. to a desktop computer. This function has largely been taken over by USB, but SPI can still be a useful communication tool for some applications. SPI runs using a master/slave set-up and can run in full duplex mode, meaning that signals can be transmitted between the master and the slave simultaneously. There is no standard communication protocol for SPI.

SPI is still used to control some peripheral devices and has some advantages over [[I2C communication between PICs|I2C]] (another type of serial data communication). SPI can communicate at much higher data rates than I2C. Furthermore, when multiple slaves are present, SPI requires no addressing to differentiate between these slaves. Compared to parallel buses, SPI has the additional benefit of requiring only simple wiring.

Peripheral devices that still use SPI:

• Converters (ADC and DAC)

• Memories (EEPROM and FLASH)

• Real Time Clocks (RTC)

• Sensors (temperature, pressure, etc.)

• Others (signal mixer, potentiometer, LCD controller, UART, CAN controller, USB controller, amplifier)

Basic Operation

SPI requires four lines, and is therefore often termed the “four wire” serial bus. These four lines are described in the table below.

{| border="1" cellspacing="2" cellpadding="3" align="center"
|-
!Line!! Name!! Description
|-
|SCLK||Serial Clock||Output from master
|-
|MOSI/SIMO||Master Output, Slave Input||Output from master
|-
|MISO/SOMI||Master Input, Slave Output||Output from slave
|-
|SS||Slave Select||Output from master (active low)
|-
|}

The master, as its name suggests, controls all communication. By controlling the clock, the master decides when data is sent and received. Within each clock cycle a full duplex communication is carried out; each side sends and receives one bit of information. Because there is no standard communication protocol, the master can either send data or both send and receive data, depending on the needs of the application. Likewise, the slave can either receive data or both receive and send data back to the master.

Using the “Slave Select” line, the master chooses which slave with which to communicate. Note that more than one slave may be selected, simply by applying a logic low to the desired SS lines, as illustrated in the schematic diagram shown above. If a given slave is not selected (its SS is high) it disregards signals sent by the master.

References

[http://www.totalphase.com/support/articles/article03/ SPI Background](www.totalphase.com)

[http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus SPI Wikipedia Article] (www.wikipedia.org)

[http://www.mct.net/faq/spi.html More Information] (www.mct.net)

== Circuit ==
Master connected to three slaves:

[[Image:spi-diagram.png]]

Here each slave must be enabled through the slave select pin in order to communicate with the Master.

One PIC master and one PIC slave:

[[Image:spi.jpg]]

The master, on the left, and the slave, on the right, are connected as shown above. Be sure you also connect grounds!

== Code ==
SPI communication on the PIC is accomplished via the functions spi_read() and spi_write(), which read and write one byte at a time over SPI. In the example below, the master reads an 8-bit value from the analog-to-digital converter and sends it to the slave via SPI. The slave reads the value and displays it on an LCD display.

Note: The code given below does not work perfectly: the slave failed to received 10-20% of the messages sent by the master. In this example that failure rate was not critical, as the slave just missed an update of the ADC reading when it missed a message. If more accurate data transmission is required, the failure rate inherent in this system may be unacceptable.

SPI Mode Numbers

There are four SPI "modes" which describe the relationship between the phase of the clock line and the phase of the MISO/MOSI lines. In order to successfully communicate using SPI, the master and slave must operate using the same mode. [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Mode_Numbers Wikipedia] has a good explanation of these mode numbers.

The Slave Select Line

In addition to being used to select which slave is active during a communication, the slave select (SS) line, is vital for synchronization. A slave's SS line should be high except when the master is talking to it. When the SS line is pulled low, the slave knows that a new communication is starting.

If a slave fails to receive a message properly, it will be reset when the SS line goes high at the end of the message and the slave will be prepared for a new message when the SS line goes low again. If the SS line is not used (e.g. by disabling it or running it directly to ground) there is a risk of the slave becoming out of sync with the master; if the slave misses a bit, it will always be one bit off in the future. Effective use of the SS line allows the slave and master to realign themselves at the beginning of each communication, in case of a transmission error.

Master Code:
<pre>#include <18f4520.h>
#fuses EC,NOLVP,NOWDT,NOPROTECT
#device ADC=8
#use delay(clock=40000000)

//These define the different SPI modes in terms of constants the compiler knows about
//NOTE: our PICs only seemed to work in modes 1 and 3, though they are supposed to work with any modes
#define SPI_MODE_0 (SPI_L_TO_H | SPI_XMIT_L_TO_H)
#define SPI_MODE_1 (SPI_L_TO_H)
#define SPI_MODE_2 (SPI_H_TO_L)
#define SPI_MODE_3 (SPI_H_TO_L | SPI_XMIT_L_TO_H)

#define SS_PIN PIN_D0 //this can be any output pin on the master

void main()
{
int val;

//Set up the ADC to read from A0
setup_adc_ports(AN0);
setup_adc(ADC_CLOCK_INTERNAL);
set_adc_channel(0);

//The next statement sets up the SPI hardware, with this PIC as a master using mode 1
//SPI_CLK_DIV_64 sets the speed of the SPI clock pulses--this is the slowest speed
setup_spi(SPI_MASTER | SPI_MODE_1 | SPI_CLK_DIV_64);

while(true) {
val = read_adc(); //read the value to be sent

output_low(SS_PIN); //pull the slave select line low to select the slave
delay_us(10); //give the slave time to notice this (may be unnecessary)

spi_write(val); //send the value

delay_us(10); //(may be unnecessary)
output_high(SS_PIN); //deselect the slave.

delay_ms(10);
}
}</pre>

Slave Code:
<pre>#include <18f4520.h>
#fuses EC,NOLVP,NOWDT,NOPROTECT
#use delay(clock=40000000)

#include <LCD.C>

#define SPI_MODE_0 (SPI_L_TO_H | SPI_XMIT_L_TO_H)
#define SPI_MODE_1 (SPI_L_TO_H)
#define SPI_MODE_2 (SPI_H_TO_L)
#define SPI_MODE_3 (SPI_H_TO_L | SPI_XMIT_L_TO_H)

void main()
{
setup_spi(SPI_SLAVE | SPI_MODE_1); //set up SPI hardware as a slave in mode 1

lcd_init();

while(true) {
val = spi_read(0); //spi_read must be passed an argument. The argument value is sent
//back to the master whenever the master sends us a message again.
//This allows two-way communication, but here the master ignores
//whatever the slave sends back, so just send a 0.

//display the value read:
lcd_gotoxy(1, 1);
printf(lcd_putc, "Pot at: %u ", val);
}
}</pre>

Alternative Slave Code, Using Interrupts:
<pre>#include <18f4520.h>
#fuses EC,NOLVP,NOWDT,NOPROTECT
#use delay(clock=40000000)

#include <LCD.C>

#define SPI_MODE_0 (SPI_L_TO_H | SPI_XMIT_L_TO_H)
#define SPI_MODE_1 (SPI_L_TO_H)
#define SPI_MODE_2 (SPI_H_TO_L)
#define SPI_MODE_3 (SPI_H_TO_L | SPI_XMIT_L_TO_H)

#int_ssp //this interrupt will occur whenever we receive an SPI message (or an I2C message, actually)
void message_receieved() {
unsigned int val;

val = spi_read(); //When you don't pass an argument, spi_read just returns the most
//recently received SPI message. We can do this here because we know
//that we just received a new message.

//display the value:
lcd_gotoxy(1, 1);
printf(lcd_putc, "Pot at: %u ", val);
}

void main()
{
setup_spi(SPI_SLAVE | SPI_MODE_1); //setup the PIC as a slave in mode 1
enable_interrupts(INT_SSP); //enable interrupts on SPI messages
enable_interrupts(GLOBAL);

lcd_init();

while(true); //sit and wait for a message
}</pre>

Two-way communication [This code has not been successfully tested!]

Though not shown above, it is possible to use SPI for two-way communication between master and slave. If the slave calls
<pre>message_from_master = spi_read(123);</pre>
It will wait for the master to send some clock pulses; when the clock pulses come the slave will simultaneously read the message being sent by the master and send its own message (the number 123). The master, for its part, will call
<pre>message_from_slave = spi_read(22);</pre>
This will cause the master to send the number 22 to the slave and simultaneously read the message sent back by the slave (in this case the number 123). So the master and slave have exchanged one byte of information. If you are the master and you just want to get a byte from the slave without sending one, just send a junk value, which the slave will discard:
<pre>message_from_slave = spi_read(0);</pre>

Useful resources

The CCS user manual

[http://www.ccsinfo.com/forum/ CCS forum]

[http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Wikipedia article]

USB bootloading

2009-04-27T01:51:20Z

Gregory McGlynn:

'''This article assumes you are using Windows.'''

Bootloading allows you to reprogram your PIC without the need for an expensive hardware programmer like an ICD.

Bootloading works like this:
* You compile your program on the computer, which generates a file with a .hex extension. This is the compiled code for your program, which you want to get onto the PIC.
* You connect the PIC to the computer, in this case with a simple USB cable.
* You fire up a PC program that takes your hex file and sends it to the PIC.
* Sitting on the PIC there is a small program called a bootloader. It takes the hex file that is coming from the computer and writes it into memory.
* You reset the PIC, and your program starts running!

== USB Bootloading with the [[PIC 18f4553]] ==
USB bootloading is bootloading over a USB cable. To do this you need to be working with a PIC that talks USB, like an 18f4553. Then you need to have a bootloader on the PIC. The only way to put a bootloader in place is with a hardware programmer like an ICD, but you only need to do this once: afterwards, all you'll need is a regular USB cable. See [[USB communication with PC|here]] for how to connect a USB cable to a PIC.

=== Loading the bootloader ===
Here is a USB bootloader hex file that works for the 18f4553 with a 20Mhz oscillator: [[Image:FW_B_20.hex]]. It comes from http://www.schmalzhaus.com/UBW , where you can find the source it was built from, if you're interested.
To load this precompiled hex file onto the PIC using the CCS ICD, use the icd.exe program in the C:\Program Files\PICC directory. Now the bootloader is itself loaded.

=== The PC software ===
There needs to be a program on the PC that sends your hex files to bootloader on the PIC. This bootloader uses a program from the Microchip USB Framework. You can download the framework installer [http://ww1.microchip.com/downloads/en/DeviceDoc/MCHPFSUSB_Setup_v1.3.exe here]. It will create some folders in the C:\ directory. The loader program is at C:\MCHPFSUSB\Pc\Pdfsusb\PDFSUSB.exe.

=== Required circuitry ===
You need some sort of button or switch hooked up to pin RC2 so that it is normally high. If you reset the PIC and pin RC2 is high, the bootloader will run whatever program you've loaded onto it. But if RC2 is low, because you're pressing the button, the bootloader will run, allowing you to load a new program onto the PIC. You don't need to keep holding the button down, C2 just has to be low at the time the PIC resets. So whenever you want to put the PIC into bootloader mode, press and hold the reset button, then press your bootloading button, then release the reset button, then release the bootloading button. You can attach an LED to pin RC1 and the bootloader will flash it when it runs.

=== Installing Drivers ===
When you first connect the PIC to the PC and make the bootloader run, Windows will need to install a driver. Point it to "C:\MCHPFSUSB\Pc\MCHPUSB Driver\Release" and it will install the right driver. Now you're all set up.

=== Compiling for a bootloader ===
A bootloader takes up part of the available program memory, and you need to take this into account when you write your program. Generally, the bootloader takes up a small chunk of memory at the beginning of space available for program memory. You need to tell the compiler to place your code just after the bootloader. Our bootloader takes up the memory from 0x000 to 0x7FF (the first two kilobytes of program memory). Your program therefore needs to start at address 0x800 and not touch the memory from 0x000 to 0x7FF. You can accomplish this by adding the following two lines at the top of your code:

<pre>#build (reset=0x800, interrupt=0x808) //code starts right after the bootloader
#org 0, 0x7FF {} //don't overwrite the bootloader</pre>

=== Bootloading ===
Now that everything's set up, here are the steps to load your program onto your PIC:

* Compile your program with the two lines mentioned above.
* Fire up PDFSUSB.exe.
* Put your PIC into bootloading mode. You should now be able to select "PICDEM FS USB 0" from the PDFSUSB.exe drop-down list.
* Click "Load Hex File" and go find the hex file that you created when you compiled your program.
* Click "Program Device" to load your program.
* Reset your PIC and your program should run.

== See also ==
[[USB communication with PC]]

[[Wireless PIC bootloading]]

USB communication with PC

2009-04-27T01:51:03Z

Gregory McGlynn:

Some PIC models have built-in USB transceivers that make it simple to connect the PIC to a computer via USB. One such PIC is the [[PIC 18f4553]], which is similar to the 18f4520 in almost all respects, except that it has hardware support for USB built into it. The 18f4553 will work just fine in one of the [[4520_Board_intro|PIC protoboards]].

I'm not clear on how cross-platform USB software tends to be. '''This article currently assumes you're running Windows.'''

== The USB protocol ==
USB is a pretty complex protocol with a long specification, but it's not necessary to understand every part of it to use it. It's enough to know what wires to hook up and what software libraries to include in your code, and using USB will be easy.

Wikipedia has a detailed and informative [http://en.wikipedia.org/wiki/Usb page on USB].

USB connectors have four leads; the pictures on Wikipedia show which is which on standard connectors.
* +5V: the host [computer] provides up to 500mA of current at 5V that you can use for power. If your PIC is self-powered, though, make sure you don't connect the two +5V sources or bad things may happen.
* GND: ground; make sure you do connect this to your PIC's ground.
* D+ and D-: data is transmitted on these lines. The exact protocol is complicated and you probably don't need to know the details.

== USB with the PIC 18F4553 ==
=== Hardware ===
On the 18f4553, the D+ line connects to pin RC5 and the D- line to pin RC4. The ground line of course connects to ground.

Additionally pin 18, called Vusb, should have a capacitor to ground. Try 220 or 470nF.

=== Software ===
On the software side you have some choices. Probably the simplest thing to do is use a preexisting software library that makes the USB connection look like an [[PIC RS232|RS232 connection]]. The CCS compiler has a CDC library that provides functions like usb_cdc_getc or usb_cdc_putc that work over USB exactly like regular getc and putc work over RS232. CCS also provides a Windows driver for the PC that creates a virtual COM port that you can open in Matlab or Hyperterminal and use to talk to the PIC.

A sample program using CCS's CDC library is shown below. The program waits for some input and then responds to it. When you first plug in the PIC to the computer, Windows will need to install a driver to talk to it. If you're running XP or earlier, point it to the directory C:\Program Files\PICC\Drivers, where it will find what it needs. If you're running Vista the driver may not be there; download [[Image:Cdc_NTXPVista.inf]], save it somewhere, and point Windows to it. Once the driver is installed a virtual COM port will be created (it will be visible in the device manager) and you'll be able to talk to the PIC in Hyperterminal, Matlab, or anything else that communications over RS232.

<pre>#include <18f4550.h> //if your version of the compiler doesn't support the 4553, you can put the 4550 in your code, which is almost exactly the same.
#use delay(clock=48000000) //because of tricky fuses a 20Mhz oscillator will make the PIC run at 48Mhz
#fuses HS, NOWDT, NOLVP, NOPROTECT //standard fuses

//these fuses are critical. they assume a 20Mhz oscillator:
#fuses PLL5 //The USB module must run at 48Mhz. This tells the PIC to take the oscillator, divide the frequency by 5, then multiply by 12. The result must be 48Mhz.
#fuses HSPLL //I'm not exactly sure what this fuses does, but it's probably necessary.
#fuses VREGEN //The USB module must run at 3.3V. This tells the PIC to accomplish this by using an internal voltage regulator.
#fuses CPUDIV1 //This tells the PIC to run at a frequency of 48Mhz / 1 = 48Mhz. It may or may not be necessary.

#include <usb_cdc.h> //Include the CCS USB library. If you want to see all the functions available look at usb_cdc.h and usb.h.

void main() {
int c;

//these lines do some initialization, obviously:
usb_cdc_init();
usb_init();
usb_wait_for_enumeration();

while(true) {
usb_task(); //handles connections to and disconnections from the computer, registering the PIC with the computer, etc. call this pretty often so that the PIC responds to being plugged in.

if(usb_cdc_kbhit()) { //did we get some incoming data?
c = usb_cdc_getc(); //get one character of input
printf(usb_cdc_putc, "you typed: %c\r\n", c); //print out a response over usb
}
}
}</pre>

CCS also has an example where the PIC registers itself as a Human Interface Device (HID). USB mice and keyboards use HID. The advantage of this is that doesn't require the user to install a special driver. The disadvantages are (a) the connection doesn't look like a simple RS232 link and (b) bandwidth is limited. A HID can only send messages to the computer once every millisecond, and can only send 64 bytes in each message, so the maximum data transfer rate is 64K bytes/second. In theory, USB can go up to 12M bits/second, so HID is fairly slow in comparison.

Microchip provides a USB framework for use with its [[PIC Microcontrollers with C18 Compiler|C18 compiler]].

It's also possible to create one's own setup from scratch or by modifying a preexisting library. This probably takes some effort.

== See also ==
[[USB Bootloading]]

PIC 18f4550

2009-04-27T01:50:32Z

Gregory McGlynn:

PIC 18f4550

2009-04-27T01:50:01Z

Gregory McGlynn:

PIC 18f4550

2009-04-27T01:49:44Z

Gregory McGlynn: