22 thoughts on “Eevblog #8 part 1 of 2 – graphical lcd displays pic micro demo boards”
dave my dear name buddy i am oing to test you(r voltages!) i got a real teardown and repair for you all i say it's a 4K$ proffesional piece of yamaha elec porn but i onley send i if you mail me it got a long story with it. bunny.
Hi Dave, for such low resolution monochrome displays (e.g. 128×64) SPI is fast enough. When it comes to a "higher-res"-display (e.g. TFTs) you should use a parallel interface like I8080, M6800 or even DPI.
SPI makes good sense for another reason; modern micros allow you to use a DMA channel to feed the SPI peripheral, very much offloading the micro, I don't know about the PIC you are using though.
That is not necessarily true. At extremely fast clock speeds, simply clocking a parallel can be a tremendous challenge. Look at FPGA's which now have gigabit transceivers. You cannot implement a parallel interface running at gigabit speeds because keeping track of all of those parallel edges becomes a nightmare. Truly high speed requires serial data link that has an embedded clock. These can be ganged in parallel, but each transceiver still operates serially.
No, maybe if you pick and choose examples this may have happened, but a serial connection would need to be clocked considerably faster just to equate to that of a parallel connection, and a higher clocked parallel connection will net a higher reward per clock than serial. It's easy to see how parallel is a much better starting point if speed is a concern.
There's nothing to stop you clocking a parallel interface just as fast as a serial link. It can be effectively the same thing – just multiple serial links.
@EEVblog hey thanks for the answer, somehow I thought that SPI mode would have shorter timing requirements, which would make up for the the parallel transmit of the data with longer cycle times, but I just had a look at a datasheet on the newheaven website and its the other way round, i.e. it takes longer to transmit one serial bit than 8 parallel bits…
Really like your style and I'm really enjoying your interesting and informative videos, keep up the good work!
@DarkerMark For a given clock rate, parallel will always be faster because you transfer all the bits at once (or much fewer processor instructions) than serial that must shift the same data one by one.
I just watched the video, and the one thing I didn't get was that you mentioned that the parallel mode gave you more transfer speed as opposed to SPI mode. Could you care to explain why? I somehow thought that serial was the way to go for higher data rates, is it the displays fault oder has it to do with how fast SPI vs parallel works on a (that) µC?
Damm dev boards…
Youre lucky this board has .1 headers that's something, the explorer 16 has this horrible connector that is just CRAP you can't plug anything in it and youre pretty much stuck buying their adapter boards….
Every development board should implement jumpers or dip switched to disable onboard features so that you have full control over MCU pins I/O.
Also please dont wiring the linear regulator output directly to the MCU I want to try other power options !!!
what is that pcb that you lcd is connected too ?
it looks like it got pads ready to solder for many different packages already ? how does that work ?
and is that layout somekind of standard or open source so I can etch my own ?
Their benefits are in speed of prototyping, as they typically have everything you need to in hardware to get up and running right out of the box. e.g. header connectors, screw terminals, LEDs, switches, power supply, programming interface etc. So no need to breadboard all this. It takes time and patience to wire all this stuff up on a breadboard without any mistakes.
And you can't easy breadboard anything but a DIP chip. Try to breadboard a PIC32 or an ARM chip in a QFP or BGA package!
I've always just breadboard my MCU when I start a new project. Those developement boards are very expensive. At what point do their benifits outweigh their cost? It doesn't take me long to connect a programmer-to-breadboard adapter and power supply, everything else just seems so non-essential on those developement boards.
dave my dear name buddy i am oing to test you(r voltages!) i got a real teardown and repair for you all i say it's a 4K$ proffesional piece of yamaha elec porn but i onley send i if you mail me it got a long story with it.
bunny.
Hi Dave, For EEVblog #8 Part 1 of 2 – Graphical LCD Displays & PIC Micro Demo Boards…. where is part 2 of 2?
Hi Dave, for such low resolution monochrome displays (e.g. 128×64) SPI is fast enough.
When it comes to a "higher-res"-display (e.g. TFTs) you should use a parallel interface like I8080, M6800 or even DPI.
No "Haai?" at the beginning?
🙁
SPI makes good sense for another reason; modern micros allow you to use a DMA channel to feed the SPI peripheral, very much offloading the micro, I don't know about the PIC you are using though.
Part 1 of 2 ?
If there is no part 2, why name this video part "1 of 2" ?
That is not necessarily true. At extremely fast clock speeds, simply clocking a parallel can be a tremendous challenge. Look at FPGA's which now have gigabit transceivers. You cannot implement a parallel interface running at gigabit speeds because keeping track of all of those parallel edges becomes a nightmare. Truly high speed requires serial data link that has an embedded clock. These can be ganged in parallel, but each transceiver still operates serially.
No, maybe if you pick and choose examples this may have happened, but a serial connection would need to be clocked considerably faster just to equate to that of a parallel connection, and a higher clocked parallel connection will net a higher reward per clock than serial. It's easy to see how parallel is a much better starting point if speed is a concern.
There's nothing to stop you clocking a parallel interface just as fast as a serial link. It can be effectively the same thing – just multiple serial links.
Serial links can be clocked considerably faster than parallel links in order to achieve a higher data rate.
You and I know Murphy well.
Dave, RTFM !!
@EEVblog hey thanks for the answer, somehow I thought that SPI mode would have shorter timing requirements, which would make up for the the parallel transmit of the data with longer cycle times, but I just had a look at a datasheet on the newheaven website and its the other way round, i.e. it takes longer to transmit one serial bit than 8 parallel bits…
Really like your style and I'm really enjoying your interesting and informative videos, keep up the good work!
@DarkerMark For a given clock rate, parallel will always be faster because you transfer all the bits at once (or much fewer processor instructions) than serial that must shift the same data one by one.
I just watched the video, and the one thing I didn't get was that you mentioned that the parallel mode gave you more transfer speed as opposed to SPI mode. Could you care to explain why? I somehow thought that serial was the way to go for higher data rates, is it the displays fault oder has it to do with how fast SPI vs parallel works on a (that) µC?
Damm dev boards…
Youre lucky this board has .1 headers that's something, the explorer 16 has this horrible connector that is just CRAP you can't plug anything in it and youre pretty much stuck buying their adapter boards….
Every development board should implement jumpers or dip switched to disable onboard features so that you have full control over MCU pins I/O.
Also please dont wiring the linear regulator output directly to the MCU I want to try other power options !!!
@illusionLord pcbcart DOT com
what is that pcb that you lcd is connected too ?
it looks like it got pads ready to solder for many different packages already ? how does that work ?
and is that layout somekind of standard or open source so I can etch my own ?
You can always build QFT or SOIC to dip package with a simple board with some .1inch male headers. But hey what do I know. I'm only 14
Their benefits are in speed of prototyping, as they typically have everything you need to in hardware to get up and running right out of the box. e.g. header connectors, screw terminals, LEDs, switches, power supply, programming interface etc. So no need to breadboard all this. It takes time and patience to wire all this stuff up on a breadboard without any mistakes.
And you can't easy breadboard anything but a DIP chip. Try to breadboard a PIC32 or an ARM chip in a QFP or BGA package!
I've always just breadboard my MCU when I start a new project. Those developement boards are very expensive. At what point do their benifits outweigh their cost? It doesn't take me long to connect a programmer-to-breadboard adapter and power supply, everything else just seems so non-essential on those developement boards.
Nice job! keep it up!