Massimo Sanna is a reader of this blog and has designed a PCB for the MIDI Sync Box for all of us to share. Thanks very much Massimo!.
I have now finished the code. Tested it and after a few bug fixes, everything works just great. The final software is 930 lines of assembler. You can download it here if you want to.
I also learnt how to use ProTel so I could draw up the final circuit properly. Here’s the result. Notice that I’ve got it down to just one chip now, the little PIC is doing everything. It can directly drive the LED and the MIDI output. I’ve used multiplexing to enable it to drive the 7 segment display and read all the inputs. The PIC’s built in timer keeps everything running accurately, all in all, I’m very pleased with the result.
I threw it into a box and its done! You can see in this photo that I also added a second MIDI output.
Sorry there have been no updates in months. Things have been busy lately, that’s the problem with having a life. I’m only a part-time geek after all.
Since I last did any work on this project, I have upgraded my PC to a Duron 900 and have installed Windows 2000. I am most impressed with the stability of Win2K, I rarely have more than two crashes per week as opposed to about three times a day under Win98.
However, Windows 2000 will not run the NOPPP software which I have been using to download code into the PIC. I suspect the way ports are accessed in Win2K is not backward compatible with Win95.
To cut a long story short, I have found the Linux version of NOPPP works just fine so I’m using that instead. gpasm is a free compiler for the PIC which runs on Linux so I’m all set to continue development without using Windows.
I’ve redesigned the thing again and got rid of the buffer chip. I’m driving the MIDI output directly from the PIC and it works fine. I’ve used a 7 bit bus arrangement to allow all the inputs to share the same I/O pins as the LED display.
One little hitch was the discovery that the big red illuminated push button needs 12 volts to light up. But I’m running everything off 5 volts. So I’ve made a little adapter out of a small piece of veroboard so I can substitute a LED. I tellya these modern LEDs are so bright! I nearly blinded myself messing about with it.
Well, It’s great to have something work. I finally got it to send out MIDI clock messages and my sequencer accepted them. Yay!
One thing I had a lot of trouble with was understanding the MIDI signals. I couldn’t seem to find much documentation on them. I had to do a lot of trial-and-error and also use my CRO to analyse the signals coming out of some MIDI equipment. Here’s what I found:
MIDI works by current, not voltage. The receiving end has a 1k input impedance and the sender is expected to put a 5V voltage differential across this which produces a current of 5mA. Current flow is indicative of a logic 0. No current flow is a logic 1. There is no current flow when the line is idle.
A fairly standard way to implement a MIDI output is to tie pin 4 of the DIN plug to 5V and pin 5 to your digital output. This forms a hardware inverter so you can use normal logic levels in your circuit.
The data rate is 31250 bps +/- 1%
Another confusing thing is that nowhere is it described how the serial data is sent. The literature will tell you that there is 1 start bit, 8 data bits and one stop bit. Great, just like RS-232 I thought. Well no, it’s not anything like RS-232. The start bit in MIDI is a 0, the stop bit is a 1 and the data bits are sent in reverse order. All perfectly fine but I had to discover this myself.
The firmware is now over 1000 lines and is almost finished. I’ve just got to figure out how to store the BPM setting in the internal EEPROM and it’s done.
I’m steadily building the firmware for this thing. Something that sounds simple is turning out to be a little more complex than I thought, still, that’s pretty normal in the software world. My program is around 600 lines and I’ve still got a lot of stuff left to do.
Another problem I’ve come across is the Potentiometer voltage ramp arrangement has turned out to be not very accurate, the reading varies wildly depending on voltage, temperature, current and just about any other variable you can think of. After wasting a lot of time with it, I’ve decided it’s just not a suitable method for setting the speed.
So instead, I’ve got myself a rotary encoder. This looks like a potentiometer but it’s actually a binary counter which increments as you turn it. It has detents so it won’t drift once you turn it to a specific position and is generally much more suitable for this role.
Of course, I now have to modify the software to read it.
Now it’s time to move back into the software domain. Microchip supply a development environment called MPLAB. You can download it for free off their website. Only problem is, it doesn’t work, it kept giving me these errors “Could not initialise dialog box” and would refuse to compile anything. I suspect that there is a DLL missing in the installer, but I have little time to debug other people’s software.
Fortunately, there is another little utility that comes with MPLAB called MPASM for Windows. This program is a little irritating since it dies after every compile but having to reload it every time is a minor inconvenience compared to MPLAB.
So, finally I managed to compile some of the example code. The next step was to learn the PIC’s programming language and write some stuff of my own.
I haven’t done any microcontroller programming for six years, and even then it was on a Motorola 6805, a totally different architecture; so I expected a bit of a learning curve here. But to my surprise, I managed to learn the new instruction set and write some code that worked within an hour. Writing firmware must be like riding a bicycle.
The time had come to do some more electronics. I put together my LED display and wired it up to the PIC. A little bit of soldering, a little bit of coding and in hardly any time, I had a fully functional 3 digit LED counter tumbling away through the numbers.
I’ve built the little NoPPP programmer. The only problem with the thing is it has no flashing lights of any kind! So I put in two LEDs, one to indicate power and the other to indicate programming voltage.
You’ll also notice that there is no PIC socket in my programmer. That’s because I am going to be doing in-circuit programming.
The NoPPP test mode was very handy in finding a couple of problems with my setup. The biggest problem was the LED I added to indicate programming voltage was draining too much current and the programming voltage dropped to about 8 volts. That was too low so I added another transistor specifically to drive the LED and all is fine.
Then I wired my PIC onto a board and tried to program it. No luck. The verify failed although chip erase seemed to work.
I tested all the voltages again with my voltmeter. Everything seemed fine. Perhaps my PIC was bad. It was brand new so that would be unlikely. I decided it was time for more analysis. I got out my dusty old rusty old CRO and had a poke around. All the data signals looked fine so I kept looking. Finally I found it, the programming voltage would drop to 6V when the chip was being programmed. This only happened for about a quarter of a second which is why I didn’t see it on my voltmeter. When the programmer was in test mode, the voltage was OK. The only difference I could spot was that in test mode, the PIC was not switched into the circuit. It sounded like my PIC might be internally shorted.
I still wasn’t ready to believe that the PIC was faulty. I checked my wiring again. Found it! There was an almost invisibly tiny solder bridge between the programming voltage pin and an I/O pin. So, once fixed, the program could be downloaded just fine.
Next I attached a LED to a random I/O pin and ran the test program that comes with NoPPP. The LED started flashing furiously. It’s a wonderful feeling when something works!
Well, one never gets things right the first time. Looking at that first schematic, I can see it is not the best design. For a start, it uses three chips – way too many. I also ran out of I/O pins so I had none left for the stop button or the MIDI output. I’ve redesigned it using a 7 bit bus approach.
Instead of the 74HC05 buffer, I’ve used a 74HC174 which can latch the MIDI output and allow me to share the bus with the LED display. I’ve also gotten rid of the 74HC47 LED driver, I’m now driving them directly from the PIC.
I went parts shopping today. Jaycar had everything I needed, well, except the PIC. They were out of stock. They didn’t have 8MHz crystals either so I’ll have to use a 10MHz. They also had mysteriously run out of jiffy boxes. Anyway, I got enough stuff to start building the thing.
I did some MIDI research today. It turns out that the MIDI clock protocol is quite simple. All messages I’m interested in are a single byte only. These are the ones I will be using:
The ‘MIDI Clock’ message should be sent 24 times per beat. So at 120bpm, it will need to be sent 48 times per second.
I’ve decided to support ‘MIDI Stop’ as well as ‘MIDI Start’ so I’ve altered the design to include a smaller STOP button beneath the big fat START button.
I’ve also found a schematic for a really simple interface so I can program the PIC from the PC’s printer port (try to say that three times fast!).
I’ve sniffed around several other PIC and MIDI pages on the web today. I’ve found out how to interface the PIC to a MIDI connector and how to make an R/C ramp arrangement to let me read input from an analogue knob. I’ve incorporated these items into my first circuit design.
(click on the circuit to see a larger, more readable version)