I’m working on the old Floorboard project. The circuit is breadboarded and hooked to an old keyboard I’m willing to sacrifice in order to get this thing running. So far, it’s not. I’m decent at troubleshooting audio circuits, but a digital circuit is a horse of a completely different color!
Assistance desperately needed (and begged for)!
Here’s all I’ve been able to figure out:
I’m using a 16F877 instead of the 874 because I couldn’t get any 874s that ran at 20MHz. I compiled the program with the “USE AS KEYBOARD” option. It compiled and linked flawlessly. The PIC also was loaded flawlessly. The circuit?
Power: 9V wall-wart feeding a 7805 with a 1000uF cap before and after. Rock-solid 4.99VDC. Also got 4.99 at all Vdd pins and the pin that feeds +5V to the MIDI output.
Output: NOTHING! Keyboard silent. Also tried putting an oscilloscope on the PIC output, hoping to catch logic pulses or something. Also nothing.
Could I get some advice on troubleshooting this thing, please?
I’ve put using the 4017 on hold for now while I worked on incorporating the LED digits and selecting the octave manually. Here’s where I stand. TK, I think I need help from you specifically, if you’re available.
Anyway, I’ve put a common-anode LED digit in the low-digit position and hooked it up exactly like the diagram. I modified the Init logic to set the LED to 0 on startup instead of 1 because I’m defaulting my octave offset to 0 for debugging purposes. I’ve set up logic for buttons D0, D1 and D2 to set the offset to 0, 12 and 24, respectively – which will create no offset, one octave up or two octaves up. The LED will also be set to 0, 1 or 2.
OK, here’s where I need some help. I have nothing connected to pins D0 - D2. On power-up, the LED does its tricks, then reads 0 – exactly like it should. A few seconds later, it gets set to 1. A few seconds more, and it becomes 2! The 2-octaves-up goes into effect too! I’ve tried putting +5 and ground on each of the D0-D2 pins in an attempt to simulate logic 1 or logic 0. Nothing seems to make any difference. It’s haunted! It executes each button_pressed and button_released routine in sequence for pins D0-D2. It does play notes just fine.
TK, the LED digits are set through some kind of interrupt, right? As an applications programmer, I stopped dealing with interrupts about 20 years ago, so I’m not real skilled with them. We’ve communicated before about sustained settings on input pins and I thought I had followed the directions. I guess not!
Take care that the interrupt routine doesn’t use the same resources like the main program, otherwise there could be unwanted influences.
In general on such a situation, where you don’t know from where a strange effect is coming from, it makes sense to disable parts of the code step-by-step (!) in order to find out, which one of the parts is causing the problem. This means, that you have to reprogram the firmware several times. It doesn’t make fun with the PIC16F87x (without MIOS bootstrap loader), but propably this is the fastest way anyhow
I’m still working on debugging my octave selection functionality. I have 5 buttons on pins D2 through D6. D2 is supposed to be my octave select button. D3 through D6 are the lowest 4 notes. I have the code set up so that LED_DIGIT0 displays the button number (2…5) when it’s pressed and 0 when it’s released. Buttons 3…5 still play notes, but I’m not even bothering with that right now.
The pull-up resistors have been a thorn in my side since I began this project. When I added note 13, I figured out that I needed to slide the 4 pull-up resistors down one pin so they were connected to pins D3 - D6. When I added functionality for pin D2, I initially didn’t have a pull-up resistor on it because it was supposed to be a sustained input like a switch setting, not a temporary input like a pushbutton. I’ve since modified my design so that the octave select button works like note buttons, but I have code in the button_pressed routine to increment the octave number and LED digit, or reset as needed. The octave select button didn’t behave as I expected, so I moved the pull-up resistors down one more pin so they were on pins D2 - D5. After that, it seemed like my note on D6 was “sticking”. Now, I freely admit that I could easily have introduced wiring errors into the use of these pull-up resistors because of what it took to get them connected on a breadboard. But, I’ve come this far, so my wiring hasn’t been too bad.
My first question is:Â Do I just need pull-up resistors on the “lowest” 4 pushbuttons like the original circuit diagram shows, or should I have pulldowns on all pushbutton pins “before” the TX pin?
Second question:Â Since button 2 doesn’t perform any MIDI functionality, I ended its _pressed and _released procedures with “return” instead of goto statements. Do I need the return statements, or will the procedure return when it encounters the label for another procedure?
One of my tests last night confirmed that I did indeed need more than 4 pull-up resistors. When I installed the last one, the weird stuff I described earlier went away. I need to test what happens with the pins that TK’s diagram doesn’t show pull-ups on.
The other thing I discovered is that if you’re going to test for a limit value on a counter, it really should be incremented BEFORE you test it!! Duh!
The schematic doesn’t show pull-ups at Port B, since this port provides internal pull-ups
Best Regards, Thorsten.
Oh, yeah. That’s right! I remember seeing something about that in the code! OK, that explains that. Good!
Something else that’s good is that I seem to have the octave select function working – but not reliably. The pushbutton is REAL sensitive! I haven’t done much to make it less “bouncy” so far. I just tried disabling interrupts in the button_pressed routine and enabling in the button_released routine. This morning, I noticed that there was some button debouncing code in the MIDI program change side of the IF USED_AS_KEYBOARD. Would that help with debouncing my octave select button? I’ll just CALL it instead of doing a GOTO.
yes, debouncing is a must, when buttons are connected directly to IO pins and used to trigger events.
Best Regards, Thorsten.
Is debouncing enough to make the octave select less touchy? Do I need to disable interrupts while I’m executing the octave select logic, or do I need a delay loop? I stuck 5 NOPs in both the _pressed and _released routines, but they didn’t seem to make a difference.
The reason why I recommented to disable interrupts some postings ago was, to find out if a problem is caused by a programming error or not. If you’ve programmed everything properly (no resource conflicts), this is not required, and debouncing alone helps.
The delayed caused by 5 NOPs is not enough, I guess that you need a delay which waits for at least one mS, better 10 mS
A proper way to realize such a delay is the use of timers… but I don’t have the time to explain you the details, I’m sure that there are informative application notes at the microchip.com website, which explain all the basics!
: