DOut over long (50-100m) cable?

[TK.]

CS_MENU_SID is a variable of the MIDIbox SID application, it's normaly not part of mbnet.inc - you added it from somewhere else...

Instead of:

CS_MENU_MBNET_Tx_SimpleSend

	movlw	0x01

	movwf	CS_MENU_SID

	movff	CS_MENU_SID, MBNET_SLAVE_ID	; prepare transmission[/code]






you could also write:

[code]CS_MENU_MBNET_Tx_SimpleSend

	movlw	0x01

	SET_BSR  MBNET_SLAVE_ID

        movwf    MBNET_SLAVE_ID, BANKED

which is doing the same w/o the usage of a temporary variable. Or you could even remove the "movlw" (loading constant value into WREG):

CS_MENU_MBNET_Tx_SimpleSend

	SET_BSR  MBNET_SLAVE_ID

        movwf    MBNET_SLAVE_ID, BANKED

[/code]




and initialize WREG before calling CS_MENU_MBNET_Tx_SimpleSend

[code]        ;; send something to slave #0x01:

        movlw   0x01

        call    CS_MENU_MBNET_Tx_SimpleSend

which gives you more flexibility (and doesn't require the CS_MENU_SID variable anymore.

One last thing that optimally goes into the software before all that: Can aynbody tell me how/where I can arrange that, depending on the device Id (i.e. only on the master core), all midi in messages get forwarded to midi out? then this box will also be controllable by external midi, and I don't have to duplicate the CAN-transmit-code somewhere else. I can't simply put the CAN transmit code in USER_MPROC_NotifyReceivedEvent, because that's where CAN/MBNet puts the Midi events it transports, and I think this would generate an endless loop... :no:

You can use

        call    MIOS_MIDI_DeviceIDGet

[/code]




to determine the device ID of the core on which the application is running.

See also http://www.ucapps.de/mios8_fun.html#MIOS_MIDI_DeviceIDGet



I don't see the reason why it shouldn't be possible to add the transmit code to USER_MPROC_NotifyReceivedEvent



E.g., try following code (untested - just to give you the idea - if it doesn't work, first try to debug this by yourself!)

[code]

USER_MPROC_NotifyReceivedEvent

        ;; master forwards MIDI events to slaves

        movff   MIOS_PARAMETER1, TMP1   ; MIOS_MIDI_DeviceIDGet overwrites MIOS_PARAMETER1, therefore we temporary store it in TMP1 (such dependencies are the disadvantage of assembly language... :-( - but still easier to handle than a stack)

        call    MIOS_MIDI_DeviceIDGet

        movff   TMP1, MIOS_PARAMETER1   ; restore MIOS_PARAMETER1

        bnz     USER_MPROC_NotifyReceivedEvent_S   ; fortunately "movff" doesn't change the ZERO flag - branch if return parameter of MIOS_MIDI_DeviceIDGet not 0x00


USER_MPROC_NotifyReceivedEvent_M

        ;; copy MIDI event into MIDI_EVNT[01] and _VALUE

        movff   MIOS_PARAMETER1, MIDI_EVNT0

        movff   MIOS_PARAMETER2, MIDI_EVNT1

        movff   MIOS_PARAMETER3, MIDI_EVNT_VALUE


        ;; send to MBNET

        movf    MIOS_PARAMETER1, W

        andlw   0x0f ; MIDI channel located at MIOS_PARAMETER1[3:0]

        addlw    1     ; add +1, we don't want to send to the master... -> MIDI channel 0 (counted from 0) sends to slave 0x01, or in other words: MIDI channel #1 (counted from 1) sends to slave with device ID 0x01 

        call    CS_MENU_MBNET_Tx_SimpleSend   ; we assume that CS_MENU_MBNET_Tx_SimpleSend copies WREG into MBNET_SLAVE_ID

        return ; finished


USER_MPROC_NotifyReceivedEvent_S

        ;; so something else here

        return ; and finish

Now you can decode the MIDI event at the slave side -> up to 16 slaves can be controlled this way, and each slave has an individual coding for up to 128 inputs and 128 outputs

For forwarding MIDI events just enable the integrated MIDI merger.

And a last hint: if your CS_MENU_MBNET_Tx_SimpleSend function would already use MIOS_PARAMETER[123] instead of MIDI_EVNT* variables, the copy operations at the beginning of USER_MPROC_NotifyReceivedEvent are not required - as MIOS_PARAMETER[123] are predefined for all MIOS applications, this makes your function more portable.

Best Regards, Thorsten.

[bilderbuchi]

TK, i love you :cool:

thanks for the code, just what i needed! will test this in the evening!

CS_MENU_SID is a variable of the MIDIbox SID application, it's normaly not part of mbnet.inc - you added it from somewhere else...

yes, this comes from CS_MENU_MBNET_Tx_SendEvent (the original function SimpleSend is based on). It's also contained in CS_MENU_MBNET_FoundNode, which is called in the MBNET_ConHandler, so I thought it may be important elsewhere.

And a last hint: if your CS_MENU_MBNET_Tx_SimpleSend function would already use MIOS_PARAMETER[123] instead of MIDI_EVNT* variables, the copy operations at the beginning of USER_MPROC_NotifyReceivedEvent are not required - as MIOS_PARAMETER[123] are predefined for all MIOS applications, this makes your function more portable.

will do. reason i didn't is because in midi_evnt.inc, where I call the CAN sender, this is not the case:

;; --------------------------------------------------------------------------

;;  FUNCTION: MIDI_EVNT_Send

;;  DESCRIPTION: sends a simple MIDI event

;;  IN: 

;;     o first  MIDI event byte in MIDI_EVNT0

;;     o second MIDI event byte (if applicable) in MIDI_EVNT1

;;     o value in MIDI_EVNT_VALUE

;; --------------------------------------------------------------------------

MIDI_EVNT_Send

;; --------------------------------------------------------------------------

;; MBNet stuff (BB)

;; hope this is functional code:

	call CS_MENU_MBNET_Tx_SimpleSend

I didn't want to overwrite the MIOS_PARAMETERs because of the dependencies you pointed out in the new code - i didn't want to break something inadvertantly by overwriting values.

[bilderbuchi]

just a quick report: code worked out, i'll let the software side rest for a while. Many thanks for your help!

Now on towards CAN transceivers! Initial experiments were unsuccessful, but maybe I'm too tired. Still lots of options left: reducing the slew rate, terminated bus ends, taking the oscope to the circuit...

[bilderbuchi]

It works! :frantics: Assembled and nearly finished at last, adapter cables are about the only thing left. Will try to write some documentation soon(ish).

btw: CAN with low data rate over 100m generic cable with no problems.. :D

Edited December 2, 2010 by bilderbuchi

[lylehaze]

It works! :frantics: Assembled and nearly finished at last, adapter cables are about the only thing left. Will try to write some documentation soon(ish).

btw: CAN with low data rate over 100m generic cable with no problems.. :D

An awesome accomplishment!!

Just out of curiosity, you mentioned a low data rate.

How does it compare to the "normal" MIDI rate of 31250 baud?

I suspect your "low" rate is significantly faster than regular MIDI.

LyleHaze

[bilderbuchi]

I reduced the default CAN data rate (I guess it's the CAN max of 1MBit/s but never calculated it) to 1/8th of its value; in mbnet.inc:

- movlw (0 << 6) | (0 << 0) ; SJW, BRP

+ movlw (0 << 6) | (1 << 3) ; SJW, BRP

This (128kbit/s?) should still compare favorably to MIDI (31.25kbit/s if I'm not deceived). :)

The reason: As per the CAN specification, 1MBit/s is only specced for cable lengths <=40m. this length progressively rises to some 7km(!) for the lowest data rate of 10kbit/s. I just chose something convenient in between.

A table I found somewhere:

Bitrate cable length

10 kbits/s 6,7 km

20 kbits/s 3,3 km

50 kbits/s 1,3 km

125 kbits/s 530 m

250 kbits/s 270 m

500 kbits/s 130 m

1 Mbits/s 40 m

Edited December 3, 2010 by bilderbuchi

[bilderbuchi]

Build log is finished and online:

A big thanks to everyone involved! This project wouldn't have been possible without the help of this great community! :hug: