This page is intended for a those curious about some of the internals of how the WiFire (and other boards) works and how this can help achieve shorter programming times. It somewhat more technical than other parts of the tutorial series.
There a two major ways you can increase the upload speed. By following these steps the upload time can be reduced to only 20s.
This method requires a device that can act as an in-circuit serial programmer (ICSP). A variety of devices are available to do this such as the chipKIT PGM, the Microchip PICkit along with many others.You may even be able to program another microcontroller as seen here, although this would require implementing the ICSP protocol used by the PIC chips.
chipKIT provides the WiFire with a bootloader implementing the STK500v2 protocol. This allows the tool avrdude, originally designed for uploading to AVR chips, to program the WiFire without needing a dedicated device to program them. This can be useful as it means there is no need to purchase or use an additional piece of hardware. Instead the STK500 bootloader can receive the program over the serial connection and re-program the chip itself.
The default bootloader uses a set speed of 115200 bits per second - just over 110 kbits/s. This is slow. The WiFire can handle receiving data at 3000000 bits/s or 3 Mbits/s. By modifying the bootloader source provided here by chipKIT we can bump the expected baud rate of the WiFire bootloader all the way up to 3 Mbps.
Change line 1390 to use the new baudrate
from #define BAUDRATE 115200 // avrdude baudrate
to #define BAUDRATE 3000000 // avrdude baudrate
Click the “Clean and Build Main Project” button at the top (the button with the hammer and broom icon)
You can find the new bootloader hex file in the following location: PIC32-avrdude-bootloader-master\bootloaders\chipKIT-Bootloaders.X\dist\WiFire\production\chipKIT-Bootloaders.X.production.hex
You might like to rename this to chipKIT-bootloader-3Mbit_upload.hex
Load the new bootloader onto your Wifire using MPLAB X IPE tool and a hardware programmer such as the ChipKIT PGM, PICkit 3 or MPLAB ICD3.
When using this bootloader set the board type to the 3Mbps variant in board selection.
In order to program the WiFire (non-Flow version) you will have to
change chipkit_WiFire.upload.speed to 300000000 in the config file
found in hardware/pic32/variants/WiFire/boards.txt
The next thing we can do is decrease the latency timer in the FTDI chip. The WiFire uses a FTDI chip between the USB and the WiFire for serial communication.
The FTDI chip has an internal buffer of 62 bytes (+ 2 status bytes) which it fills before sending out on its UART channels (both RX and TX). If this buffer does not fill within a timeout (default 16ms) the chip sends the buffer anyway as the data still needs to arrive.
The use of the buffer significantly reduces overhead on the USB as instead of needing to generate a USB packet for almost every byte the transmission of data can be broken into blocks of 62 bytes (or 16ms worth of data, whichever happens first). This packaging of the data is fine for sending the program to the chip as the blocks of data sent are several times greater than 62 bytes so do not spend as much time waiting.
The issue stems from the fact that STK500 also requires verification of each data block sent. These verification packets are less than 62 bytes (as STK500 does not optimise for use with FTDI chips) and therefore sit in the receive buffer for 16ms before being sent back to the programming computer. Because of this avrdude must wait 16ms beyond what is required before sending the next block of data.
By decreasing the timeout we can reduce how long avrdude has to wait for the verification.
Doing so will increase the USB overhead making the programmer do more work and potentially even lose data.
To decrease the timeout in windows open the device manager, go to the Ports (COM and LPT), choose the FTDI USB Serial Port and change the timeout under the port's Properties > Port Settings > Advanced > BM Options
A final tweak would be to disable verification in avrdude. This requires modifying MPIDE, either recompiling, changing the java bytecode or making a wrapper avrdude for MPIDE to call instead that strips off the flags and calls the real avrdude. This method is not worth it and only shaves off a couple of seconds.