I have a couple questions that I thought I proposed in an e-mail, but never received a response back. I would appreciate it if any one could pass along the info. I am looking at purchasing a couple of the LK202-24-USB.
1) It has a 6x4 keypad matrix, can I use this as 10 different GPIs (Not in a matrix) and send the information to the computer rather than the screen. I basically want to interpert this as a key push when one of the lines is set to +5V like the keypad does. If I set it up as a Matrix controller with up to 24 inputs would I need to worry about ghosting? Can the inputs be passed directly back through the serial port (USB) and read through the Com Port without changing the status on the LCD?
2) I read it supports 4, 1Wire interfaces. Can I buy 1Wire chips and talk
bidirectionally to them? If I can't read them, can I atleast write to them? I am looking at the DS240, which I believe gives me 8 outputs per OneWire chip. I understand you can connect multiple 1Wire chips on the same bus, does this 4 mean that you can connect 4 chips to the controlling LCD, or can you have 4 buses with 32 wire chips per bus (this is what maxim said the max number of chips on the 1Wire bus is.) I would not need bidirectional IO on the chip mentioned above.
3) Does it support OneWire Counting Chips (for GPI)? Or is it only unidirectional output?
A Side Note Question, does anyone know where I can get an inexpensive 4"-5" Color VGA LCD display that I can hook to my graphics card? (DVI or SVGA).
Thanks,
Eric Levy
Broadcast Software Engineer/ Flight Simulator Designer
Pre-Sale ?s - OneWire Interface and keypad as GPI
Hi Eric,
Thanks for posting on the lcd forums.
Strange. I remember this question, and I have sent an email.
I will answer the questions again though.
1) When you press a key on the keypad a character is generated, and it is sent to the RX line of the serial port. The status of the display won't change until you program the key to respond to a command or with text. When you refer to ghosting for the keypad, do you mean debounce?
2) You can use any one wire device, but you need know how to program it. You can connect multiple one wire devices on the same bus, since it is addressed by the different 64 bit IDs.
3) As stated above, you can use any 1-wire devices, as long as you can do the programming.
The following link at http://www.matrixorbital.ca/appnotes/1wire/1wire_intro will give you a better understanding on how to program a 1- wire device with our displays. You can also refer to page 24 of the manual at http://www.matrixorbital.ca/Manuals/LK_ ... SB_140.pdf
If you have anymore questions or concerns, please feel free to ask.
Best Regards,
Thanks for posting on the lcd forums.
Strange. I remember this question, and I have sent an email.
I will answer the questions again though.
1) When you press a key on the keypad a character is generated, and it is sent to the RX line of the serial port. The status of the display won't change until you program the key to respond to a command or with text. When you refer to ghosting for the keypad, do you mean debounce?
2) You can use any one wire device, but you need know how to program it. You can connect multiple one wire devices on the same bus, since it is addressed by the different 64 bit IDs.
3) As stated above, you can use any 1-wire devices, as long as you can do the programming.
The following link at http://www.matrixorbital.ca/appnotes/1wire/1wire_intro will give you a better understanding on how to program a 1- wire device with our displays. You can also refer to page 24 of the manual at http://www.matrixorbital.ca/Manuals/LK_ ... SB_140.pdf
If you have anymore questions or concerns, please feel free to ask.
Best Regards,
I have one more 1Wire Question. I am need more GPIs than are avaialable with the 24 keypad (actully I am looking to purchase 4 of the displays) and 96 pulse GPIs aren't enough, I need 120! I have done some research on one wire chips to use for the GPI trigger, but I am afraid my application will not be able to pole the 1Wire device often enough to detect a trigger pulse (using a tactile switch). Do you know of a 1Wire device that can send a command when it receives a trigger pulse?
I am curious if you can shed any insight on how your keypad works, is it a proprietary chip or does it use a 1Wire chip?
Or maybe this would be easier... Would it be possible to buy a USB controller board with 24 GPIs and 6 inputs without the LCD display?
Any suggestions would be appreciated.
Thanks,
Eric Levy
I am curious if you can shed any insight on how your keypad works, is it a proprietary chip or does it use a 1Wire chip?
Or maybe this would be easier... Would it be possible to buy a USB controller board with 24 GPIs and 6 inputs without the LCD display?
Any suggestions would be appreciated.
Thanks,
Eric Levy
-
Paradigm
- Matrix Orbital
- Posts: 255
- Joined: Thu Sep 13, 2001 6:00 pm
- Location: Calgary, Alberta, Canada
Hi boaderman
Just thought I should jump in this conversation. First of all, do you mind me asking what you are doing with 120 inputs? I'm very curious. Now onto the good stuff.
The keypads on USB units are arranged into a 4x6 matrix, and the 4 rows are scanned for changes. Only when the status of a row changes are the 6 columns scanned. Only the first changed row is scanned. So ghosting will be a major issue. If multiple keys are pressed at the same time, the first valid row/colum pair that was detected will be asumed to be the only one that changed. So all other rows/colums that changed will be ignored. And the display assumes that the key will be released before another one is pressed. So if you want to detect multiple simultaneous events, the keypad is no good.
From your posts I think you're misunderstanding the capabilities of Dalas One Wire (DOW) and what the display can do for you. To start off with the most popular question we get regarding DOW, how many devices can you connect? The answer is: ALL of them
. I mean every single device that was ever designed for DOW can be put on the same bus. Each device has a unique 64bit address and no two in the world have the same one, so all devices would technically be able to fit on the same bus. The biggest problem is what happens to the signals when the bus gets two long. The edges from +5v to gnd and back become very rounded and sometimes echo on longer busses. This causes the devices/host to miss things or see things that aren't there. Personally, we've gotten 32 devices on a short bus in a star topography (1m or 3'4" per arm) working fine, your mileage may vary. So there is no hard and fast number, but if you're careful, you should be able to get quite a few on the bus.
The DOW bus is always bi-directional, however the master initiates everything. It tells the device what to do and when to send data back. Tom included a link to my 1-wire tutorial eariler. Refer to that for some examples.
This all brings me back to exactly what you are trying to do? By the sounds of it you are trying to trigger something on an event. In order to do this the right way, you need to know various aspects of these events:
How often do they occur?
What range of duration do they have?
Are they asserted until you acknowledge them?
If you get back to me with more detail in what you are doing, I might be able to suggest something. However as it stands now, I don't know enough about your situation to be able to suggest anything.
Just thought I should jump in this conversation. First of all, do you mind me asking what you are doing with 120 inputs? I'm very curious. Now onto the good stuff.
The keypads on USB units are arranged into a 4x6 matrix, and the 4 rows are scanned for changes. Only when the status of a row changes are the 6 columns scanned. Only the first changed row is scanned. So ghosting will be a major issue. If multiple keys are pressed at the same time, the first valid row/colum pair that was detected will be asumed to be the only one that changed. So all other rows/colums that changed will be ignored. And the display assumes that the key will be released before another one is pressed. So if you want to detect multiple simultaneous events, the keypad is no good.
From your posts I think you're misunderstanding the capabilities of Dalas One Wire (DOW) and what the display can do for you. To start off with the most popular question we get regarding DOW, how many devices can you connect? The answer is: ALL of them
. I mean every single device that was ever designed for DOW can be put on the same bus. Each device has a unique 64bit address and no two in the world have the same one, so all devices would technically be able to fit on the same bus. The biggest problem is what happens to the signals when the bus gets two long. The edges from +5v to gnd and back become very rounded and sometimes echo on longer busses. This causes the devices/host to miss things or see things that aren't there. Personally, we've gotten 32 devices on a short bus in a star topography (1m or 3'4" per arm) working fine, your mileage may vary. So there is no hard and fast number, but if you're careful, you should be able to get quite a few on the bus.The DOW bus is always bi-directional, however the master initiates everything. It tells the device what to do and when to send data back. Tom included a link to my 1-wire tutorial eariler. Refer to that for some examples.
This all brings me back to exactly what you are trying to do? By the sounds of it you are trying to trigger something on an event. In order to do this the right way, you need to know various aspects of these events:
How often do they occur?
What range of duration do they have?
Are they asserted until you acknowledge them?
If you get back to me with more detail in what you are doing, I might be able to suggest something. However as it stands now, I don't know enough about your situation to be able to suggest anything.
James McTavish, P.Eng
Director of Engineering
Matrix Orbital
Director of Engineering
Matrix Orbital
James-
I am building a flight simulator avionics stack to replicate the Garmin GPS GNS 430 and Nav/Com radios used in aviaion, along with numerous other controls to replicate what is in a normal airplane through MS Flight Simulator (I will PM a diagram, it's pretty cool.) There will be around 10 inputs that are on/off switches (I will probably use DTR/CTS/CD -or whatever the two input lines are on a 232 port, I forget- on a Rocket Port card I bought for these or I may use One Wire Devices to poll the state every 250 ms.)
I have around 15 LEDs, that I plan to use the GPO from the Matrix Orbital displays to run.
Now for the tuough part... I have around 110 pulse GPI inputs, that are a combination of tactile switches (60 inputs) and Rotary Pulse Switches (50 inputs). I think the tactile switches should be fairly straight forward, because most of them are not buttons which are pushed repeatedly. (i.e. One button might activate a mode on the GPS or another might turn on and off listening to the COM2 radio. This kind of button has an LED at the top and the LED is controlled through the software which sends a signal through one of the GPOs, much like the lights in many electronics using tactile switches.)
Correct me if I'm wrong, but I don't think ghosting will be a huge problem with the tactile switches. There will be atleast 100 ms, probably more like 200 ms of time between button presses. The really tough part is the rotary switches. These would be like repeated button presses, but often of the same button. The pulse rotary switch works by momentarily closing switch A-B when it is turned clockwise and momentarily closing switch C-D when turning counterclockwise. I.E. it sends one GPI pulse on one set of leads when turned one direction and another GPI pulse when turned in another direction. (The poor man's rotary encoding switch!) There would probably only be around 10-20 ms between successive pulses with the rotary switch.
I think I will look into alternatives to the excess GPIs I need, like using Maxim's I2C interface with a microprocessor or a TTL to Serial Converter. I am still looking into how to do this, but I figured I would ask about the 1Wire Interface first.
If you can't tell, I am a software guy trying to learn the hardware side. Any suggestions would be appreciated, but I also realize this is outside your normal realm of support. I will PM a diagram of the display I am creating to give you a better idea.
Thanks Again!
Eric
I am building a flight simulator avionics stack to replicate the Garmin GPS GNS 430 and Nav/Com radios used in aviaion, along with numerous other controls to replicate what is in a normal airplane through MS Flight Simulator (I will PM a diagram, it's pretty cool.) There will be around 10 inputs that are on/off switches (I will probably use DTR/CTS/CD -or whatever the two input lines are on a 232 port, I forget- on a Rocket Port card I bought for these or I may use One Wire Devices to poll the state every 250 ms.)
I have around 15 LEDs, that I plan to use the GPO from the Matrix Orbital displays to run.
Now for the tuough part... I have around 110 pulse GPI inputs, that are a combination of tactile switches (60 inputs) and Rotary Pulse Switches (50 inputs). I think the tactile switches should be fairly straight forward, because most of them are not buttons which are pushed repeatedly. (i.e. One button might activate a mode on the GPS or another might turn on and off listening to the COM2 radio. This kind of button has an LED at the top and the LED is controlled through the software which sends a signal through one of the GPOs, much like the lights in many electronics using tactile switches.)
Correct me if I'm wrong, but I don't think ghosting will be a huge problem with the tactile switches. There will be atleast 100 ms, probably more like 200 ms of time between button presses. The really tough part is the rotary switches. These would be like repeated button presses, but often of the same button. The pulse rotary switch works by momentarily closing switch A-B when it is turned clockwise and momentarily closing switch C-D when turning counterclockwise. I.E. it sends one GPI pulse on one set of leads when turned one direction and another GPI pulse when turned in another direction. (The poor man's rotary encoding switch!) There would probably only be around 10-20 ms between successive pulses with the rotary switch.
I think I will look into alternatives to the excess GPIs I need, like using Maxim's I2C interface with a microprocessor or a TTL to Serial Converter. I am still looking into how to do this, but I figured I would ask about the 1Wire Interface first.
If you can't tell, I am a software guy trying to learn the hardware side. Any suggestions would be appreciated, but I also realize this is outside your normal realm of support. I will PM a diagram of the display I am creating to give you a better idea.
Thanks Again!
Eric
-
Jeroen Vonk
- LCD Guru
- Posts: 55
- Joined: Tue Apr 12, 2005 2:31 am
-
Paradigm
- Matrix Orbital
- Posts: 255
- Joined: Thu Sep 13, 2001 6:00 pm
- Location: Calgary, Alberta, Canada
Hi boarderman:
Sorry about the long delay. I've been away for a bit.
Sounds like a nightmare of an input situation. You've got inputs crossing the entire gambit. I'll tackle them one a time and propose a few alternatives.
First we'll start with the easy ones. Output. If you take a look at the DS2408. It's a 1-wire part with 8 ports of input/output. This is perfect if you need to expand your output capability. Of course you would need to buffer the outputs with a transistor to drive LEDs, but it should work very nicely.
It will also work nicely for slow inputs and even some fast inputs. it does have an input latch which will only look for edges and will retain that information until you poll it. So it will store the current state of the inputs as well as if the state has changed since you last polled it. For some momentary push buttons this is all you need. The only thing that will be a factor here is latency. The time between pressing a button and polling could be too long. This is a problem with ANY polling setup. The maximum latency is the polling period. For more real time controls you need to goto a more active setup.
There are a couple more options to get more active. The first way would be to use a microcontroller with firmware that you'd have to write. A general "if this pin changes, send this character via RS232" firmware setup would be fairly simple. Then the latency issues can be pushed back upto the PC where you can deal with them there. The other solution would be to trigger a keypad even every time an input changes. You could do this with a simple gate (either OR or NOR depending on your display version) and a transistor (either NMOS or PMOS depending on your display version. Wire all the inputs into the gate, and the output of the gate to the transistor's gate, and the source/drain across a keypad row/column. Then when a key is pressed that is your notice to check the current state of the inputs. It's a quick hack, but it could work. The better solution is to do it with a microcontroller though. In fact, with a series of microcontrollers, you might be able to handle your I/O situation a little more easily. It will be more work, but the end results might be better. Our current displays were only designed to be used as displays with simple I/O. You've crossed the simple line
. I would reccomend that you look into Atmel's ATMega lineup. They are a nice set of general microcontrollers with an execllent community behind them.
Finally for your rotary encoders. Take a serious look at the DS2423. It is a 1-wire chip with two hardware counters. In your situation all you might need is one of these per rotary encoder. One for counting up ticks, the other for counting down ticks. Then poll these every so often, subtract the down ticks from the up ticks and you have your net result.
Sidenote: I've been getting a lot of questions over rotary encoders lately. To head off a slew of questions I must warn anybody else who is reading this that this is *NOT* how normal rotary encoders work. Counting the ticks on each pin does not work with normal rotary encoders.
You also included a question about ghosting. Unfortunately due to our keypad algorithm, ghosting is always an issue. We only scan until the first keypad key is pressed. It doesn't matter if you have another key pressed, the first one it finds pressed, it will stop looking. The other catch is that it will wait until that key is released before it scans for another key press. It has been done this way for many reasons (robustness and hardware constraints being the main ones), and it doesn't allow for much flexability. Future products will address this, since multikey detection has been requested many times.
To address Jeroen Vonk: Unfortunately the same problem that I just described will be a problem with all keypads, doesn't matter what their size.
Sorry about the long delay. I've been away for a bit.
Sounds like a nightmare of an input situation. You've got inputs crossing the entire gambit. I'll tackle them one a time and propose a few alternatives.
First we'll start with the easy ones. Output. If you take a look at the DS2408. It's a 1-wire part with 8 ports of input/output. This is perfect if you need to expand your output capability. Of course you would need to buffer the outputs with a transistor to drive LEDs, but it should work very nicely.
It will also work nicely for slow inputs and even some fast inputs. it does have an input latch which will only look for edges and will retain that information until you poll it. So it will store the current state of the inputs as well as if the state has changed since you last polled it. For some momentary push buttons this is all you need. The only thing that will be a factor here is latency. The time between pressing a button and polling could be too long. This is a problem with ANY polling setup. The maximum latency is the polling period. For more real time controls you need to goto a more active setup.
There are a couple more options to get more active. The first way would be to use a microcontroller with firmware that you'd have to write. A general "if this pin changes, send this character via RS232" firmware setup would be fairly simple. Then the latency issues can be pushed back upto the PC where you can deal with them there. The other solution would be to trigger a keypad even every time an input changes. You could do this with a simple gate (either OR or NOR depending on your display version) and a transistor (either NMOS or PMOS depending on your display version. Wire all the inputs into the gate, and the output of the gate to the transistor's gate, and the source/drain across a keypad row/column. Then when a key is pressed that is your notice to check the current state of the inputs. It's a quick hack, but it could work. The better solution is to do it with a microcontroller though. In fact, with a series of microcontrollers, you might be able to handle your I/O situation a little more easily. It will be more work, but the end results might be better. Our current displays were only designed to be used as displays with simple I/O. You've crossed the simple line
. I would reccomend that you look into Atmel's ATMega lineup. They are a nice set of general microcontrollers with an execllent community behind them.Finally for your rotary encoders. Take a serious look at the DS2423. It is a 1-wire chip with two hardware counters. In your situation all you might need is one of these per rotary encoder. One for counting up ticks, the other for counting down ticks. Then poll these every so often, subtract the down ticks from the up ticks and you have your net result.
Sidenote: I've been getting a lot of questions over rotary encoders lately. To head off a slew of questions I must warn anybody else who is reading this that this is *NOT* how normal rotary encoders work. Counting the ticks on each pin does not work with normal rotary encoders.
You also included a question about ghosting. Unfortunately due to our keypad algorithm, ghosting is always an issue. We only scan until the first keypad key is pressed. It doesn't matter if you have another key pressed, the first one it finds pressed, it will stop looking. The other catch is that it will wait until that key is released before it scans for another key press. It has been done this way for many reasons (robustness and hardware constraints being the main ones), and it doesn't allow for much flexability. Future products will address this, since multikey detection has been requested many times.
To address Jeroen Vonk: Unfortunately the same problem that I just described will be a problem with all keypads, doesn't matter what their size.
James McTavish, P.Eng
Director of Engineering
Matrix Orbital
Director of Engineering
Matrix Orbital