Troubleshooting the Floorboard

[Axeslinger]

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?

Thanks!

[raphael]

Seems, that your firmware doesn`t run on 16f877.

Have you included the right header: p16f877.inc instead of p16f874.inc?

Also look at make.bat. It is compiled with /16f874. (Don't know if this is important).

I'm no expert in porting apps from PIC to PIC. Someone else?

Raphael

[Axeslinger]

AAahhhh!!  Dagnabit - the include!  I think I forgot to use the 877 one.  Thanks, Raphael!  That one I can definitely address!

I'll check back in a few days.

[Axeslinger]

Raphael:

Compiled with 16F877 include

Code shows MIDI channel value as 0  ???  Is that valid?

Crystal is pulsing

Did LED trick I found in the MIDI diagnosis area.  IT FLICKERS!

Only have 4 pushbuttons right now -- the ones with the 10K resistors.

Are paper clips big enough to simulate the pins on a MIDI cable?

[Axeslinger]

IT WORKS!  ALL RIGHT!  ;D ;D ;D ;D ;D ;D

It was the stupid keyboard I was testing with!

Next up:

    1)  Add note #13

    2)  Rig my organ pedalboard to the breadboard

What a kick!  This is so cool!  This thing rocks!!!!!!!!!!!!!  :o :) ;) :D ::)

[Axeslinger]

Did the code changes for pedal 13 this morning.  Now all I need is some bench time...

[Axeslinger]

YEAH!

My code change worked!  The Floorboard is putting out 13 notes.

BWHA-HA-HA-HA!   ;D ;D ;D ;D ;D

[TK.]

Great! :)

Best Regards, Thorsten.

[Axeslinger]

Got the octave generation logic working yesterday and added the code changes this morning...

[Axeslinger]

I'm back...

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!

Help!

Please?

[TK.]

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

Best Regards, Thorsten.

[Axeslinger]

Funny you should mention sequential disabling.  That's how I decided that I'd better put a digit on PORTA instead of LED's.

OK, I guess I need to disable my D2 through D0 logic in sequence.

What would be the possibility of using ICSP with this thing?

[Axeslinger]

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?

[Axeslinger]

I answered at least one of the questions.  I did need the return statement.  It's looking like I need more than the 4 pull-ups.

[Axeslinger]

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!

[TK.]

The schematic doesn't show pull-ups at Port B, since this port provides internal pull-ups

Best Regards, Thorsten.

[Axeslinger]

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.

I'm getting close!

[TK.]

yes, debouncing is a must, when buttons are connected directly to IO pins and used to trigger events.

Best Regards, Thorsten.

[Axeslinger]

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.

[TK.]

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!

Best Regards, Thorsten.

[Axeslinger]

No problem.  The advice you've already given has been more than enough.  Besides,  there's already a DELAY subroutine in there!

[Axeslinger]

The subject says it all.  I am so pumped!

All I had to do was put in a call to the button debounce code.  No messing with interrupts, no delays, no fuss.  I called the debounce when the button was pressed, and also when it was released.  Rock-steady octave selection!  Works GREAT!

Mr.  Klose, as promised, I will write up and send you what I've done.  I have very little free time, however, so this will take me awhile because my primary concern is to get the board built and usable.  I figure you should expect a ZIP file from me containing my documentation around Christmas.

(Ladies and) Gentlemen, thanks for all the help!

[Axeslinger]

It's me again...  sorry.  I've been trying to incorporate one or two more input buttons into my Floorboard mutation.  I'll have to use two pins on PORTC because that's all that's left.  I started by using C7 since that's already set up as an input in TRISC.

I started off with the belief that I couldn't add the C7 pin to the "shift register" formed by ports D and B since those ports were set up as all inputs and it appeared from the code that the button that was actually pressed or released was determined from the button pointer subscript.  I added code to check C7 if the subscript was greater than 16.  I was looking for a 1 on the pin.  To shorten a long story, C7 appeared as if it was being ignored.

Then I had what I thought was another brainstorm.  I added PORTC to the shift register processing.  I then set the button pressed and button released condition tables up so that the pressed and released subroutines for pins C0 through C6 did nothing.  The LED digits went crazy!  They just cycled through their possible values -- over and over again!  The input buttons were ignored.

Does anyone have any suggestions for how to implement C7 and possibly C5 as inputs? I sure would appreciate it!

Thanks!

[TK.]

In short: C7 is configured as MIDI In, you can use it as common GPIO pin by removing the access to RCSTA in init.inc

Shift register processing: possibily the registers are not shifted often enough? Check the loop counter

Best Regards, Thorsten.

[Axeslinger]

I tried to do this by commenting out the statement with the << before the reference to RCSTA.  This had no perceptible effect.  What you actually meant was to execute the statement, but substitute 0 for 1.  What I'm supposed to do is leave the TXSTA register alone, but disable RCSTA.  This will allow RC7 to be handled as a GPIO pin.  Is this correct?