MBSID V2: Hardware Changes

TK. · January 14, 2007

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.

fluke · January 15, 2007

Off topic, but will the PIC18F4685 work with MIDIbox FM since it uses the same ports as the LCD to talk to the OPL3 module?

Wilba · January 15, 2007

Excellent work, TK!

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

You can programmatically turn on 4-bit mode in the application's initialization, but it's not a configuration bit in the PIC ID header. Can you add a bit in the PIC ID header so MIOS can use 4-bit mode on any PIC, not just the 18F4685? (or use 8-bit mode on the 18F4685, if one didn't need CAN?)

This hardware change has just brought to my attention that I could use a cable with four less wires and would like to start doing that now! ;D

stryd_one · January 15, 2007

8)

bill · January 15, 2007

That's beautifull !!! ;D

I cant wait to use those new pic's ! (i allready ordered some)

PLease TK, could you make the new bootloader and MIOS available (even if there's 'beta') so we can have fun with all that extra memory ? :)

Greetz !!!!

cheater · January 15, 2007

That's wonderful, TK!

Does this CAN interface allow us to connect this PIC to more "muscular" cousins?

For example, will it be possible to write some MIOS apps so that 8 of those PICS = 1 "bigger" PIC that only advanced users know how to solder/operate/etc?

Thanks,

D

SLP · January 15, 2007

Some noob questions:

The remaining HW (pcb, etc..) will stay the same, right?

Will the SID-V1.xxx run on the PIC18F4685 ?

matthias

TK. · January 15, 2007

Off topic, but will the PIC18F4685 work with MIDIbox FM since it uses the same ports as the LCD to talk to the OPL3 module?

as my boss says to such questions: today we will solve the problems of today, tomorrow the problems of tomorrow ;-)

However, the two allocated pins RB2 and RB3 have to be duplicated at a free port, e.g. Port RA2 and RA3. This doesn't cost much performance

You can programmatically turn on 4-bit mode in the application's initialization, but it's not a configuration bit in the PIC ID header. Can you add a bit in the PIC ID header so MIOS can use 4-bit mode on any PIC, not just the 18F4685? (or use 8-bit mode on the 18F4685, if one didn't need CAN?)

Currently I would prefer a compile option here, since it's a very special case.

I've already changed MIOS, so that derivative specific settings can be made at a single place (mios.h), thereafter you need to build a new mios binary.

#if PIC_DERIVATIVE_TYPE == 4
LIST P=PIC18F4685, R=DEC
#include <p18f4685.inc>
#define PIC_DERIVATIVE_CODE_SIZE 0x18000
#define PIC_DERIVATIVE_RAM_SIZE 0xd00
#define PIC_DERIVATIVE_EEPROM_SIZE 0x400
#define PIC_DERIVATIVE_IRQ_WORKAROUND 0
#define PIC_DERIVATIVE_T08BIT_INVERTED 0
#define PIC_DERIVATIVE_SET_LCD_4BIT 1
#endif
[/code]

This hardware change has just brought to my attention that I could use a cable with four less wires and would like to start doing that now! ;D

Please note that I found out, that the 4bit initialisation sequence doesn't work with all LCDs (it didn't work with my displaytech 2x20). In the meantime I solved this, the fix will be available with the next MIOS release

PLease TK, could you make the new bootloader and MIOS available (even if there's 'beta') so we can have fun with all that extra memory ? :)

I will make it available next weekend. My priority was on CAN setup at the application side, I haven't updated MIOS yet to support addresses >= 0x10000, this will require some changes at places where the table pointer is initialized, and the ISR needs to store/restore TBLPTRU in addition

Does this CAN interface allow us to connect this PIC to more "muscular" cousins?

CAN is an ISO standard, there are many microcontrollers available which support this interface, especially 16bit and 32bit microcontrollers for the automotive range

For example, will it be possible to write some MIOS apps so that 8 of those PICS = 1 "bigger" PIC that only advanced users know how to solder/operate/etc?

which "bigger" PIC do you mean?

Or do you mean another microcontroller family? Yes, of course, it's only a question of implementation effort.

The remaining HW (pcb, etc..) will stay the same, right?

yes

Will the SID-V1.xxx run on the PIC18F4685 ?

it will require a small modification in app_defines.inc, some variables which are located to 0x060-0x07f, and which are accessed directly, need to be located to another location (or the code need to be changed).

However, a modified MBSID V1.7303 version is available on request. It's 100% compatible, and already gets use of the CAN interface - I won't release this version officially, as the communication protocol is not the best (accordingly this is not a good programming example), it's just a quick&dirty hack that I've used to evaluate the feasibility.

In MBSID V2 I will take care that the memory structures are optimized for fast CAN transfers from the beginning

Best Regards, Thorsten.

fluke · January 16, 2007

as my boss says to such questions: today we will solve the problems of today, tomorrow the problems of tomorrow ;-)

And considering how fast i'm building my MIDIbox FM, it is likely to be a problem of 2008. :)

However, the two allocated pins RB2 and RB3 have to be duplicated at a free port, e.g. Port RA2 and RA3. This doesn't cost much performance

So there's no longer any 8 bit ports that don't have some pins used for special functions?

cheater · January 16, 2007

Hmmm... Does this CAN port mean easy memory extension, TK?

ilmenator · January 16, 2007

You already have that with the Bankstick. It's even implemented in MIOS - so why go CAN anyway? Alternatively you can address memory via an 8-bit port - via the same pins that the LCD uses - but both can be connected in parallel.

Regards, ilmenator

SLP · January 18, 2007

What can I do with my IIC-module now?

Is there a way to turn it into - lets say a midimerger?

TK. · January 18, 2007

Yes, there is a way - just use the MIDI router project.

A firmware for a standalone MIDI merger is not available, however, I guess that you have a PIC18F452 free from your MBSID V1

Best Regards, Thorsten.

Wilba · January 22, 2007

WinPic800 doesn't burn PIC18F4685 (yet), so I've asked the name to add it.

PICPgm already supports the PIC18F4685, but not the "ID Locations", so I've asked the name to add it. (Actually, I asked him six months ago and just nagged again! He's sent me a prerelease and it works well).

Both are incredibly reliable and work perfectly with my JDM burner.

http://www.midibox.org/dokuwiki/doku.php?id=jdm_with_winpic800

http://www.midibox.org/dokuwiki/doku.php?id=jdm_with_picpgm

TheAncientOne · January 22, 2007

I've had a thought, though it may be too much work for a minority usage, but might it be possible to dedicate an extra PIC to being the control surface processor, so that it would be possible to remote the surface from the sound generator system?

I know from industrial work that CAN is a very robust interface, and I have this vision of 4 (or More) SID's in a rack module, with all their I/O out of the way, and a neat 9 Pin D connecting to a control surface.

Dumb idea probably . . . . . :-\

Mike

TK. · January 22, 2007

In the meantime I made some additional experiments, and I think that I will release a last V1 version with CAN support (for PIC18F4685 only) which will include all the communication functions which I will use for MBSID V2 as well. This is to get more experiences about the best protocol handling before I'm starting with V2

I've had a thought, though it may be too much work for a minority usage, but might it be possible to dedicate an extra PIC to being the control surface processor, so that it would be possible to remote the surface from the sound generator system?

Thanks to CAN it doesn't really make a big difference anymore, if the SIDs are connected to the PIC which also handles the CS, or if they are connected to slaves, and accessed from the master remotely. Accordingly, so long only 2x3 SIDs (stereo option) should be used for such a system, just left out the SIDs on the control surface PIC.

I've prepared the protocol for up to 127 CAN nodes, but I think that 7 should be the maximum for the internal handling, otherwise it would only be a waste of memory. Makes 1 master + 7 slaves = 16 SIDs ;-)

But I want to highlight, that I would never test such a system and cannot guarantee that it will really work. My own configuration is still 1 master, 3 slaves, 8 SIDs

Best Regards, Thorsten.

tarzan boy · January 23, 2007

TK, are you able to fit those 4 extra SID modules into your existing classic C64 box?

I'm struggling to get my similar config to close without smashing stuff inside with only the original 4 SID modules.

thinking about putting some sort of thick gasket in between my top and bottom to allow more space.

TK. · January 23, 2007

I'm using Wilba's PCB in the meantime and accordingly don't have problems with the space inside the case

See http://www.midibox.org/midibox_sid_blm_photos/

Best Regards, Thorsten.

tarzan boy · January 23, 2007

whoa ok I missed out on this. Are those PCBs still available? I've got 4 spare SIDs ready to do their work.

visibleman · January 24, 2007

To give you an impression about the hardware changes, here a schematic for the MIDI/CAN wiring

The schematic mentions "cheap solution". Is there an "expensive solution", better in some ways?

In the meantime I made some additional experiments, and I think that I will release a last V1 version with CAN support (for PIC18F4685 only) which will include all the communication functions which I will use for MBSID V2 as well.

This is great news! Now I can built SID with CAN communication before V2 is released and use V1 until then! Cool!

Hope Smash TV starts selling PIC18F4685s with preburned bootloader soon!

Wilba · January 24, 2007

For info about "Wilba's PCB" ;D go here:

http://www.midibox.org/forum/index.php?topic=8389.msg58396

tarzan boy · January 24, 2007

thank wilba, tried searching for it in the forums but didnt think of trying "6582!"

TK. · January 24, 2007

The schematic mentions "cheap solution". Is there an "expensive solution", better in some ways?

The expensive solution would require seperate CAN tranceivers for each PIC. But the diode/pull-up resistor approach works extremely stable as I noticed, and I think that tranceivers are only required for higher distances (e.g. > 1m or so..), or if you are planning to access the master/slaves from another CAN node like from a PC with CAN interface card (I've prepared this multimaster capability in the protocol).

Maximum distance: 40 meters

Best Regards, Thorsten.

bill · January 24, 2007

Hello TK,

Is a mios bootloader for the PIC18F4685 available somewhere ?

Thanks :)

TK. · January 24, 2007

Just write me a mail to get a temporary version

Best Regards, Thorsten.

Sign In

MBSID V2: Hardware Changes

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation