Maker Pro
Maker Pro

Has anyone here ever used a serial screen?

I used to often use VT100 & VT220s. Are these serial screens?
I've used SPI-connected LCD displays, on Raspberry pis & such. Is that the sort of thing you mean?
 
I used to often use VT100 & VT220s. Are these serial screens?
I've used SPI-connected LCD displays, on Raspberry pis & such. Is that the sort of thing you mean?
I would like to use a smaller screen, similar to the size of a mobile phone screen, to create a console to control my mcu
 
OK, sorry.
Screen to what?
A shell, so text only, but to an operatiing system?
A serial channel, as in communications port, for debugging, programmed entry & display?
A full graphics capable, but programmed
.
My LCDs that I put on SPI are great, they are text & graphics capable & support libraries from most languages. There are a couple of common chipsets. Mine used ILI9431. Easy to talk to from python. Touch versions available too.
Several sizes. To fit my box & chose 2.2" (inch).
.
8-pin? As in a 9-pin DIN? RS232C?
 

Harald Kapp

Moderator
Moderator
think it could be called a uart screen.
UART protocol is way too slow for transmitting display data. Usually terminals like the ones mentioned here (VT100...) are used via UART.
@Johnson2 : as you can see we're pretty confused about your idea. Please state more precisely what you want to do:
  • what is the source of your display data?
  • what is the format of your display data?
  • what is the expected size of your display (mechanical as well in # of pixels)
  • what is the update rate of your display (e.g. life video vs. static text)?
  • color or b/w?
  • what length is the serial connection to be expected
  • ....

Do you realize that VGA, HDMI, display port, even classic over-the-air TV etc. all use a kind of serial protocol?
 
The only need for a parallel protocol would be a high speed camera, monitors would never need it because we only see at about ~60hz. :)
 
Has anyone here ever used a serial screen?
Yes.
What would you like to ask?
.
BTW:
The only need for a parallel protocol would be a high speed camera, monitors would never need it because we only see at about ~60hz.
Each of us has knowledge according to our experience & learning so some have seen limitations that don't affect all applications. Traditional UARTs tend to be slow for good reasons. Displays now need more data & hence higher data rates for good reasons.

As Harald says
Do you realize that VGA, HDMI, display port, even classic over-the-air TV etc. all use a kind of serial protocol?
.
Give us an idea of what sort of "serial terminal" you are interested in and likely someone here has knowledge about them and can help.
 

bertus

Moderator
The only need for a parallel protocol would be a high speed camera, monitors would never need it because we only see at about ~60hz. :)
Hello Ratstar,

The 60 Hz you mention is the vertical frequency of a CRT television.
The horizontal frequency is already much higher like 15600 Hz.
The "pixel" frequency in a monitor can be in the MegaHertz range.

All of this has nothing to do with the question of the TS.

In the old days there where serial terminals:
https://en.wikipedia.org/wiki/Computer_terminal

Bertus
 
It does. if youve got a 1000x1000 screen it only takes 60 megahertz to hit every pixel 60 times a second, so its easily done with one wire. If you had a 10,000x10,000 screen, then it would be 6,000 megahertz, out of the range of cheap transistors, but I guess professional ones could do it.

If u wanted every led a separate wire, then you could get 1 million FPS, with a megahert, maybe that would be good for some parallel optical delay line memory? But other than that, pretty superfluous just for an ordinary monitor.
 
It does. if youve got a 1000x1000 screen it only takes 60 megahertz to hit every pixel 60 times a second, so its easily done with one wire. If you had a 10,000x10,000 screen, then it would be 6,000 megahertz, out of the range of cheap transistors, but I guess professional ones could do it.

If u wanted every led a separate wire, then you could get 1 million FPS, with a megahert, maybe that would be good for some parallel optical delay line memory? But other than that, pretty superfluous just for an ordinary monitor.
Actually I only need this LCD to support the touch, I just want to design a simple button so I don't have too many requirements for graphics, colours, animations.
 
Actually I only need this LCD to support the touch, I just want to design a simple button so I don't have too many requirements for graphics, colours, animations.
Is it a touch screen?

I wonder if you just put a random oscillation into it, noise would appear on the screen.
 
Actually I only need this LCD to support the touch, I just want to design a simple button so I don't have too many requirements for graphics, colours, animations.

You might want to look at an Arduino approach.
Clone Arduino boards work fine and help keep the cost down.
There would be plenty of circuits and advice out there for a basic touch screen running on I2c with library support also to get you started.
Just what you intend to display is unknown but you will get some ideas and experience in the Arduino forums.
 
You might want to look at an Arduino approach.
Clone Arduino boards work fine and help keep the cost down.
There would be plenty of circuits and advice out there for a basic touch screen running on I2c with library support also to get you started.
Just what you intend to display is unknown but you will get some ideas and experience in the Arduino forums.
I've been reading some tutorials online over the last few days and I'm going to use arduino and stone lcd for my project.
 
Best to get yourself some gear and get your feet wet, so-to-speak.
Better to get hands on and try to avoid copy and paste of the code.
Read it up by all means but you will learn a lot more if you try to write the code yourself.
If you get stumped you can always go back and read it up once again.
Touch screens might be a bit ambitious to begin with.
Try getting familiar with the way the programming works with other hardware as well.
Switches, LED's, servos ...
 
Best to get yourself some gear and get your feet wet, so-to-speak.
Better to get hands on and try to avoid copy and paste of the code.
Read it up by all means but you will learn a lot more if you try to write the code yourself.
If you get stumped you can always go back and read it up once again.
Touch screens might be a bit ambitious to begin with.
Try getting familiar with the way the programming works with other hardware as well.
Switches, LED's, servos ...
Thank you very much for the pointers
 
Top