Differences

This shows you the differences between two versions of the page.

--- mcan [2018/08/03 09:02]
antichambre [Basic Mode]
+++ mcan [2018/08/03 12:53] (current)
antichambre [A basic example]
@@ Line 256: / Line 256: @@
 **But before any MIDI features we need the MIOS32 driver for that CAN controller...**
 ----
-===== MIOS32_CAN implementation =====
+===== MIOS32_CAN =====
 ==== CAN controller as a generic peripheral in MIOS32. ====
 MIOS32_CAN feature is only compilable under STM32F4.\\
@@ Line 297: / Line 297: @@
 There a few options you can override here...
 <code c [mios32_config.h]>
-/* the use of MCAN must be precised.
+/* the use of CAN Controller must be precised.
  */
 #define MIOS32_USE_CAN
@@ Line 395: / Line 395: @@
 ----
-===== MIOS32_CAN_MIDI implementation =====
+===== MIOS32_CAN_MIDI =====
 ==== Package and Packet ====
 Like the others MIDI peripherals, we need a bridge between our new CAN features(mios32_can.c/h) and the MIDI process[[http://www.midibox.org/mios32/manual/group___m_i_o_s32___m_i_d_i.html|(mios32_midi.c/h)]]\\
@@ Line 458: / Line 458: @@
 ----
-==== Basic Mode ====
+===== MCAN Basic Mode =====
 This is the default mode, the funny one, just interconnect some Cores in parallel with J18 and they are able to communicate in MIDI. Easy.\\
 In this mode:
@@ Line 466: / Line 466: @@
   * The MCAN can be easily added to any of your existing App.
   * The messages are in broadcast over the buss, no filtering and no sophisticated features.
-  * There's no buss management to optimize the bandwidth but the MIDI packets are small.
+  * There's no buss management to optimize the bandwidth but the MIDI packets are short.
 \\
 You will need 5 minutes to make it work and start your multicore App. 8-O\\
 \\
 \\
-=== Standard Packet in Basic Mode ===
+==== Standard Packet in Basic Mode ====
-Even if the MCAN make the MIDI packet for you, let me show you some of them:
+Even if the MCAN make the MIDI packet for you, let me show you some of them:\\
+The IDE bit in frame is always 0, cause we only use the Standard Id Packet, the Type and the Cable must be placed in the Id.\\
+The DLC, indicates the number of necessary MIDI bytes and is automatically set.\\
+It's very simple:
+  * Type and Cable byte => in the Standard Id.
+  * The regular MIDI package => in the datas field.
+  * the regular MIDI bytes number => in the DLC field.\\
+The Sysex messages are an exception for the DLC, we makes packets of 8 bytes(max) with it, and we mark the packets as Starts, Continues or Ends in the Type field, using the code 0x4, 0x6 and 0x7.\\
+==== Real-time packet messages example ====
+<code c [mios32_midi_pcktype_num_bytes]>
+, // 5: Single-byte system common message
+</code>
+  * Type is set to 0x5(Single-byte system common message).
+  * The regular MIDI byte number is 1.
+e.g. MIDI Clock:
+<WRAP group><WRAP half column 100%>
+{{:antichambre:mcan_frame-rt.png?462 |}}
+</WRAP><WRAP half column 0%></WRAP></WRAP>
+<wrap lo center> an 0xf8 MIDI Clock over the port MCAN2.</wrap>\\
+==== Voice packet messages examples ====
+<code c [mios32_midi_pcktype_num_bytes]>
+, // 8: Note Off
+, // 9: Note On
+, // a: Poly-Key Press
+, // b: Control Change
+, // c: Program Change
+, // d: Channel Pressure
+, // e: PitchBend Change
+</code>
+  * Packet Type is equal to the regular MIDI status event type.
+  * There is data(2 or 3 bytes), where the data length depends on the exact type.\\
+e.g. Note-On, 3 bytes:
+<WRAP group><WRAP half column 100%>
+{{:antichambre:mcan_frame-voice3b.png?530 |}}
+</WRAP><WRAP half column 0%></WRAP></WRAP>
+<wrap lo center> Note: D#2, vel: 100 on MCAN6/Channel 4.</wrap>\\
+e.g. Program Change, 2 bytes:
+<WRAP group><WRAP half column 100%>
+{{:antichambre:mcan_frame-voice2b.png?492 |}}
+</WRAP><WRAP half column 0%></WRAP></WRAP>
+<wrap lo center> Program: 33, on MCAN3/Channel 13.</wrap>\\
-There are two CAN busses on a Core32. For STM32F4, CAN2 I/O is not easily accessible as it shares pins with very important ports of MIOS: J8/9, J19, J4B. However if I add one in software I must add the other too.\\ Another reason is that it maybe useful to use a Core as 'gateway' between two Busses (e.g. a multi-core device as a network).\\</del>
+==== SysEx packets message example ====
+<code c [mios32_midi_pcktype_num_bytes]>
+, // 4: SysEx starts
+, // 6: SysEx continues
+, // 7: SysEx ends
+</code>
+  * 8 bytes packets are automatically formed.
+  * The first and last packets are recognizable.
+  * Last packet has a variable length depending on the remaining bytes.
+  * Regular MIDI bytes number doesn't matter.
-Except for SysEx, the messages will be 'UDP-like.' In MIDI, a machine doesn't answer back if a message is received, the same thing occurs with MCAN. And remember, there's already a hardware Ack. and an automatic retry for faulty packets.\\
+e.g. A 20 bytes SysEx stream:
+<WRAP group><WRAP half column 100%>
+{{:antichambre:mcan_frame-SysStart.png?750 |}}
+</WRAP><WRAP half column 0%></WRAP></WRAP>
+<wrap lo center> First packet(type 0x4) where the first data byte is the SOX(0xf0).</wrap>
+<WRAP group><WRAP half column 100%>
+{{:antichambre:mcan_frame-SysCont.png?750 |}}
+</WRAP><WRAP half column 0%></WRAP></WRAP>
+<wrap lo center> Second packet(type 0x6).</wrap>
+<WRAP group><WRAP half column 100%>
+{{:antichambre:mcan_frame-SysEnd.png?590 |}}
+</WRAP><WRAP half column 0%></WRAP></WRAP>
+<wrap lo center> Last packet contains 4 bytes, last byte is the EOX(0xf7).</wrap>\\
+A 1024 byte stream takes 330ms over a regular MIDI, the same stream takes 8,5ms over MCAN.\\
+\\
+\\
+\\
-Like regular UART, MCAN is hot-pluggable. I can remove or add a device on the buss. The buss doesn't fall and the other devices are back online once everything is reconnected and the buss is correctly terminated. \\
+----
+===== Basic Mode, declare and use =====
+Just add this lines in your mios32_config.h(your app).\\
+<code c [mios32_config.h]>
+/* 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
+</code>
+<wrap lo>Done! MCAN is ready!</wrap>\\
+==== A basic example ====
+For this example we will use 2 Cores to get an 8 MIDI ports link between 2 different computers.\\
 \\
-==== MCAN Specifics: ID and Arbitration field. ====
+<WRAP group>
-<WRAP center round important 60%>
+<WRAP half column>
-After a lot of test and trying to make it work with the M16 Interface...
+{{:antichambre:mcan_example1.png?400 |}}
+</WRAP>
+<WRAP half column>
-<del>This is not a problem because we can transpose it just for the transmission time. Real-time events are shifted down just before transmitting and it is shifted back upon recption.\\ A MIDI status byte starts at 0x80 to be recognised. In a CAN packet, data have their own field, thus we can use values from 0-0x7f as status data too.</del> \\
-<WRAP center round 65%>
-^Event ^MIDI Status ^MCAN Status ^Priority ^
-|Note-off|0x8x|0x8x|1|
-|Note-on|0x9x|0x9x|2|
-|Poly-Aftertouch|0xax|0xax|3|
-|Control Change|0xbx|0xbx|4|
-|Program Change|0xcx|0xcx|5|
-|Channel-Aftertouch|0xdx|0xdx|6|
-|PitchBend|0xex|0xex|7|
-|System Exclusive|0xf0|0xf0|8|
-|System Common	|0xf1-0xf7|0xf1-0xf7|9|
-|Real-Time|0xf8-0xff|<wrap left round important 60%>0x78-0x7f</wrap>|<wrap left round important 60%>0</wrap>|
-|<wrap left round tip 60%>Nodes System Exclusive</wrap>new!|--|0xf8|10|
-|<wrap left round tip 60%>Nodes System Common</wrap>new!|--|0xf9-0xff|11|
 </WRAP>
-<del>There are special node system messages too. These easily distinguish between Device System and Node System messages. They have separated functions and callback and are not forwarded to the normal MIDI process.\\
+</WRAP>
-Only real-time events are given special treatment. Now whatever happens, **MIDI events are naturally prioritised** on the buss. Good!</del>\\
+\\
+\\
+The USB limits the link to 8 MIDI ports. Don't forget to declare it too.\\
+<code c [mios32_config.h]>
+/* 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 8
+// enable 8 USB MIDI ports
+#define MIOS32_USB_MIDI_NUM_PORTS 8
+</code>
+\\
+Go in your App code and add this lines in your APP_MIDI_NotifyPackage:\\
+<code c [app.c]>
+/////////////////////////////////////////////////////////////////////////////
+// This hook is called when a MIDI package has been received
+/////////////////////////////////////////////////////////////////////////////
+void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package)
+{
+  if((port & 0xf0) == MCAN0){
+    // receive the voice messages from MCANx and forward it to the USBx
+    MIOS32_MIDI_SendPackage(USB0 + (port & 0x0f), midi_package);
+  }else if((port & 0xf0) == USB0){
+    // filter for voice messages from USBx
+    if(midi_package.type >= 0x8 && midi_package.type <= 0xe){
+      // forward the voice messages to MCANx
+      MIOS32_MIDI_SendPackage(MCAN0 + (port & 0x0f), midi_package);
+    }
+  }
+}
+</code>\\
+\\
+**Done! Your App with the MCAN(Basic) is ready to upload and is the same for both Cores. 8-) **
+\\
+\\
+\\
+----
+===== MCAN Enhanced Mode =====
+<WRAP center round todo 60%>
+There are two CAN busses on a Core32. For STM32F4, CAN2 I/O is not easily accessible as it shares pins with very important ports of MIOS: J8/9, J19, J4B. However if I add one in software I must add the other too.\\ Another reason is that it maybe useful to use a Core as 'gateway' between two Busses (e.g. a multi-core device as a network).\\</del>
+Except for SysEx, the messages will be 'UDP-like.' In MIDI, a machine doesn't answer back if a message is received, the same thing occurs with MCAN. And remember, there's already a hardware Ack. and an automatic retry for faulty packets.\\
+Like regular UART, MCAN is hot-pluggable. I can remove or add a device on the buss. The buss doesn't fall and the other devices are back online once everything is reconnected and the buss is correctly terminated. \\
+\\
 To get the maximum priority throughput, the MCAN status must be at the MSB of the ID... But we write 3 bits before this.\\
 This gives us the possibility to override the status arbitration, or we can isolate groups of devices (8 max), which resembles 'VLAN'. Creating multiple virtual networks in the buss will not decrease the total bandwidth :!: \\
 Three other bits are added after the status bit, which are used to extend the MIDI channels of voice messages. Applications could control an audio mixer or transport DMX data (lightning). Within a SysEx message they indicate which part of the stream the packet is (Start/Cont/End).\\
-\\
-{{ :antichambre:mcan_id.png?750 |}}
-<wrap lo center 80%> The MCAN Id field.</wrap>
-\\
 The group bit indicates that the destination ID is an address of a group of devices and not an individual device.\\
 The group ID range is 0x80-0xef; 0xf0 to 0xff are reserved for special addresses like Broadcast(All) = 0xff.\\
@@ Line 521: / Line 646: @@
 \\
-==== MCAN specifics: frame (packet) format ====
-<WRAP center round important 60%>
-=> frame format will also have a new composition!   \\
-ToDo...
-</WRAP>
 We use the different frame format (length) depending on the MIDI message type.\\
 This will optimise traffic on the buss.\\
+</WRAP>
-Default vlan_prio = 0.
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-std.png?670 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> A MCAN Standard frame.</wrap>
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-ext.png?950 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> A MCAN Extended frame.</wrap>\\
-=== Real-time messages ===
-  * Real-time events broadcast on the buss. We don't need the device ID as there's no channel.
-  * There's no data.
-  * A Standard ID is enough for this type of message.\\
-e.g. MIDI Clock:
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frame-rt.png?390 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> This is the smallest packet size.</wrap>\\
-=== Voice messages ===
-  * Note-on, note-off ... pitchbend events are 'unicast' on the buss. We need the device ID and the Extended channel.
-  * There is data, where the data length depends on the exact type.
-  * We need to insert the source and destination ports. They can be USB0 to SPIM7 and the other MCAN buss if it's available.
-  * An Extended ID is required for this type of message.\\
-e.g. Note-On:
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-note.png?790 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> Note: D#2, vel: 100 on Ch: 4, from USB0 of Device Id#0 to all Devices UART0 Port(Broadcast).</wrap>\\
-e.g. Program Change:
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-pc.png?750 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> Program: 33, on Ch: 13 from USB0 of Device Id#5 to UART2 of Dev1 Device Id#2.</wrap>\\
-e.g. PitchBend:
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-pb.png?790 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> PitchBend: 0, on Ch: 10 from UART0 of Device Id#0 to UART0 of Device Id#1</wrap>\\
-=== SysEx messages ===
-  * System Exclusive messages are 'unicast' on the buss. We need the Node ID.
-  * The Extended channel field is use to know which part of the stream was received (0)start, (1)cont, (2)start+end single packet, (3)end.
-  * There is data, the stream is divided in 8 byte packets. Last packet has a variable length depending on the remaining bytes.
-  * We do not need to insert source and destination ports, the stream contains the MIDI Device ID to target.
-  * Multiple Extended packets are required for this type of message.\\
-e.g. A MCAN 20 byte SysEx stream:
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-sysstart.png?950 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> First packet(start).</wrap>
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-syscont.png?950 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> Second packet(cont).</wrap>
-<WRAP group><WRAP half column 100%>
-{{:antichambre:mcan_frames-sysend.png?725 |}}
-</WRAP><WRAP half column 0%></WRAP></WRAP>
-<wrap lo center> Last packet contains 4 bytes.</wrap>\\
-A 1024 byte stream takes 330ms over a regular MIDI, the same stream takes 8,5ms over MCAN.\\

MIDIbox

User Tools

Site Tools

Differences

Page Tools