Hi all
I played last month with mios32 MCAN implementation from
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
Hi,
what has to be done to support MCAN? (at the interface layer…)
Best Regards, Thorsten,
Hello TK (and happy new year )
based on 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
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:
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
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.
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.
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.
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
Hello
Thank to both of you to take care of this
So far MCAN seem a great feature !!
Best
Zam
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 
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
@ALL .About the MCAN
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
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:
Best Regards, Thorsten.
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
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…
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;
What do you think about?
Best regards
Bruno
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.
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
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.
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.hAs 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