serial to parallel continued...

[mstechca]

Heres my plan.

I want my circuit to work the fastest possible without use of an external clock. It needs to read data from a serial port, and as soon as 2 stop bits are read, it sends the byte (8-bit data) to a buffer.

If only I could get my hands on something similar to a 74HCT273 or a 74HCT374 without having to use a clock as an input, I think I'll be on my way.

right now, I think I'll have to go from scratch. (make a set of flip-flops from nand gates).

 

[Roff]

How in the heck are you going to go from serial to parallel without using a clock? How are you going to tell where the bit boundaries are? Is clock embedded in the data?

 

[Dialtone]

Why are you determined to use a serial port to do a parallel conversion? Why not just use the parallel printer port? You can pass data thru it at rates the serial port cannot even come close to, and no conversion of logic levels is needed. You can even use the ports control lines to simulate the clocking you need to latch the data into the register(s). Just a little simple program and you are done.
Just in case you do not think it may be fast enough, I am running data thru my port at rates approaching 4 mega-bits/second in EPP mode, and it is NOT going to a printer. Fast enough for your needs?
Dialtone

 

[mstechca]

why serial?

#1, I only have 9 pins to deal with
#2, I think managing data with it is somewhat easier
#3, now a-days they have USB, and serial port is closer to a USB port than a parallel port in terms of operation.
#4, I use Qbasic to send data to the ports, and during debug time, the parallel ports take longer than serial ports if I mismanage the busy signal.
#5, I'm struggling either way.

I tried the parallel port, but I somewhat have more success with it, but not enough.

Using serial or parallel port (I dont care at this point), I want to be able to send data to an LCD, and make the computer wait until the LCD is finished processing the last instruction.

With my LCD, I think pin 5 is the R/W pin. If it is enabled, data is extracted from the LCD. Otherwise, data is sent to the LCD. There is also a clock pin.

According to my LCD manual, when R/W is set to READ mode, data bit 7 must be clear for the LCD to not be busy. At this point, the computer needs to know it can continue.


In other words, I want to send data to the LCD without entering delays in my program on the computer. Yes, I'm going for speed too, because the faster data can go to the LCD, the better.

 

[ljcox]

If you are using the LCD display (16 characters x 2 lines dot matrix LCD module) that I used with a PIC, the rise and fall times of the signal driving the enable input (E) need to be lengthened.

I used a series 560R resistor and a 100 pF capacitor from E to gnd.

Len

 

[Dialtone]

Is the LCD you are trying to use a dot matrix that uses the Hitachi standard interface? If so, it is a snap to interface it directly to the parallel port, and you can do both reads and writes in either byte or nybble modes (8 or 4 bit).

I have one interfaced to mine and programming is not difficult at all, and timing is not really an issue either. Any programming delay that allows the data to scroll out in a smooth manner for easy reading will have more than enough delay to allow the LCD to process the order without bothering to check the busy/idle status.

I too wrote my first control program for it in QBasic, and printer port control requires nothing more than INP and OUT commands for read and write orders.

Now if your LCD is another type (such as a grapchics module) then it may be more of an issue,

Dialtone

 

[Nigel Goodwin]

In other words, I want to send data to the LCD without entering delays in my program on the computer. Yes, I'm going for speed too, because the faster data can go to the LCD, the better.

You seem to be going about it VERY strangely?, it's very simple to do this with a PIC - and one of my PIC tutorials does exactly what you want, taking RS232 from a PC and displaying the data on an LCD module.

Using large numbers of TTL chips isn't at all practical!.

You can also buy LCD's with PIC modules attached, so they can connect directly to a serial port - Scott Edwards has been selling them for years (although he's not the only one), try https://www.seetron.com/slcds.htm.

You don't require much speed anyway, because an LCD is a slow device, 9600 baud is more than fast enough, and 2400 baud is probably fast enough, and commonly used.

 

[mstechca]

I dont want to use a PIC. Dont PIC's have to be programmed first?

I just need something simple.

 

[mstechca]

Is the LCD you are trying to use a dot matrix that uses the Hitachi standard interface?

Yes it is.

I have one interfaced to mine and programming is not difficult at all, and timing is not really an issue either. Any programming delay that allows the data to scroll out in a smooth manner for easy reading will have more than enough delay to allow the LCD to process the order without bothering to check the busy/idle status.

I too wrote my first control program for it in QBasic, and printer port control requires nothing more than INP and OUT commands for read and write orders.

I dont want to do a programming delay in my qbasic program. I want it done in the hardware itself.

 

[Nigel Goodwin]

I dont want to use a PIC. Dont PIC's have to be programmed first?

I just need something simple.

A PIC is as simple as it gets!, your other choice is a UART chip like the 6402, which also requires some support components. Trying to build a UART from TTL chips is going to be anything but simple!.

The Scott Edwards modules I gave the link for are ready programmed, and would link directly to your serial port!.

Or I'm sure there are plenty of people here with PIC programmers who would happily program a PIC for you?.

 

[Dialtone]

[/quote]I dont want to do a programming delay in my qbasic program. I want it done in the hardware itself.[/quote]

I fully understand that you want to read the matrix controller status to tell if the last instruction completed, but to do so requires you to write a LOT of code to constantly read and re-read the status register and then confirm its status. This is in effect a delay itself.
You can avoid all this additional programming hassle simply by allowing the desired amount of processing time to elapse before you send the next character to the controller.
If you do not want to delay your program from doing other things during this delay time, simply design your code around a base level loop that only enters the write to controller subroutine at specific time intervals, sends one character, and exits back to the main loop, that way, your program is free to do other things as needed.
No matter whether you code to verify the status or simply insert the delay up front, you are going to have a delay in your program. There is no way around it.
You are making this much more complicated than it has to be.
Dialtone

 

[bbiandov]

mstechca,

IT IS totally possible to built hardware-only device. In fact I always favor the no-software design but the truth is, where would you draw the line. You can go PAL/PDL and achieve the objective but that is software too, I mean more low-level stuff but you still code, compile and then "make" the custom chip.

If by no-software you mean no-PIC and no-PAL then I have to ask-- do you really want a huge breadboard of 74xxx series ICs. I have never tried it but I suspect it will be complicated but most of all- yes clock, I dont see any other way. I wish I had a schematic for you but take a look here: **broken link removed**

Pretty close to what you want to do I supose, lots of counters and NANDs but it works.

~B