Go Down

Topic: ILI9341(new)SPI library for Due supporting DMA transfer(Uno, Mega,.. compatible) (Read 185967 times) previous topic - next topic

david_prentice

From ILI9341_due.h
Code: [Select]

virtual size_t print(double, int = 2);

So you can just say:
Code: [Select]

     tft.print(1.2345, 1);

In exactly the same way that you would say Serial.print(1.2345, 1);

The library lets you align text however you want.
Of course you can format your float expressions with dtostrf() into a char buffer in the normal.   Then print the buffer with all the facilities provided by Marek.

David.

Rossp

Not too familiar with  your suggestion but I redid my sketch using Sprintf and TFT.printAt to comply with the library demands as in the arcs.ino example and I was able to succeed with a 3 digit integer value but the int always displays a "?" instead of the real value.

Sketch is over 700 lines so here's some details below

Serial data:
avgwindspeed varies from 0-99.9
avgwindangle varies from 0-360


float avgwindspeed ;

int avgwindangle ;

char textBuff [20];

void loop();

sprintf(textBuff, "%4.1f", avgwindspeed);
tft.printAt(textBuff, 260, 23);


sprintf(textBuff, "%3d", avgwindangle);
tft.printAt(textBuff, 260, 80);

Any ideas why ?

Once this is resolved then padding needs to be arranged.

Thanks

david_prentice

Arduino started off on a small AVR.    It supports f-p printing with C++ classes.    You can specify how many decimal places but not the overall format width.    (it defaults to 2 dec places)

Although you have access to the regular C library,  printf() defaults to the cut-price version.     Formatting f-p expressions is quite expensive.   That is why you see "?" when you try to use "%f"

Code: [Select]

#if defined(__arm__)        //e.g. Zero, Due, STM32
#include <avr/dtostrf.h>
#endif

void setup()
{
    Serial.begin(9600);
    
    Serial.println("print Floating Point on Arduino");
    Serial.print("regular Serial.print(1.234) ");
    Serial.println(1.234);
    char buf[40];
    Serial.print("sprintf(2.345) ");
    sprintf(buf, "%5.2f", 2.345);
    Serial.println(buf);
    Serial.print("dtostrf(3.456) ");
    dtostrf(3.456, 5, 2, buf);
    Serial.println(buf);
}

void loop()
{
}


Note that some Arduino "cores" expect you to include "dtostrf.h"
But the standard AVR IDE always knows about dtostrf()

Cores like ARM, ESP32, ESP8266 come with a full-fat printf() so you can use %f easily.
If you want to use a Uno, Mega, ... you will need dtostrf()

dtostrf() can format output nicely
Arduino print() can never pad expressions.   Everyone has discovered how nasty integer and hex numbers look.

David.

Rossp

Thanks David got it displaying all values now. I read somewhere that it would provide text padding as well but it does not seem to be the case so I'm using TFT.fillRect for padding.

Ross

phoefler

Hi,

I am trying to add support for ILI9325 controller to this library.
But I am really not very experienced with all this display stuff.

Do you think that it's doable?
I like the DMA support, but I have to use a display with ILI9325 controller.

I am confused by the init code for the ILI9325 controller
As far as I understand the init of ILI9341 there is always a command byte and then a variable amount of data bytes.
But when looking into an init sequence of a ILI9325 it seems, that command and data are a word.

Here are a few lines of the init code of a ILI9325 driven display:
//************* Start Initial Sequence **********//
 write_command(0x00,0x01);write_data(0x01,0x00); // set SS and SM bit
 write_command(0x00,0x02);write_data(0x07,0x00); // set 1 line inversion
 write_command(0x00,0x03);write_data(0x10,0x30); // set GRAM write direction and BGR=1.
 write_command(0x00,0x04);write_data(0x00,0x00); // Resize register
 write_command(0x00,0x08);write_data(0x02,0x02); // set the back porch and front porch
 write_command(0x00,0x09);write_data(0x00,0x00); // set non-display area refresh cycle ISC[3:0]
 write_command(0x00,0x0A);write_data(0x00,0x00); // FMARK function
 write_command(0x00,0x0C);write_data(0x00,0x00); // RGB interface setting,01,11ÉèΪ16BIT RGB½Ó¿Ú//01,10ÉèΪ18BIT RGB½Ó¿Ú
 write_command(0x00,0x0D);write_data(0x00,0x00); // Frame marker Position
 write_command(0x00,0x0F);write_data(0x00,0x00); // RGB interface polarity;//ob//02 Õâ¸ö¼Ä´æÆ÷ºÜÖØÒª£¬Òª¸ù¾Ý¿ÍÈ˵ÄÖ÷¿ØÀ´ÉèÖÃ,¾ßÌåÇë¿´IC¹æ¸ñÊé¡£ÓÐʱ¿ÉÒÔÉèΪ00£¬00£¬Ö±½Óµ÷Ö÷¿ØʱÐò.


david_prentice

Are you using the 8080-8 or 8080-16 parallel interface?   This library is for SPI.

If you are using the SPI interface with ILI9325 it works differently to the ILI9341 SPI.

Very few TFT modules allow access to the IM# pins.   So it is unlikely that you can select different interface modes anyway.

David.

phoefler

Thanks for your reply.
I am trying to use SPI interface for both controllers.

You think it's not possible to add support for ILI9325 as the controllers are too different?

david_prentice

Do you have access to the IM# pins?

I have written code for SPI ILI9320.   The SPI works fine.   And in fact it suits DMA better than the 4-wire ILI9341 style.

However,   I would find it daunting to fiddle with Marek's code.
Your best bet is to buy an SPI ILI9341 display.

At least you are using a proper 3.3V Due.   Life is much easier without level converters.

David.

phoefler

I am not sure, how I can determine if I have access to the IM# pins :-)
I am talking about this display: http://en.startek-lcd.com/IPS024/2015-11-21/22228.chtml
It has multiple interfaces and I use SPI.

I am afraid, that you would say I should go for a ILI9341 display.
It's difficult for me, as I have several requirements. Among others the FPC route is important ...

Thanks for your help!
ph

david_prentice

Woo-hoo.   The datasheet shows that IM0-IM3 are on pins 3-6 of the 45-way ribbon cable.

So you can select SPI interface.    But unless you are experienced,   you will find it difficult to alter the operation of the library as well as the interface driver.

Marek may or may not be interested.    It would be a lot of work for just one beneficiary.
From your point of view.    If you are using 1000 cheap ILI9325 panels it might be worth your time and effort.
The IPS panels certainly have better viewing angles than regular TFT.

I suspect that you could get a similar price / quality with a modern controller.    If you are intending to use 1000s of screens,   Chinese agents will get you a good deal.

David.

phoefler

Thanks for your explanations.
I will not need 1000 pcs in the near future, so probably it's not worth the time. I was hoping that it's only a small adaption in the first place ...

Can you recommend a good Chinese agent?
I am googling the last couple of days and wrote emails to all agents or manufacturer I've found, that nearly meets my requirements. Some did reply some not. But I haven't found a suitable display right up to now.

Currently I am using this display:
https://fanscoo.en.alibaba.com/product/940112893-217020767/Small_2_4_transflective_sunlight_readable_lcd_panel_display_screen_module_with_SPI_RGB_optional.html

That meets all my requirements, but they break with no obvious reason.
I think some cells leak out and black/grey lines are visible.

Thanks for your help,
ph

david_prentice

What is your current controller?
The link does not mention the controller.

I have only used "cheap" TFT screens.    They look fine at 90 degrees.    Ok for graphics from an angle but photos look appalling.

Incidentally,   the ILI9325 does not work as fast as the ILI9341.

David.

phoefler

The Fanscoo Display has an ILI9341 controller. With that display Markek's lib works perfectly.
But these displays are failing and that's why I am looking for another one.

I didn't find a transflective display with SPI and that FPC route and ILI9341 controller ... :-(

Thanks for pointing out, that ILI9341 is faster. I was not aware of that. I used a ILI9325 controller once, but I thought the speed came from the DMA of the Due and Marek's lib.

david_prentice

The ILI9341 seems to work much faster than the datasheet says.

Don't assume that other controllers have such good performance.

David.

phoefler

@david_prentice,
Hallo David, I've one more question :-)
I found a few displays using the ST7789V controller instead of the ILI9341.
I found some older posts from you stating [1][2], that both controllers are very similar and just the RGB order is switched.

Would you say, that adapting Marek's lib to support ST7789V controller is doable?
You said, that ILI9341 is faster than others. Do you have a comparison between these two controllers using SPI with DMA?

[1] https://forum.arduino.cc/index.php?topic=546228.0
[2] https://www.avrfreaks.net/forum/320x240-controller-differences-st7789s-and-ili9341-solved

Go Up