The main problem with timer handling is interleaving the 4inputs and
4outputs effectively. Perhaps a miny RTOS using TMR2 and PR2 as a delay
system. The main problem then would be efficiently recording what should be
done on the next interrupt. However the PICs with 3 timers generally have
ADC's and too much RAM, plus the only such flash chips are the 'F87x's so I
would have to either pay for ADC's, RAM, Pins etc. that I don't need or
prototype on a 'F87x or a windowed part and use OTP for production. Which is
a pity as I liked the idea of having incircuit Firmware updates via MIDI
(could still update other chips of course).  Also, a bit of logic would be
required to decide when to group operations together (and handle this in the
interrupt) because they can't run as serial delays. The one thing I would
have on my side is Program code space. By bloating the code incredibly to
handle individually as many situations as possible may help speed. Ideally I
would use the 16F84A as it's the only 20MHz chip without extraneous
peripherals. However it does not include the one peripheral I want: a
hardware serial interface to communicate with the rest of the PIC's (ideally
I would use multi slave SSP as one PIC will clearly be the controller).

The shift registers would be a nice alternative in terms of cost but MIDI
has no clock so I would have to deal with generating 4 clocks, if possible
in the middle of the MIDI clocks. I would then also have to multiplex the 4
shift registers to the PIC. Thus I would need to have a multiplexed latch
for the data ouput or use a device with >13pin (8 for input data + 2 for mux
+ 4 for clock detect = too many pins). A shift register could at least help
communicate with the other PICs via a nice 2 wire interface yet still allow
parallel transfers if the reciever has more pins than cycles.

My main problem with a Scenix is that of reliability due to my lack of
electronic expeience. I have heard of fairly experienced PICsters burning
out scenix's so myself with little MCU experience would have even more
trouble. I've also heard of some weird things with scenix's like
spontaneously deciding to burn out (I'm not saying a 50MHz PIC @ 50MIPS
would do any better).. The external ADC for a scenix is not a big problem as
I can get a SX28-50 (50MIPS) and a Burr brown 500kHz 12-bit ADC for AU$15
and US$7 respectively. A total of ~AU$30 (have to get ADC from digikey so
add shipping) which compares not too badly with AU$25 for a 'F877 (10-bit
500kHz+ (I think) ADC). The other thing is even one scenix is not
excessively overpowered for the application. 50MIPs should be plenty, but
unfortunately those 50MIPs are spread across a whole second, so getting
everything to work at once may still be a challenge. Also, the ADC will have
to deal with sampling 64-128 voltages and getting extremely linear 7bit
outputs, doing this with only 128bytes of RAM (and doing UARTs etc) will be
pushing it. Hence overall segregation into multiple smaller units has
advantages in terms of both easing many of the design constraints and making
the final system more scalable. That particular virtual peripheral does
8x19.2K UARTs at 12.5MIPS (@50MHz). I would gather then that 4x31.25K could
then be done in less than 15-20MIPS @50MHz (or much the same at any clock).

I think I'll have muck around in MP-Sim and see how that goes. Due to other
tasks it may be that having 2 'F84A's doing 2 UARTs a piece is a workable
solution. However, I'll definitely be investigating thouroughly hardware
UARTs such as the Phillips UART without modem control.

Thanks Ben, Erik, Jay and all,
Tom.
----- Original Message -----
From: Erik Reikes <ereikes@XSILOGY.COM>
Subject: Re: 4 x Serial I\O
> > The main problem is 4 channels of MIDI in. In theory I think it should
just
> >about be possible. The main problem is keeping the timing.
> >I could either poll the 4 inputs or have interrupt on falling edges (Stop
> >bit -> start bit).
> >
>
> This is quite a problem.
>
> This may or may not work, but as I see it your biggest problem is 4 start

> bits coming in at 4 different times asynchronously.
>
> I would set up your Timer0 to give you a beat of Tbit/4, so 40
> instructions.  This will give you fairly decent resolution in your bit
> timing.  Then I would use interrupt on change for your 4 serial lines to
> catch the start bits.  What you want to do is catch each start bit, turn
> off the int on change, and delay one to two Timer0 beats to catch the
> approximate middle of the bit.  The two interrupts could communicate via
> some global variable, that would say how many more beats to sample the
> first bit.  So basically what's happening is that Timer0 interrupt is
> marking off exactly 1/4 bits,  the int on change catches the start bit of
> each bit and signals the Timer0 interrupt to sample at appropriate times.
>
> Any other processing will be done in the down times when interrupts are
not
> being serviced.  Where this gets sticky is the 4 instruction cycle
latency.
>  With a 40 instruction beat, that kills 10% of you CPU right off the bat,
> pllus whatever you use in the Timer0.  There may not be enough to go
around.
>
> Another suggestion might be to byte buffer your serial ins with shift
> registers.  You would need a clock at 31250 KHz and a shift register for
> each line you want to buffer.  The start bit generates an interrupt and
> your micro enables the proper shift register.  You setup your timer0
> interrupt to wake up at least every byte time (which is now 160*8 ~= 1200
> instructions) to pull in the data.  This is sort of a roll your own UART.
>
> Good luck!
>
> -Erik Reikess