I2C driver for New Haven LCD display

Does anyone have a driver written for I2C communication with New Haven Displays? The new display I have uses the ST7036i firmware. I have an I2C driver for my EEPROM that works good and a serial driver for a different type of FW. I could merge them but if someone has one prewritten that would save me a lot of register headaches.

The link to the driver posted for the same display type is broken.

I wrote a driver with basic functions for a NHD-0420CW-AG3 display. If thats useful for you, I could look for the code and share it (I shared it in the Codeshare-section of the old forum, maybe you can also find it there).

Found the old link… I wanted to look at it also

http://old.ghielectronics.com/community/codeshare/entry/1088

Nice! Took the day off yesterday so just now getting around to checking it out.

@glx Hm I am having a bit of trouble…execution keeps failing…

Does anyone see something wrong with this? Did I format my byte[] wrong in creating the transaction?

I2CConfig=new I2CDevice.Configuration(0x78,400);
I2C = new I2CDevice(I2CConfig);
I2CDevice.I2CTransaction[] xActions = new I2CTransaction[1];
xActions[0] = I2CDevice.CreateWriteTransaction(new byte[]{0x00,0x38});
Thread.Sleep(10);
If(I2C.Execute(xActions,1000)==0){
Debug.Print("Failed Transaction");
}

Do you know what exactly fails?
I think your I2C-address has the “wrong” format (I think you took the one from the datasheet). There are two different ways to tell the I2C-address, one is the (I think) normal way, using the 7-bit address (e.g. NETMF,) because the last bit is the read/write bit, or taking the 8-bit address (what e.g. mbed uses). 0x7C and 0x3E is basicly the same number (if you look at its bits)
01111100 = 0x78 (8-bit)
0111110 = 0x3E (7-bit --> shifted 1 right)
Mostly (as in this case) the datasheets tell you the bit-pattern, thats used so you can “calculate” the right address-format for your system by yourself e.g. using the windows-caltulator (just set it to programmer-mode, then you can select the individual bits and it tells you your number in different formats).
So maybe you could try just using the other address-format :slight_smile:.
On the hardewae-side the olny thing that could go wrong is wrong wiring or forgetting the pullup-resistons on the SCL- and SDA-line.

netmf is 7-bit addressing only. According to a datasheet I found, the address is 0x3c to 0x3f

Ah thank you I should not have assumed that they were giving me the address in 7-bit…I need to brush up on all these formats.

@Brett wait so is the i2C address supposed 0x3E and the register addresses 0x3c to 03f?

All I see is slave address = 0x78 and DDRAM goes from 00 to 53 (why do they mix addresses like 4A, 4B, 0E,0F, etc. in with regular numbers?)

What is this windows converter thing you speak of glx?

Just the regular windows calculator app.

The slave-address is 0x78 in 8-bit-format, but you need the 7-bit (which is 0x3C), because thats the one NETMF uses.

I tried 0x3C when creating the I2CConfig but my transaction stlil failed.

@glx Is this address wrong too?

xActions[0] = I2CDevice.CreateWriteTransaction(new byte[]{0x00,0x38});

00 means sending a command and 0x38 is the display’s function set up (ie set 2 lines, etc)

no, the I2C address is in the range of 0x3c to 0x3f, for a device datasheet that I looked at. You need to look at your hardware, to see whether that is true for yours, and whether any jumpers are set. But clearly 0x78 is an 8-bit address, so can’t be used as-is in netmf code without adjustment.

And what fails? I’ve talked in the past about being precise with the feedback you give us (we’re not in front of the code or the hardware) so you need to help us help you by explaining more what is going on. I’ve also pointed out making sure you use the return code from transaction execution to see what is working, is that incorporated in your code?

@Brett I used 0x3C for the I2C address which is the 7-bit equivalent of 0x78. I think I may be doing the addresses in this part wrong too but I am not sure:

xActions[0] = I2CDevice.CreateWriteTransaction(new byte[]{0x00,0x38});

It fails at the execution at the end of this code:

I2CConfig=new I2CDevice.Configuration(0x3C,400);
I2C = new I2CDevice(I2CConfig);
I2CDevice.I2CTransaction[] xActions = new I2CTransaction[1];
xActions[0] = I2CDevice.CreateWriteTransaction(new byte[]{0x00,0x38});
Thread.Sleep(10);
If(I2C.Execute(xActions,1000)==0){
Debug.Print("Failed Transaction");
}

As I said - the datasheet I saw said the address can be set with hardware/jumpers, so 0x3c is still a stab in the dark. Please check the hardware and validate that you’re even trying the correct address. But yes, 0x3c is the 7-bit equivalent of 0x78. But you didn’t ever have that address working, did you?

In my view, this again becomes a wiring issue unless it’s a speed issue. Try 100 or 200 instead of 400, see if that helps, but I expect 400 to work. Is there a reason you haven’t just tried GLX’s codeshare driver and see if it works?

@Brett My data sheet states the slave address is 0x78

The display only has 8 pins. Wired it just like the schematic with pull ups on SDA and SCL…it doesn’t mention what size pull ups in the data sheet so I just used 10k. The display lights up, I just can’t write to it yet. I will try a different speed (my EEPROM uses 10k ohm for 400 kHz I am pretty sure).

I am using parts of glx’s driver…his display has different features so I just drew from his.

if your hardware doesn’t have jumpers to set/change the address, then fine, 0x3c it is. Want to tell us where the datasheet is? Also, remember, you don’t need double pullups, assuming you’re using the same i2c lines.

As @Brett mentioned - you only need one set of pull ups.

2.2k is a better starting point than 10k…