Hi,
I'm planning my next project, which will be a laser harp, with an onboard synthesiser using the retro sounding YM2149F chip. That chip requires super fast pin switching and so I will be running it directly off of the arduino nano's digital pins. This takes up 10 I/O pins, leaving little room for other components, so I am using several 74HC595 shift registers to handle the 20+ inputs and 20+ outputs that the project requires. However, these shift registers need to be reasonably fast also, since this allows me to be able to calculate velocities of the 'strings' being played on the harp. To achieve this speed, I will use the Arduino's RX and TX pins.
My issue is that with such an awesome synth, I would like to be able to plug my keyboard into it, which would require a midi input, and I would like to also be able to send MIDI data from the harp, which requires a MIDI output.
My Question is:
Would I be able to use the arduino's built in Serial connections for both the MIDI I/O and the shift registers? Or would a software serial connection be sufficient (and possible) for midi?
Use SPI.transfer( ) to move data in & out of shift registers, not the Rx/Tx pins.
Move up to a 1284P based board for 32 IO:
2 used for Serial
2 used for Serial1
4/5 used for SPI (SCK, MOSI, MISO, chip select, latch for incoming shift register data)
24 free for other things.
I offer boards in several form factors, including my largest (10cm x 10cm) with battery backed RTC, 3.3V buffered SD card, some prototype area, buffer for RS232 if needed, data/power/gnd available at each header location, and optional screw terminals:
http://www.crossroadsfencing.com/BobuinoRev17/
Ahh - thanks, didn't realise about SPI with shift registers, this will allow me to control the MIDI and shift registers without any funky wiring - I think I do have just enough pins to do what I want on the nano, and I can always use analog pins as digital ones should the need arise. Problem solved! Thanks again for the help!
That chip requires super fast pin switching and so .....
No it doesn't, you can run that off port expanders or shift registers. In fact it will be better because you will not have the slew associated with either outputting one output pin at a time, or from direct port addressing spread over more than one chip.
To achieve this speed, I will use the Arduino's RX and TX pins.
These pins are no faster than any of the others.
since this allows me to be able to calculate velocities of the 'strings' being played on the harp
The problem with this is that you have to scan all the strings to see if any timing needs to be started. You will be better off using a port expander chip on SPI, these allow 16 inputs to generate the output on one pin if things have changed, therefore you don't keep having to read all the pins just to see if anything has changed.
Thanks for the clarification, but I have been working from this article , which suggests that the chip in question requires the buffer to be written within 50ns and it provides optimised code to achieve this. Is this kind of speed really possible with shift registers?
As for the RX and TX pins, this page suggests that the arduino has a hardware serial interface built in, which would be appropriate for my scenario with midi interfacing. However, I have never used them before, so may be wrong, but if I have those pins free anyway, then I might as well use them.
With the calculation of velocities, my tactic is to put all laser sensor pins on shift registers and set to High, with each of the outputs of the shift registers being wired through a sensor (LDR), then to a single Arduino analog pin. without meddling with any shift registers, I would scan for a notable difference in the analog reading, start a timer, then wait until the value stabilises and stop the timer. It can be assumed that the value represents a fully broken beam and the time represents the velocity. Then, I can scan through all of the sensors to establish which one has been broken and synthesise the relevant note.
The only way this could fail would be in the event of two beams being broken at once. In this case, it can be assumed that the velocities are all the same; it would be unusual for a piece of single staffed music to do anything otherwise.
requires the buffer to be written within 50ns
Can't even do that without shift registers: 16MHz = 62.5nS clock.
Best you can do is wire the laser sendor pins together with diodes to create an interrupt - on the interrupt, capture the state of all shift register inputs (simple pulse at the latch input) then shift in the data at 8 MHz rate with SPI and act on any notes that are active.
I don't see how analog comes into this - either the laser is blocked/reflected, or it is not, yes?
I didn't think that you could do it with shift registers, but luckily I have just enough pins to run it straight from the arduino like in the article I referenced. As for analog, I was planning on using LDRs for the sensors, which would have the lasers shining directly at them. The LDRs would give me an analog reading, which I can use to estimate how much of the laser beam has been broken (the beam is around 5mm in diameter). Provided I can get at least two measurements from the sensor as the beam is being broken, I can estimate the velocity that the beam is being broken at.
I'd rather not do anything particularly complicated on the hardware side to achieve this, since it's just an added bonus really, if I can get it to work then great, but i doesn't really matter a huge amount. However, I have a large amount of experience on the software side and so am fine facing any challenge regarding code.
the beam is around 5mm in diameter
The thinnest part of my pinky finger, the very tip is 15mm. More than likely you will only see whole beam breaks, and you will want faster response vs slower response,
Fair point; I think I will just leave the whole velocity thing out of my planning for now and just wait until I actually have a working prototype. However, some maths:
You can move your hand into the beam at about 1 m/s = 100 cm/s.
That means that it takes around 10 ms for your hand to move 1 cm and 5 ms to travel 5mm.
Therefore to fully break the beam it takes around 5 milliseconds.
If the sensor could be read every 1 millisecond, then a fair estimate of the velocity could be calculated. Does that sound plausible?
If you say so. Gonna take some practice moving a finger tip that slowly. Stringed instruments are not usually played that way.
Well, it is stringed with lasers :). Thanks for everyone's help - I can't wait to get this thing built and master my laser harp skills ! (both playing and making it). I might do an article on it when (if?) I get it all working.
but I have been working from this article , which suggests that the chip in question requires the buffer to be written within 50ns
You misunderstood that article maybe even the author did not understand what he did. He arranged those lines to be switched at the same time not one after the other. Did you understand the bit about the slew? You can do exactly the same thing with shift registers or port expanders, that is switch both control lines at the same time.
the arduino has a hardware serial interface built in, which would be appropriate for my scenario with midi interfacing.
Yes it does and yes you can use it as a MIDI interface, those pins are also used for programming the Arduino through the IDE so you have to disconnect or switch out the MIDI circuit when you program the Arduino.
But that is not what you said, you said:-
However, these shift registers need to be reasonably fast also, since this allows me to be able to calculate velocities of the 'strings' being played on the harp. To achieve this speed, I will use the Arduino's RX and TX pins.
Which to me reading it does not say you want to use these pins as a MIDI interface, it says you want to use these pins to drive shift registers.
After re-reading both the code and the article several times, I now understand the point that you are making about the shift registers being a very viable option. Looking at the datasheet for the chip, I can see where the 50ns is referenced and the purpose of the two pins that are being switched. What you were saying about slew makes sense now - I thought, since I did not fully understand the optimised pin switching that the pins were intended to be switched one after another. Doh! The oscilloscope never lies, I should have trusted it!
As for actual implementation, is there anything funky that I need to do in order to achieve the synchronous pin switching with the shift register, or would a standard implementation achieve this anyway?
You're completely right about my original post being unclear - my brain must have been partially marmalised while I wrote it. I dunno. Friday evening syndrome? Anyway, good point about disconnecting pins 1 & 2 while programming it. I'll put in a dpdt switch to break the connections when appropriate. As long as there's no midi cable plugged in then nothing bad should happen, but better safe than sorry!
would a standard implementation achieve this anyway?
Yes it would. Bits are loaded into the shift register one at a time but they are not transferred to the output until the latch pin gets the correct edge. This means that all the pins change simultaneously.
s long as there's no midi cable plugged in then nothing bad should happen,
Nothing to do with the MIDI cable it is the MIDI interface circuit between tha cable and the Arduino that screws things up.
This is what I did:-
http://www.thebox.myzen.co.uk/Hardware/MIDI_Shield.html
Shift registers sound like a simple solution that works better than the arguably more complicated one in the article (code-wise at least). And as for the RX/TX protection, a switch seems like a nice and simple solution also.
Also, some further reading of the datasheet revealed to me that it is quite simple to re-gain the pins lost by the YM2149. Probably won't use it, since it can only really be used for inputs and shift registers are really cheap anyway, but could save me some PCB space. I was looking at the schematic for the ZX spectrum (which uses a pin compatible variant of the YM2149) and it uses that technique to gain some inputs.
