Well, I thought that tonight would be the night when I got the MPG-200 up and running with the JX-3P for the first time. Alas, I failed miserably ;-)
I've checked the output from both the MPG-200 and the PG-200, and they both output the same signals. BUT - I've forgotten that I implemented running status support on the MPG-200 (which means that the midi device generating the CC messages does not have to send the controller number again as long as it is the same controller as the previous one). The JX-3P on the other hand, does not support running messages, so it has to explicitly get a controller (or address as it is called in the PG-200 service notes) message for every data message. I have forgotten to implement this and instead just send the new controller value. Not a hard thing to fix, but missing none the less.
Here is a picture of my setup btw:
To the left is a macbook connected to a saleae.com logic probe, which I used to decode the PG-200 signals. The white square to the right of it is a prototype card/solderless breadboard, with all the necessary electronics (except for the microcontroller and associated circuitry) for interfacing the JX-3P. Behind that is my good old Mikroelektronika EasyPIC3 development kit, connected to a different PC (behind the synth). This kit holds the microcontroller. To the right of it, just beneath the big screen is the JX-3P, and below it is the guts of the PG-200 (the box is actually under it). To the far right is my Australian Redback edition Little Phatty which I only use as a midi controller in this setup.
Sunday, November 11, 2012
Saturday, November 10, 2012
Ask google
For a while now I've been working on the MPG-200 (Midi enabled PG-200). One of the challenges is that while midi is 8 bit serial, the PG-200 runs 9 bit. Because of this, I've been trying to use a normal output pin for transmitting data to the JX-3P, while reading midi using the built-in UART on the microcontroller (PIC 18F series).
Aside from some rather ugly code, I've had some trouble getting the "bit banging" to work fast enough - I tried to send one bit at the time through an interrupt routine, but even with almost no code in the interrupt handler, the minimum delay between invocations was higher than I needed to achieve 31.25kHz transmission.
I did successfully implement a method where data was sent in one go, with NOP instructions in between bits for timing, but that takes a full 1/4000 of a second for each byte, in which time the microcontroller cannot do anything else.
So, to try to figure out how everybody else do their bit banging (...), I asked Google. The first post I found was this: http://www.embedded.com/design/embedded/4006445/Tricks-with-PICs. Here, I discovered something cool. The PIC family can actually transmit 9 bit while still receiving 8 bit! All my problems suddenly vanished :-D
The moral of the story is: Ask google, there's always someone who has done what you want to do before you :-)
Aside from some rather ugly code, I've had some trouble getting the "bit banging" to work fast enough - I tried to send one bit at the time through an interrupt routine, but even with almost no code in the interrupt handler, the minimum delay between invocations was higher than I needed to achieve 31.25kHz transmission.
I did successfully implement a method where data was sent in one go, with NOP instructions in between bits for timing, but that takes a full 1/4000 of a second for each byte, in which time the microcontroller cannot do anything else.
So, to try to figure out how everybody else do their bit banging (...), I asked Google. The first post I found was this: http://www.embedded.com/design/embedded/4006445/Tricks-with-PICs. Here, I discovered something cool. The PIC family can actually transmit 9 bit while still receiving 8 bit! All my problems suddenly vanished :-D
The moral of the story is: Ask google, there's always someone who has done what you want to do before you :-)
Subscribe to:
Posts (Atom)