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?

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!

...which is exactly what I was planning to do. I was just proceeding carefully and trying to make sure I had done my homework properly before venturing into unknown territory. So far, everything I've done has just been a matter of building on code you already had in there or the little tricks I've added for button function processing.

I've been figuring out how to implement some additional functions on my bass pedal unit -- which started life as the Floorboard. After adding the 13th pedal note, PORTD had three inputs left. One of those was used by my octave select function. The other two are reserved for additional functions I want to implement. So far, so good. I can do everything I have to do here. If I were to stop developing right now and start building, I'd have a pretty cool bass pedal controller. Unfortunately, I seem to never be satisfied. One success builds on another. It occurred to me that it would be cool if I had some ability to change the voicings on the NanoBass my pedal unit drives. Well, since this functionality is already there, this should be easy.  I could add another LED digit to display the preset number because there's room for one more anode output. Using one LED digit displaying in hex, I'd be able to implement 16 MIDI program change commands by stepping through them with a pushbutton the way I do with the octave selection. And there's where I could have a problem -- the pushbutton. I need one more input! Let's say that I wanted to use pin RC5 as my new input. Based on what I saw in the PIC datasheet and the Floorboard code, I would have to set TRISC (maybe PORTC also, I can't remember) to treat RC5 as an input. Then I would go through the usual stuff of adding RC5 to the shift register, adding code for C5_pressed and C5_released, and adding these modules to contab. I assume I would also have to have a pullup resistor for this pin. Finally, I'd need my pushbutton. Do I have this covered? Is there some reason I can't use pin RC5 as an input? Is there something I've missed? I swear, I did read the datasheet before I posted this. N.B. I think I mean C5. If I recall correctly, the TX and RX pins are the uppermost pins in PORTC.

Hmmm... I think maybe I'll just try doing this in code. That way I can control all the variables.

I was reading about a pedal which sends a MIDI sustain / sostenuto command (B0 40 xx) to a synth. Does anyone know: Is the sustain command executed first, then one single note played? Is the sustain command executed, then you play whatever note(s) you want sustained? Or, do you start your note(s) and then execute the sustain command? I can implement this in software, but I thought it would be cool to know how it works. Thanks!

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!

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

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.

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!

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!

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.

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?

I won't need to reset a 4017 because I'm not going to use one. My state change methodology is going to be implemented in software.

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?