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?

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?

I'm going to put this issue on the back burner. It's more important to get my control mechanisms working properly. Instead of indicating the octave with individual LEDs, I'll just take advantage of the LED digit tools already provided in the code. Speaking of code, I...  uhhh... found some...  uhh... errors...

Uhhh... because I didn't know such things existed?!?!?!?!  ??? ??? ??? ???

I'm sure that whatever is going on is not the fault of TK's code snippet. The advice he's given me so far has been dead right, and the fact that I've been able to get this far is proof of how well this device has been designed and coded. With that said, though, this power-on reset thing was just an impuse thing I decided to try to do for my convenience. Resetting the 4017 doesn't HAVE to be done by the PIC. I found a simple way to implement a power-on reset with discrete components, so I'm going to try that. I'm hoping that my circuit will work better with the 4017 in full possession of its faculties. Once I get my primary objective (octaves) in place, I might go back and try P-O-R again.

Hey, a reply! I started with the Floorboard, so that was the source for my initial code. Since that unit was writing program change information to LED digits, PORTA was already configured for output. I know this to be true, because another chunk of code I changed is turning on 3 LEDs that are connected to RA1, RA2 and RA3. They aren't supposed to ALL be on and I've been hoping that this is because the 4017 is confused. There could always be problems with my code, too.

Well, I sure didn't expect this! When my PIC powers up and the Init code executes, I have the sequence (per TK) bsf PORTA,0 nop bcf PORTA,0 which is intended to send a logic 1 "pulse" through pin RA0 to the reset pin of a 4017 so it is set to a known state upon power-up. The 4017 resets, which is cool, BUT the PIC is looking like the BCF doesn't execute. It's not letting go of the pin! The 4017 "locks up" and refuses to do anything unless I pull the wire off its reset pin. It works fine then. Can anyone tell me how to make this "pulse" actually PULSE so the 4017 can go to work? Thanks!

Let's see if I can get this right:Â GRUSS, HERR KLOSE!

So if I were going to use RA0 to send my pulse, I would set PORTA to 0x01, do a NOP, then set PORTA to 0x00? Easy enough!

I'm using a 4017 as a 1-of-3 selector. My tests indicate that this chip will power up in whatever state it was when power is turned off. This is not what I need. I'd like to have the 4017 power up in a state of my choosing, so I'd like to have the PIC16F877 send a pulse to the 4017's reset pin so it starts at digit 0. My question is: how long would the pulse have to last to do the job?

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