MCAN

[Zam]

Hi all

 

I played last month with mios32 MCAN implementation from @Antichambre

I basically make it work with MB_NG at .ngc but not at .ngr (yes I'm not good at this...)

Any -official- agenda planed to add those ports natively for MB_NG ?

I'm very pleased with the first test I performed

 

Best

Zam

[TK.]

Hi,

what has to be done to support MCAN? (at the interface layer...)

Best Regards, Thorsten,

[Zam]

Hello TK (and happy new year )

 

based on @Antichambre trunk (he share with me for beta test) I mod and compile MB_NG

here is notes of what I do to have port accessible from .NGC (don't remember yet if router work...) I test all this weeks ago,

but EVENT send/receive proper midi data between cores linked at MCAN pin with the extra 4 digit definition at port=

 

Quote

at mbng_file_c
line1480:
      if( (value=get_bin(value_str, 24, 0)) < 0 || value > 0xffffff ) {
replace
      if( (value=get_bin(value_str, 20, 0)) < 0 || value > 0xfffff ) {

 

at mbng_event.c
line 3787 3827 and 3844
for(i=0; i<24; ++i, mask <<= 1)
replace
for(i=0; i<20; ++i, mask <<= 1)

at mbng_file_r
line 1180 and 1512
    if( out_port == 0xffffff && ((out_port=parseValue(line, command, port_str, tokenize_req)) < 0 || out_port > 0xffffff) ) {
replace
    if( out_port == 0xff && ((out_port=parseValue(line, command, port_str, tokenize_req)) < 0 || out_port > 0xff) ) {

So far I don't succeed to use MCAN port at .NGR  (don't remember why I do this at mbng_file_r...)

The idea is simply to have MCAN fully integrated at MB_NG like any other midi port.

Best

Zam

[Antichambre]

4 hours ago, TK. said:

what has to be done to support MCAN? (at the interface layer...)

Hi Thorsten,

MCAN ports are seen as regular MIDI ports. and accessible via new enumerated ports MCAN0 to MCAN15 with base address 0x60.

  ...
  SPIM7 = 0x57,
 
  // New MCANx virtual Ports.
  MCAN0 = 0x60,
  ...
  MCAN15 = 0x6f
 
} mios32_midi_port_t;

It is fully embedded in MIOS32, this is 4 files to add and some changes in others.

the new dirvers:

• mios32_can.c, mios32_can.h for the CAN features
• mios32_can_midi.c, mios32_can_midi.h for native MIDI other the CAN

This is my entire trunk. But there's more than the MCAN feature added... It's my experiencing thrunk, I test the m16 and the dipCoreF4 with it.
With it you can also test the HID support, with a Disco or wCore and OTG FS as HOST, but it remains me to add the callback installer for app layer.

On the MCAN side:

• For testing with hardware you just need 2 or more Cores over the CAN bus, using J18 with 'MBNET' one wire.
• In software, MCAN driver has to be enabled. 

    /* the use of CAN Controller must be precised. 
     */
    #define MIOS32_USE_CAN
     
    /* CAN1 is MCAN must be precised. 
     */
    #define MIOS32_USE_CAN_MIDI
     
    /* Number MCAN MIDI Ports, default and max is 16 
     */
    #define MIOS32_CAN_MIDI_NUM_PORTS 16

More information here (dokuwiki).

It's CAN and MIDI you should like it ;)

Best regards
Bruno

 

 

Edited January 7, 2019 by Antichambre

[TK.]

Hi Bruno,

alright, I see... many changes ;)

I won't be able to sort this out the next two weeks due to limited time.

Would it be possible that you create a minimal update branch until then which is easier to review? This would simplify the work at my side.
Once you did this, you could add your local changes again to the official version (they should be taken over separately)

Best Regards, Thorsten.

[Antichambre]

3 hours ago, TK. said:

Would it be possible that you create a minimal update branch until then which is easier to review?

I tried but without success, under eclipse I can create a branch but i don't know where I have to..?
I just 'succeed' to copy trunk in trunk and and deleted it. :(
Do you suggest me to create a copy of the trunk, with another name, in the same root?
branching is a new concept for me but I can try again if someone can help me, explain me a few, a kind of quickstart for branch under SVN.

[TK.]

First google hit: https://articles.assembla.com/using-subversion/getting-started/branching-and-tagging-in-svn

I just tried:

svn copy svn+ssh://svn@midibox.org/mios32/trunk svn+ssh://svn@midibox.org/mios32/branches/my_activity

it works: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Fbranches%2F

You then set MIOS32_PATH to branches/my_activity (resp. the name of your branch directory) instead of trunk

Note that this branch looks like a complete copy, but actually it's only a reference on the server, which we will delete once we are happy with the changes and merging has been done.
Your changes are still documented in the history.

Best Regards, Thorsten.

[Antichambre]

@TK. Ok thank you for the explanation. helpfull.

The modified trunk with MCAN features only is ready in http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Fbranches%2Fmcan%2F&rev=2654&peg=2649#

I added an example for the MCAN in basic mode here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Fplayground%2Fantichambre%2Fexamples%2Fmcan%2Fmios32_mcan_basic%2F&rev=2655&peg=2655
 

I can compile example properly on my side.

Best regards
Bruno

 

Edited January 8, 2019 by Antichambre

[Zam]

Hello

Thank to both of you to take care of this

So far MCAN seem a great feature !!

Best

Zam

[Antichambre]

2 hours ago, Zam said:

Thank to both of you to take care of this

It's fine, you obliged me to share it correctly and learn a good way to do it :)

[Zam]

Just now, Antichambre said:

It's fine, you obliged me to share it correctly and learn a good way to do it :)

Great if it's fine... at some point I realise that maybe I push a little

as uncomfortable to "ask" because I can't really help community on this subject (except beta testing...)

I'm sure it will be useful for many pple as soon as it get full implementation at MB_NG

Best

Zam

 

[Antichambre]

@ALL .About the MCAN

MCAN, MIDIbox Controlled Area Network

Low cost MIDI(Native) Network using CAN, this is MCAN…

 

2 cores interconnected with simple 'One Wire'. But you can add more:
2 wires in fact, we need a short common ground too.


Bus length is limited to a total of 45cm. Unknown maximum number of Cores, but 4 is suggested.

 

3 interconnected Cores with CAN Tranceivers:
Cables between the MCAN modules are RJ12, I use molded high speed ADSL cables from supermarket.
First RJ12 connector is IO, second is a Loop Thru. If loop is not used each MCAN module has a 120 Ohm terminator switch.
First and last nodes must have terminator ON.


Bus length is limited to a total of 15m. Unknown maximum number of Cores, just respect maximum bus length.

For both connection methods, the Cores are dialoguing in MIDI natively, thru the 16 virtuals MCAN ports.
This is something you can expand, you can create your own Sysex based MCAN layer to build one unique app which is in fact a multi-Core App.
Or you can easily create your MIDIBox(es) based Network to interconnect yours Seq, Synth and/or Controllers App. with easy to find ADSL cables.
Note: In basic mode, all nodes(Cores) can talk, if one is talking the others are listening, that's all. Message priority is based on the types of MIDI events, and there's no filtering or Node ID to set.

Best Bruno

Edited January 8, 2019 by Antichambre

[TK.]

Alright, this is now much better to review, I just need to enter "meld branches/mcan trunk" and get a nice graphical diff + merge function.

Some first observations:

• mios32_can.h and mios32_can_midi.h define types which are not in the mios32_* namespace, which could collide with types defined at higher SW layers.
  Therefore please add the mios32_ postfix to all types which are visible in these header files
• how to you handle collisions?
  If two cores send a frame with the same ID concurrently, the arbitration will pass and the remaining frame might collide (e.g. due to different data being sent).
  The CAN nodes won't automatically re-send the frames.
  This situation could be avoided if you ensure that each core sends unique IDs, e.g. bring source and destination node into the ID.
  I guess that you considered this for extended frames, but this format isn't enabled by default... you should do this.
• mios32_can.h: MIOS32_CAN_VERBOSE should be optional (#ifndef MIOS32_CAN_VERBOSE) and disabled by default
• you can change the copyright notice to your name (I'm not the creator of this part, you are! :)

Best Regards, Thorsten.

[Antichambre]

12 hours ago, TK. said:

mios32_can.h and mios32_can_midi.h define types which are not in the mios32_* namespace, which could collide with types defined at higher SW layers.
Therefore please add the mios32_ postfix to all types which are visible in these header files

Of course it's done.

 

12 hours ago, TK. said:

how to you handle collisions?
If two cores send a frame with the same ID concurrently, the arbitration will pass and the remaining frame might collide (e.g. due to different data being sent).
The CAN nodes won't automatically re-send the frames.
This situation could be avoided if you ensure that each core sends unique IDs, e.g. bring source and destination node into the ID.
I guess that you considered this for extended frames, but this format isn't enabled by default... you should do this.

I don't manage collisions in basic mode, it was the case before but after some tests I removed it cause it was working fine, for a basic mode. Errors happens only when the traffic begins to be very dense.
On error It doesn't stop or isolate the node I just loose some frame. It's a choice for this mode. Very short frames but collision are not handled.
In enhanced Mode the Extended Id is used there's no problem.
But I will do if you think it's a bad idea to let it like that, for that I've got 2 choices:

• Using the extended Id for basic mode too.
• I can add 3 bits for node signature in the standard id and limit the basic mode to 8 nodes maximum.

  struct {
    // extended
    u32 none:1;
    u32 is_request:1;
    u32 is_extended:1;
    u32 src_node:7;
    u32 dst_node:8;
    u32 app_type:3;
    // standard
    u32 cable:4;
    u32 type:4;
    u32 vman_prio:3;
    // ports
    u8  src_port;
    u8  dst_port;
  };
} mios32_mcan_header_t;

I can shift vman_prio field after type and cable and use it for a 3 bits limited Id.

 

13 hours ago, TK. said:

mios32_can.h: MIOS32_CAN_VERBOSE should be optional (#ifndef MIOS32_CAN_VERBOSE) and disabled by default

Yes I have to change all verbose function to optional and add levels for it.

 

13 hours ago, TK. said:

you can change the copyright notice to your name (I'm not the creator of this part, you are! :)

I will do ;)

More than that I have to complete, error handling and field filtering for enhanced mode.

Best
Bruno

[FantomXR]

Looks like an awesome feature! A perfect way to connect two or more midiboxes without adding latency! Thanks for sharing! :-)

I'll give it a try also...

[Antichambre]

On 1/8/2019 at 0:26 PM, Antichambre said:

On 1/7/2019 at 10:41 PM, TK. said:

how to you handle collisions?
If two cores send a frame with the same ID concurrently, the arbitration will pass and the remaining frame might collide (e.g. due to different data being sent).
The CAN nodes won't automatically re-send the frames.
This situation could be avoided if you ensure that each core sends unique IDs, e.g. bring source and destination node into the ID.
I guess that you considered this for extended frames, but this format isn't enabled by default... you should do this.

I don't manage collisions in basic mode, it was the case before but after some tests I removed it cause it was working fine, for a basic mode. Errors happens only when the traffic begins to be very dense.
On error It doesn't stop or isolate the node I just loose some frame. It's a choice for this mode. Very short frames but collision are not handled.
In enhanced Mode the Extended Id is used there's no problem.
But I will do if you think it's a bad idea to let it like that, for that I've got 2 choices:

• Using the extended Id for basic mode too.
• I can add 3 bits for node signature in the standard id and limit the basic mode to 8 nodes maximum.

  struct {
    // extended
    u32 none:1;
    u32 is_request:1;
    u32 is_extended:1;
    u32 src_node:7;
    u32 dst_node:8;
    u32 app_type:3;
    // standard
    u32 cable:4;
    u32 type:4;
    u32 vman_prio:3;
    // ports
    u8  src_port;
    u8  dst_port;
  };
} mios32_mcan_header_t;

I can shift vman_prio field after type and cable and use it for a 3 bits limited Id.

I decided to add a Basic Id field, 3 bits which will allow 8 Cores on the MCAN Bus. And remove the vman_prio field which was an optional feature.
I think it's the best compromise.
 

  struct {
    // extended
    u32 none:1;
    u32 is_request:1;
    u32 is_extended:1;
    u32 src_node:7;
    u32 dst_node:8;
    u32 app_type:3;
    // standard
    u32 basic_node:3;
    u32 cable:4;
    u32 type:4;
    // ports
    u8  src_port;
    u8  dst_port;
  };
} mios32_mcan_header_t;

- Message types are always prioritized(type)
- We keep the 16 MCAN ports (cable)
- 8 chained cores max in the basic mode(basic_id), the basic_node field will not be used in extended mode and replaced by the src_node.
Of course this basic_node id will have to be declared in mios32_config.h and different for each core on the buss, value from 0 to 7.
Notes: the type of message is always a priority, the cable has priority over the id

@TK. What do you think about?

Best regards
Bruno

Edited June 16, 2019 by Antichambre

[TK.]

We could reserve a bootloader location to make this basic_node number configurable without touching the source code.

Similar the way I did for other "permanent" flags & values.

Best Regards, Thorsten.

[Antichambre]

1 hour ago, TK. said:

We could reserve a bootloader location to make this basic_node number configurable without touching the source code.

it would be great! :)
...
I will definitely go in this direction.
Thank you for your answer

Best regards
Bruno

[TK.]

Which values would you like to permanently store & change in the bootloader.

I need names + sizes

I will define those values in mios32_sys.h within the MIOS32_SYS_ADDR_BSL_INFO_BEGIN section
-> https://github.com/midibox/mios32/blob/master/include/mios32/mios32_sys.h

As you can see, we can either define a block + confirmation value, or individual values + confirm.
If you could predict today how many bytes need to be allocated, we could use a single confirmation which saves space for other future extensions (used for other purposes)

Best Regards, Thorsten.

[Antichambre]

22 hours ago, TK. said:

Which values would you like to permanently store & change in the bootloader.

I need names + sizes

I will define those values in mios32_sys.h within the MIOS32_SYS_ADDR_BSL_INFO_BEGIN section
-> https://github.com/midibox/mios32/blob/master/include/mios32/mios32_sys.h

As you can see, we can either define a block + confirmation value, or individual values + confirm.
If you could predict today how many bytes need to be allocated, we could use a single confirmation which saves space for other future extensions (used for other purposes)

Best Regards, Thorsten.

Hi Thorsten,

For the basic mode nothing more than the node number is necessary. It's 3 bits (0...7) then 1 byte is enough
Something like this:

# define MIOS32_SYS_ADDR_DEVICE_ID_CONFIRM  (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd0) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_DEVICE_ID          (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd1)
# define MIOS32_SYS_ADDR_FASTBOOT_CONFIRM   (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd2) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_FASTBOOT           (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd3)
# define MIOS32_SYS_ADDR_SINGLE_USB_CONFIRM (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd4) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_SINGLE_USB         (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd5)
# define MIOS32_SYS_ADDR_ENFORCE_USB_DEVICE_CONFIRM (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd6) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_ENFORCE_USB_DEVICE (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd7)
# define MIOS32_SYS_ADDR_SPI_MIDI_CONFIRM   (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd8) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_SPI_MIDI (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xd9)
# define MIOS32_SYS_ADDR_MCAN_NODE_CONFIRM   (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xda) // 0x42 to confirm value
# define MIOS32_SYS_ADDR_MCAN_NODE (MIOS32_SYS_ADDR_BSL_INFO_BEGIN+0xdb)

Let me 1 day or 2 and I will do the stuff for the Bootloader Updater, as you get the minimum to do, just valid/correct.
Except if you really want to do it yourself.

Best regards
Bruno
 

[TK.]

Hi Bruno,

yes, just try it and commit your change in a special branch (from master) - we can merge once we both are satisfied.

By searching for defines like MIOS32_SYS_ADDR_SPI_MIDI (e.g. via "grep --rec") you can find the places which need to be modified.

Best Regards, Thorsten.