On Sun, May 28, 2000 at 09:38:33PM -0400, Bob Ammerman wrote: > There are some good ideas here, but you have moved the data movement problem > from SERIAL<->PIC to be PIC<->PIC. You're still going to need some hefty > horsepower to do the PIC<->PIC transfers. Remember, the main processor has > to handle all channels at once. MIDI waits for no man (nor PIC) :-) This is true to a point but you can gain a few advantages: 1) Many of the mid level PICs have hardware support for such transfers. A 16F87X could use its hardware USART or I2C module to do the transfers thus eliminating the high powered need for software bit banging from the main PIC. And while the auxillary PICs are stuck with the software bit banging problem, their function is limited to a single channel. Thus you gain an advantage because the aux processors are not trying to do everything in the system for all channels, just limited functionality for a single channel. 2) Intelligent buffering can mitigate quite a few of the tight timing contraints in the PIC to PIC transfers. In short the main processor can dump events that it knows is going out to the intelligent UART before the actual moment the event needs to be played. This happens often in a multichannel MIDI situation because the primary usage is as a multitrack MIDI recorded where the sequencer plays some or all of the prerecorded MIDI tracks while the musician adds the next track to the sequence. The timing sequences of the prerecorded tracks are known apriori and can be scheduled accordingly. 3) Compression can be utilized in the PIC to PIC transfer whereas with a straight UART the exact data stream that's required for the end unit must be sent to the UART. For example each event in the MIDI stream encodes a 4 bit channel number. However if an intelligent UART knows that it's only going to output 1 channel, or possibly two because of a a keyboard split, then the channel information isn't required at all in the PIC to PIC transfer, potentially saving a ton of bits. Another example is that typically in MIDI streams a NOTE OFF events is generated by sending a NOTE ON event with a volume of 0, requiring 2 to 3 bytes in the actual MIDI data stream. However we could easily compress a note off event into a single BIT in the PIC to PIC stream, having the Intelligent MIDI UART (IMU) do the proper expansion on output. 4) The potential of direct IMU to IMU communication can potentially alleviate the latency caused on the real time streams that are being recorded. See typically the controller generating the real time stream and the one playing that realtime stream are not on the same IMU. For example I generate my MIDI events using my Yamaha digital piano, but those events are played on my Alesis Nanosynth or my old Roland MT32. So the transfer sequence is Input IMU -> main processor -> Output IMU. This would require a low latency main processor to turn the events around quickly. However if instead the transfer can be Input IMU -> main processor and Output IMU, then the Output IMU would get the event with lower latency and the main processor could take more time recording the event because it's not obligated to turn the event around to the IMU. MIDI streams have structure. This structure can be exploited by an IMU type system. But it requires something more than a dumb UART. This would be the exact reason I'd look to a software periperal. BAJ > > Bob Ammerman > RAm Systems > (high function, high performance, low level software) > > ----- Original Message ----- > From: Byron A Jeff > To: > Sent: Sunday, May 28, 2000 8:22 PM > Subject: Re: [EE] Microcontroller with 4 USARTs and 40 pins > > > > On Sun, May 28, 2000 at 06:21:24PM -0300, Edson Brusque wrote: > > > > >If it don't say anything more, it may be the classic 8051's: one > machine > > > > >cycle is formed by twuelve clock cycles, and the instruction cycle > > > > >depends on the particular instruction. > > > > >If You want more speed enhacement look at Dallas MCS-51 compatible, > > > hi-speed > > > > >micros. > > > > Or the AVR, at one xtal clock per instruction (a few take two). 8 mhz, > but > > > > that's 96 to an 8051 apparently. > > > > > > Ok, but beside the Scenix, there's no 8-bit microcontroller capable > of > > > doing more than 20 MIPS??? > > > > > > And what about the 16-bit micros? Can it be a good option for my > > > project? A US$10-20 microcontroller isn't very expensive to me if it can > do > > > all I need on this project. > > > > A piece of advise. Stick to environments you know instead of striking out. > > Especially when your striking out for more MIPS because you want them for > > something that's easily done in hardware. > > > > I'd advise sticking with PICs. Let me throw out a couple of suggestions. > > > > 1) I'm planning on using a Cirrus Logic CL-CD180 octart. Unfortunately > Cirrus > > Logic has obsoleted the part. In fact they've spun off their communcations > line > > into Basis Communications. I have a couple of samples and an incomplete > > data sheet. If anyone has the pinout I'd really appreciate it. I liked the > > part because of the number of serial ports and the fact that it came in a > > 84 pin PLCC package making it easy to use to hobby work. Basis Comm does > have > > an updated version the CL-CD1865. But it comes in a 100 pin PQFP. Not real > > easy to prototype with. > > > > 2) My second choice was to build an intelligent UART out of a PIC. > Specifically > > for MIDI conversion of the stream into events with timestamps would be > > very useful. Also having buffering so that the main processor can dump > > events ahead of time and have the intelligent MIDI UART deliver them to > the > > channel at the appropriate time. Also doing MIDI channel mapping, splits > and > > volume control in the UART seems interesting. It's also interesting to > consider > > direct transmission of events from one UART to another bypassing the main > > processor. > > > > A single software channel can easily be handled by a 12C509 with a > software > > UART. Of course developing the UART code, the interface to the main > processor, > > (probably something I2Clike) would take some effort. But once it's done > > any number of channels could be added to the system and the main system > > wouldn't have to be uberpowered. > > > > > > Maxim has an interesting discussion in their MAX3100 intro describing the > > issues of software UARTs. You can find it here. > > > > http://dbserv.maxim-ic.com/tarticle/view_article.cfm?article_id=53 > > > > The bottom line IMHO is that the traditional approach is better than the > > Winmodem approach because you end up having a highly overpowered processor > > just so that you can have the MIPS to bit bang UARTS. Just remember that > > 8 12C509's will give you 8 MIPS just for the UARTS. Think about the > > distributed processing solution. > > > > BAJ