Recent Posts

Pages: 1 ... 4 5 [6] 7 8 ... 10
51
TFTs / Re: Raspberry Pi driver for 1.8" and 2.4" TFT models
« Last post by deanflyer on July 06, 2018, 08:54:55 AM »
Just came across this post. Ive been messing around with theNH 2.4" sunlight readable TFT and the raspberry pi. Unfortunately I managed to short it out, so need to order another one :(

I'm more of a software guy. What im looking for is a small 2.4-3.5" TFT that I can drive at up to 60fps. It needs to be sunlight readable though i.e. ~1000CDM, hence looking at the Newhaven 2.4" displays.

Not 100% tied into Raspberry Pi, as long as I can develop c/c++ code on a SBC and interface it, I'd be happy.

Any thoughts before I order another TFT?
52
OLEDs / Re: NHD-3.12-25664UCY2 Drawing
« Last post by row_dev on July 05, 2018, 08:33:06 AM »
I ran some further tests. I thought the behaviour looked like the display was running out of power, so I connected the display circuit to an external variable power supply, isolated from the Arduino via an SN74LVC245 8-bit level shifter.

This time I was able to display 3 vertical bars, so I recorded the current taken to display differing numbers of vertical bars:
1 bar = 20 mA  [displayed]
2 bars = 25 mA [displayed]
3 bars = 30 mA [displayed]
4 bars = 14 mA [failed to display]

While the trying to display 4 vertical bars (columns) I decided to tweak the display voltage from 3.3V slowly up to about 4.0V. At 4.0V the display was suddenly able to show the 4 bars at full brightness!

I understood this to be a 3.3V display. Is it possible that I have a 5V version, or is there some other phenomenon at play here?

I attach a photo of the back of the display, showing the model and ID and await further advice before attempting any other work at higher voltages (I really don't want to burn out the display through improper use).
53
OLEDs / NHD-3.12-25664UCY2 Drawing
« Last post by row_dev on July 04, 2018, 11:35:27 AM »
I have been experimenting with the display on an Arduino Uno using the example code modified to use SPI without the port remapping. I have discovered the settings that allow drawing to the desired pixel:

Set_Col_Address(0x1C,0x5B);
Set_Row_Address(0x00,0x3F);

This eliminates the need to draw to off-screen buffer.

The problem I'm having is that I can draw a small number of pixels anywhere on the screen, but if that number increases the display doesn't display the image properly and is usually too dim to see. In the example pics below I successfully draw two 4 pixel lines at each side of the display. When I draw an additional line in the middle, I can see the line being drawn brightly then very quickly becoming super dark, before drawing is complete. When I fill the entire screen with pixels, it is super dark, but just visible (not bright as in the pic in the post by bill titled "NHD-3.12-25664UCY2 display - inconsistent pixel brightness in same areas").

Any thoughts as to how to get a greater number of bright pixels?
54
Character LCDs / Re: NHD-0220D3Z-NSW-BBW-V3 using I2C dropping characters
« Last post by jimhogue on July 02, 2018, 03:20:27 PM »
We are using NHD-C0220BIZ-FSW-FBW-3V3M
It seems to have I2C speed issues and does not ack properly if the pull-up resistors are lower than 10K.  We are using an I2C bus, so we have a bit more capacitance than just the micro to the LCD.  It seems the LCD cannot pull the data line low enough to ack properly.  Is this going to be fixed?
55
Character LCDs / Re: NHD-0220D3Z-NSW-BBW-V3 using I2C dropping characters
« Last post by Paul_B on July 02, 2018, 09:57:10 AM »
Hi bwendin,

Iím sorry to hear about the trouble you are having with the NHD-0220D3Z-NSW-BBW-V3.

There is a known issue on our serial LCD modules which affects its operation when used in I2C mode.
When using the moduleís I2C interface at a clock rate of 100KHz NACKs/bit errors/hanging, may occur.
Therefore, if using the I2C interface of these serial LCD modules, a MAX clock rate of 50KHz should be used.

We have updated the I2C section of our datasheet to reflect this information, and the updated specs should be accessible on our website shortly.
If you have any questions or need any assistance getting these serial LCD modules working, please contact us by emailing our technical support email nhtech@newhavendisplay.com, or by calling our phone M-F, 8am - 5pm CST (number listed on our website in the contact us section), we're always happy to help!  :D
56
TFTs / Re: EVE2 Palette8 Pixels
« Last post by Paul_B on July 02, 2018, 09:32:20 AM »
Hi warriorofwire!

Iím sorry to hear about the trouble you are having with storing / displaying Paletted8 bitmaps.

FTDI has an application note for image file conversion (see page 14):

http://www.ftdichip.com/Support/Documents/AppNotes/AN_303%20FT800%20Image%20File%20Conversion.pdf

Code: [Select]
//The following code shows a PALETTED8 example for the FT81x. PALETTED8 format is supported
//indirectly in the FT81x and it is different from the PALETTED format in the FT80x. To render
//Alpha, Red, Green and Blue channels, multi-pass drawing action is required.

//addr_pal is the starting address of palette lookup table in RAM_G
//bitmap source(palette indices) is starting from address 0

dl(BITMAP_HANDLE(0))
dl(BITMAP_LAYOUT(PALETTED8, width, height))
dl(BITMAP_SIZE(NEAREST, BORDER, BORDER, width, height))

dl(BITMAP_SOURCE(0)) //bitmap source(palette indices)

dl(BEGIN(BITMAPS))
dl(BLEND_FUNC(ONE, ZERO))

//Draw Alpha channel
dl(COLOR_MASK(0,0,0,1))
dl(PALETTE_SOURCE(addr_pal+3))
dl(VERTEX2II(0, 0, 0, 0))

//Draw Red channel
dl(BLEND_FUNC(DST_ALPHA, ONE_MINUS_DST_ALPHA))
dl(COLOR_MASK(1,0,0,0))
dl(PALETTE_SOURCE (addr_pal+2))
dl(VERTEX2II (0, 0, 0, 0))

//Draw Green channel
dl(COLOR_MASK(0,1,0,0))
dl(PALETTE_SOURCE(addr_pal + 1))
dl(VERTEX2II(0, 0, 0, 0))

//Draw Blue channel
dl(COLOR_MASK(0,0,1,0))
dl(PALETTE_SOURCE(addr_pal)

Regarding the palette / index scheme of FTDI's image converter tool it may be beneficial to seek support from their support team directly.

http://www.ftdichip.com/FTContact.htm.

Hope this helps!

57
TFTs / EVE2 Palette8 Pixels
« Last post by warriorofwire on July 01, 2018, 02:52:40 PM »
This display is awesome!  I've referenced FTDI's FT81x Series Programmers Guide and implemented a display library, asset management and lightweight display stack for RGB565.  I have a couple needs for small, high quality transparent Paletted8 bitmaps, however.  Here are the bytes that are written to memory, line:[ ] pixel: ():

[ (ff 00 00 ff) (00 ff 00 ff) (00 00 ff ff) ]    [ (ff ff ff 00) (ff ff ff 80) (ff ff ff 00) ]

This is supposed to be RGBA, 3px wide by 2px high.
Top row goes red, green, blue.
Bottom row goes transparent, halfway white transparent, transparent.

On the display there's just garbage.  What is the proper way to store in memory and display a Paletted8 bitmap on EVE2?

Code: [Select]
display_list.begin(bitmaps));
display_list.bitmap_handle(0));
display_list.bitmap_layout(BitmapFormat::Paletted8, width, height));
display_list.bitmap_size(BitmapFilter::nearest, BitmapWrap::border, BitmapWrap::border, width, height));
display_list.bitmap_source(bitmap_location));

// Alpha
display_list.blend(BlendFunction::one, BlendFunction::zero));
display_list.color_mask(0, 0, 0, 1));
display_list.palette_source(bitmap_location + 3));
display_list.vertex2ii(x, y, 0));
display_list.blend(BlendFunction::dst_alpha, BlendFunction::one_minus_dst_alpha));

// Red
display_list.color_mask(1, 0, 0, 0));
display_list.palette_source(bitmap_location));
display_list.vertex2ii(x, y, 0));

// Green
display_list.color_mask(0, 1, 0, 0));
display_list.palette_source(bitmap_location + 1));
display_list.vertex2ii(x, y, 0));

// Blue
display_list.color_mask(0, 0, 1, 0));
display_list.palette_source(bitmap_location + 2));
display_list.vertex2ii(x, y, 0));

Regular 565 2 bytes per pixel works great.  I've got animations and counters working great already, just need to figure out how to draw an RGBA8888 image :-)

I found FTDI's tool for converting PNG's to palette8.  It seems to be broken though - it won't open any png file I can find.  "invalid input file" on anything I've produced or found on the Internet.  I just need the file format and I'll make my own tool!!  What does a palette & index bytewise schema look like?
58
Evaluation Tools / Can't connect to NHDev via JTAG interface
« Last post by SteveK on June 28, 2018, 06:07:48 PM »
Hi there,

I am trying to access the programming interface on the NHDev board using an STMicro ST-LINK programmer.

I am aware of a note in a previous (2015) topic:
The Dev board code disables the JTAG after a second of power, so
when loading the code you must hold the board in reset and program
immediately after letting off the reset button.


OK, so I do this, trying various delays between lifting the reset button and clicking "connect" on the ST-LINK.  I cannot make it connect - it reports "No Target Detected", or "Internal command error" if I keep the reset button down for longer.

Also in the previous topic, you stated that you use the Keil ULINK programmer, but at over $300, that's not an option at this stage.

Has anyone had success with the ST-LINK? Or, has anyone had success with an alternative but affordable programmer?

Many thanks,
Steve

59
Character LCDs / Re: NHD-0112BZ-FL-YBW not displaying all characters
« Last post by 7b_w on June 26, 2018, 08:11:40 PM »
Thanks for the info Ted.
I had help on the Arduino forum ( see https://forum.arduino.cc/index.php?topic=554855.0 ) and first off it was part contrast problem which I ended up using a pot to
adjust. Second I had to use lcd.begin(6,2) to treat the display as 2 lines but  2nd line actually next to first.
I then added the library hd44780.h which has a lcd.lineWrap() which took care of the 2 lines being added together to make one line.
The display works as expected and like the 16x2 display that i used for bread boarding.

Bruce
60
Character LCDs / Re: NHD-0112BZ-FL-YBW not displaying all characters
« Last post by Ted_M on June 26, 2018, 09:39:09 AM »
Hi Bruce,

Use lcd.begin(12,1).  D0 - D3 can be left open.

When the display is powered on, it is by default in 8-bit mode and therefore the 4-bit data must be transferred twice. After 2 more 4-bit operations, transfer the busy flag and address counter data.

From the ST7066U datasheet:

For 4-bit interface data, only four bus lines (DB4 to DB7) are used for transfer. Bus lines DB0 to DB3
are disabled. The data transfer between the ST7066U and the MPU is completed after the 4-bit data has
been transferred twice. As for the order of data transfer, the four high order bits (for 8-bit operation, DB4 to
DB7) are transferred before the four low order bits (for 8-bit operation, DB0 to DB3). The busy flag must be
checked (one instruction) after the 4-bit data has been transferred twice. Two more 4-bit operations then
transfer the busy flag and address counter data.

http://www.newhavendisplay.com/appnotes/datasheets/LCDs/ST7066U.pdf

For further details, also see Table 12 on pg 42 of the HD44780U driver for writing to a 1 line display with 4-bit operation.

http://www.newhavendisplay.com/appnotes/datasheets/LCDs/HD44780.pdf

Regards,
Pages: 1 ... 4 5 [6] 7 8 ... 10