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).
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 .
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.
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:
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?
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).
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.