display RS485


McAwesome

Golden Member

Er zijn ook displays met een ingebouwde I2C-interface zoals de RC1602B5-LLH-JWV van RayStar Optronics. De displays zijn betaalbaar en je hebt geen opsteekprintje of extern IC nodig. Het aansturen is standaard met commando's zoals bij een HD44780 maar dan via I2C.

Voor RS485 kan je een opsteekprintje gebruiken zoals: https://uk.rs-online.com/web/p/display-interface-kits/8247134/ of zelf iets bouwen.

Serenity now, insanity later
trix

Golden Member

zit er trouwens een libary voor lcd's in atmel studio 7 ?

ik ga denk ik eerst proberen om het in de 4-bits mode werkend te krijgen, dan kan ik later nog b.v. het i2c gebeuren tussen voegen.

[Bericht gewijzigd door trix op 13 december 2019 19:13:53 (54%)]

eigenwijs = ook wijs
trix

Golden Member

een vraagje:
ik zit net de datasheet van mijn display te bekijken, en ik lees dat er in de 4-bits mode gebruik moet worden gemaakt van de busy-flag.

is dat altijd zo ?

ik vraag me dat af omdat arco zij 6 pinnen nodig te hebben, maar dat worden er dan 7.

eigenwijs = ook wijs

Busy flag is niet nodig als je voldoende tijd tussen de commando's laat. Sommige commando's duren wat langer dan andere.

En als je de busyflag wil lezen dan moet je ook de r/w pin aansturen dus dat kost 2 pinnen extra.

Dit zijn die I2C opsteekprintjes:
https://www.ebay.com/itm/5-Pcs-IIC-I2C-Serial-Interface-Board-Module-F…

[Bericht gewijzigd door deKees op 14 december 2019 17:32:56 (82%)]

buckfast_beekeeper

Golden Member

Wil je custom tekens laten verschijnen heb je R/W sowieso nodig.

Opzetprintje? Waarom dan niet ineens kiezen voor een serieel display?

Ik gebruik graag LCD's van newhaven. Die hebben de standaard display groottes met een seriële aansluiting. Naar keuze RS232 (TTL), I²C en SPI. Bij RS232 maar 1 I/O nodig. Van 300Bd tot 115.2K Bd.

Van Lambiek wordt goede geuze gemaakt.

Busyflag wordt bijna nooit gebruikt. Sommige displays ondersteunen die zelfs niet...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
trix

Golden Member

Op 14 december 2019 17:56:46 schreef buckfast_beekeeper:

Ik gebruik graag LCD's van newhaven. Die hebben de standaard display groottes met een seriële aansluiting. Naar keuze RS232 (TTL), I²C en SPI. Bij RS232 maar 1 I/O nodig. Van 300Bd tot 115.2K Bd.

dat was mijn oorspronkelijke vraag :)

onder hinweis

eigenwijs = ook wijs

Voldoet een RS232(TTL) aan de vraag?

Als je er zelf één wilt maken, hier de link
https://hobbybotics.com/projects/hobbybotics-serial-lcd-cont...ller-v3-0/

Die heb ik zelf al enkele keren gemaakt en werkt voortreffelijk.

LDmicro user.

...onder hinweis

Zoals gezegd,

Afvragen busyflag wordt zelden gedaan, heeft weinig meerwaarde. Gewoon je aan de (datasheet) timing houden is genoeg.

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Op 14 december 2019 19:42:59 schreef Arco:
Afvragen busyflag wordt zelden gedaan, heeft weinig meerwaarde. Gewoon je aan de (datasheet) timing houden is genoeg.

In een ander draadje heb ik gezegd dat Engels genoeg is, dat er nauwelijks relevantie informatie in het Duits is. Ich stehe korrigiert.

Afijn, de (duitse) datasheet van trix claimt dat de ausfuhrungszieten in het datanblatt alleen gelden als je naar de busy-flag kijkt, en dat ze anders wezenlijk anders zijn.

Dat is iets wat ik ook nog nooit eerder gezien heb, maargoed, ik lees ook alleen engelse datasheets. Daar ben ik nooit zoiets tegengekomen.
TS: Welk part is dit?

Timing staat in de datasheet:

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
buckfast_beekeeper

Golden Member

Op 14 december 2019 19:42:59 schreef Arco:
[...]
Zoals gezegd,

Afvragen busyflag wordt zelden gedaan, heeft weinig meerwaarde. Gewoon je aan de (datasheet) timing houden is genoeg.

Er zijn wel wat testen rond gebeurd. Boven 10MHz zou de busy flag opvragen sneller gaan dan niet. Onder 8MHz neemt het extra tijd in beslag.

Uit de C librarie die ik gebruik. Standaard gebruik ik de busy flag een R/W wel. Zoals al aangehaald elders, wat kost enkele I/O extra nog? Enige is dan dat je de grotere pin hoeveelheden niet in DIL hebt.

#define RW_LINE_IMPLEMENTED 1 // 0 for no RW line (RW on LCD tied to ground), 1 for RW line present
#define WAIT_MODE 1 // 0=Use Delay Method Faster if running <10Mhz) // 1=Use Check Busy Flag (Faster if running >10Mhz) ***Requires RW Line***
#define DELAY_RESET 15 // in mS

Van Lambiek wordt goede geuze gemaakt.

Een 44780 display is een character display. Vaker als een paar keer per seconde updaten is zinloos en maakt alles onleesbaar...
Tijden zijn gemiddeld 37uS, da's 25kHz... (een paar uS meer of minder merk je dan niet)

't Kost maar 1 pin extra, maar die ga ik niet opofferen voor een vrij zinloze zaak.
(busyflag kan meer problemen geven als oplossen daarbij. Zoals gezegd ondersteunt niet ieder display het)

Gewoon netjes de tijden in de tabel aanhouden, en je hebt geen problemen.
(we hebben er tienduizenden uitstaan, nooit problemen met het display)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
EricP

mét CE

Grappig... Ik heb dus ooit een libje geschreven voor die 44780. Uiteraard checked die de busy flag. Fijne daarvan is dat je helemaal niet over timing na hoeft te denken.
Tot op heden slechts 1x een display gehad wat niet wilde. Dat bleek een rotje in het display zelf te zijn - z'n broertje deed (en doet) het prima.

Ja, je kunt je aan de timing houden. Gaan kl*ten met delays enzo. Veel te veel gedoe en al helemaal niet handig als het controllertje meer moet doen dan alleen iets op een display frutten. Die paar extra I/O pinnen? Ach, die heb je tegenwoordig toch zat. En als het echt krap wordt (heel soms gebeurt dat), dan is het met een shift register ook zo opgelost - libje voor, je merkt er in code niks van. Kun je de volledige I/O met 4 pinnen doen (ok, als je met timing gaat hannessen met 3...).

(we hebben er tienduizenden uitstaan, nooit problemen met het display)

Als dat ook tienduizenden dezelfde displays zijn... Dan is dat ook niet zo raar als het eenmaal werkt :). Overigens valt het ook niet altijd op - als het 'meestal' goed gaat, zou het zomaar kunnen dat er geen klant over klaagt. Tsja... Prutswerk. Maar dat is dan ook goed genoeg, dat klopt.

Waarom het nou RS485 moet zijn? Dat is alleen maar handig als het ook wat verder weg zit - serieel op TTL of 3V3 is voor 'on board' ook uitstekend te doen. Trix, wat let je: maak een stukkie software wat die LCD controller aanstuurt en ondertussen op z'n UART luistert. Schrijf iets van een 'terminal emulatie' waarin je een wat control spul hebt zitten om bepaalde acties te doen - er is vast nog wel ergens een beschrijving van VT100 ofzo te vinden.
Nadeel daarvan is wel dat het je een UART kost (of wil je het gaan bit-bangen? :) ). Dat is voor mij doorgaans een veel groter obstakel dan een paar I/O pinnen...

buckfast_beekeeper

Golden Member

Dat de busy flag nog aanwezig is bij het gros van de display's heeft echt wel een reden. Als het zonder kan/moet hadden ze de pin al lang op de schop gezet. Zo lang newhaven de displays aanbied met busy flag, zal ik deze blijven gebruiken. Wat iemand anders doet interesseert me dan heel matig.

Van Lambiek wordt goede geuze gemaakt.

Als dat ook tienduizenden dezelfde displays zijn...

Nee, tientallen verschillende merken...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
trix

Golden Member

ik ben nu aan het proberen om het display the initialiseren in de 4-bits mode, maar dat wil nog niet erg vlotten. ik blijf op de bovenste regel allemaal blokjes houden.
doe ik het op de juiste manier ? of zie k iets over het hoofd ?

c code:


#define F_CPU 1000000UL // 1 MHz int osc

#include <util/delay.h>
#include <avr/io.h>
#include <avr/interrupt.h>

int xpuls;

int main (void) // Beginpunt
{

DDRB = 0b11111111;
PORTB = 0b00000000;

while(1)  // oneindige lus
{
	_delay_ms(10);
		
	PORTB |= ( 0b0010 & 0xF0); 	//function set high nibble
	PORTB |= (1 << PINB2); // enable
	_delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable
			
	PORTB |= ( (0b1000<<4) & 0xF0); //function set low nibble
	PORTB |= (1 << PINB2); // enable
        _delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable
			
	PORTB |= ( 0b0000 & 0xF0);	//display on/off high nibble
	PORTB |= (1 << PINB2); // enable
	_delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable

	PORTB |= ( (0b1111<<4) & 0xF0); //display on/off low nibble
	PORTB |= (1 << PINB2); // enable
	_delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable
	
	PORTB |= ( 0b0000 & 0xF0); 	//clear display high nibble
	PORTB |= (1 << PINB2); // enable
	_delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable
		
	PORTB |= ( (0b0001<<4) & 0xF0); //clear display set low nibble
	PORTB |= (1 << PINB2); // enable
	_delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable
		
	PORTB |= ( 0b0000 & 0xF0); 	//entry node set high nibble
	PORTB |= (1 << PINB2); // enable
	_delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable
		
	PORTB |= ( (0b0110<<4) & 0xF0); //entry mode set low nibble
	PORTB |= (1 << PINB2); // enable
	_delay_ms(10);
	PORTB &= ~(1 << PINB2); // enable
			
	}
}



eigenwijs = ook wijs

Wat denkt je hiermee te bereiken? de meeste programmeertalen zijn al voorzien voor de aansturing van zo'n display en een printinstructie.
Ga je dat allemaal zelf ontwikkelen?

Als het de bedoeling is om te leren dan OK, anders is het tijdverlies en begrijp ik de bedoeling niet.

LDmicro user.
trix

Golden Member

nee, ik wil het niet zelf ontwikkelen of om van te leren. ik wil het gewoon werkend hebben.
ik gebruik atmel studio 7, zijn er voor het aansturen v/h display libary's beschikbaar ?

eigenwijs = ook wijs

Je moet een foto eerst even 'croppen' voordat je 'm plaatst. (zo'n postzegel op een enorm wit vlak is niet handig... ;) )
Initialisatie staat in elke 16x2 lcd datasheet:

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Ben niet vertrouwd met AVR maar als je eens Googlet krijg je zeker enkele voorbeelden oa. deze

LDmicro user.
trix

Golden Member

oh,..ja croppen. dat hebben ze me pas verteld.

die Initialisatie staat niet in die datasheet van mij, ik vond hem al erg summier.

eigenwijs = ook wijs
trix

Golden Member

verdorie MGP dat is een goede link, had ik zelf nog niet gevonden.

edit: libary een beetje aangepast, (welke pinnen op welke outputs) en tekst op het display.

eigenwijs = ook wijs

Ik heb ook regelmatig met die 4-bits mode zitten tobben. Het flow diagram is niet helemaal gelijk voor alle displays.
Het laaste project waar ik mee bezig was(ben) specificeerde bijvoorbeeld 15 ms als opstart tijd en die hierboven 30 ms.

Die "function set" moet soms meerdere keren schrijven om je display weer aan de gang te krijgen na een soft reboot bijvoorbeeld.

Bij poweron komt het display op in 8-bit mode en je moet deze dan omschakelen naar 4-bit. Als het programma restart zonder power cycle dan werkt het display niet meer als de init-code wat kort door de bocht is.

Dit zit er in mijn init (op een STM32):
(Oh ja ik gebruik de busy ook gewoon)

code:


/*
 * Initialize a Hitachi compatible LCD display
 *
 * Pass in init structure to the function with the
 *  correct I/O and row/column configuration. (@@TODO@@ Not yet implemented)
 *
 *  The clock cycle is typical 270 Khz, (190 .. 350 KHz worse case).
 *  This yields a clock period of 3.7 uS typical (or worse case 5.3 uS)
 */
int HD44780_Init(const struct HD_Config *config) {

    HAL_Delay(16); // Wait more than 15mS
    // We can't check the busy flag yet.

    /* Set GPIO to outputs */
    setGpioDataDirection(OUTPUT);

    /* Make sure we have no enable active */
    setE(false);
    /* Select the Instruction register */
    setRS(false);
    setRW(false);

    // The display is set to 8-bit mode after reset, so we need to send 2 cycles to switch back.

    // Function set
    //  DL=1 8 bit interface
    //    DB7 DB6 DB5 DB4
    //    0   0   1   DL
    writeNibble(0x03);
    HAL_Delay(6); // Wait more than 4.1ms
    writeNibble(0x03); // Repeat function set
    HAL_Delay(2); // Wait more than 100 uS

    // Repeat function set (8-bit interface)
    //  DL=1 8 bit interface
    //    DB7 DB6 DB5 DB4
    //    0   0    1  DL
    writeNibble(0x03);
    HAL_Delay(2); // Wait more than 100 uS

    // Function set (4-bit interface)
    //  DL=0 4 bit interface
    //    DB7 DB6 DB5 DB4
    //    0   0   1   DL
    writeNibble(0x02);
    HAL_Delay(2); // Wait more than 100uS? (not specified)

    // BF can be checked now.
    // When BF is not checked, the waiting time between instructions
    // must be longer than the execution time. (See Instruction set)

    // 8-bit writes shall be used from now on (in two nibbles).

    // Function set: Specify display lines
    // N=rows-1, F=0 (5x8 font)
    //    DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
    //    0   0   1   0   N   F   *   *  0x28
    writeIR(0x28);

    // D=1/0 Display on/off, C=1/0 Cursor on/off, B=1/0 Blink on/off
    //    DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
    //    0   0   0   0   1   D   C   B 0x08 Display off, Cursor off, Blink off
    writeIR(0x08); // Display off

    // Clear Display
    //    DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
    //    0   0   0   0   0   0   0   1 0x01 Display CLEAR
    writeIR(0x01);

    // Entry mode set
    // I/D=1   , S=0
    //    DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
    //    0   0   0   0   0   1  I/D  S 0x06 entry mode set I=1 auto increment, S=0 No shift.
    writeIR(0x06);
    // --- END INIT ---

    // D=1/0 Display on/off, C=1/0 Cursor on/off, B=1/0 Blink on/off
    //    DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
    //    0   0   0   0   1   D   C   B 0x08 Display OFF, Cursor OFF, Blink OFF
    writeIR(0x0E); // Display on/cursor on/blink off

    return 0;
}

WriteIR() en WriteDR() zijn dus functies die dus 2 nibbles schrijven. Eerst HIGH dan LOW deel (+Enable puls met de juiste timing).
WriteNibble() schrijft alleen de 4 LSB's (+E puls).

De code moet ik nog een keer fixen dat die ook de mee-gepassede struct met de IO pinnen gebruikt. Ben ook daar nog niet aan toegekomen net als de rest van het project wat al een jaar stil ligt.

Henri's Law 1: De wet van behoud van ellende. Law 2: Ellende komt nooit alleen.