I'm working on a very simple midi controller using an Arduino Yun.
I'm just wondering, when no data is being sent should the TX always be high? My multi meter is showing TX as always high. When I press the button that triggers a MIDI note on the multimeter shows a drop of 0.01v.
I am wondering if this could be causing my current issues as no MIDI data is being sent to my MIDI controller.
Is this normal behaviour for TX?
My code is below on the Arduino Yun:
int buttonPin = 3; // Pin that button is connected to
int ledPin = 8; // Pin for the LED light
void setup() {
// nothing happens in setup
pinMode(buttonPin, INPUT);
pinMode(ledPin, OUTPUT);
digitalWrite(ledPin, LOW);
// Set MIDI baud rate
Serial.begin(31250);
}
void loop() {
// Read input of pin3
bool isPressed = digitalRead(buttonPin);
isPressed = !isPressed;
if(isPressed)
{
digitalWrite(ledPin, HIGH);
noteOn(0x90, 0x1E, 0x45);
}
else
{
digitalWrite(ledPin, LOW);
}
}
void noteOn(int cmd, int pitch, int velocity)
{
Serial.write(cmd);
Serial.write(pitch);
Serial.write(velocity);
}
Yes I have a pullup resistor, that's why I flipped the isPressed. The LED lights up fine when the button is pressed. I have the female MIDI connector setup correctly too.
Naturally when a button is pressed it's value would be on. But with the pullup when the button is pressed the value is 0, which is off. So it makes things a little confusing when thinking about them. I like to use logical complement to make it more natural to read in programming. It makes if statements easier to follow.
But right now code quality isn't my main concern as I'm just playing around to learn electronics.
I've uploaded an image of my circuit if it's any help
Well not really, what is needed is a schematic. Common mistakes are wiring the socket as if you are looking from the wrong side. However I don't like that sort of MIDI output circuit, it is not very good. I prefer one with a transistor, like I used here:- http://www.thebox.myzen.co.uk/Hardware/MIDI_Shield.html
I noticed you edited your post and flipped the if and else as I was submiting. To me that doesn't make sense to read when debugging, because if "if(digitalRead(buttonPin))" looks as if it's saying "If digital read for button pin is true". I'm a stickler for easy to read code at the cost of a few extra finger presses.
Well that is how grown ups write code. It is only not easy for you because you are inexperienced. For example why use an external pull up resistor whether is an internal one you could enable?
Yes I misunderstood what you were doing because most external resistors are used in the pull down mode.
Anyway however you code it if the led is going on and off then you are sending MIDI messages but something in your hardware is wrong so it is not getting through.
Yes that will do as well but it is going round the houses.
It is still wrong because it will spam the MIDI system, it will not just send one message per push.
I am a professional programmer. And I happen to prefer more readable code over code that has the potential to confuse.
You can not tell me this if statement reads correctly:
if(digitalRead(buttonPin)) {
// The button has not been pressed ...
}
That makes no sense when glancing at the code. It's just personal preference dude. Chill. Don't judge me on one dirty little program that I'm using to learn electronics. It's god damn awful code I will admit, but it's not like I'm building web services in Java that have to pass QA is it?
I'd have discovered the midi issue ... if I was able to send MIDI messages, but I've gone wrong somewhere on the board so I haven't been able to even get to that point.
In Digital electronics, there are a boatload of Negative logic scenarios. Starting with the 7400 "NAND" gate, you have a "Negative AND" and it just carries on from there.
When doing real world interfacing there are going to be a lot of times when you perform a task to ACTIVATE something, you must bring a pin to a "0" state for this to occur.
So, while I understand where you are coming from where 0 = False anything else must be True... I say that it is you that need to adjust you expectation that "asserted" is the same as true.
Your logic much match your hardware and your goals... that is the only truth.
No spam (see reply#3), just one message (guaranteed) if you detect (and act on) change of state for your buttons. That is, detect when a button has just been pressed or just been released.
Processing sections of code repetitively "while" a button is pressed or "while" its released is rarely needed and it wastes MCU cycles, kind of like using delay().
