www.servomagazine.com/index.php?/magazine/article/
october2010_Eady
Mouser
MicroSD Card Socket
www.mouser.com
Microchip
PIC18F Starter Kit
Microchip Application
Libraries
www.microchip.com
combination of the pushbutton, touch slider, and touch
pads. Depending on the user input, the bootloader code
will bounce around in the LoadApplication state machine
until a .hex file is selected. With a valid application file in its
grips, the bootloader disables the bootloader hardware
configuration and passes control to the newly loaded
application image:
/* Launch the application if the image in
/*Flash is valid */
if (BL_ApplicationIsValid())
{
/* Must deinitialize the boot loader IO */
BLIO_DeinitializeIO();
/* Launch the application */
BootApplication();
}Naturally, there is safety net code that informs the user
and programmer if the bootloader code or bootloader
process falls out of bounds. Speaking of bounds, Figure 1
puts all of the bootloader versus application memory space
ruckus to rest. Here’s the code behind Figure 1:
// These macros define the maximum size
/ of a Flash block.
#define PROGRAM_FLASH_BASE 0x0000A000
// Physical address
#define PROGRAM_FLASH_END 0x0000FC00
// End of flash
#define FLASH_BLOCK_SIZE (0x400)
// Size in bytes
Basically, the bootloader sub-application lives in the
program Flash area below 0xA000. The interrupt vectors
that the PIC18F46J50 is expecting to be available at their
normal memory locations are now the property of the
bootloader. So, it seems that some ISR (Interrupt Service
Routine) detour code is in our future:
#define APPLICATION_ADDRESS 0xA000
#define APPLICATION_HIGH_ISR 0xA008
#define APPLICATION_LOW_ISR 0xA018
#pragma code High_ISR = 0x08
void Remapped_High_ISR (void)
{
_asm goto APPLICATION_HIGH_ISR _endasm
}
#pragma code Low_ISR = 0x18
void Remapped_Low_ISR (void){
_asm goto APPLICATION_LOW_ISR _endasm
}We took a riverboat tour of the PIC18F Starter Kit
MicroSD card bootloader code. All we were able to see
were the animals that lined the shore. The wildlife behind
the bootloader shore animals roams in the Microchip
memory disk drive file system forest.
The Microchip Memory
Disk Drive File System
The memory disk drive file system is included in the
Microchip Application Libraries download. Like the TCP/IP
Stack — which is also a part of the Microchip Application
Libraries download — the memory disk drive file system is
an API-based collection of C routines that take all of the
pain out of working with a MicroSD card.
Some time ago, I designed a little ditty called the ATA
hard drive controller that communicated with surplus low
capacity five volt laptop drives. I recall having to write the
hard drive API from scratch. The memory disk drive file
system is ready to roll and can read, write, and erase files
and directories on a tiny 2 GB MicroSD card.
Invoking FSInit initializes the memory disk drive file
system library. Once the library is initialized, we can create a
file like this:
FSFILE pointer;
// Create a file
pointer = FSfopenpgm (“FILE1.TXT”, “w”);
The FSfopenpgm function will copy the file name and
mode argument (w) into RAM arrays, and then pass those
arrays to the FSfopen function. A new FSFILE object will be
created. In this case, the new instance of FSFILE is called
pointer. FSFILE is really a structure type that holds all of the
important information concerning the open file it
represents. This is what the FSFILE type looks like from a
code point of view:
typedef struct {
DISK dsk;DWORD cluster;
DWORD ccls;
WORD sec;
WORD pos;
DWORD seek;
DWORD size;
FILEFLAGS flags;
//pointer to a disk
//structure
//first cluster of the file
//current cluster of the
//file
//current sector in current
//cluster
//position in the current
//sector
//absolute position in
//the file
//size of the file
//a structure containing
//file flags
SERVO 10.2010 61
