The intention of this thread is to inform you early enough about a new decision I made for the MBSID V2 hardware.
As mentioned in the wishlist thread (http://www.midibox.org/forum/index.php?topic=6564.0), I’ve evaluated the usage of a CAN interface for MIDIbox SID V2. More informations about this interface can be found here: http://en.wikipedia.org/wiki/Controller_Area_Network
The big advantage for MIDIbox SID is, that the master can not only send data to the slaves, but also receive data from any slave. Accordingly, it will be possible to share resources over multiple microcontrollers w/o the need for mirroring the data. This ensures data consistency, and frees some memory for nice features, e.g. double buffering of parameters for non-destructive modulations, an UNDO function for patches, large bassline and drum sequences, etc…
Another advantage is the speed of course, it’s 1 MBit/s, and the ECAN peripheral handles most of the transactions (e.g. message filtering, checksum calculation, data buffering via FIFO), which leads to a very good performance and stability compared to other network solutions like MIDI or IIC.
With the PIC18F4685, Microchip provides a Microcontroller which is pin compatible to PIC18F452, almost SW compatible (with only one exception: RAM between 0x60-0x7f is not directly accessible), which contains 96k flash (3 times more than the PIC18F452), 3328 bytes RAM (ca. 2 times more), and a 1k EEPROM (4 times more).
It seems that the EUSART bug has been solved on this new derivative (an advantage compared to PIC18F4620), accordingly no MBHP_IIC_MIDI interface will be required as a workaround anymore.
So much about the reasons for the decision.
For all users who already purchased a PIC18F4620: at the beginning of the project it can propably be used for a master-only MIDIbox, but once the application is bigger than 64k, you will have to switch to PIC18F4685.
A possibility is maybe to sell the chip to users who are building a MIDIbox SEQ V3, because this application still needs a PIC18F4620 due to the RAM requirements
To give you an impression about the hardware changes, here a schematic for the MIDI/CAN wiring:
(PDF: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf)
All CAN Rx lines are connected together to a single wire, which is pulled to 5V via a 1k resistor.
The CAN Tx lines are connected via 1N4148 diodes to the wire, which forms a “wired-AND”
The Master Core has a MIDI In/Out pair, the MIDI In is directly forwarded to the slaves for an optional “direct control”, and for MIOS code upload (in MBSID V1, the MIDI Ins of the slaves were connected to the MIDI Out of the master, this is not required anymore, as the master can send data to the slaves via the CAN interface)
Since two data pins of the LCD are allocated by the CAN peripheral, the LCD has to be used in 4bit mode. This is no performance loss, as the LCD benchmark turned out. The 18F4685 variant of MIOS always accesses the LCD in this mode
During this weekend I adapted the bootloader and MIOS for PIC18F4685 and PIC18F4682 (a similar derivative, but with smaller flash memory), and I changed the MBSID V1 firmware, so that the master sends patches and parameter changes to the slaves via CAN. The results are already very very promissing, in fact there is no difference anymore, if a sound is played from the master or from a slave, it “feels” like a big microcontroller is running which controls all SID chips directly (quad-core). 
Since resources are shared, it would even be possible to attach more microcontrollers and to control them from the master. Not only MIDIbox SID’s, but also MIDIbox FM’s… thanks to the 96k flash, there should be enough room for CS variations. This as an outlook for next year (2008) or later 
Best Regards, Thorsten.
