MIOS Bootstrap Loader
The MIOS bootstrap loader allows you to write applications, but also the operating system itself into the flash memory of a PIC18F452 over the MIDI interface without the use of a special programming device like the MBHP_BURNER module. It is possible to exchange application code on-the-fly. The development of new code can be handled much more efficiently, since it isn't necessary anymore to switch off the MIDIbox, to plug the programming adapter into the ICP socket and to wait two minutes until the flash content has been updated - with the MIOS loader this formerly tiresome procedure takes not more than 3 seconds anymore for a common application.
Take two
In fact two bootstrap loaders are provided by MIOS: the primary and the secondary loader:
- The primary loader gets active immediately after power-on for about two seconds. During this time the loader waits for a SysEx command which initiates a flash write. If this command is not received, the loader deactivates itself and MIOS will be started.
- The secondary loader gets active after MIOS has been booted and the application is running. In difference to the primary loader, the secondary doesn't allow to overwrite the memory allocated by the operating system. This kind of protection saves you from destroying MIOS if your application overlaps the system area by mistake.
After the upload and for the case of an application failure ("blue screen"), the PIC will be reset and the primary loader will be started again for 2 seconds. If your application crashes very early, so that you are not able to correct the error by exchanging the code during runtime, the primary loader will save your day. :)
However, such features don't mean that the bootstrap loader is only a tool for code developers - the common user gets the advantage that he don't need to build a MBHP_BURNER module by himself, but can ask others for doing this job. Once the primary loader has been burned into the PIC, you are able to update the operating system and applications without a PIC burner.
And here another hint to make it clear: it is not possible to use any MIOS application without the bootstrap loader and without uploading MIOS before! The upload procedure is described at the bottom of this page.
Boot options
The bootstrap loader has to know about two important parameters: the MIDI device ID, which should be unique number in a chain of multiple MIDIboxes, and the baudrate. Currently it can be chosen between the common MIDI baudrate (31250) and the rate used by the MIDIbox-to-COM interface (38400). A third parameter allows to define the connected LCD type, so that MIOS is able to select the appropriate driver before printing a message on screen. Currently character displays (1x8, 1x16, 2x16, 2x20, 2x40, 4x16, 4x40) and KS0108-based graphical LCDs are supported, other GLCD types require a special driver which is embedded into the application.
Info for code developers: MIOS uses the following functions during the boot phase: MIOS_MIDI_DeviceIDAutoSet, MIOS_MIDI_InterfaceAutoSet, MIOS_LCD_TypeAutoSet, so that you don't have to take care about these settings. Never overwrite these modes if it doesn't make sense in order to ensure the compatibility with different hardware setups.
With Bootloader V1.2 and higher, it's possible to use a MBHP_IIC_MIDI module as alternative default MIDI Out port. This is intended as workaround for the EUSART bug (only PIC18F4620 A3 and A4 affected).
The boot options are located in the PIC ID header, which can be modified by using IC-Prog or the change_id application. The SysEx device ID is located in bitfield ID[57-63], the UART mode in ID[55], the LCD type in ID[48..51], the MBHP_IIC_MIDI address for MIDI Out redirection in ID[40..47]. Here are some setup examples:
ID = 0000000000000000 USE THIS ID IF YOU ARE UNSURE! |
Device ID = 0x00 common MIDI interface character LCD |
 A snapshot of IC-Prog which shows the location of the ID section Note:If you are using a single core, it's highly recommended to select Device ID = 0x00 - the examples at the left side are using different IDs to indicate the position. |
| ID = 0000000000000012 |
Device ID = 0x12 common MIDI interface character LCD |
| ID = 0000000000000142 |
Device ID = 0x42 MIDIbox-to-COM interface character LCD |
| ID = 0000000000001000 |
Device ID = 0x00 common MIDI interface graphical LCD (KS0108) |
| ID = 0000000000120000 |
Device ID = 0x00 common MIDI interface Redirect MIDI Out stream to MBHP_IIC_MIDI with address 0x12 |
SmashTV wrote a nice online user interface to select the PIC ID values!
Restrictions
In order to improve the upload speed, the dump is stored in a 1k RAM buffer first before it will be written into the flash memory. Therefore blocks larger than 1k cannot be uploaded at once. However, MIOS Studio takes care for this restriction and split the program into several SysEx strings. Once a 1k block has been uploaded (this takes about 330 mS), the loader will go into programming state for ca. 400 mS. During this time, incoming MIDI events are ignored! The SysEx tool has to insert delays between the SysEx strings in order to prevent data-loss, suggested tools which can do this pretty well are MIDI-Ox for Windows, and SysEx Librarian for MacOSX
Sidenote: MIOS Studio splits the code into 256 byte chunks in order to overcome WinXP/Java specific issues with some MIDI interfaces, the required delay between these blocks is ca. 300 uS.
MIOS Studio
MIOS Studio simplifies the upload of code, provides a debug environment for code development, and much more. Don't miss this nice Juce based and OS independent tool!
SysEx protocol specifics
If it should be for interest, the SysEx commands and error codes are described in this document.
Performance
- upload of MIOS (12k): 9 seconds
- upload of a typical application (4k): 3 seconds
Download
this way

Last update: 2011-04-27
Copyright © 1998-2011, Thorsten Klose. All rights reserved.
|