Building a MIDI keytar

Status
Not open for further replies.
Vcap can make or break a pic24 project ! also AVdd AVss as well I don't follow that MCLR connection ... PIC24FV32KA304 . is good choice


R1 is 100R R2 is 10k
MCLR VddVss
 
Last edited:
Looking at the \( \overline{MCLR} \) line, the cap (C1 on the image you posted) seems to be a reset cap.
The manual implies that it needs to be disconnected when the PIC is being programmed.

I have an ICD3, so I'd like to be able to program the device and use the debugger functionality.



To use the ICD3, which pins do I need to use? Or better yet, which pins can I eliminate and open up as ports?
Another thing I'm thinking of is using \( \overline{MCLR} \) as an output port. if C1 is omitted, the C for the reset time constant
would be the input of whatever gate is there.

I guess what I'm thinking of doing is programming the \( \overline{MCLR} \) / Vpp / RA5 to be an output port.
Is that even possible?

To get rid of the Vcap problem, it may be as simple as choosing a 24F32KA302 as opposed to the 24FV32KA302.
 
I guess the best place to start is at the power supply. The ideal situation is to use a 5v USB wall wart (The kind that comes with most cell phones.)
and be able to charge a Lithium battery of some kind.

I found this:
https://www.maximintegrated.com/en/products/power/battery-management/MAX1874.html
I'm wondering if I could use a cell phone battery pack and charge it from the USB using this chip.

That would give me 3.3 volts and I can use the 24F series PICs.
 
I'm going to try the internal clock too. It looks like I can get another 2 I/O pins.
Click to expand...
I wouldn't do that.
For the serial connection You have to use a pretty exact clock signal.
When the frequency is not exact it can make some transmission issues.

For keyboard scanning I would only use one microcontroller with enough ports / pins.
The alternative is to use an decoder chip ( hex to 1 Output e.g. 74HC4514 ) or an shift register.
Both will slow down processing time.
With velocity You have to make 128 scans to generate one MiDi frame.

For the Display I would use hardware SPI.
That's faster then an I²C connection.
Why You need an external EEPROM?
Has the 24Fxxx no internal one, or is it to small for storing all of the values?

For Lookup Tables You can also use the Program memory ( Flash ).
Better is to load them once and store them into RAM, because the aquire time should be shorter.

All depends how much space is in the different memorys availible and how fast had it to run.
 
Last edited:
MichaelaJoy said:
To use the ICD3, which pins do I need to use?
Click to expand...
Either pair PGEC / D can be used for debug / program has to match the FICD config setting. after program can be used as IO ... but then debug not available ( !) i tend to use as just as ICSP
MichaelaJoy said:
Another thing I'm thinking of is using MCLR¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ \overline{MCLR} as an output port. if C1 is omitted,
Click to expand...
Think RA5 can only be input if not MCLR
Choosing mcu can be a bit of a roller coaster. i have several diy PIC dev boards 100 pins down to 8 , if i can during prototype start with more IO and code / data space, than may be needed. 3.3v devices are ok if you don't need to do lots of level translation.. ( 3.3v PICs have some 5v tolerant pins )
wkrug said:
For the serial connection You have to use a pretty exact clock signal.
Click to expand...
Not noticed any frequency / serial problems with using internal osc. with the PLL registers and osctune register for adjustment ..
MC have several development boards with 28 / 44 pin PIC's I have a couple of "microstick II" with 28pin PIC24 has programmer / debugger on board. nice for testing code , not sure if still available..
 
Last edited:
wkrug said:
I wouldn't do that.
For the serial connection You have to use a pretty exact clock signal.
When the frequency is not exact it can make some transmission issues.
Click to expand...
wkrug: In a previous post, I said that I was going to try both with a crystal and without.
So, I won't say that it can't be done until I've tried it.
Worse case, I'll have to put a crystal and a pair of 22pf ceramic caps on the board and reprogram the CPU.

wkrug: Remember: We're talking about a 49 note keybed, and we're talking about the keytar only.
In a larger unit, I will need a larger CPU, especially if I'm going to try to control a larger keybed (or more than one.)

Take a look at the Alesis Vortex. It only has a 3 digit numeric display that is used for the current program number.
The MIDI channel is set by pressing a combination of buttons and pressing the keyboard in a specific range.

They do it like that so that they use as few port lines as possible.

wkrug said:
For the Display I would use hardware SPI.
That's faster then an I²C connection.
Click to expand...

wkrug: For the keytar, the display is going to be a very small numeric display.
I2C should be fine, because I'm not doing anything that would require a lot of speed.


wkrug: I'm still looking into that, and whether the PIC I chose is big enough to do what I need to do.


granddad: Since I really do not gain anything by reprogramming the MCLR line, I'm just going to leave it as is.

I'm also looking into having an adapter made for 24FV32KA304. I found these guys on the web.

https://schmartboard.com/schmartboard-ez-0-5mm-pitch-44-pin-qfp-qfn-to-dip-adapter-204-0045-01/

The adapter is $6.00 USD. For another $6.00 they offer a soldering service as well.
You buy your part from whatever distributor you like and mail them the part.

All together, I think I can get by with spending about $22.00 with shipping.

It's still too early over here, but when their store opens, I'm going to give them a call and get all of the details.
 
For more I/O you can use shift registers.
Serial in > latched parallel out for outputs and parallel load > serial out for inputs.
Using an SPI port at high speed you can update a lot of outputs and read a lot of inputs in a very short time.

Using a DSPIC33 at full clock speed you can should be able to eg. update blocks of 16 inputs and 16 outputs in a 100KHz clock interrupt routine with little overhead. With some switch multiplexing thats a lot of fast inputs with just four pins, the SPI port and a "latch" output.
The 74HC594 & 74HC597 are suitable types.

If you need high current drivers, the MIC5841 and MIC5891 are excellent; low and high side drive respectively.

[I also like to avoid surface mount when possible; you can do an awful lot with a 28 pin DIL PIC and suitable expansion..
Our standard devices at present are the DSPIC33EP256MC502 & DSPIC33EP512MC502, they have masses of memory and just about every peripheral imaginable, with assignable I/O pins].


Be wary of I2C unless you are polling the TX and RX ready bits and reading/loading data explicitly in your own code.
Some I2C subroutines or compiler functions hang at each command until the byte transfer sequence is completed, which can be some milliseconds each time. That's not good for high-speed real time work.
It can be OK using generic routines if that part is in your main loop and all the time-critical stuff in done in the clock interrupt, but just something to be aware of.
An SPI or parallel-connected display is much less finicky.
 
rjenkinsgb said:
Be wary of I2C unless you are polling the TX and RX ready bits and reading/loading data explicitly in your own code.
Click to expand...
Agree. I built my own back-pack LCD (PIC18F14K22). and just throw data at it at 200khz. for just a simple seven segment display sparkfun have a serial SPI I2C (all 3) 4 digits , got one not tried it seriously yet
 
rjenkinsgb: Thanks for replying.

Take a look here: https://schmartboard.com/schmartboard-ez-0-5mm-pitch-44-pin-qfp-qfn-to-dip-adapter-204-0045-01/

Depending on the outcome of the conversation with these guys, I'll switch over to the 24F32KA304, which is 44 pins and 3.3 volts.
If they can do it, I'll have them mount the CPU to the adapter pictured above. That will provide me with more I/O pins and
the ability to use SPI. The display doesn't need to update continuously in real-time, so that should ease the timing requirements.

I'm using a 49 note key action which has a diode board on it. The output connector is an 26 pin IDC plug with two rows of 13 pins each.
I still have to reverse engineer the keybed to determine which pins are signal, ground and voltage.
Once I do that, I can determine the best approach to scan the keybed.

I won't post that information here because it's more than likely proprietary to Roland, and I don't want to cause problems.

As a preliminary thought, I may be able to use a 74AC138 to generate the "row" drive signals and a pair of 74AC573s to capture the column scan lines.
 
Remember: We're talking about a 49 note keybed
Click to expand...
Yes I know.
For an 49 note keybed with velocity ( 8Bit ) You need 8 Ports ( Note lines ) + 7 ports ( NO Lines ) + 7 ports ( NC Lines ) = 22 ports.
Calculation 8 Bit * 7 lines = 56 notes.
Without the possibility of velocity You have to had 15 Ports.

IMHO it will run faster, is easy to route and at the end cheaper when using a little bigger controller instead additional decoder chips.
@ MJ You was faster .
But both should be possible.

The most importent thing is how the keybed is cabeled.
Do You have a schematic for this ?

My Idea is to pull down the lines behind the diodes and readout the NO and NC Lines that has an pullup or pulldown resitor.
After 8 Steps the complete notes are ready for processing.
After pulling down first bit, readout NO and NC Lines and step to bit 2.
Then process the result of the first bit scan to give enough settle time, because the processing take a little bit of time.
Then readout the second bit results, step over to bit 3 and process results of bit 2 ... and so on.

At the end You can prepare the first bit for the next round.

I guess the keybed has a little capacitance and so the drivers has more time to load this up.

To get a proper timing i would configure a timer and set a flag in fix periods.
In main routine the keybed scanning starts when this bit is set.
At the end of the scanning routine the bit can be cleared.
 
Last edited:
wkrug: So I went to proto advantage and had them fab up a 44 pin dip to 44 pin TQFN adapter. I had them solder the 24F32KA304
package to the adapter. That should give me extra I/O ports and solve the scanning problem.
It will take about a week for the finished board to get to me.

I still have to reverse engineer the keybed and generate a pinout. The output connector is an 26 pin IDC plug with two rows of 13 pins each.

I'll start that process in a bit.
 
wkrug: Thanks. But it's not pinned out exactly like that. I have the Roland A33, and it has a pair of those 16 pin plugs.

At this point, I'm thinking that it might be custom made by Roland.
 
Okay. A picture is worth a thousand words.

Here's the keybed:

Top:


And the bottom:


This keybed is not easily serviceable. You have to remove all of the keys to get to the contact board.

Here's the removed contact board.


And here's the bottom.


Here's a closeup of the connector.



The pins are labeled as follows

On the keyed side:

T0
T2
T4
T6
PM7
PM6
PM5
PM4
PM3
PM2
PM1
XX These two appear to be not used.
XX

On the non-keyed side:

T1
T3
T5
T7
SM7
SM6
SM5
SM4
SM3
SM2
SM1
XX These two appear to be not used as well.
XX
 
The A37 appears to use the same two-contact rubber switch system.
(From the same web site) https://www.synfo.nl/servicemanuals/Roland/ROLAND_A-37_SERVICE_NOTES.pdf

The key mechanics drawing (Page 4) shows the PM contact towards the back of the key and SM nearer the front; that looks like PM is the timing start and SM the key-down one.

The key matrix drawing on the last page shows the generic contact & diode matrix, though that still has the switches labelled BR and MK, presumably a hangover from the older changeover style wire contacts.
I'd guess the terminal names on your A49 connector will be banked in the same groups of eight strobes and paired contacts.
 
MJ at this rate u be done and dusted by weekend

Roland A37= interesting they use a dedicated IC for key scan ...
Re the
 

It'll take about 5 to 7 days to reach me. Maybe less. (fingers crossed)

Nothing I can do about it, so I'll concentrate on the remainder of the board design.

I started to look at this problem a few years ago. The dedicated chip was / is the greatest showstopper in building any keybed interface.

I didn't have a logic analyzer or a scope back then. So I purchased a Tektronix 2465B and a HP 1662C.
The HP1662C cost me $150 USD plus $30USD shipping. The 2465B was a little more than that.
I got it from ebay for $300USD. They said it worked...it didn't. I found a guy who refurbishes Tek scopes
out of California. He charged me a flat fee ($600USD) to refurbish and cal it.

Guaranteed for 6 months...At about 9 months, one of the chips started to act up.
He repaired it for free (Just the shipping)

Anyhoo...

So, on to the next hurdle...the power supply.

For now, I'm going to use a 9VDC wall wart. I'm running the DC through a bridge rectifier for two reasons:

1 ) If the polarity is reversed, the bridge will switch it to the correct polarity and nothing gets blown up.

2 ) The voltage dropped across the bridge should provide about 7.5V (roughly), which will go into a 7805.
That should keep it fairly cool. I have a LDO adjustable regulator (MIC2941A) which I'm going to set up for 3.3V.

I'm wondering if I can take the regulated 5V and run that into the MAX2941 for 3.3V.


After that...the MIDI I/O.

I was snooping around the web and I found a few MIDI interface schematics.

The MIDI receiver looks fine. It's the MIDI out that bugs me. Even if it is through a 220 ohm resistor, I just don't feel comfortable with driving
the MIDI out with the pin from a CPU directly. I just don't feel comfortable doing that.

I'm wondering if a CD4049 (or CD4050) would be a better way to drive the output port. If something happens to the MIDI cable on the MIDI output,
couldn't it short the output port of the CPU?

Maybe I'm paranoid...Maybe I know about Murphys' Law ("Nature always sides with the hidden flaw")

So the scan logic looks like it going to be 74AC573 x 3. I was going to use a 74AC138 to clock the lines, but the outputs are active-low.
 
Last edited:
granddad : Thank you. That's what I thought.

I should be able to use a 2N2222A
The 4069 will also be used in the MIDI receiver, giving me 3 extra gates for somewhere else..
 
Status
Not open for further replies.

Similar threads

  • Question
Assistance in building a moisture probe and circuitry
Replies
0
Views
1K
chopnhack
W
  • Question
Building a quantized sequencer without programming (MC)
2
Replies
28
Views
6K
liamjerr
L
I need some advice on building a battery charger for my bank of 20 Li-ion 5000mAh 26650A
2 3
Replies
40
Views
6K
sheffieldyorky
E
  • Question
Building a Crystal Radio first time
Replies
16
Views
8K
edteach2
E
B
Building a dim bulb current limiter
Replies
4
Views
2K
briesmith
B
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…