27 replies to this topic

[Tecchie]

Having a quick look at klotz's code, it seems that having to shift the address 0x50 one bit to the right may be the culprit.

   I2CConfig = new I2CDevice.Configuration(0x50 >> 1, 100);

[klotz]

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");
        }
    }
}

[Asaak]

I used the code and the same...nothing happens. I work with it using serial rs232 and it works just fine, so I guess it is not something wrong with it...

[klotz]

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 Files

•  NHD-0220D3Z-NSW-BBW connections to Netduino.jpg   209.78KB   27 downloads

[Tomcat]

Hi, do you still struggle with this? To me it seems to be the "standard problem" of I2C addressing. You are using 0x50 (which is quite common on the AVR libs), unfortunately .netmf uses the correct 7-bit address (according to the I2C standard the LSB bit is used for distinguishing read and write access). Having looked up some I2C standard addresses I assume that you should use 0x50 >> 1 ... which is 0x28.... simply 'cause there are no devices 0x50 :-) And dont forget to use the pullups (10k or 4k7 ohms) on the CLK and DA bus .... this can also fool you a lot. Best wishes + good luck, Tomcat

[Troll feeder]

Tomcat, Assuming you are correct, and I have no reason to doubt it, it sounds like a classic bounds check problem on the part of .netMF. If something as important as the address is out of bounds an exception should be thrown. I expect to see some arduino code which is less than perfect, aside from the professionals using it a lot of hobbyists are, many soldiering through it on intestinal fortitude and a leading arduino book. A commercial software company that doesn't bounds check parameters is asking for a lot of trouble, viruses, exploited computers, botnets et.al. Oh wait, we are talking about Microsoft ;^) All levity aside, I am surprised error as simple as an address out of bounds wasn't caught in software at a 4.1 version.

[Chris Walker]

Troll feeder, Good feedback. Not sure that it's a bound-checking exception issue as much as it is allowance for extension to 10-bit addresses on microcontrollers that support them. But something to bring up for sure... Chris

[Troll feeder]

Troll feeder,

Good feedback. Not sure that it's a bound-checking exception issue as much as it is allowance for extension to 10-bit addresses on microcontrollers that support them. But something to bring up for sure...

Chris

Thank you Chris,

I may be net to the .netmf arena however, as a long time programmer to see a routine fail to check a passed parameter to see if it is in bounds. What is really odd is the full blown .Net is positively anal about checking values in some places. In any case I'll defer to your opinion on the cause as I ammjust getting started with I2C, SPI et. al.

Mike.