■ SCREENSHOT 3. Focus on the Kernel header files in this
shot. The purpose is to give you an idea of the division of
the VOS Kernel Services and the device drivers which are
under the control of the Device Manager.
need to include in the application source code space:
#include “USBHost.h”
#include “USB.h”
#include “MSI.h”
#include “BOMS.h”
#include “UART.h”
#include “FAT.h”
#include “GPIO.h”
#include “string.h”
#include “DesignCycle-App.h”
The MSI.h and FAT.h files support the BOMS.h functionality.
MSI is short for Mass Storage Interface while FAT is the
good old Microsoft acronym that translates to File Allocation
Table. BOMS — Bulk Only Mass Storage — is a USB class
that describes a device for communicating with mass
storage devices. In the Vinculum-II world, a mass storage
device doesn’t physically get any bigger than a thumb drive.
Once a device is opened, Device Manager returns a
unique handle for that device. The returned handle is of the
type VOS_HANDLE. Here’s how VOS_HANDLE is declared
within the Kernel’s devman.h file:
#define VOS_HANDLE uint16
VOS_HANDLE vos_dev_open(uint8 dev_num);
VOS_HANDLE is simply an unsigned 16-bit integer that
holds the unique handle value returned by the vos_dev_open
function which is one of the Device Manager functions.
According to the device list coded in the application header,
we need to reserve five unique VOS_HANDLE slots:
VOS_HANDLE hUsb1, hUsb2, hUart, hBoms, hGpio;
The FAT driver needs to have a context declared to
allow it to communicate with the file system on our mass
storage device. Here’s how the FTDI folks do it:
THE DESIGN CYCLE
■ SCREENSHOT 4. The Runtime header files are the same
header files you’ll find in most any C program
development environment.
fat_context fatContext;
And, that’s how we will do it. The fat_context code that
follows is found within the FAT.h header file. The FAT driver
is layered on top of the BOMS driver. Thus, the context
declaration is a bit different from context code you’ll be
exposed to as we continue:
// context pointer for instance of FAT
// file system
typedef void *fat_context;
fat_context *fat_open(VOS_HANDLE hBoms, unsigned
char partition, unsigned char *status);
According to the fat_context source code we can
gather from the various Vinculum-II toolchain header files, it
seems that the FAT context data is derived from the
invocation of the fat_open function. The fat_close function
adds fuel to that fire as the returned fat_context information
is also used by the fat_close function:
void fat_close(fat_context *fat_ctx);
The vos_create_thread function returns a pointer to the
newly registered thread. So, we’ll need to accommodate
that action by declaring a pointer to our user-generated
application thread which we will name application_thread:
vos_tcb_t *tcbApplication_thread;
Although the thread is not created until the last moment
in the main function, I’ll provide an advanced look at the thread
creation function call so you can relate the *tcbApplication_
thread pointer we declared to the thread creation process:
tcbApplication_thread = vos_create_thread
(29, SIZEOF_FIRMWARE_TASK_MEMORY,
application_thread, 0);
The first parameter in the vos_create_thread function
October 2010 17
