Jump to content
Due to a large amount of spamers, accounts will now have to be approved by the Admins so please be patient. ×
IGNORED

LED pushbutton switches


Recommended Posts

Hey guys,

 

Im currently designing a visual percussion sequencer, and wondered if anyone knew of any combination small pushbuttons with a LED in them. Basically a PB switch (not momentary) that lights up when 'ON'.

 

I tihnk there are a few around for industrial uses, but I am looking for about a 10mm diameter or thereabouts, still in planning stage. Hopefully cheap too, cause I'm going to need at least 64 of the buggers...

Link to comment
Share on other sites

yeah, Its just they look at bit big, as I want 64 of them relatively close. I'll keep searching, I may just have to use simple small clear buttons and put LEDs under them.
Link to comment
Share on other sites

do they need to latch on?

 

Surely if you are making a sequencer they can be momentary switches with push on/push off and LED switching handled in software? It may increase the complexity a bit, but lets you use all sorts of cool buttons, like these guys here:

 

http://www.altronics.com.au/index.asp?area=item&id=S1177

 

or

 

http://www.altronics.com.au/index.asp?area=item&id=S1171

 

or

 

http://www.altronics.com.au/index.asp?area=item&id=S1132

 

or

 

http://www.altronics.com.au/index.asp?area=item&id=S1101

 

or the ultimate in tiny:

 

http://www.altronics.com.au/index.asp?area=item&id=S1063

 

All of these are available in different colours, except the last one. And that is just from one supplier!

 

Cheers

JAcob

Link to comment
Share on other sites

Yeah they look cool, just not sure at the moment how many pins will be available. Didn't really want to have to monitor it as an input, then also drive it as an output.

 

If your writing your own software it's actually better to drive the state from the software if you use momentary switches. Even if you don't use momentary switches your still going to need to monitor the state of the switches, unless you plan to just query the state when you need to (which I doubt).

 

The benefit of driving them from the software is that you always know the state of the software and you will always know that your hardware and software is in sync (in case you have timing issues which can happen depending on your interface and how often it scans). This means that if a use presses the momentary switch too quickly and the scan doesn't pick it up, then they will know because the LED didn't activate. The user will learn quickly the optimum press time to get the LED to go on. May sound like a bummer, but trust me it's the best way for software driven via hardware that guarantees it's state.

 

Another advantage of driving the state of the switch from the software is that you can have the states of the buttons saved and loaded by the software. so if you had different potential default configurations, the user could cycle through the different saved configs via a button, with the LED showing which one it is, or load em via the UI. Even better if you have a LCD on the board that you can write which saved state it is that you have loaded. Also you can persist the state of the hardware when you power down via the software, so that when you boot up the software can restore the state.

 

If you need a hand with some of the scanning and event handling and your writing it in java then give me a yell, I've done a lot of work in this area and can assist if you need a hand. :)

Link to comment
Share on other sites

I may also throw in that there may be a way to utilise the same matrix to both illuminate the LEDs and scan the buttons.

 

I'm no expert there, but it is possible. If you are running out of IO, another solutoin would be to have an additional slave controller running the matrices, so your main controller and code can just get on with the job, and grab the state of the matrix when it needs it...

Link to comment
Share on other sites

I may also throw in that there may be a way to utilise the same matrix to both illuminate the LEDs and scan the buttons.

 

I'm no expert there, but it is possible. If you are running out of IO, another solutoin would be to have an additional slave controller running the matrices, so your main controller and code can just get on with the job, and grab the state of the matrix when it needs it...

 

That's a good point. You could have a separate controller with a serial or usb interface (serial would be more common). Serial drivers to drive LED's are pretty common and there are a tonne of kit's out there to do that. Input's are a tad harder, all depends on how much I/O you require and if you require buffering. Plenty of info out there on converting a parallel port or a joystick port!

Link to comment
Share on other sites

There are a lot of ways to get more IO.

 

An I2C IO expander for example:

 

http://www.futurlec.com.au/Philips/PCF8574AP.jsp

 

at $3.00 each are a good thing if you know about I2C comms. If you are using several though, an additional microcontroller may end up cheaper!

 

AS far as inter-device communications, serial is an easy (but slow) option - there is also TWI (which is the same as I2C but without the Philips trademarked name) and SPI as well.

 

There are also the good old fashioned serial/parallel data shifting options out there, but they need a lot of work to drive in software...

 

Not trying to hijack Gints, but just putting some options out there for you.

Link to comment
Share on other sites

Yeah gotta look at it all.

 

It's actually going to be in an FPGA, so it will be a hardware design with switch states stored in registers, clocked by the input itself, so it will be an asynchronous and instant updating of switch state.

 

I will look into ways of doing it with momentary and hopefully not doubling the IO requirements

 

While Im here, what do you guys recomend as the best ways of implementing a pin controlled switch. I need to short a few wires for various things, I will have a LVTTL output (3.3V) would the best way just be NPN BJT or some small dedicated relay? Any tips?

Link to comment
Share on other sites

It's actually going to be in an FPGA, so it will be a hardware design with switch states stored in registers, clocked by the input itself, so it will be an asynchronous and instant updating of switch state.

 

Ahh, sorry my bad, presumed you would be interfacing with an embedded pc or similar. I'll leave it to the guys who know about this kinda stuff :redface

Link to comment
Share on other sites

It will be 4 rows of 16 buttons.

 

Basically I figured having an LED switch would be easier because the pin would either be HI/LO, which would corrrespond to the LED lighting and also mean I simply have to make the D-flip flops rising/falling edge sensitive to update the status.

 

Last night I drew up some diagrams though using a co-ordinate arrray to read and write to the LEDs which should work fine, using 16x4 to read and another to write. Only issue with this is that I can't drive them consistently, so I will have to drive the first 4 (whichever need lighting) then the next 4 etc.

 

So basically each set wil only be illuminated 1/16 of the time... but from what I've seen with 7seg displays and the like, our eyes are probably too slow to pick it up.

 

I would be interested to know how you monitor and drive it from one pin David, and if that is possible in my situation which is so timing dependent.

Link to comment
Share on other sites

I use shadow registers to keep track of the LED states. In the PIC code, I set the port pins to output and copy the shadow byte to the port. Whenever an LED state change occurs, I refresh the shadow to the port.

 

To get the switch data in, I tristate the port, read the value, save the result, then set the port back to output and refresh the data. This happens every 50ms or so but the tristate read only take a few microseconds so you don't even see it!

 

For lots of buttons, I use external shift registers (one per 8 LED out and one per 8 switches in) but it still only requires one pin between the PCB and the LED/switch plus two common wires that go to all LED/switches. Either way, there's no multiplexing of the LED's as such, only sampling in a small dead time.

 

+5V -----|LED|------|330R|------|SWITCH|----
                            |             |
PIC PIN----------------------              |
                                          |
0V ----------------------------------------

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...