Netduino home hardware projects downloads community

Jump to content


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.

klotz's Content

There have been 60 items by klotz (Search limited from 29-March 23)


By content type

See this member's


Sort by                Order  

#10829 Keypad driver and scheme

Posted by klotz on 11 March 2011 - 10:46 PM in Netduino 2 (and Netduino 1)

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.



#10803 Keypad driver and scheme

Posted by klotz on 10 March 2011 - 10:22 PM in Netduino 2 (and Netduino 1)

And then here is my solution to the Sparkfun keypad
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.



#10802 Keypad driver and scheme

Posted by klotz on 10 March 2011 - 10:18 PM in Netduino 2 (and Netduino 1)

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/

Attached Thumbnails

  • I2C_HDI.jpg



#10157 Controlling multiple LEDs with a few outputs as possible

Posted by klotz on 25 February 2011 - 04:24 AM in Netduino 2 (and Netduino 1)

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



#10103 Controlling multiple LEDs with a few outputs as possible

Posted by klotz on 24 February 2011 - 09:34 PM in Netduino 2 (and Netduino 1)

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
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.



#9904 i2C netduino won't work!

Posted by klotz on 20 February 2011 - 06:57 PM in Netduino 2 (and Netduino 1)

So we have a good start on solving the problem. We have two of four things verified. 1. The display works, this was demonstrated by the successful use of the display with serial connections. 2. The driver on Fezzer works as it has been successfully used with SPI, I2C and Serial be several people with the Newhaven serial displays. This leaves us with just two things to verify: 1. The shorting block on the Newhaven display is correctly soldered. 2. The connections for I2C between the Netdiuno and the display are correct. Since the thread does not specifically identify the Netduino, I will go with the assumption that we are talking about a Netduion classic. So the connection between the Netduino and the Display would be as follows: Netduino Pin -> Display 5vdc -> 10 Gnd -> 9 A4 -> 8 A5 -> 7 I did not show a picture of the R1 jumper, because it is clearly displayed in the manual. However, I have attached a picture of the display working and its connections.

Attached Thumbnails

  • NHD-0220D3Z-NSW-BBW connections to Netduino.jpg



#9891 i2C netduino won't work!

Posted by klotz on 20 February 2011 - 01:01 PM in Netduino 2 (and Netduino 1)

Ok, I just got up and tried my driver on the Netduino. In fact I used my latest demo program I use for debuging driver improvements and the only thing I had to change was a few "using" statements and references.
If you start from "New project" paste the embedded code to you programs.cs, you would only have to add a reference to the Newhaven Displays class.
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.Netduino;

namespace Netduino_With_Newhaven_Display
{
    public class Program
    {
        private static NewhavenDisplay.SerialLCD display;
        private static I2CDevice bus;

        static void sendFunction(byte[] data)
        {
            I2CDevice.I2CTransaction[] xAct = new I2CDevice.I2CTransaction[] { I2CDevice.CreateWriteTransaction(data) };
            int bytes = bus.Execute(xAct, 1000);
        }
        public static void Main()
        {
            bus = new I2CDevice(new I2CDevice.Configuration(0x50 >> 1, 100));
            display = new NewhavenDisplay.SerialLCD(sendFunction);
            display.Clear();
            display.Write("Well did it work?");
            display.Write("Lets see what happens with this one");
        }
    }
}



#9873 i2C netduino won't work!

Posted by klotz on 20 February 2011 - 04:13 AM in Netduino 2 (and Netduino 1)

I have a Newhaven display running in .NETMF, you can look a working code on http://www.fezzer.co...ial-lcd-display . While this was done FEZ Panda, the code should work on Netduino. Give it a look. I will try it with the Netduino tomorrow morning myself so I can post a demon with the Netduino



#6913 Question about SPI

Posted by klotz on 03 January 2011 - 03:28 PM in General Discussion

If available and if the distance is not too great I would prefer I2C over SPI.

Could you break this down a bit more? Distance being what? If I have a central Netduino in the house, and several scattered around the property, what's the prefered for 50 -200 ft, CAT5 cable?


I would not use I2C or SPI for those distances. In the first case, one should not think of I2C or SPI as a protocol for anything say outside the box. Both are intended for communication between ICs or small peripherals, like ethernet chips, lCD displays and the like.
If I have to go more than a couple of feet, then I would start to concider one of the interconnect serial protocols like Async (TTL, RS232, or RS485.)
Then if we are in the range of Room to Room or greater I would concider ethernet.
So in answer to you direct question. At 50-200ft, especially if you have already installed CAT5, go ethernet. The shields for 'duinos are cheap and .NETMF makes it easy to program.



#6866 Question about SPI

Posted by klotz on 03 January 2011 - 12:25 AM in General Discussion

What are the differences between SPI and the other thing that uses TX and RX? I understand that SPI has a clock so the shift register (lets use that as an example) knows when to read the other pin for a HIGH or LOW. but then how does the TX and RX communicate? how does it know when to get the data? Are they both Serial types of communication or not? Any info is appreciated, links are good too. Thanks!

Tx and Rx are used for Asynchronous Serial communication which is sometimes described as "self clocking". This is misleading to most users in that the data rate must generally be agreed upon before hand as Chris has stated, the selfclocking come from the method for detecting the begining of the data octet or byte. Here is the Wikkipedia page that describes this http://en.wikipedia....ver/transmitter as before I can only vouch for the correctness as of Jan 2, 2010 when I read it. :D

If I had a choice, I would use SPI over TX/RX because it is easier for me to use. If available and if the distance is not too great I would prefer I2C over SPI.



#6865 Question about SPI

Posted by klotz on 03 January 2011 - 12:19 AM in General Discussion

What are the differences between SPI and the other thing that uses TX and RX? I understand that SPI has a clock so the shift register (lets use that as an example) knows when to read the other pin for a HIGH or LOW. but then how does the TX and RX communicate? how does it know when to get the data? Are they both Serial types of communication or not? Any info is appreciated, links are good too. Thanks!


I don't know how much time you have to read stuff, and we could spend a lot of time asking and answering questions so I thought that it may be helpful to supply you with a link to the Wikki page that describes SPI. This may be way more than you wanted to know but there are nuances to using SPI that are not immediately apparent and which many of us take for granted. So here is the Wikki link ( and yes I read it and it is a good description on Jan 2, 2010 :D You know how Wikkipedia can be )
http://en.wikipedia....l_Interface_Bus



#6022 InterruptPort please stop interrupting me! Help.....

Posted by klotz on 13 December 2010 - 12:29 AM in General Discussion

I found that when using the tactile miniswitches, http://www.sparkfun.com/products/97 , if I add a 0.1 mF cap from the signal line to gnd and enable the pull-up resistor cleans up the interupts just fine.



#4396 Where to find these connectors?

Posted by klotz on 31 October 2010 - 05:04 PM in General Discussion

Hey,

I'm looking for male PCB mount connectors and their female counterparts (leads). I prefer the connectors have only one way to connect, so you can't switch poles by accident.

I've seen leads like these on LiPo batteries, but I can't seem to find anything useful on RS Online or Mouser when searching for "JST connector".

The PCB connector part looks something like the white connectors on this shield.

I'm EU based so I prefer a supplier like Mouser or RS Online that ships easily to Belgium. Any other EU based shop is good too!

Thanks a lot!

Niels R.

I think this is what you are looking for if the ones in your second picture will work. http://www.sparkfun....roducts_id=8232

Attached Thumbnails

  • Connectors.jpg



#4151 Where can I get an at91sam7x512

Posted by klotz on 23 October 2010 - 08:32 PM in Netduino 2 (and Netduino 1)

As I reported a while back, I killed one of my Netduinos. I recently successfully removed the dead chip, but now I can seem to find any available ( both Mouser and Digikey report out of stock and won't have any 'till after the first of the year). :angry: I believe that I have been able to verify that the board is still viable so I wanted to "glue" a new cpu chip on this guy to test my smd skills. Any one know where I can locate a at91sam7x512?



#3740 Experimental Drivers for Wiznet-based Ethernet Shields

Posted by klotz on 10 October 2010 - 11:36 AM in Beta Firmware and Drivers

Probably not the way to do it, but I got it to accept multiple connects by moving these 2 lines of code inside the while(true) loop in the Main()

Socket listenSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
listenSocket.Bind(ep);

So the listening socket gets created and bound every time it finished a connection :)
No I can connect as many times to the Netduino as I want.


I would never have thought to do it that way. I am used to using sockets under WinSocks and you would not normally have to recreate the socket to get a new connection. It looks to me like it is not dropping the connection when I close the socket. Your solution causes the socket to be desposed and that may explain why it works.



#3721 Experimental Drivers for Wiznet-based Ethernet Shields

Posted by klotz on 09 October 2010 - 05:08 PM in Beta Firmware and Drivers

updated the code. I found I was not doing the bind/listen/accept cycle correctly. Not sure I have it right yet, I still can't connect more than once. Hope someone could tell me where I am going wrong.



#3668 Experimental Drivers for Wiznet-based Ethernet Shields

Posted by klotz on 08 October 2010 - 07:53 PM in Beta Firmware and Drivers

Ramon,
While I'm unfamiliar with this particular code, I've seen that behavior before and in my case it was because my Ethernet Shield (NKC and authentic Arduino Ethernet Shield) require the 6 pin ICSP header. Both shields were stuck waiting until I solder the ICSP header on the Netduino. You might be running into the same issue.


That is a very good point. I did have a problem with my Seeeduino Ethernet board, it would not accept any of the commands. It turned out that I could do one of two things, add an ICSP connector to my Netduino or change some soldered jumpers on the board.
You may want to check to see if the enthernet board has jumpers. The best place to look would be on the schematic.



#3659 Experimental Drivers for Wiznet-based Ethernet Shields

Posted by klotz on 08 October 2010 - 10:47 AM in Beta Firmware and Drivers

Hi klotz!

I'm trying to get your test project to run, but I must be doing something wrong, because it never gets past this "do loop":

do
{
socketStatus = ReadRegister((UInt16)(socketBaseAddress + 0x0003));
} while (socketStatus != (byte)WiznetStatus.SOCK_ESTABLISHED);

It never returns:
WiznetStatus.SOCK_ESTABLISHED

Do you have any idea what can be wrong?

Thanks,

Ramon


I can't be sure without more details, so I appologize for asking the obvious question, 1) do you have the board connected to a 192.168.11.x network? 2) Have you posted a request from a client computer, "http://192.168.11.98"?
The code waits for a connections from the client, the loop you mentioned so is blocked.



#3649 Experimental Drivers for Wiznet-based Ethernet Shields

Posted by klotz on 08 October 2010 - 01:19 AM in Beta Firmware and Drivers

Well after killing one of my Netduino's, I have managed to add listen, bind and accept to the experimental drivers. I think there is a disconnect between the implementation in the Wiz5100 chip and WinSock or Berkley Sockets. So based on my implementation you can only receive one connection request. Maybe someone can find where I am going wrong and post an update. I have changed the namespace so I could keep my changes separate from the original SecretLabs implementation. EDIT KLOTZ: Update the implementation of the bind/Listen/accept code based on some more reading. Also change the test code. Still does not reconnect.

Attached Files




#3629 Just cooked my 'duino

Posted by klotz on 07 October 2010 - 04:39 PM in Netduino 2 (and Netduino 1)

Unfortunately, the Atmel chip is about a $20 chip (of course unless it is purchased in quantity). I'd say digikey is your best bet.

Just be lucky it isn't a ~$150 chip :P


In either case logic dictates that I order a new Netduino. $20 + shipping and handling and frustration of removing the old and adding a new > 34.95 + shipping and handling.



#3616 Just cooked my 'duino

Posted by klotz on 07 October 2010 - 10:11 AM in Netduino 2 (and Netduino 1)

R.I.P.

But now you have a perfect board to practice SMD reworking (assuming you've burnt just the micro) Posted Image

Now there's a good suggestion.Since I am normally a software guy, where would be the best place to get a replacement Atmel? Digikey is asking $20+shipping handling tax. Almost the price of a new Netduino.
Any suggestion where else I should look?



#3596 Just cooked my 'duino

Posted by klotz on 07 October 2010 - 02:15 AM in Netduino 2 (and Netduino 1)

Hi klotz,

No fun at all. It sounds like it got fried, but you may want to try erasing the Netduino (using the ERASE) pad and seeing if you can reprogram it. It's probably fried--but there's a small possibility of recovery...

Chris

P.S. Reverse power protection and a resettable fuse are built into the Netduino. And the odd pin spacing for shields helps keep pins in the right place. But while Netduino is designed to take a certain amount of abuse, it is possible to fry a pin (or in more extreme cases, to fry a whole Netduino). Most users will be fine--but it makes me sad to see one get electrocuted...


He's dead Chris.
No amount of protection can survive an unattentive user. Just got to excited about testing my two ethernet shields and didn't notice I had plugged it in wrong. The Seeeduino shield is wider than most so it is not as easy to see the pins if you don't pick it up and inspect it.
And of course I was convince I had checked it so I let it cook while I trouble shot the failure to connect. The Atmel was way hot, and I can't get any response from it at all except a very bad smell and lots of heat.
(Kind of reminds me of like Washington D.C. or Springfield, IL)
I'll mount this one on the wall with a note "CHECK THE SHIELD" hanging from it.
That's what overconfindence will get you.



#3594 Just cooked my 'duino

Posted by klotz on 07 October 2010 - 12:39 AM in Netduino 2 (and Netduino 1)

I ALWAYS triple check my connections. So far, I have not fried even a single component.

I have gotten quite close though ;) Just ask my temp sensor that had a backwards pinout to the dumb datasheet....


I guess I shouldn't try to work on my board with distractions. Just did not notice the pins that were not in their sockets.



#3591 Just cooked my 'duino

Posted by klotz on 07 October 2010 - 12:11 AM in Netduino 2 (and Netduino 1)

I unfortunately plugged my shield in off key without noticing it and when I powered my Netduino it failed to connect. I tried to find the software reason it wouldn't connect rather than what could be wrong with hardware. Once I notice the shield was not plugged in correctly, I disconnected the power removed the shield and allowed the duino to cool. TOO LATED :o Well live and learn. From now on, I won't power-up without checking the connections. Oh well now I have to order a new one Just had to get that off my chest.



#3506 Compatible Shields and Accessories

Posted by klotz on 04 October 2010 - 11:36 PM in Netduino 2 (and Netduino 1)

Add the following Wiz5100 ethernet shield http://www.seeedstud...l?cPath=101_102 also available from http://www.nkcelectr...eeedstudio.html Like the latest Arduino Ethernet shield it requires an ISPC connection. Sorry about that, I found the schematic and it will work without the ISPC. There are three zero ohm resister used as jumpers that just have to be moved to convert from ISP to DI MOSI. Duh! :unsure:

Attached Thumbnails

  • wiznetshield500.jpg




home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.