Pull Up Resistors Instead of Pull Down

[dniym]

Sorry if this is painfully simple however I need to change my switch inputs from +5vdc to ground..

My code works fine with pull down resistors, however it does not work with pull up resistors; How would I need to modify the button press code to work with pull up resistors? I need to have two switches that change modes independently.

Code: Select all

 ' Mode Changing Code - Detects input on B6 and B7 and acts accordingly
    if(oldr7 <> PORTB) THEN                              'Check to see if primary mode changed
      oldr7 = PORTB         'Snapshot of current button states
      if PORTB.RB7 = 1 THEN  'If Primary Button was pressed increment the mode
         delay_ms(300)       'Short pause to give the user time to get off the button
         if inc(mode) >= MAX_MODE THEN mode = 0 END IF   'If we've passed the max # of modes then start over
         mode2=0 ' Make sure we reset the sub mode counter
         dir1 = 0 ' make sure we clear the PWM direction
         PORTC = 00000000 ' always clear the LEDs on PORTC
         if mode = 3 then
             p1 = %11111100
             curzone = 1
         end if

         

      if  PORTB.RB6 = 1 THEN                            'Check to see if sub-mode changed
         inc(mode2)                                    'Increment the value of mode2 (sub-mode)
         random = 0
         delay_ms(300)

      END IF

I feel like a simple change on if PORTB.RB6 = 0 THEN inc(mode2) would do it however that isn't causing the modes to change at all with a pull up resistor.

[Megahurts]

Hi,

What hardware are you using? --(ALL)

If a pull-UP/DN resistor is used on a line, (to pre-load a logic state), make sure the button does the opposite
by connecting to opposite polarity, without a resistor in its path to that connection.

It really does not matter which way you do it, as long as hardware and software are set up right.

Make sure the "TRISx" statement in code is set to Input (1) for PORT-Pin used and that nothing else
in the PIC (HW), is active/enabled that would use same pin. Pins used as button inputs need to be
set as "digital I/O" also, - See PIC datasheet for device using.

Code looked ok to me for what your are trying, except depending on PIC's Osc speed and the way
you are showing how to detect button press, the time your code takes to loop back and test for
a button press may cause program to miss any short press's of the button.

One way is to have a short loop that only looks at port pin state for a change, then snapshots a state
image (temp old value variable) and then do your testing of what was pressed.

This only works if your program flow does not need to do other things than just waiting for a button press.

If your program needs to do other things like update the display of a ADC sample or anything, you will
need to have buttons on a PORT with "Interrupt on change" hardware feature and write interrupt
handling routines.

HTH, Mhz. B^)

[dniym]

Hi,

What hardware are you using? --(ALL)

If a pull-UP/DN resistor is used on a line, (to pre-load a logic state), make sure the button does the opposite
by connecting to opposite polarity, without a resistor in its path to that connection.

It really does not matter which way you do it, as long as hardware and software are set up right.

Make sure the "TRISx" statement in code is set to Input (1) for PORT-Pin used and that nothing else
in the PIC (HW), is active/enabled that would use same pin. Pins used as button inputs need to be
set as "digital I/O" also, - See PIC datasheet for device using.

Code looked ok to me for what your are trying, except depending on PIC's Osc speed and the way
you are showing how to detect button press, the time your code takes to loop back and test for
a button press may cause program to miss any short press's of the button.

One way is to have a short loop that only looks at port pin state for a change, then snapshots a state
image (temp old value variable) and then do your testing of what was pressed.

This only works if your program flow does not need to do other things than just waiting for a button press.

If your program needs to do other things like update the display of a ADC sample or anything, you will
need to have buttons on a PORT with "Interrupt on change" hardware feature and write interrupt
handling routines.

HTH, Mhz. B^)

Hardware:

I'll be using a SPDT center off momentary switch, with the common pole of the switch connected to ground. Thus I need the pic to trigger on a ground pulse instead of a + pulse.

The Pic is a PIC16F785

If I understand correctly the PIC16F785 has weak pull ups on port A, thus perhaps I should be using port A for my switches?

Edit:
The delay is just to prevent it from re-testing too fast, I stuck it in there because the tiny buttons on the easypic 7 were getting checked twice per press, I may very well have to take that out when I install a real world switch! The processor is running at 4mhz at the moment to give the desired speed of strobe on the output.

[Megahurts]

Hi dniym,

You are correct about the weak pull-ups on PORTA, and they are also the ones that have the hardware
IOC (Interrupt On Change) functions also.

You don't have to use the internal weak pull-ups if you supply external resistors also.
Depending on your circuitry, sometimes you have to pick your own resistors for a value (ohms) that
overcomes circuit design characteristics that require custom tweaking in order to make it work.

The internal pull-ups and IOC on PORTA is unique to small number of PIC's, most have that feature on PORTB pins instead.
You can find examples for IOC usage in mikro's codes, but they will probably be written for PORTB usage.
Just change code to PORTA for that PIC chip.

The IOC can be configured so that it will work on your design, (Hi--press--->Lo---release--->Hi).
You will have to wade through the PIC's Datasheet about this and make sure you are using the right pins
that have IOC for any change, some PIC's have to be configured for which direction a change will cause an interrupt,
like HI-going-LO or LO-going-HI on external interrupt pins.

The datasheet will state which operations this chip supports. I didn't read it fully to get these answers, it's not a chip I have worked with.

You might want to change to a more commonly used chip that the available examples were written for
unless there is a reason you needed this particular PIC MCU.
If that is the case, then you will be in the same boat as everyone else who is working on a MCU that
is not a popular chip....on your own and converting or writing custom code.

Something to think about. More help available if it's a popular chip.

HTH's, Mhz.

[dniym]

I'm not married to this chip, in fact the only reason I picked this one was for the two hardware pwm's which I ended up using software pwm anyway as the pwm built in wouldn't do what I needed it to do.

So far I've figured out most of the code questions I've had by using other examples, I've only been buying a few at a time so a chip change isn't out of the question. What might you recommend? As long as its got 8 outputs, internal osc, and will work with a software pwm Im okay with it.

I also need to be able to take an audio signal and break it up into low mid and high ranges but that's probably going to be a hardware issue to cross

[Megahurts]

Hi,

I'm not sure I'm the right person for that question lol. As it seems I always run out of pins for ideas
that keep getting added to practically every project.

The PIC18 family is my preferred choice, the more memory the better and one that has Hi/Lo priority
interrupts. After that, I like the PIC18F4620 for general use or one of the PIC18F2550-4550 for USB needs.
If you are going to be doing any analog signal processing, you might want to step it up to a dsPIC family
if you need fast CPU and digital signal algorithms features. The PIC18F4620 has internal Osc
and a PLL clock multiplier to allow it to run at 4,8,16 or 32 MHz and Hi/Lo interrupts and it
ships on a few mE development systems - so some example codes are available.

Nice thing about PIC's, lots of choices and many will swap jobs with many others with little modifications to coding mostly,
the hardware stays compatible across a wide range of devices.

I'm just getting into the dsPIC and PIC32 devices myself, been doing everything with the 16's and 18's so far.

Hth's and good luck with project. If you need more help, I or someone will try to help.
Mhz. B^)

[dniym]

All those seem like good guidelines my next phase of this project will need to accept a line or speaker level input then in theory activate my software pwm based on the signal strength coming into the pic. I think the easiest way to do this would be to build a crossover circuit that broke the signal up into low midrange and high frequencies. I'd rather do this via software but I don't know if that's possible or not

[dniym]

upon further research it seems that the dsPIC offers some ADC sampling routines, which might be the best choice as far as options go.

However; I really only need to be able to flash these leds with the music in the midrange / low frequencies... In the past i've gotten this to work simply by connecting three leds in series across the positive/negative speaker outputs. The LEDs would beat with the music although at high volume, I also feel like they could be turned on by adding a transistor into the mix, letting the transistor be triggered by the speaker level signal and Feeding the LEDs their proper voltage.


Sitting here pondering over it I think I could use a pair of transistors, one to be triggered by the speaker output, the other turned on by the pic when the proper mode was selected by the user.

The pic triggred transistor would provide the ground, whilst the speaker triggered transistor would tell the LED when to turn on/off.

[Megahurts]

Hi dniym,

Sorry for late reply, got busy last summer with vacations and working on new projects with newly purchased Mikroe hardware.

I would suggest that you do use the transistor switching method as some amplifier outputs could overdrive the LEDs and having the
LED in parallel (or series) with the speaker, will actually cut half of the waveform that the speaker receives and cause a lot of distortion to what you
will hear.

The transistor switching idea, if done right, will still give you the results you want and be a no-load (or minimal load) addition to the amplifiers output and
not add any distortion to the output.
It is important that an amplifier sees the proper load on the output finals. Otherwise it can cause a cascade event that will burn out
many if not all of the preamplifier transistor stages if the final output transistor fails.

Hopefully you have already solved the issues on this project and have moved on to something else, but if not, sorry again for my late reply.

Robert.