Searching \ for '2-way MIDI' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=way+midi
Search entire site for: '2-way MIDI'.

Truncated match.
PICList Thread
'2-way MIDI'
1999\06\03@205320 by Thomas Brandon

flavicon
picon face
I am new to PICs so please excuse any stupidity. I would like to design a
MIDI "router". It would have say for INs and OUTs and allow you to route
messages between the various channels on the INs and OUTs (e.g. route IN1
Channel 3 to OUT1 Channel 4 and OUT2 Channel 5). I realise it is a fairly
ambitious project to start with but I don't expect it to be easy or fast.

At the moment I'm trying to devise a way of supporting that many MIDI ports
(i.e. 8). I can think of two possible methods:
1) Use PICs such as the 16C74 that have USARTs.
   One disadvantage of this is that no PIC has more than 2 USARTs thus for
a 4x4 box I would need at least 4 PICs (probably 5, 1 to deal with moving
messages between the other 4 PICs). Also, I'd need a fair few JW parts for
prototyping and these don't come cheap (especially here in Australia). In
this arrangement I guess I2C would be a good way of communication between
PICs.

2) Use external UARTs
   I am unsure of how this would work. How many UARTs can you "drive" off
one PIC? How many I/Os do you need for an external UART? I gather an
external UART can be used asynchronously by using the external interrupts on
PORTB. So, I guess you're limited to 4 UARTs on one PIC.

Another possible problem is that MIDI runs at 31250 baud so the UART must
support this. I know the PIC USART can and I've heard SMC UARTs support
31250 out of the box( so to speak). I gather you can change the crystal on a
UART to get other rates but is 31250 easy to do with available crystals? BTW
the MIDI specs allow for a +/-1% on the speed so there a bit of room in
which to use.

In summary my basic questions are:
   - Do either of these designs appear even slighly feasible?
   - Is there a better design?
   - Is interfacing a UART to a PIC possible/difficult/processor intensive?
   - Is it possible to do 31250 on all UARTs? (Easily?)

Sorry for the large ammount of info but I'm not sure what is/isn't relevant
yet.

Thanks in advance,
Thomas Brandon.

1999\06\03@210146 by spare

flavicon
face
Use a Scenix SX/28 at 50MHz. IIRC, Scenix have a virtual peripheral
application note for 8 full duplex UARTS *in software*, on a single
chip. Cheaper than a PIC too, I'd imagine. Check http://www.scenix.com.

Cheers,

Ben

{Quote hidden}

1999\06\03@214137 by Richard Prosser

flavicon
face
How about analogue or digital multiplexers controlled by a PIC? (Plus output
buffers etc as required)

Richard

> {Original Message removed}

1999\06\03@215822 by Thomas Brandon

flavicon
picon face
How do you mean? Multiplex external UARTs I guess you mean.
You'd need a FIFO buffer of a reasonable size so you could ignore 1 line for
a period of time and not lose anything.

Can anyone suggest a suitable UART/FIFO for this task?

> How about analogue or digital multiplexers controlled by a PIC? (Plus
output
> buffers etc as required)
> Richard
<SNIP>
> > In summary my basic questions are:
> >     - Do either of these designs appear even slighly feasible?
> >     - Is there a better design?
> >     - Is interfacing a UART to a PIC
> > possible/difficult/processor intensive?
> >     - Is it possible to do 31250 on all UARTs? (Easily?)

1999\06\03@225821 by Byron A Jeff

face picon face
>
> I am new to PICs so please excuse any stupidity.

No such thing here. Thi is a good project. It's on my task list of things to
do. I also want to add storage.

{Quote hidden}

Personally I vote for 3: Use PICs that do not have UARTS. Distribute the load
by assigning only 1 software UART to each PIC. Use an 8 pin part like a
12C508. Use a clocked serial interface like I2C between the control PIC
like a 16F84. To maintain good clocking you'll probably want to generate
and distribute the 4 Mhz signal to the PIC/UARTS instead of using their
internal oscillators.

The good thing about this arrangement is that you can test with a single
JW part then duplicate the PIC/UARTS with OTP parts.

Thinking about it, I think that having an actual chip select may be useful
to fight the addressing problem of multiple chips. Also a interrupt or a
busy line may be helpful.

So there'd be a 4 wire connection from the control PIC to each PIC/UART. Three
lines CLOCK/DATA/INT are shared among all the PIC/UART and an individual
CS line for each PIC/UART. So a 18 pin PIC could easily drive up to 8
PIC/UARTS.

I just realized that I've used too many pins on the PIC12C508. Will have
to rethink.

BAJ

1999\06\04@010538 by Ross Bencina

flavicon
face
Thomas Brandon wrote
>2) Use external UARTs
>    I am unsure of how this would work. How many UARTs can you "drive" off
>one PIC? How many I/Os do you need for an external UART? I gather an
>external UART can be used asynchronously by using the external interrupts
on
>PORTB. So, I guess you're limited to 4 UARTs on one PIC.

Check out the MAX3100 from maxim, it has a serial interface to the PIC so it
won't chew too many pins. It's got an 8 byte input buffer (no output buffer
from memory). Because of the input buffering you can probably get away with
polling each chip separately.

>Another possible problem is that MIDI runs at 31250 baud so the UART must
>support this.

Shouldn't be a problem. The MIDI Baud rate is designed to be easily
divisible from 1,2,4,8 MHz cpu clocks.

Good luck, I'm sure there is a lot of interest in this project. If you end
up documenting it on the web let me know and I'll add it to my PIC MIDI apps
page:

http://www.audiomulch.com/midipic/

Regards,

Ross.

1999\06\04@012637 by w. v. ooijen / f. hanneman

picon face
When you just want to route (not interpret)
there is no need to use UARTs.
Use for instance a few analog switches,
maybe controlled by a PIC.
It might even be possible with a PIC
only because it only needs to copy
from the in pins to the correct out pins.

Wouter.


----------
{Quote hidden}

1999\06\04@013050 by Jamil J. Weatherbee

flavicon
face
i don't know much about midi.  But unless you are actually processing some
of the data being routed, wouldn't it be much more efficient to construct
a switch/amplifier that is just controlled by the pic?

Kind of like a telco switch but for midi levels.


On Fri, 4 Jun 1999, Thomas Brandon wrote:

{Quote hidden}

1999\06\04@014353 by Thomas Brandon

flavicon
picon face
In MIDI 16 seperate channels are sent down each line thus I'm effectively
routing between 64INs and 64OUTs just grouped into 16s.  The MIDI channel is
part of the data so I need to interpret the messages (at least the first
byte). Also as I'm possibly routing from more than 1 Channel to an OUT I
need to be able to buffer excess data. This is going to be tricky. I will
allocate as much of a buffer as I can (based on RAM and cycle restrictions)
but after that I'll just give an error.

The other thing I would like to have the option of doing is slowing down
MIDI data to certain ports. If anyone's tried to send SYSEX from Cubase
(with slow MIDI sending enabled) to an MC-303 they might have noticed that
the MC-303 doesn't like fast MIDI data. Thus, I would like a way to slow
down MIDI messages. Therfore: more interpretation.

Thanks for the ideas though. If only it were that easy. I will though
probably implement that system to allow straight through routing with almost
no cycles. Although it may be possible to allow that functionality which
would dramatically.

Thanks,
Thomas Brandon.
{Original Message removed}

1999\06\04@205612 by Byron A Jeff

face picon face
>
> Thomas Brandon wrote
> >2) Use external UARTs
> >    I am unsure of how this would work. How many UARTs can you "drive" off
> >one PIC? How many I/Os do you need for an external UART? I gather an
> >external UART can be used asynchronously by using the external interrupts
> on
> >PORTB. So, I guess you're limited to 4 UARTs on one PIC.
>
> Check out the MAX3100 from maxim, it has a serial interface to the PIC so it
> won't chew too many pins. It's got an 8 byte input buffer (no output buffer
> from memory). Because of the input buffering you can probably get away with
> polling each chip separately.

I'm back again. I rethought about using 12C508 8 pin PICS as smart UARTS.
It's a good idea. See you can distribute the work of routing through the
smart UARTS. First of only a two pin interface is required just like I2C.
I thought through several senarios of doing interrupts using a two wire
interface. None worked effectively. So like above, polling seems to be
the ticket.

Now to the routing. If you use a smart PIC as a UART it can also be a routing
element. For example say UART1 channel0 is destined for UART4 channel10. With
ordinary UARTs the MIDI data would come into the controller with channel0
intact and the controller would have the job of converting from channel 0
to channel10. However with a smart PIC/UART the controller could program
the PIC/UART to do the conversion and thus would only have to receive the
data and transmit it to UART4 without having to do the conversion.

Distributed routing.

>
> >Another possible problem is that MIDI runs at 31250 baud so the UART must
> >support this.
>
> Shouldn't be a problem. The MIDI Baud rate is designed to be easily
> divisible from 1,2,4,8 MHz cpu clocks.

Correct. It's exactly 1/16 of 500khz and so is a simple binary divide from
any of the CPU clocks listed above.

>
> Good luck, I'm sure there is a lot of interest in this project. If you end
> up documenting it on the web let me know and I'll add it to my PIC MIDI apps
> page:
>
> http://www.audiomulch.com/midipic/

Thanks for the info. I hope we can put together something interesting.

BAJ

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...