CAN and MBNet HLP thoughts and questions

Design Concepts
1

Hi all,

I read stuff about CAN these last days as i want to use it to interconnect my future MB’s four cores and my computer. I’ve also read about MBNet and this raised me a lot thoughts and questions, especially about the MBNet HLP and its request/reply and master/slave design.

Disclaimer: By posting this topic, i don’t want to offend anyone. I’ve got lot of respect for the work of the MB community and I am also very thankful for that. I hope those comments and questions don’t arrive too late. I’ll try to sum that up in the most ordered way i can. Please apologize for the length of the post.

Use Case 1: MidiBox Extension thru CAN port (a la CiA)

I think providing an standard way for extending the midibox via a CAN port would be a very good thing. Lots of people have made extension ports for their midibox, all of which are quite incompatible. A CAN port could make an easy way to connect and extend MidiBoxes, provided that the extension requires itself a new core.

If such a thing is made possible with the new PICs, it seems to me that the MBNet HLP request/reply design and master/slave model is quite limited in that respect.

For instance for hot-pluging new devices, Masters are forced to poll regularly the network to see if new devices are connected. More over, it has to ping all the devices by their id.

Regular discovery protocols uses advertisement messages (new devices on the network advertises themselves at plug time). This design avoid the overhead of having to ping the potentially existing devices addresses. With a CAN port, plug time could be easily detected by the MB extension thanks to the incoming current. But the HLP must permit any node to post advertisement messages.

Also why correlate the node id to the PIC ids ? Imagine person X comes at Y’s home wants to connect its midibox on Y’s one and realize they have the same PIC ids ??

Use Case 2: Different cores with different responsibilities

In my future midibox, i would like to have three different types of nodes.

Node CS1 and CS2: 8 channel strip (with motor-fader and encoders)

Node P: Paging (or layering if you prefer) system with paging control buttons and navigation control

Node S: Storage of the fader positions for the different pages.

User press a “Next page” button on node P, P sends a page change event on the CAN bus. S observes the page change event and accordingly sends the corresponding fader position change events on the CAN bus. CS1 and CS2 observes the fader position change events and react accordingly.

(I gave the example of fader positions as I have no LCDs on CS1 and CS2. But i could have wanted to display the track names with some LCDs and send the track names the same way.)

I don’t see how i can make my protocol fit in the MBNet HLP. Who is master and who is slave ?

Use Case 3: DMX Connector Node (or whatever protocol PIC is not able to handle)

Let’s say we want to extend a midibox with a node that handles another protocol than MIDI, let’s say DMX. I want that node to be remote configurable. For instance, i would tell him that fader changes of one other node is to be transformed in changes of the x DMX circuit, and so forth…

However, the node that owns the fader do not know that new node. Neither should he know the other node that currently transmits fader changes as MIDI CCs. This uses case shows that if we want extensibility, we need multi-cast if not broadcast capabilities with the MBNet HLP.

I would like to propose for an extension of the MBNet HLP to enable such use cases. In fact, I think restricting the protocol to a request/reply and master/slave design really limits the future potential use of the CAN interface. Maybe we could make the existing HLP a subset of a more versatile HLP.

I don’t know if implementing an existing HLP would be so much work. I’m currently reading the CanKingdom spec and will have a better view of that later. It seems however that CanKingdom is the existing HLP that is the best suited for control.

Here are some thoughts of my whishlist for the HLP:

  • Dynamic allocation of node ids at startup and after hotplugs.

  • Core communication routines (request/reply, publish/subscribe and broadcast)

  • Core services (such as discovery protocol, ping protocol, application upgrade, remote control and configuration)

  • Dynamic allocation of application-specific services’ CAN message identifiers

Ok, sorry for all that. I hope i didn’t bother everyone…

Best regards,

Didier. (MidiBox rocks!)

2

Hi Didier,

I fear that I won’t have enough time to discuss this topic intensively enough. Since you have some fresh ideas how to improve MBNet, I would recomment that you start to work out an alternative protocol in order to prove that it is working sufficiently enough to meet all requirements.

MBNet was mainly tailored for interconnecting MIDIbox SID V2 cores with the limited features of the integrated ECAN peripheral of PIC18F4685.

Therefore the restrictions were driven by free resources (under resources I understand flash, RAM, CPU load and peripheral features) and special requirements of this synth application.

I’m sure that there are better CAN based solutions possible, e.g. for MIDI controllers - like OSC/ACN as you proposed by you in this article http://www.midibox.org/forum/index.php?topic=9376.msg67121#msg67121

But I’m also sure, that a synth which is running on a 8bit controller would never be able to support all features. And I’m also sure that you would never achieve the same performance and robustness. As mentioned above: it was tailored around an existing application. And this application is one of the most complex one I ever implemented.

Best Regards, Thorsten.

3

Hi Thorsten,

I fear that I won’t have enough time to discuss this topic intensively enough. Since you have some fresh ideas how to improve MBNet, I would recomment that you start to work out an alternative protocol in order to prove that it is working sufficiently enough to meet all requirements.

Great, this is what i thought i would do. I wrote this post to explain my position and get feedback from you. I wanted to know whether there still will have a possibility that we could merge in things i could produce if it proves to be useful. So your answer makes me feel you are ok about that.

MBNet was mainly tailored for interconnecting MIDIbox SID V2 cores with the limited features of the integrated ECAN peripheral of PIC18F4685.

Therefore the restrictions were driven by free resources (under resources I understand flash, RAM, CPU load and peripheral features) and special requirements of this synth application.

This is how i understood it.

I’m sure that there are better CAN based solutions possible, e.g. for MIDI controllers - like OSC/ACN as you proposed by you in this article http://www.midibox.org/forum/index.php?topic=9376.msg67121#msg67121

Well, for now, i don’t think about OSC or ACN, but in fact i see in CAN a good way to add features around MB that maybe require some other micro-controller. I mean getting the best of MIOS/PIC and plugging something else (like a PC) for more complex tasks.

But I’m also sure, that a synth which is running on a 8bit controller would never be able to support all features. And I’m also sure that you would never achieve the same performance and robustness. As mentioned above: it was tailored around an existing application. And this application is one of the most complex one I ever implemented.

Please don’t ever think i’m spitting on your work. I just find what you have done is huge!!

Thanks for your feedback.

Best regards, Didier.

4

Please don’t ever think i’m spitting on your work. I just find what you have done is huge!!

thanks! I knew how you mean your article, and just wanted to highlight again for people who propably join the discussion and don’t know the background, that there are huge differences between programming 8bit controllers (which are mainly constructed to save costs and therefore come with many restrictions) and 32bit controllers (which mostly provide much better peripheral functions, and in addition allow to apply state-of-the-art programming concepts)

I mean getting the best of MIOS/PIC and plugging something else (like a PC) for more complex tasks.

yes, thats the most comfortable way to go for PICs which are connected to a PC anyhow (this wouldn’t be the case for MBSEQ or MBSID/MBFM…).

Best Regards, Thorsten.

5

Heya ptitjes :slight_smile:

I think you were around when I was talking about using CAN in a sequencer the other night in the chat room… The implementation would be similar to a couple of things that you mentioned in case 2, IE: having broadcast messages rather than ID-based communications, and messages triggering a core to transmit another message in response. I think Case 3 would be essentially the same, except that the triggered message would be sent to another port (not CAN but DMX or ethernet or IIC MIDI or something). If you want to go ahead with this idea, please let me know, maybe we can work on this together?

That said, I am extremely aware that in doing things like this we are pushing the boundaries of what is practical with an 8-bit micro… It’s easy to bite off more than you can chew, be careful :wink:

6

If you want to go ahead with this idea, please let me know, maybe we can work on this together?

Yeah surely!! The fact is i’ve got no core for now to work with. But i’m preparing my order for smash. And maybe, i’ll have something setup in a few weeks.

For now, i’m thinking about the design of such a system. (and also am digesting the PIC18F4685 data sheet… :))

That said, I am extremely aware that in doing things like this we are pushing the boundaries of what is practical with an 8-bit micro… It’s easy to bite off more than you can chew, be careful :wink:

So we must keep it simple! :slight_smile: Here is what a general plan that is comming into my head (to reorder):

  • Design abstract messaging schemes (request/reply, publish/subscribe and broadcast) and identify general rules to bind that to CAN protocol

  • List core services we would need (i can identify for now by order of occurence: node self-advertisement, node configuration, user action publication, node control)

  • Identify what messaging scheme we need for what service (for instance broadcast for user action publication)

  • Write use cases for the different MB applications we would like to use this alternative HLP (for each use case a detailed flow of service uses)

  • Identify, from all the above, system management services and see for each how we can achieve their implementation (using hardware filters and masks or not, fifo or legacy modes…, using interrupts or regular polls in the main loop)

For the implementation part, i would really like, as i did not program in assembler for years, that we start making some C bindings for the common PIC configuration (filters and masks configuration, message transmit, message receive interrupt handlers…), implement the HLP above that and then little by little rewrite some stuff in assembly language as needed to achieve better performance.

What are your thoughts about that ?

Best regards, Didier.