Serial data transmission speed

[David]

I was kicking around the idea of trying to implement a MIDI bass pedal controller with a PIC16F628 - until I realized that it didn't have enough pins.  I then tried to conceptualize a master/slave arrangement of two 16F628s arranged so that the master had a set of matrixed "pushbuttons" as its inputs.  When a pedal was pressed, the master would send the "note number" as serial binary data to the slave.  This would generate an interrupt for the slave, which would then transmit a MIDI message.  The 628s would both have to be running at 20MHz.  The fly in the ointment I ran into is that the serial data would have to be transmitted faster than the transmission rate for MIDI.  I also wouldn't be able to use the USARTs on the 628s because I need the slave's USART to transmit MIDI data.

Is there a way to transmit binary data faster (way faster) than MIDI?

[Dave_B]

A lot of the code I see for transmitting MIDI doesn't even use the USARTS, since it can be done with a subroutine.  You could let the 628's talk to each other through the USARTS, then handle the MIDI manually.

Do you have your heart set on using the '628's?  It seems like you could do it all with one chip if you used a larger '877 (for example).  Maybe there's another reason you want a master/slave setup, but if you don't, that could get you there. 

[David]

Sure, I could use an '877.  Ultimately, I probably will.  I was just foolishly and stubbornly dwelling on the master/slave concept because I hadn't seen it used for MIDI and I thought it would be cool.  I'm funny that way.  Actually, it's because I found about 75% of the code that I would need to bastardize written for the 628, and I thought the resulting circuit would be simpler.  The idea of wire-wrapping the 877 circuit I had originally been planning was... intimidating, to say the least.

Nigel Goodwin had projects for the 628 using a matrix keypad and LED digits.  I was going to borrow those.  I've also figured out how to display a digit on a common-cathode LED digit using a BCD display driver.  Anyway, I only need four pins to display a digit.  I also don't have to worry about extra transistors because of current limitation or about creating interrupts to handle display refresh.

If I have the 628s communicate by USART, what "baud rate" could they practically use with a clock rate of 20MHz?  Also, where is the code you referenced?  I'd like to see a sample...

Thanks!

Edit:  Actually, the real reason for the master/slave configuration is that I've seen that a uC has to be running at about 20MHz to handle transmitting MIDI data properly.  I had kind of thought that maybe it didn't take this much horsepower to process a switch matrix and send a binary number to another uC. That might allow me to just use the internal 4MHz oscillator, thus saving 2 more pins.

[Dave_B]

The code I've seen is for the ATMEL Tiny26, but I found this one for the PIC.  It's written for the 16f84, but that helps here (since it doesn't have a USART).  Check out the part of the code "sendmidi:" about 2/3rd's down the page.  Each trip through that subroutine sends one byte of data.

[Peter Snowberg]

Why not transmit at the same speed as MIDI or just send the MIDI from the uC with the switches? If your clock rate is the same it gets much easier to sync multiple serial systems.

For adding more pins, check out the 74HCT595. There is a corresponding chip for inputs, but I don't recall the number at the moment. With the right wiring, you can get 64 buttons out of 4 uC pins and a little programming.

[David]

I think I might have this knocked.  Gonna be a while before I get all the bugs worked out, but if I read this code correctly:

http://files.neonascent.net/4mhzmidisend.asm

I can send MIDI data from a PIC running at 4MHz - the speed of the 628's internal oscillator.  Thus, no 20MHz crystal needed, and I get 2 more pins to play with.  Okay, PORTB is taken up by the keypad.  RA5 is an input only.  So, if I modify the above code to output to, say, RA4 instead of RA2, I can use RA0 - RA3 as a bus to supply my 4511 LED digit drivers.  RA4 will be my MIDI send pin.  I'll use RA6 and RA7 to select which LED digit gets updated (2 buttons are for octave up and octave down.  One of the digits shows the octave.  The other digit will show "harmony" mode (none / octave / third / fifth - represented by blank/0/3/5)  This is also selected by a button and is done by sending the correct note keyed to the pedal and then playing a second note shifted by the proper amount.

This could be cool!  If everything works out, I can get the most important part of what I had planned to do with a 16F877 and a 20MHz crystal out of a 628 and a couple of 4511s!

And if it doesn't work out at 4MHz,  I've got code to use at 20MHz.  I'll put the crystal back in and then shove the Column pins on PORTB into output mode to feed the 4511s. 

I love having options...   

[Peter Snowberg]

David,

Check out the TPIC6B595 from TI. You only need two chips with the 4511s to drive the digits which is much better than the three or four required with 7447s (because of the need for an external latch), but with either of those solutions you're talking about 6 I/O pins. That's a high cost. The TPIC6B595 is a chainable shift register with high current drivers that will allow you to drive as many as a dozen or more digits with just three pins, two of which may be multiplexed with other uses like keypad inputs. The simplified hardware requires a tiny increase in software, but nothing that can't be solved in 5 minutes. You need to add a look-up table to convert the number you want to display to a pattern of on and off LEDs to be fed to the shift register.

The other thing to watch is the actual frequency of the built-in oscillator. It's not a problem for the speed to be all over the place when it's only one chip, but in serial communication you need consistency. Try to avoid internal oscillators when using serial communications. Crystals and quality ceramic resonators are the only way to go.

[David]

Oh, goody!  One more option!   

Man, that TPIC6B595 looks like the cat's meow!  I ordered a couple of them to fool around with.  Also managed to find a project that used some of them with a '628 to drive LED digits.  How convenient!   

Once I get the keypad logic working, me gonna be having lots of fun!   

[David]

I'm getting output from my test bed, but it sure isn't what I expected.  I need to get the key response pattern straightened out and to tweak my code so it outputs only while the key is held down.  In order to debug the keypad, I have a stripped down circuit which consists of the 628, a hex keypad and 5 LEDs.  The circuit is supposed to output the binary number corresponding to the key and display this number with the LEDs (not a digit - individual LEDS so I could eliminate the 4511 as a culprit).  I'll report back when the keypad gives me the results I need.  At that time, it'll be time to put the LED digit functionality back in.  Then I can move on to MIDI note output.

[David]

That was weird!  I just spent a couple of days trying to figure out why the results I got from my keypad were different from the results I predicted from my program.  It turns out that the pinout of my keypad is nothing like how it's labeled.  This morning I figured out how to move the keypad connections around to get my outputs to come out as {1,2,3,4}, {5,6,7,8}, {9,10,11,12}, {13,14,15,16}.  I also found a code snippet from the PicList which is supposed to be able to detect when a key is released, so now I can figure out how to do that.

Actually, detecting key release was mind-numbingly simple.  I'm almost embarrassed!
Now to see if I can get the thing to play some music at 4MHz...