DOut over long (50-100m) cable?

T.K · November 7, 2010, 6:32pm

Regarding cs_menu_mbnet.inc and sid_mbnet.inc:

I didn’t want to include them because I didn’t want to make the code even more complicated with stuff I don’t need (no SIDs anywhere near), and wanted to avoid the Control Surface fighting with Midio128 for control of the LCD.

I will try to include them, though, and see if it relieves my problems.

No, you don’t need to include these files, it won’t help.

I missed mbnet.inc, and thought that you forgot to add other files as well…

@ Frames on the RX pin: Isn’t this ensured by the wired-and connection already? I wired the CAN bus according to the pdf (as already mentioned above).

Yes, but if you made anything wrong (e.g. diode in wrong direction, bad soldering joint), you would see such effects as well. Therefore this assumption…

To clarify: I’m puzzled why the CAN-functionality works only sometimes. I’d have expected all or nothing. Is it possible that something gets reset in between? Although I haven’t observed a necessary waiting period or whatnot, sometimes the recognized buttonpresses are quite close together, sometimes very far apart…well, I’ll try including the rest of the code and see what happens…

I don’t have more explanations for this effect yet.

If you would work on a MIOS32 application, I would propose to add some debugging messages sent to MIOS Terminal, e.g. at the location where a new frame is sent, where it is received, where a reply is sent, where the reply is received… but MIOS32_MIDI_SendDebugMessage isn’t available for MIOS8.

Instead you could debug with MIDI events.

E.g., send “B0 00 <any-number>” at interesting locations to get some hints about internal operations.

btw TK, do you have any input regarding the MIOS-Studio-on-Linux thread? It would be a bit more comfortable, I think, not having to work in the old beta9. But it’s not that important…

No, I tried it with my Ubuntu installation some time ago, but it wasn’t possible to send/receive MIDI messages.

This seems to be related to the Juce version that I was using at this time, but I haven’t continued debugging in the hope that a Linux expert could solve this.

Best Regards, Thorsten.

T.K · November 7, 2010, 6:42pm

Oh, hello can of worms. If I include cs_menu_mbnet.inc, I get loads of “Symbols previously not defined” errors. Many could be fixed by extending app_defines.h. Unfortunately, there are overlaps in the addresses (?) between MIDIO128’s and SidV2’s app_defines.h, e.g.

MB_STAT EQU 0x010

and

SID_STAT EQU 0x010

,

respectively. And that’s not the only one. That can’t be good, right?

Also, if I include some (or the whole) of the cs_*.inc files, there’s even more errors on make. I’m not sure anymore if this approach makes sense? I think the whole app is just too tightly integrated…

as mentioned before, it isn’t really required to include cs_menu_mbnet.inc

I was only confused about the missing files.

Meanwhile I noticed that you added mbnet.inc to include/asm instead of src/ - thats the wrong location, include/asm is normaly copied from http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Finclude%2Fasm%2F and will never be touched.

It would be better if you would work with the original repository…

Best Regards, Thorsten.

T.K · November 7, 2010, 6:47pm

While looking into your mbnet.inc modifications I noticed that you commented out some important stuff, such as:

CS_MENU_MBNET_Tx_SendEvent
;; movff CS_MENU_SID, MBNET_SLAVE_ID ; prepare transmission
[/code]









this will lead to an undefined ID - probably the master will send to any slave, but not to the slave you wanted to address







there might be more errors.







Best Regards, Thorsten.

bilderbuchi · November 7, 2010, 7:06pm

No, you don’t need to include these files, it won’t help.

I missed mbnet.inc, and thought that you forgot to add other files as well…

ah, great.

Yes, but if you made anything wrong (e.g. diode in wrong direction, bad soldering joint), you would see such effects as well. Therefore this assumption…

ic. diodes are ok. i ruled out hardware errors due to the fact that the intermittent firing of CAN events already starts at the master core Tx pin, so i thought there’s got to be a software error.

Instead you could debug with MIDI events.

E.g., send “B0 00 <any-number>” at interesting locations to get some hints about internal operations.

good idea. i’ll try midi messages. i already (unsuccessfully) tried to adapt the function which yells if there’s a midi timeout to notify on the LCD if there’s a CAN node found.

No, I tried it with my Ubuntu installation some time ago, but it wasn’t possible to send/receive MIDI messages.

This seems to be related to the Juce version that I was using at this time, but I haven’t continued debugging in the hope that a Linux expert could solve this.

thanks for the heads up. unfortunately, i don’t think i’m expert enough.

While looking into your mbnet.inc modifications I noticed that you commented out some important stuff, such as:

CS_MENU_MBNET_Tx_SendEvent

;; movff CS_MENU_SID, MBNET_SLAVE_ID ; prepare transmission

this will lead to an undefined ID - probably the master will send to any slave, but not to the slave you wanted to address

it didn’t work with this line (no pins triggered at all). which is why i figured i use this instead

movff	MBNET_RETRY_NODE, MBNET_SLAVE_ID

since, with only one slave node, the retry_node id should be the right one. i will look into that again, maybe the retry id changes often, which is what produces the intermittent behaviour.

there might be more errors.

of that i’m, unfortunately, quite sure. coding assembly is like “topfschlagen” for me, where it can’t take a pro very long to make the necessary modifications. i already reduced the planned feature set considerably. i’ll be glad if i get it working at all.

bilderbuchi · November 7, 2010, 8:28pm

While looking into your mbnet.inc modifications I noticed that you commented out some important stuff, such as:

CS_MENU_MBNET_Tx_SendEvent

;; movff CS_MENU_SID, MBNET_SLAVE_ID ; prepare transmission

this will lead to an undefined ID - probably the master will send to any slave, but not to the slave you wanted to address

A major success: I tried to do it “properly”, i.e. by using the above line; no luck, no CAN activity, except for the first buttonpress after booting. Then I hunted around (maybe CS_MENU_SID is not defined in midi_evnt.inc, where the function is getting called? Don’t know if something like scope is even possible in asm…) Anyways, I found some code where SID numbers get assigned (CS_MENU_MS_GetSIDNumber). from there I took some snippets and hard-coded the value of CS_MENU_SID. I know, not exactly nice style, but at least it works now, consistent LED triggerings! :frantics: I ended up with

CS_MENU_MBNET_Tx_SimpleSend

	movlw	0x01

	movwf	CS_MENU_SID

	movff	CS_MENU_SID, MBNET_SLAVE_ID	; prepare transmission

I don’t understand why I can’t leave the first two movs out, and only write movff 0x01, MBNET_SLAVE_ID, but I’ll leave it at that.

This actually generates some more problems: Re-discovering nodes, a second distributor; any kind of CAN status messages still don’t work; but I have accomplished enough for today. Now I know 100% that the setup I envisioned so long ago will really work, and can finish building the box. After that I can (maybe) work on more software polishing.

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:

T.K · November 7, 2010, 9:32pm

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](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 · November 8, 2010, 8:53am

TK, i love you

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 · November 9, 2010, 9:52pm

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 · December 2, 2010, 9:46am

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..

lylehaze · December 2, 2010, 9:55pm

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..

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 · December 3, 2010, 8:56am

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

bilderbuchi · December 8, 2010, 10:21pm

Build log is finished and online: <___base_url___>/blog/20/entry-47-midibox-slidecontrol-build-log/?do=embed

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