UIRT with LCD?

[Jas39]

Hi all
Is there any room left in the PIC when running UIRT? I'm wondering if it's possible to add some code for running a LCD with a slight modification of Myke's 2 wire LCD interface. The original is found at:

http://www.rentron.com/Myke1.htm


and the modified, not tested :wink: ,one would be more like the picture in the end of this mail

the needed PIC code would be something like this:

http://w1.864.telia.com/~u86435834/2wire4015_lcd.asm

which, by the way, has not been close to a compiler. Some additions to the current protocol would also be needed unless port banging over rs232 is the only way.

BTW, Is the john_rhees commented asm code available anywhere?

Thanks for any input
/Anders


http://w1.864.telia.com/~u86435834/2wire4015_lcd_R2.jpg

[Jas39]

Hi all
I've updated my test application with this schematic and support for writing to the lcd using the bitbanging method. It does take some time since every clock and data transition must be commanded over rs232 but it does work.

Take a look at:http://w1.864.telia.com/~u86435834/UIRT_test.zip

Regards
/Anders

[Jas39]

Hi
I've been trying to contact Jon Rhees to see if I could help get the
code needed to drive a LCD this way included into his current implementation but have not received an answer. Is Jon's email as given here the correct one?

jrhees@cardaccess-inc.com


Regards
/Anders

[Eelector]

Wow! Using UIRT to control a VFD/LCD would be GREAT!

Will there be any functionality limitations (reduced char-set ?) when using the Hitachi LCD chip in 4bit mode?

Could you please post a UIRT2-PCB with the LCD modifications as soon as possible. I plan to build a UIRT2 soon, and I really dont want to miss this feature. :)

[jon_rhees]

Jas,

Sorry for not responding, but I've been quite busy lately.

I was wondering about a few things:

1. Certainly it is possible to have the PIC directly drive the shift registers to produce the 4-bit display drive, but aren't there already available serially-driven LCD displays? Or, are these displays more expensive, etc.

2. Have you considered going to a higher pin-count PIC device? This would remove the need for the shift registers altogether...

-Jon

[Robin]

Jon,

I noticed from reading the protocol spec that you've left room for larger PICs ... the IO side seems to be capable of addressing 4 8-bit ports (A-D), which are only available on the 40 pin PICs (16F877 for example).

So why have I never seen an asm file for anything other than the 18 pin 16F84's ? (Does one exist ?) Couldn't the UIRT driver (or an adaptation of it) be used to pulse data through these additional ports to drive an LCD / VFD ?

[unimatrix]

hi

the pic 16f877 has not just more ports, it has a lot of other features, that could be usefull for the UIRT Project.

It has a builtin UART to handel the serial communications, a capture module (perhaps it could be used to improve IR-Features), the UART is I2C capable, so a external BIG EEPROM could be used for storing IR Codes and programs to be executet while the PC is off.

[Robin]

I understand, however, this wasn't a debate on the microcontroller used, more that Jon has already developed his protocol with larger PICs in mind ... look at the spec, it specifically requests that you ask the PIC for it's capabilities without assuming anything.

This would suggest that other variants exist, as all of the current UIRTs are based on 16F84's and have only two ports (A - 5 pin, B - 8 pin) there wouldn't be any need for querying PIC capability.

Jon - Do you have an ASM for a 40 pin PIC ?

Unimatrix - What were you intending to do with an A-D converter / PWM comparator that would be so useful in a UIRT ?!

[unimatrix]

Hi Robin.

I didn't say, that the ADC or the PWM would be usefull unlike someone would like to control a motor wiht the UIRT ;-)

I just mentioned the I2C functionality and the capture module.

The I2C could be usefull to handle external Eproms for storing additional PIC programs for offline operation and IR macros(without the PC).

I am not sure if the capture module would be interesting, I just know that it can be used for measuring times of pulses and pauses and afaik is this exactly that, what has to be done for IR reception. I thought the PIC could let the capture module do the measuring and could meanwhile do some other usefull things.

But this is not more than a proposition because I am not familiar with the assembler code for IR reception in the 16F84.

Back to the LCD:

What Information should be displayed on it? Do you think of title / time information while playing any kind of media like DivX or MP3?


Greetings,
Unimatrix

[jon_rhees]

Robin,

No, I haven't coded for any other PIC's -- mainly because I haven't built HW around any of them. The choice of the 16F84 was *only* because people already had circuits built up with these parts. It turns out Microchip has several more capable parts -- some of which cost LESS.

Frankly I shy away somewhat from launching down the path of another PIC because for most people this means a major investment in time, etc. to get/build new hardware. For a few of us, its no big deal since we just pull out the soldering iron and protoboard.

with *Any* protocol I design I like to make it upward compatible. This makes things easier in the long run.

Jon

P.S. My time is very limited, so if you have a major interest in supporting a particular PIC, etc., send me the HW :)

[Robin]

Jon,

Thanks for the reply ... my question wasn't actually for my own benefit, I just saw people trying to integrate LCD & UIRT and thought of all the extra I/O available through a larger PIC, plus the allowances you made for increased functionality in the protocol.

It struck me that a change to the UIRT DLL could implement LCD functionality through these additional I/O pins, something I experimented with before ... but it's really not important, just an alternate train of thought to everyone elses :wink:

It's refreshing to see someone planning for a future though !

[Marsupial]

Ok, I guess we turned around this subject long ennough...

there is still a question unanswered...

can the actual UIRT2 pic do the job for extra processing of the LCD screen? As I understood, the protocol would allow it.

I guess what most users are looking for is a way to ALTER their actual UIRT/UIRT2 for LCD support, with no major changes.

with "no major changes" I implies either taking the same HW or the same board with alterations (new pic: same board, some wires) because I guess most of the UIRT users don't exactly want to build a totally new UIRT leading the previous one to the trashcan.

So, Can the actual PIC do the job for LCD displayal?
What modofications would be needed?
can the plug-in be modified to suit the needs of the LCD displayal?

I guess that's the major issues in here.

hope to make to reflection go a little further.

[Robin]

Marsupial,

From previous experience I found I could control an LCD either by using a parallel port (therefore a separate entity to the UIRT) or via a shift register (acting as a serial in, parallel out device) for two wire connection (data & clock). Note that you can't turn backlights on and off like this, that would require extra wires (which may be available).

The current UIRT2 does have at least two spare pins, and could therefore do the LCD handling without too much trouble. However, you REALLY wouldn't want to have to write Girder scripts to torture the UIRT driver into doing this.

There aren't too many extra functions required, so it may be possible to create a UIRTLCD library that makes use of the existing UIRT driver ... I'll look into the feasibility, although I don't actually have a use for an LCD anyway !

This shouldn't require any reprogramming of the UIRT's PIC, just an add-on pack for the UIRT driver (depending on the current driver's speed). Additional hardware would comprise of a shift register, an LCD and a few wires. (all of which are cheap, unless you go for a really flash LCD !)

[chavex]

Please see my postings at :

http://www.girder.nl/phpBB2/viewtopic.php?t=2139

In particular Jas39 and Jon Rhees.

(I'm developping a prototype PCB for UIRT2 with a generic connector [RA2/RA3/RA4/VCC/GND] to plugin an optional shift register LCD module or whaterver future demands)

To Jas39: I think it is usefull to have a stand alone application to program the offline commands of UIRT2 for the applications i'm thinking in develop.

To Jon Rhees: PIC16F628 is cheaper, pin compatible with 16f84 and has more memory and periphericals. Could be a nice improvement without require new pcb's.
Also i will develop a module to dimm mains lights but it will require aditional functions on firmware. If you have time and disponibility we can talk details and i can arrange prototype HW to help you with the development.


Best regards,
N. Chaveiro

[Marsupial]

Are you thinking of an alternate PIC to let more room for the programs without changing your PCB?

I've saw you PCB on onother thread: it is very similar to another version of UIRT I saw, could you explain the main differences?

If I understood great: you have already planned an LCD pinout... am I right?

[chavex]

Are you thinking of an alternate PIC to let more room for the programs without changing your PCB?

I've saw you PCB on onother thread: it is very similar to another version of UIRT I saw, could you explain the main differences?

If I understood great: you have already planned an LCD pinout... am I right?


Yes to all questions!
My pcb just has in mind my own expansions ideas and as a connector to allow that. I will post specs and details as soon as i have some time to dedicate to it.

Best regards,
Chaveiro[/quote]