Proposal for MBHP_IIC_MIDI transfer protocol enhancements

Design Concepts
1

Dear Thorsten, dear MIDIBOX community

Since several months I have the idea of a sophisticated MIDI Patchbay/rtp-MIDI LAN device in my mind based on your beloved IIC-MIDI & MIOS32 Hardware platform.

After some top-down and bottom-up mindgames, I started buttom-up by defineing a iic interface protocol for interconnection the STM32 Module with the iic midi IF.

Motivation:

The MIDIBOX IIC MIDI Module (s. http://www.ucapps.de/mbhp_iic_midi.html) can be enhanced to act as a pair of “intelligent” MIDI sockets,

keeping away the computational load of basic MIDI protocol processing in a host as the CORE_STM32 Module.

The MIOS32 based host then can then handle the more application specific tasks like a MIDI patchbay (eventually with a LAN Interface for processing the rtp-MIDI protocol stack)

or a MIDI Sequencer like the current MIDIbox SEQ V4 (maybe V5).

What would be nice to have as enhancement for the curent implementation:

  1. Filter/Mute commands for MIDI IN and MIDI OUT to minimize transfer of unused commands on MIOS_IIC_ByteReceive and on MIDI OUT line:

1.1 MIDI Channel Voice msg

1.2 MIDI SYSTEM COMMON msg

1.3 MIDI SYSTEM REALTIME msg

  1. Autonomous handling of Active Sensing without involving the host under normal operation conditions.

(Active Sensing may be usefull to dectect cable breaks or unintended power losses in a networked remote environment)

  1. Handling of Running Status on MIDI Input & Output

  2. Exact same REALTIME Command execution on all MIDI Outs.

Since the actual IIC implementation of the PIC 16F88 lacks of the broadcast address definition, this could be achieved by using a scheduled

(delayed) command which is processed when a dedicated pin, common for all IIC MIDI modules is triggered by the host.

  1. Prioritized processing of REALTIME commands at MIDI Input

  2. PANIC (Sequence of All Notes off, Reset all controllers etc. on all MIDI channels) on MIDI Output.

  3. Housekeeping commands. (Initialize, Bufferstatus, Reset)

Preconditions for this protocol enhancement:

  • downward compatibility to the current IIC_MIDI transfer protocol

  • No violation of Thorsten´s inspiration from the USB MIDI specification.

  • use of the current hardware platform (s. http://www.ucapps.de…hp_iic_midi.pdf)

  • IIC addr. extension from 4 to 8 slave devices (maybe RA2?) on J1

  • 1 additional interrupt generating input pin (maybe RA3?) on J1 as a common “execute” signal for scheduled MIDI Realtime Commands (s. below)

Additional RAM resources used in PIC16F88 (1st guess):

  1. MUTE Patterns

1.1 Channel Voice msg: 16 bytes

1.2 SYSTEM COMMON msg: 1 byte

1.3 SYSTEM REALTIME msg: 1 byte

18 bytes/direction => 36 bytes in unused GPR1

  1. Additional SYSTEM REALTIME cmd handling

2.1 Prioritized REALTIME msgs: 4 x 1 byte

2.2 Scheduled REALTIME msgs: 4 x 1 byte

8 bytes in SHARED RAM area (73..7F)

  1. Active Sensing Processing: ca. 4-8 bytes in GPR1

  2. Additional states: ca. 4 bytes in SHARED RAM or GPR0 area

Comments and suggestions wellcome!

Regards

Jo

[IIC_Midi_Cmd Protocol.txt](< base_url >/applications/core/interface/file/attachment.php?id=8680)

2

Very nice ideas, I like the command decoding! :slight_smile:

And I’ve nothing more to add - they would already very useful!

I gave you access to the programmers section where you will find informations about the latest developments (especially about MIOS32 and the new core module)

I guess that you would add the MBHP_IIC_MIDI extensions by yourself?

Best Regards, Thorsten.

3

I gave you access to the programmers section where you will find informations about the latest developments (especially about MIOS32 and the new core module)

Thank you very much, Thorsten!

I guess that you would add the MBHP_IIC_MIDI extensions by yourself?

This is the hardest part, as I’m not familiar with PIC assembler programming. I’ve always some tutorial sites open on my 2nd screen, when I (try to) code PIC assembler.

Regards,

Jo.

4

I did some PIC Assembler programming in the last few weeks, implementing nearly all routines used for the protocol proposal.

The initial proposal needed some modifications and enhancements during implementation. (s. attachment)

I have to admit that I was not able to burn the code to a real target device up to now. This will follow in the next week(s)

But the current state of the asm code is assembled successfully (s. *.map file)

I could also post the sources here as *.zip.

Imho my code is not ready to be put in the svn repository.

What is missing a.t.m. is the trigger input handling via interrupt for scheduled MIDI Realtime Commands on MIDI output

One of my preconditions (leaving the HW untouched) in my initial post could no be fullfilled completely:

  • to make use of the trigger input via interrupt, the Port pins need to be rearranged to make a PortB pin available. (only PortB pins can generate interrupts)

If this function is not needed by the host and if not more than 4 IIC_MIDI devices are used, only one jumper has to be set to connect RA5 to GND (J1: Vs o-o X3)

If scheduled command processing on MIDI output and/or more than 4 devices, a rearrangement of the Jumpers and insertion (soldering) of 4 additional 10k Pull-Up resistors has to be done:

  1. use RB6 as low-active trigger Input (ID0 on J3)

  2. install 4 x 10k Pull-Up Resistors on the solder side of the PCB

2.1 RA2 -> 10k -> Vdd (e.g. IC1: Pin1 -> 10k -> Pin14)

2.2 RA3 -> 10k -> Vdd (e.g. IC1: Pin2 -> 10k -> Pin14)

2.3 RA4 -> 10k -> Vdd (e.g. IC1: Pin3 -> 10k -> Pin14)

2.4 RA5 -> 10k -> Vdd (e.g. IC1: Pin4 -> 10k -> Pin14)

  1. Use J1 as IIC Address terminal (Address (0x10..0x1f):

3.1 Vs o-o X0 -> ID0

3.2 Vs o-o X1 -> ID1

3.3 Vs o-o X2 -> ID2

3.4 leave X3 open!

Here some questions mainly addressed to Thorsten about his implementation:

  1. Why must the 0xff command for entering the IIC Command state be handled by a state machine?

Imho it is a violation of the USB protocol anyway, because MIDI Reset cmd (0xff) should be sent as 0x0f (single byte) and not as 0x03 (three-byte sys-comm msg).

  1. Prot.asm: the table access fct. for e.g. EXPECTED_BYTES_COMMON_TABLE suggest that the tables reside in the EEPROM area.

But the tables reside in the normal programm area.

Is there not a simpler and faster way to access them?

Comments and suggestions wellcome!

Jo

[IIC_Midi_Cmd Protocol5.txt](< base_url >/applications/core/interface/file/attachment.php?id=8807)

[map.txt](< base_url >/applications/core/interface/file/attachment.php?id=8808)

5

Thanks for the work!

Although I’ve currently too much other interests, it’s nice to see the progress.

  1. Why must the 0xff command for entering the IIC Command state be handled by a state machine?

Imho it is a violation of the USB protocol anyway, because MIDI Reset cmd (0xff) should be sent as 0x0f (single byte) and not as 0x03 (three-byte sys-comm msg).

IIC MIDI isn’t identical to USB MIDI, it’s just similar to USB MIDI and gives us some freedom for extensions :wink:

The advantage of a state machine: if it’s already there, it’s easy to add commands with more than 3 bytes.

If it’s clear that more than 3 bytes will never be transfered per command, you could also use 0x1 (which is reserved according to the USB MIDI spec)

  1. Prot.asm: the table access fct. for e.g. EXPECTED_BYTES_COMMON_TABLE suggest that the tables reside in the EEPROM area.

But the tables reside in the normal programm area.

Is there not a simpler and faster way to access them?

This is the result of reused code from an old PIC16F project that I wrote more than 10 years ago, and a newer project that I wrote on a PIC18F

The capabilities of a PIC16F are very limited, e.g. there is no tblrd* command which would allow to directly read from flash.

But I wanted to use the same tables like on my MBHP_USB_MIDI_PIC project.

Alternatively we could use lookup tables similar to this one:

MIDI_MTC_NextExpectedByte
andlw 0x07
addwf PCL, F
retlw 0xf0
retlw 0x7f
retlw 0x7f
retlw 0x01
retlw 0x01

retlw 0x00 ; dummy
retlw 0x00 ; dummy
retlw 0x00 ; dummy
[/code]









which works much faster.







But it has the disadvantage that it has to be ensured that the code is located within a 256 byte page (which mostly results into more cluttered sources), and that it will only run on a PIC16F this way. For PIC18F a similar approach is possible with a trick, but it would consume more cycles than a tblrd\*







So, it was a difficult decision to find a good compromise, and at the day I wrote the firmware I thought it would be better to make it better portable to PIC18F derivatives as I wasn't sure if PIC16F will be sufficient.







Best Regards, Thorsten.
6

Thanks Thorsten for your immediate response.

Your answer to my 1st question rel. the USB MIDI protocol makes sense, I have also to admit: Never change a winning team!

Your comments to the 2nd question are reasonable.

Btw I used the trick with the lookup table in IIC_CMD.asm for dispatching the incomming IIC commands.

Your concerns about using a branchtable (the 256 byte page limit) are true and for that purpose I used markers for the begin and end of the table to verify no page overlap in the map file (s. IIC_CMD_TableBegin & IIC_CMD_TableEnd).

I know, that there is a chance to trap in this pitfall. But the map file should be checked anyway if anything gets to be changed.

Jo

7

I know, that there is a chance to trap in this pitfall. But the map file should be checked anyway if anything gets to be changed.

thats true if you are the only person who maintains the project.

From my experience it won’t work once somebody else (e.g. a programming newbie) tries out some modifications, it could cost him multiple hours to debug this, or he just gives up.

In newer projects (e.g. MBSID V2.. which actually isn’t so new anymore) I’m using such page checks as well, and throw an #error message on overlaps, but usually I try to avoid such dependencies whenever possible with the drawback that it will cost some additional cycles.

However, I don’t want to say that you should use a different (more time consuming) method now, I only want to explain why I’m a bit more careful meanwhile.

Additional CPU cycles will be compensated by less support effort. :wink:

Best Regards, Thorsten.