- Netduino Forums
- → Viewing Profile: Posts: klotz
The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Community Stats
- Group Members
- Active Posts 60
- Profile Views 8573
- Member Title Advanced Member
- Age Age Unknown
- Birthday Birthday Unknown
-
Gender
Not Telling
1
Neutral
User Tools
Friends
klotz hasn't added any friends yet.
Posts I've Made
In Topic: Keypad driver and scheme
11 March 2011 - 10:46 PM
The ammount of current being dumped into the interrupt is not a issue, what you should be worried about is the ammount of current being drawn on the outputport driving the columns. Even in that case, the ammount of current is negligable. Worstcase for any one driver would be 4 keys. If you are seriously worried about it you can mitigate the problem by driving the 4 rows and have the Columns as the interrupts, in that case the worse case would be 3 keys.
In Topic: Keypad driver and scheme
10 March 2011 - 10:22 PM
And then here is my solution to the Sparkfun keypad
You just have to make sure that the pins you use for Columns are interrupt pins.
using System; using System.Collections; using System.Threading; using Microsoft.SPOT.Hardware; namespace Sparkfun_12_key_keypad { public class Keypad { private InterruptPort Col1; private InterruptPort Col2; private InterruptPort Col3; private OutputPort Row1; private OutputPort Row2; private OutputPort Row3; private OutputPort Row4; private uint column1 = 0; private uint column2 = 0; private uint column3 = 0; private uint recieveKey; void Col_OnInterrupt(uint whichCol, uint data2, DateTime time) { recieveKey = 0xFFFFFF; for (uint Row = 0; Row < 4; Row++) { switch (Row) { case 0: Row1.Write(false); Row2.Write(true); Row3.Write(true); Row4.Write(true); break; case 1: Row1.Write(true); Row2.Write(false); Row3.Write(true); Row4.Write(true); break; case 2: Row1.Write(true); Row2.Write(true); Row3.Write(false); Row4.Write(true); break; case 3: Row1.Write(true); Row2.Write(true); Row3.Write(true); Row4.Write(false); break; } if ((whichCol == column1) && (Col1.Read() == false)) { recieveKey = (Row*3); break; } else if ((whichCol == column2) && (Col2.Read() == false)) { recieveKey = (1 + (Row*3)); break; } else if ((whichCol == column3) && (Col3.Read() == false)) { recieveKey = (2 + (Row * 3)); break; }; } Row1.Write(false); Row2.Write(false); Row3.Write(false); Row4.Write(false); } public Keypad( Cpu.Pin Col1, Cpu.Pin Col2, Cpu.Pin Col3, Cpu.Pin Row1, Cpu.Pin Row2, Cpu.Pin Row3, Cpu.Pin Row4) { this.Col1 = new InterruptPort(Col1, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow); this.Col2 = new InterruptPort(Col2, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow); this.Col3 = new InterruptPort(Col3, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow); this.column1 = (uint)Col1; this.column2 = (uint)Col2; this.column3 = (uint)Col3; this.Row1 = new OutputPort(Row1, false); this.Row2 = new OutputPort(Row2, false); this.Row3 = new OutputPort(Row3, false); this.Row4 = new OutputPort(Row4, false); this.Col1.OnInterrupt += new NativeEventHandler(Col_OnInterrupt); this.Col2.OnInterrupt += new NativeEventHandler(Col_OnInterrupt); this.Col3.OnInterrupt += new NativeEventHandler(Col_OnInterrupt); } } }
You just have to make sure that the pins you use for Columns are interrupt pins.
In Topic: Keypad driver and scheme
10 March 2011 - 10:18 PM
I did a 4x4 keypad decoder as well. In my case I used a 8574 chip and the I2C bus, but the basic idea is the same. You may get some ideas from the code I wrote for that, see http://www.fezzer.co...-port-extender/
In Topic: Controlling multiple LEDs with a few outputs as possible
25 February 2011 - 04:24 AM
I got your latest code to work by adding a pull-up resister on ~RESET(pin18). Not too obvious in the description in table 1-1 "Hardware reset. Must be externally biased"
I sort-of had it working without the pull up but it was not reliable. Once I put the resister in there, it became extreemly reliable.
Sorry I didn't notice this before.
And by the way, I had it working without any of the code changes I suggested.
http://www.vimeo.com/20357391
In Topic: Controlling multiple LEDs with a few outputs as possible
24 February 2011 - 09:34 PM
I have had some success using I2C and I have the data sheet for the MCP23017 here in front of me so I think you are doing things right. I will have to get my hands on one the the chips to be sure.
First, the address should be in the range of 0x20 - 0x27. With the way it is wired, assuming the drawing is correct, the address of the configuration should be 0x20.
It appears that you have this right, but let me explain for those who may not be aware. The I2C address as used by the I2CDevice.Configuration is the 7-bit address. With some other interfaces for I2C, it is common to list two addresses for a device, one write address and one read address. The two addresses differ only in the lsb, where an even number is the write address and an odd number is the read. In the case of those interfaces, the address would be 0x40 for Write and 0x41 for Read.
This gets more confusing since some datasheets list the addresses as the Read/Write address, for instance Newhaven displays and the Sparkfun MPR121 use this method. In those cases to use the device you will often see
Second, according to the data sheet, when using the I2C device the speeds are 100kHz, 400kHz and 1.7 MHz so that is correct.
Now for the final point. I will admit that at this time I am just a compitent C# programmer. But I generally avoid using "var" when I know the data type. So, I would avoid using:
Other than that I will see what I can do about duplicating you hardware and see if I can find something else.
First, the address should be in the range of 0x20 - 0x27. With the way it is wired, assuming the drawing is correct, the address of the configuration should be 0x20.
It appears that you have this right, but let me explain for those who may not be aware. The I2C address as used by the I2CDevice.Configuration is the 7-bit address. With some other interfaces for I2C, it is common to list two addresses for a device, one write address and one read address. The two addresses differ only in the lsb, where an even number is the write address and an odd number is the read. In the case of those interfaces, the address would be 0x40 for Write and 0x41 for Read.
This gets more confusing since some datasheets list the addresses as the Read/Write address, for instance Newhaven displays and the Sparkfun MPR121 use this method. In those cases to use the device you will often see
new I2CDevice.Configuration(ADDR >> 1, 100);
Second, according to the data sheet, when using the I2C device the speeds are 100kHz, 400kHz and 1.7 MHz so that is correct.
Now for the final point. I will admit that at this time I am just a compitent C# programmer. But I generally avoid using "var" when I know the data type. So, I would avoid using:
var setIOCON = I2CDevice.CreateWriteTransaction(new byte[] { IOCON, 0x24 });instead I would have used:
I2CDevice.I2CTransaction setIOCON = I2CDevice.CreateWriteTransaction(new byte[] { IOCON, 0x24 });
Other than that I will see what I can do about duplicating you hardware and see if I can find something else.
- Netduino Forums
- → Viewing Profile: Posts: klotz
- Privacy Policy