een standaard voor het aansluiten van ALLE LCD`s

[decramy]

OK, nadat we in afhandeling lcd's 256*128 voor 7 $ vast liepen, op het aansluiten van het LCD, gaan we hier een standaard maken voor ALLE LCD`s

Als iemand van Power LCD even het scema willen geven, waarop te zien is welke LPT-pin welke functie heeft, dan kunnen we voortaan dat schema gebruiken voor ALLE lcd`s...

Graag zou ik dit topic dan even in de FAQ willen hebben.

Als er een standaard is, heeft iedereen hier profeit (?) van...

[Verwijderd]

http://ra2modding.virtualave.net/lpt.html

maarem, 1 standaard voor alle lcd's !?!? dat zal niet gaan vrees ik.
(of bedoel je alle soortgelijke lcd's? )

[Robino]

Jij bent wel erg: "jij geeft mij dat", "jij plaatst dit even in.."

[Verwijderd]

Verwijderd schreef op 07 augustus 2002 @ 19:08:
http://ra2modding.virtualave.net/lpt.html

maarem, 1 standaard voor alle lcd's !?!? dat zal niet gaan vrees ik.
(of bedoel je alle soortgelijke lcd's? )

iig, ik heb destijds dit --> http://ra2modding.virtualave.net/Seiko-G242C(Pollin).jpg schema gemaakt voor het pollin-lcd (sed1330). Maar ik zie dat jullie er in dat topic ook al aan uitgekomen waren om volgens het pollin-schema te solderen (wat dit dus ook is)

edit: (stom dit had een edit moeten zijn maar ik ahd het verkeerde knopje )

[Verwijderd]

Verwijderd schreef op 07 augustus 2002 @ 19:18:
[...]

iig, ik heb destijds dit --> http://ra2modding.virtualave.net/Seiko-G242C(Pollin).jpg schema gemaakt voor het pollin-lcd (sed1330). Maar ik zie dat jullie er in dat topic ook al aan uitgekomen waren om volgens het pollin-schema te solderen (wat dit dus ook is)

edit: (stom dit had een edit moeten zijn maar ik ahd het verkeerde knopje )

in jouw schema staat dat de databits alleen output zijn, maar die zijn toch I/O altijd??

of is dat schema "uitgekleed" tot gebruik voor een LCD??

[Verwijderd]

Tot de komst van de pollin LCD's, zijn grafische LCD's op GoT altijd zo aangesloten:

code:

LPT                        LCD
------------------------------------
D0-D7 (pin 2-9)            D0-D7
Strobe (pin 1)             CE
Line (pin 14)              RD
Init (pin 16)              WR
Select (pin 17)            C/D
GND (pin 18 - 25)          GND

Met deze verbindingen tussen LTP en display, zijn o.a. schema's en software gemaakt voor:

- Nan Ya modules (Conrad en GoT inkoopactie)
- Seiko G242C (GoT inkoopactie)
- Datavision 240x128 modules (soort van GoT inkoopactie)
- Powertip (GoT inkoopactie)

Hierbij zitten zowel modules met T6963C, SED1330 en SED1335 controller en ik zal ongetwijfeld nog wat displays vergeten zijn.

Ik ben dan ook van mening dat we het gewoon zo moeten houden en niet gaan werken met verschillende schema's. Dit is voor de bestaande software niet goed, voor de nog te ontwikkelen software niet en met name voor de duidelijkheid op GoT niet.

Kijkend naar hoeveel gekloot er nu soms al is bij een bepaalde inkoopactie, is het niet verstandig om er weer een grote teringzooi van te maken, want die kant gaat het wel op op deze manier.
Mijn excuses als ik nu mensen op de tenen trap, maar ik ben er vanaf het alleerste werkende grafische display op GoT bijgeweest en geloof mij sindsdien is een heleboel ontwikkeld en gemaakt door meerdere mensen. En elke keer weer is het raak dat er onduidelijkheid ontstaat over aansluiten. En dat is nu juist iets waar een eind aan moet komen, want de lol gaat er anders snel af. En daar is niemand bij gebaat.

Ik zou het trouwens wel fijn vinden om de mening van de andere LCD programmeurs te lezen. Of je het nu met me eens bent of niet, dat boeit niet, daarvoor is het een forum

edit:
Een lijst van schema's die volgens deze manier werken
- http://members.home.nl/cl.../T6963Caansluitschema.gif
- http://www.waxworks.nl/got/files/Schemas/T6963C-DV.gif
- http://www.waxworks.nl/got/files/Schemas/Seiko-G242C.gif
- http://www.waxworks.nl/got/files/LCD/HG25504.gif

Als ik mij niet vergis is PowerLCD op een Nan Ya (1e schema) en een Datavision module ontwikkeld (2e schema). Alleen de SED1330 aansturing gebruikt een afwijkend schema. Correct me if I'm wrong.

[jvhaarst]

En hoe doet LCDProc het ?

[TD-er]

Ik denk dat het eigenlijk al een beetje (te) laat is om nog één standaard aansluitschema te gebruiken.
Van de meeste software is de source open, danwel zijn de ontwikkelaars nog actief.
Ik heb in een ander LCD topic al eens geopperd om en soort van config file te gebruiken om aan te geven hoe je je LCD hebt aangesloten.
Het zou makkelijk zijn wanneer de meeste programmas een en dezelfde config file zouden kunnen lezen en dat er hier dus een soort van standaard daarvoor bedacht wordt.
Dan kan bij verschillende schema's een eigen pin-definitie gemaakt worden en hoef je alleen die definitie file maar in de dir van het programma te gooien. (een reg-entry vind ik een beetje ver gaan)
Hierin zouden dan ook zaken als de gebruikte printerpoort en dergelijke opgenomen kunnen worden.

Zotty heeft al (terecht) opgemerkt, dat de laatste tijd LCDs dusdanig populair aan het worden zijn, dat de makers van software overspoeld worden met vragen en reacties. Mischien zelfs tot vervelends toe.

Ik denk dus dat het aanpassen van schema's en gebouwde projecten en het compatibel houden voor verschillende schema's een stuk lastiger is, dan alle software uitbreiden met één routine waarin een file wordt ingelezen en aan de hand daarvan de juiste interne parameters goed gezet worden.
Dan hoef je ook niet meer in het programma allerlei lastige instellingen te doen (die per programma verschillend zijn) en voor nieuwe software hoeven zulke dingen dan ook niet meer uitgewerkt te worden.
Het zou echter vervelend zijn, wanneer er in een programma niet voldoende rekening is gehouden met uitbreidingen en zodoende de pinbezetting min of meer hardcoded in de source zit.
Hoe is de mening van de programmeurs hierover?

Een voorbeeld zou kunnen zijn:

code:

printerport = LPT1  # connected printerport
#used_chip =         # Which chip is used for USB-interfacing
portmode = ECP     # used protocol
multiple_displays = NO #using more than one LCD per printerport

A0 = pin1                # Used pin on printerport
CS = pin2
RD = pin3
WR = pin4
D0 = pin5
[..]

Hiervoor zou een standaard parser geschreven kunnen worden, zodat er maar 1 keer moeite gedaan hoeft te worden.
Voordeel is ook dat software uit NL door mensen over de hele wereld gebruikt kan worden, ook al gebruiken ze een ander schema (Arabische LCDs bijv. worden precies omgekeerd gesoldeerd is mij ter oren gekomen en de Italianen gebruiken een wat meer romeinse notatie)

[DaRuLe]

En nog een stapje moeilijker:

code:

displayheight = 256 
displaywidth = 128

Of misschien beter:

code:

displaysize = 1  # 1 = 256x128, 2 = 240x128, 3 = 256x64, 4 = 240x64

Dit is technisch natuurlijk wel haalbaar, ook voor PowerLCD.
Nadeel voor de makers is dat het programma veel uitgebreider gaat worden qua programmeerwerk.
Het mooie hieraan is wel weer dat het programma PowerLCD dan een van de meest gebruikte programma's zal worden.

[Verwijderd]

Leuk initatief, echter alle dev'ers op 1 lijn krijgen is imho een onmogelijke taak, het lijkt me duidelijk dat er een wens is iets flexibeler om te kunnen gaan met de wireing, hoe en of de dev'ers iets met die wens gaan doen lijkt me een zaak van de dev'ers.

[TD-er]

Verwijderd schreef op 08 augustus 2002 @ 08:45:
Leuk initatief, echter alle dev'ers op 1 lijn krijgen is imho een onmogelijke taak, het lijkt me duidelijk dat er een wens is iets flexibeler om te kunnen gaan met de wireing, hoe en of de dev'ers iets met die wens gaan doen lijkt me een zaak van de dev'ers.

Of je de devers nu op een lijn krijgt door rekening te houden met 1 schema, danwel dat je zo overhaalt om massaal de mogelijkheid in te bouwen om een config filetje te lezen, lijkt me even moeilijk.
D'r zal alleen wel even goed moeten worden nagedacht over de wenselijke gegevens in zo'n file.
Dingen als de grootte van het display zijn inderdaad ook nodig en eventueel hoeveel RAM aanwezig, al zal dat weer net ff iets te uitzonderlijk zijn.

code:

Backlight = YES    # Support for backlight-control by the controller
Fontsize = 5x7    # size of the used font
used_controller_chip = SED1330 # used LCD-controllerchip
[..]

Het zal niet voor elk programma nodig zijn om alle opties te gebruiken, maar wanneer er een config file gebruikt gaat worden, dan moeten er zoveel mogelijk opties bedacht worden.

[Verwijderd]

D'r zal alleen wel even goed moeten worden nagedacht over de wenselijke gegevens in zo'n file.

Dus jij gaat nadenken over wat ik in m'n config files mag/kan schrijven, ermmz intresant? Ik heb al 'n flinke driver library (hd44780/T6963c/sed133x/AC1375(serial vfD)/matrix orbital(serial)) en iedere driver heeft wel z'n eigen specifieke eigenschappen dus tot 1 generieke config zal je nooit komen,'t is zowiezo geen zaak van de gebruiker hoe een app z'n instellingen opslaaat imho, ik zeg nogmaals de wens is duidelijk laat de implementatie over aan de dev'ers..

[Verwijderd]

TD-er schreef op 08 augustus 2002 @ 10:00:
[...]
Of je de devers nu op een lijn krijgt door rekening te houden met 1 schema, danwel dat je zo overhaalt om massaal de mogelijkheid in te bouwen om een config filetje te lezen, lijkt me even moeilijk.
D'r zal alleen wel even goed moeten worden nagedacht over de wenselijke gegevens in zo'n file.
Dingen als de grootte van het display zijn inderdaad ook nodig en eventueel hoeveel RAM aanwezig, al zal dat weer net ff iets te uitzonderlijk zijn.

code:

Backlight = YES    # Support for backlight-control by the controller
Fontsize = 5x7    # size of the used font
used_controller_chip = SED1330 # used LCD-controllerchip
[..]

Het zal niet voor elk programma nodig zijn om alle opties te gebruiken, maar wanneer er een config file gebruikt gaat worden, dan moeten er zoveel mogelijk opties bedacht worden.

vergis ik me nou, of zijn deze opties eigenlijk altijd al aanwezig in het programma zelf??
dit soort opties horen mijns inziens ook in het programma zelf thuis. (dat wordt dan wel in een config file geschreven, maar die hoeft helemaal niet user editable te zijn)

welke opties is wel intressant, hoe dat in een config file terecht komt niet echt...

[DaRuLe]

Gewoon zo:

[Chimera]

DaRuLe schreef op 08 augustus 2002 @ 11:03:
Gewoon zo:

afbeelding

Woei!!! Delphi 6

btw. Zotty heeft een 320 * 240 LCD, die schrijft z'n eigen proggies, maar toch...

[ Voor 0% gewijzigd door Chimera op 08-08-2002 11:35 . Reden: By the way toegevoegd ]

[Verwijderd]

Chimera2k2 schreef op 08 augustus 2002 @ 11:33:
[...]

Woei!!! Delphi 6

moet dat???
borland c++ builder ziet er hetzelfde uit hoor...

[Chimera]

Verwijderd schreef op 08 augustus 2002 @ 11:35:
[...]
moet dat???
borland c++ builder ziet er hetzelfde uit hoor...

Ik had al ergens in een ander draadje gelezen dat ie met Delphi werkt, nu zie ik dus aan het icoontje dat het versie 6 is .

[Verwijderd]

Chimera2k2 schreef op 08 augustus 2002 @ 11:36:
[...]

Ik had al ergens in een ander draadje gelezen dat ie met Delphi werkt, nu zie ik dus aan het icoontje dat het versie 6 is .

ha, ok
snappik 't ook weer

[TD-er]

Verwijderd schreef op 08 augustus 2002 @ 10:38:
[...]Dus jij gaat nadenken over wat ik in m'n config files mag/kan schrijven, ermmz intresant? Ik heb al 'n flinke driver library (hd44780/T6963c/sed133x/AC1375(serial vfD)/matrix orbital(serial)) en iedere driver heeft wel z'n eigen specifieke eigenschappen dus tot 1 generieke config zal je nooit komen,'t is zowiezo geen zaak van de gebruiker hoe een app z'n instellingen opslaaat imho, ik zeg nogmaals de wens is duidelijk laat de implementatie over aan de dev'ers..

'kee ik was een beetje aan het doordraven geloof ik. Sorry.

[Creepy]

DaRuLe schreef op 08 augustus 2002 @ 11:03:
Gewoon zo:

afbeelding

En toen had iemand een extra LPT poort op D000 o.i.d. zitten.... en werkt je programma daar weer niet mee.. (ja, dat bestaat, ken iemand die dat heeft, LCDInf draait er op )

Er is GEEN standaard te verzinnen voor dit soort dingen. Voor een aansluit schema wel, maar alleen per TYPE display natuurlijk. Elk type display heeft weer net wat andere pinnen om aan te sluiten.

Trouwens, de topicstarter is op dreef ja..

Als iemand van Power LCD even het scema willen geven, waarop te zien is welke LPT-pin welke functie heeft, dan kunnen we voortaan dat schema gebruiken voor ALLE lcd`s...

Graag zou ik dit topic dan even in de FAQ willen hebben.

De schema's staan op de sites natuurlijk.. en zijn over het algemeen hetzelfde hoor, alleen de pin-indeling op de LCD's wil nog wel eens verschillend zijn. Uiteraard had je *ZELF* de verschillende schema's kunnen bekijken, en was je ook tot deze conclusie gekomen.

Wat betreft config files e.d. ben ik het met Yarvieh eens, dat bepaal ik zelf wel. Ik heb ook wat verschillende drivers voor verschillende soorten LCD (par. en serieel) en er komen er nog bij. Elk LCD heeft wel wat eigen instellingen.

Het is een leuke gedachte hoor, maar toon eerst ff ZELF initiatief. Ff roepen dat de "LCD programmeurs" het maar ff moeten doen.. tja... dat bepalen de LCD programmeurs zelf wel. Ik denk trouwens dat de lcd programmeurs dezelfde schema's gebruiken. Het HD44780 schema is overal hetzelfde (ook al drijven er 100 schema's rond hier op GoT, de pin-indeling blijft gelijk) en voor de GFX LCD's heeft Zotty mooie schema's in elkaar gezet, dus waarom zou je ze niet gebruiken?

[Creepy]

TD-er schreef op 07 augustus 2002 @ 21:44:
Ik denk dus dat het aanpassen van schema's en gebouwde projecten en het compatibel houden voor verschillende schema's een stuk lastiger is, dan alle software uitbreiden met één routine waarin een file wordt ingelezen en aan de hand daarvan de juiste interne parameters goed gezet worden.
Dan hoef je ook niet meer in het programma allerlei lastige instellingen te doen (die per programma verschillend zijn) en voor nieuwe software hoeven zulke dingen dan ook niet meer uitgewerkt te worden.
Het zou echter vervelend zijn, wanneer er in een programma niet voldoende rekening is gehouden met uitbreidingen en zodoende de pinbezetting min of meer hardcoded in de source zit.
Hoe is de mening van de programmeurs hierover?

De meeste schema's zitten hardcoded gok ik zo..
Bij mij wel in elk geval. Een nieuwe driver schrijven die gebruik maakt van een ander schema, of een compleet nieuw LCD, is bij mij in elk geval een eitje.
Instelbaar maken gaat wel hoor, maar zoveel verschillende schema's zijn er nou ook weer niet, dus denk dat het teveel moeite is voor het gemak dat het oplevert.

Overigens is in de meeste Windows progs de config van je LCD helemaal visueel in te stellen i.p.v. in een config filetje te rommelen, iets wat voor de meeste gebruiker handiger is, aangezien die willen klikken, en niet in config filetjes willen rommelen.

[equinoxe]

Creepy schreef op 08 augustus 2002 @ 12:11:
[...]
De meeste schema's zitten hardcoded gok ik zo..
Bij mij wel in elk geval. Een nieuwe driver schrijven die gebruik maakt van een ander schema, of een compleet nieuw LCD, is bij mij in elk geval een eitje.
Instelbaar maken gaat wel hoor, maar zoveel verschillende schema's zijn er nou ook weer niet, dus denk dat het teveel moeite is voor het gemak dat het oplevert.

Zou het dan iets zijn om van de aansturings-dll de source bij te leveren?
Kan een gebruiker eventueel zelf eea aanpassen.
Is misschien ook leuk voor als er weer eens een "exotische" LCD opduikt waar nog geen progjes voor bestaan.

[DaRuLe]

equinoxe schreef op 08 augustus 2002 @ 13:28:
[...]

Zou het dan iets zijn om van de aansturings-dll de source bij te leveren?
Kan een gebruiker eventueel zelf eea aanpassen.
Is misschien ook leuk voor als er weer eens een "exotische" LCD opduikt waar nog geen progjes voor bestaan.

En wáár is de source van:
"source-code for sed 1330
CLICK HERE" ?? op je site

link doet het niet nl.

[Verwijderd]

equinoxe schreef op 08 augustus 2002 @ 13:28:
Zou het dan iets zijn om van de aansturings-dll de source bij te leveren?
Kan een gebruiker eventueel zelf eea aanpassen.
Is misschien ook leuk voor als er weer eens een "exotische" LCD opduikt waar nog geen progjes voor bestaan.

Mijn lcd app (die nog steeds niet af is ) werkt op plugin basis, dus mocht er een nieuw exotish lcd display opduiken kan je 'n driver(plugin) maken en heb je gelijk support voor die lcd, het mee leveren van source zie ik geen reden toe werkt alleen maar cut'n'paste programmeurs in de hand..

[equinoxe]

Maar je hebt wel een uitleg van de plugin?
Want je moet weten hoe het programma de plugin en daarmee de LCD aanstuurd.

[Creepy]

Als ik het zo heb gebouwd dat de LCD aansturing op plugin basis gaat (heb daar al redelijk wat voorbereidingen voor getroffen, maar ik breng in elk geval nog 1 versie uit die nog werkt zoals de bestaande) is het een kwestie van het schrijven van een DLL en deze laten gebruiken door LCDInf.

Op het moment heb ik mijn drivers OO opgezet in Delphi. Ik zou de base-klasse (TLCD) kunnen geven zodat andere mensen drivers kunnen schrijven (een sub-klasse van TLCD) die ik dan weer in LCDInf gebruik. Maar om cut'n'pasten te voorkomen plaats ik in elk geval geen source van de implementatie van zo'n driver. Heb al veel te veel vragen gehad naar kant en klare source, van mensen die geen zin hebben om zelf moeite te doen, maar alleen maar ff willen patsen met dat ze een LCD progje hebben geschreven.
Er is info (en source!!!) genoeg te vinden op het net voor het aansturen van LCD's. Is meestal een karakter based LCD i.p.v. een grafisch, maar zoveel verschil zit er nou ook weer niet in de eigenlijke aansturing..

Ennuh Yarvieh, zet je prive leven eens aan de kant man, we wachten al maanden op dat proggie van jou

[DaRuLe]

Verwijderd schreef op 08 augustus 2002 @ 13:41:
[...]
Mijn lcd app (die nog steeds niet af is ) werkt op plugin basis, dus mocht er een nieuw exotish lcd display opduiken kan je 'n driver(plugin) maken en heb je gelijk support voor die lcd, het mee leveren van source zie ik geen reden toe werkt alleen maar cut'n'paste programmeurs in de hand..

En wellicht maakt die cut'n'past programmeur een betere variant van het programma wat jij schrijft.
Ik vind (open!)sources van anderen gebruiken geen enkel probleem, je gaat toch niet het wiel meerdere keren uitvinden? hooguit verbeteren.

Tenzij je een tegenstander bent van open source natuurlijk


Over dat patsen met sources van anderen:
Een nette programmeur laat de comments staan natuurlijk

[equinoxe]

Ai, mijn server is down.. links naar files doen het idd niet...
Ik log effe in kan even duren..
Links gefixed..

Prachtige site he, en de grafix.
Woehaahaha (sorry, het is functioneel, en aan de rest hecht ik weinig waarde..)

[Verwijderd]

Creepy schreef op 08 augustus 2002 @ 13:49:
Ennuh Yarvieh, zet je prive leven eens aan de kant man, we wachten al maanden op dat proggie van jou

Wehhee jah sorry? zorg dan dat m'n baas me 'n maand betaald verlof geeft dan krijg ik 't wel af

'k heb ff zitten prototypen:



Zoo kan je iedere wiring aan die je maar wil (er van uit gaande dat iedereen d0-d7 op de zelfde manier wired maar dat lijkt me het enige wat echt in elk schema het zelfde is)

[Creepy]

Hmmm.. en dan krijgen we weer tig topics van "Wie heeft er een werkende config voor programma X want ik snap geen ruk van de wiring/wirering/wireing" (pfff.. hoe schrijf je dat?)
Je KAN natuurlijk1 default instellen, maar dan blijf je de vraag houden als de het LCD net iets ander is bedraad (gewired... whatever ).

Ik hou het wel bij verschillende drivers, of een parameter bij een driver. (dropdownbox met schema1, schema2, schema3 etc.)

[Creepy]

DaRuLe schreef op 08 augustus 2002 @ 13:51:
[...]

En wellicht maakt die cut'n'past programmeur een betere variant van het programma wat jij schrijft.

Nee.. ik (en Yarvieh denk ik ook) bedoelen met een cut'n'paste programmeur dat ook letterlijk. Niet iemand die een source bekijkt/doorspit, kijkt en begrijpt hoe het werkt, en dan zelf gaat proggen.

Ik vind (open!)sources van anderen gebruiken geen enkel probleem, je gaat toch niet het wiel meerdere keren uitvinden? hooguit verbeteren.

Het wiel opnieuw uitvinden kan leuk zijn. Dit is de reden dat ik LCDInf heb geschreven, ik wilde een driver EN een prog schrijven voor mijn eigen LCD.

Tenzij je een tegenstander bent van open source natuurlijk

Hehehe.. ik niet.. download LCDInf Linux maar eens (jaja.. de GPL mist.. moet ik er eigenlijk nog ff bij plakken)

Over dat patsen met sources van anderen:
Een nette programmeur laat de comments staan natuurlijk

Nofi aan iedereen die mij een request voor sources heeft gestuurd, maar de meesten willen een source om zo snel mogelijk iets in elkaar te flansen. Het schrijven van een LCD driver is vrij simpel, mits je weet hoe je de LPT poort aan moet sturen. Dit probeer ik iedereen uit te leggen die mij om source vraagt. Als ze die moeite NIET willen doen.. helaas pindakaas, dan zoek je op internet maar naar een klant en klare driver, of je zoekt iemand anders die sources wil geven.

Er zijn zelf ook mensen geweest die ik heb gewezen op de Linux source. Zo moeilijk is die nu ook weer niet te lezen. Zelfs dan nog wordt er af en toe gevraagd om de WINDOWS source, omdat ze de Linux source niet (willen) snappen. De LCDInf Linux source is KLEIN, erg klein, en het driver deel zit NIET moeilijk in elkaar, is zelfs te copy en pasten en vrij makkelijk om te zetten naar VB/Delphi/Whatever... maar blijkbaar schrikt het af dat het voor Linux is, en in C geschreven.

Dus voor iedereen die aan mij wil vragen voor source: De Linux versie IS (en blijft!) opensource! De windowsversie is op het moment NIET opensource.. misschien dat ie dat ooit nog wordt.. maar voorlopig.. nee.

[Verwijderd]

Creepy schreef op 08 augustus 2002 @ 15:43:
Hmmm.. en dan krijgen we weer tig topics van "Wie heeft er een werkende config voor programma X want ik snap geen ruk van de wiring/wirering/wireing" (pfff.. hoe schrijf je dat?)
Je KAN natuurlijk1 default instellen, maar dan blijf je de vraag houden als de het LCD net iets ander is bedraad (gewired... whatever ).

Ik hou het wel bij verschillende drivers, of een parameter bij een driver. (dropdownbox met schema1, schema2, schema3 etc.)

Danne maak je 'n comboboxje met wat defaults en als laatse optie "Custom" flexibel of wat?!?

[Creepy]

Goed man
Maar dat betekent natuurlijk niet dat je vanwege het inbouwen van deze feature nog lang moet wachten met het uitbrengen vanje prog

En je zit er natuurlijk mee dat per type LCD de pinnen nog wel eens verschillend willen zijn (neem bijv. de E2 pin bij eemn 4x40 HD44780). Dan krijg je dus weer een custom settings per type LCD. En ik wilde nou net af tussen de afhankelijkheid van mijn GUI en het type LCD

edit:
en daar BEN ik vanaf

, tenzij ik in een LCD klasse de GUI van het instellen van het schema weer op 1 of andere manier in kan bouwen.... pfff..... nou snap ik waarom je zo lang bezig bent aan je prog, je wilt gewoon veel te veel kunnen

* Creepy houdt het nog bij ff het KISS principe voor de gebruiker. Zo weinig mogelijk instellen en gaan!

[Verwijderd]

He lui!
Aangezien jullie er allemaal zoveel verstand van hebben....
Ik heb een 4x40 LCD (HD44780) als ik 'm aan m'n printerpoort hang dan blijft m'n PC een tijdje hangen vlak na de P.O.S.T.
Is dit normaal of heb ik misschien iets niet helemaal goed aangesloten?
Ennnn als ik de LCD aan m'n printerpoort hang met een printerkabel, HOE kan ik dan het beste de voeding regelen? Elke keer m'n kast losmaken om een molex aan te sluiten is ook niet echt handig...?!

Graag reactie.

Groet

Henk.

[Verwijderd]

ehm.... Ik zal eventjes uitleggen:

ik heb dat schema van zotty aangepast toen ik bezig was mijn lcd van pollin werkend te krijgen. Eerst geprobeerd met dat schema van Zotty, maar dat was (in mijn ogen) onlogisch (nofi ofcourse). Toen dat aangepast naar het pollin-schema en dus al 1 werkend prog.
Toen ben ik gaan proggen voor het scherm en ben toen ook in contact geraakt met Mr.ChronoM. Elkaar wat geholpen en toen zonder (veel) moeite en aanpassen PowerLcd werkend gekregen. Maar het maakt toch niet zoveel uit als het sed1330-schema anders is als een t6963c-schema want hij moet toch anders aangestuurd worden ?.
that's my 2 cents....
(oftewel: hou idd 1 bepaald schema vast voor zo veel mogelijk van dezelfde typen lcd's )

[Verwijderd]

Sed133x met flexwire(tm) driver test

Wie oh wie wil 'm even testen..doet niet zo bar veel maar genoeg voor 'n driver test..

Test 1 laat iets zien van >>>line1<<<< ect
Test 2 Laat vbars zien.
test 3 Moet winamp.bmp laden en op je schermpje laten zien.

als 't onder 9x niet werk wel ermmz.. pech

[DaRuLe]

The specified module could not be found

vreemd

[Verwijderd]

Wel met de test.bat batch file gestart? toch geen win9x he? dlportio geinstaleerd? 'k hoor van andere mensen dat 't wel werkt, maar ben wel erg benieuwed waarom bij jou niet.

[DaRuLe]

DLPortIO staat erop, test.bat en dan:




Windows2000 SP3

[Verwijderd]

Ahh zie 't al ding is tegen de debug C runtime aan gelinkt, je moet ff msvcrtd.dll zoeken, zit zelf op de zaak dus kan die zipfile nie updaten sorry.

[DaRuLe]

Oke, hij doet het

En nu ga ik ook naar mijn werk.

[jvhaarst]

Hij is bijvoorbeeld hier (onderaan) en hier te vinden.

[ Voor 0% gewijzigd door jvhaarst op 09-08-2002 08:32 . Reden: typo ]

[Dutch_Demon]

maar nu we het over een standaard hebben: Zou deze er al niet zijn als het uberhaupt mogelijk is ????????

[3lmowww]

niet 1 standaard, je zou wel een programma kunnen schrijven, waarin protocollen voor verschillende controllers zitten, maar dan niet 2, maar 20 bv.

Enneh, heeft iemand nog een progje voor de hd61202 liggen

[DaRuLe]

Zeg Yarvieh, als ik zelf een bitmap maak en ik hernoem die naar Winamp.bmp dan laat ie het plaatje wel prima zien, alleen hij is negatief

[Verwijderd]

Enneh, heeft iemand nog een progje voor de hd61202 liggen

Sorry te weinig vraag naar.

Zeg Yarvieh, als ik zelf een bitmap maak en ik hernoem die naar Winamp.bmp dan laat ie het plaatje wel prima zien, alleen hij is negatief Kan je me dat bmptje emailen?

Hey niemand zei dat het perfect was kan je het plaatje naar me mailen dan kijk ik er ff naar

[DaRuLe]

You've got mail

Ik ging er ook niet vanuit dat het perfect was, het is alleen zo apart.
En niet dat ik t erg vind, ik maak het plaatje zelf dan negatief en dan is het ook weer goed.

[Verwijderd]

zal die driver vandaag proberen te fixen en als 't lukt je vanaaf 'n leuk speeltje mailen

[DaRuLe]

* DaRuLe is gek op speeltjes

Vooral als het iets met LCD's te maken heeft natuurlijk.