Protocol converter for graphical LCD

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 5.
To post in this forum you must have a registered copy of Flowcode 5 or higher.

Moderator: Benj

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Protocol converter for graphical LCD

Post by echase »

I have an expensive oscilloscope with a fading and obsolete 240x 240 pixel LCD graphical display. As 320 x 240 displays are cheaply available for Arduino and Pi use I am thinking I can get one of those and use a PIC as a protocol converter to read the existing display data and translate it to something the new display can use with just 240 x 240 of the screen.

If a PIC is synched to the row sequence and clock and reads all the 4 bit parallel column data into a 60 x 240 array it will have the complete map of the pixels. Or parse the 4 bits and save it all in a 240 x 240 array with each entry either say 1 for pixel on and 0 for pixel off. Somehow can that then be output on I2C or SPI to the new display? Or a parallel i/f is possible if it is necessary for speed. I can’t see a Flowcode macro that dumps an array onto the screen as most are for drawing lines, images etc. The help files says “Bit banging this display is possible but may be slow”. Is this what I am effectively trying to do?

I guess it may be necessary to have 2 copies of the array, one being saved into and the other being sent to o/p.

Anyone attempted something like this before?

Would help to know the refresh rate of the screen. Suspect it’s in the 25-60Hz range. It needs to read 60 x 240 4 bit words per screen refresh = 720kHz data rate at 50Hz. That seems doable with most PICs. Just need one with a serial interface and enough memory for the arrays. Maybe an ECIO would suit as it has a convenient form factor to fit the space available.

I looked at my Flowcode 5.5.2.1 and can find the gLCD component but can’t see if it supports common 240 x 320 displays or do you have another version that does?


PS Glad to see you are around still Ben. I have been away from here for a long time but have more time for this now.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Looking at the common ILI9341 controller chip for 320x 240 displays (has 1278 pads to drive all those rows and columns etc.!) it has a SPI data speed of 10Mb/s.

To enter a full screen into its RAM takes 240 x 320 x 18/10,000,000 = 0.14 secs as each pixel needs an 18 bit colour stated, even though I only need monochrome. Not counting control bits etc. Clearly a refresh rate of more than 7hz is not thus possible so not really understanding how people are using such displays for normal video. Maybe have to use the parallel interface instead as can transfer up to 18 bits in one clock cycle.

Some sort of compression algorithm that only transfers the changed bits could do it but don’t think the chip supports this.

Or in my case as <10% of the pixels are ever on at once maybe could just transfer those 10% of pixels but the controller RAM is not quickly geared up to receiving data in random locations as normally just does a raster scan like fill.

Looking away from colour, Hantronics monochrome displays seem to be nearest to the current scope architecture and although more expensive than the common colour ones may be easier to drive as appear to have a similar 4 bit i/f and clocks. This one is the best size. https://www.mouser.ee/datasheet/2/178/320240-22013.pdf Maybe I could just pass the 4 bit data straight on from scope to LCD without needing to store it in a PIC array. Just use the PIC to reorder the timings of clocks etc. if needed and pass on the contrast analogue signal.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Think though if using the Hantronics one that it might be necessary to use a PIC to fill in the missing 80 columns in the scope signal so can't manage without a frame store in PIC to do this.

I have measured the refresh rate as 36Hz.

Fundementally I now think what I need to buy is a lcd without a controller chip, like that Hantronics, as such a chip is just a bottleneck to speed when I am just generating a simple raster with horizontal and vertical synch pulses, plus a few MHz clock pulse. Do any of the Flowcode components work with no controller lcds?

Or I use such as the ILI9341 set to RGB parallel mode. Instead of sending 18 or so colour bits for every pixel just use hardware to send all 1s or 0s depending if pixel is black or white. So don't need 18 lines from PIC to LCD for colour data but only 1.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Sorry about these random musing, I am learning a lot about video protocols.

One flaw in having no controller on the LCD is that the PIC not only has to accurately synch with the scope to read the data, but also has to issue accurate timings to the LCD and I can see that may be difficult to do, with any unexpected delay in the PIC software causing a corrupt LCD. If however there is a controller chip the PIC can send it data at vague timings to suit the PIC and the controller does all the difficult timings with the LCD.

I.e.

Accurately timed read from scope to PIC
Send complete PIC frame to controller
Controller later, at time to suit it but before next frame arrives, outputs frame to LCD.

All that is needed presumably is the make sure the LCD is running at same frame rate as the scope data which it will if the scope’s frame clock is used to synch the controller and PIC.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

To distil the random musings into actual Flowcode questions can I ask?

1. Do you support PICs with more than 15kbyte of RAM as need that to save a full video page array? Such as dsPIC33FJ256GP710A. No 8 bit PIC has enough RAM.

2. Do you support adding an external 16kbit RAM to an 8 bit PIC? Suspect it is not a very good approach for this project if only because the addressing of this RAM would slow things down.

3. Do you support PICs with a dedicated Graphics Controller such as PIC24FJ128DA106? Would need full support for the controller part so can use Flowcode to set up all the timings and resolutions and input/output formats. Don’t want to have to revert to C to do this. Also best to use DMA to output the page to the LCD to speed it up. The best architecture seems to be to use a RGB parallel i/f to LCD, or it’s controller if it has one. Although it’s supposed to be sending 16 bit colour, in practice can send one bit from the PIC page memory and tie all 16 lines together so the same bit is loaded into all 16 locations. SPI or I2C may not be fast enough even if this trick can be used.

4. Do you support 2 dimensional arrays? E.g. set an array that is 240 x 360 big with one bit per address?

5. If 2 dimensional not possible can I generate arrays like Variable_name(counter)[360]. Where the counter goes from 0-239 and changes the array’s name so I can easily generate 240 one dimensional arrays? If not have to laboriously generate 240 arrays of 360 wide, each with a different name, one for each row of the LCD.

6. The common ILI9341 graphics controller chip I mentioned is just one of several with very similar architecture and “identical” interfaces to the processor side as they use a 8080 type I or II i/f, whatever that means. Some are more suited to larger or smaller pixel counts. Do you support any of them in RGB input mode? Do any of the E Blocks listed as supported by v5 have that sort of architecture?

If the answer is no for v5 but v6 or 7 does it then please give that answer.

Found Microchip do some useful Application Notes on driving LCDs such as http://ww1.microchip.com/downloads/en/A ... 01387C.pdf and http://ww1.microchip.com/downloads/en/A ... 01368a.pdf for LCDs without controllers. None cover the situation where like Flowcode’s gLCD the graphics controller is assumed outside the PIC.
Last edited by echase on Wed Apr 25, 2018 6:37 am, edited 1 time in total.

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: Protocol converter for graphical LCD

Post by kersing »

I have been wondering what controller the original display uses. Can't you find another display using the same controller? Or can you implement a translator of the command set of that controller to another controller?

Regarding your questions, let me try to answer them:
1. Yes. There is support for PICs with > 15K ram. PIC16 might fit you requirements, if not PIC32 has relatively 'huge' memory and is pretty fast as well.
2. You can do this yourself in Flowcharts. I haven't seen an external RAM component (there might be one I overlooked)
3. Dedicated graphic controllers in PIC are not supported as far as I know.
4. Multi dimensional arrays can be simulated: declare a[240*240] and to access an element use a[x + 240*y]. Keep in mind this will allocate 240*240 bytes, to use bits you need to do something clever yourself.
5. See work around mentioned in the previous answer.
6. There are a number of graphic displays supported by FC7 (FC6 is no longer available for purchase so if you don't use it yet you won't be able to obtain it) FC5 is no longer supported. I just read elsewhere on this forum there might be an announcement concerning FC8 in the near future.
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Many thanks kersing. There are lots of chips that do video conversion, e.g. from RGB to HDMI for TVs, PCs etc. but can’t find one that does what I need as the scope LCD uses a rather unique graphics controller made from 6 chips that can no longer be bought (rather than the one normally used) and the clock format seems slight unusual, although broadly follows a standard 8080 parallel monochrome i/f type. So can’t find an off the shelf display that will directly read the scope’s o/p.

So I’d need a PIC to translate the protocols.However am now thinking that maybe not necessary to store the whole frame. Instead:

• Read the 4 bit stream from scope, which define whether the pixel is on or off for 4 columns.
• Parse to single bits. How do you do that in Flowcode?
• Output to LCD one at a time to turn all 3 colours per pixel fully on or off.
• Simultaneously pass on the vertical and horizontal synch pulses and data clock
• If some retiming of those clocks is needed or missing pulses filled in the PIC can do that, e.g. using small delays.

At most need to store 2 rows in 2 arrays if want to stretch the data from 240 to 360 pixels. E.g. send 2 rows of data then a blank row. Or for columns output 2 bits then a filing 0 bit then another 2 to stretch it 50%. Or interpolate it such that if the 2 bits either side of the filler bit are 1 then output a filling 1 instead. No idea how real interpolation works but always amazed how smooth digital zoom is on say a LCD projector, with no visible gaps or image distortion.

Answers using previous headings:

1. Thanks
2. Thanks
3. Thanks
4. a[240*240] does not work for me. Says it’s an illegal format. Maybe only later FC versions do it. To avoid a one bit per cell array structure I can merge two 4 bit inputs into an 8 bit and save those 8 bits per cell. What is the command for this in Flowcode? If in C I guess it’s multiply the first byte by 8 and add to second byte. Can only find string manipulators for this sort of thing in Flowcode.
5. Thanks
6. I need a 3.5” display of ideally 240 x 360 resolution. Of the many controller chips supported in FC7 I think only 2 support screens that large and the availability of the exact screen is limited as either only go up to 3.2” or if 3.5” tend to have more pixels, so will have the stretch the PIC output even more to fill it. If I can avoid the frame store (needing a PIC16) and controller support don’t need to upgrade to FC7 and then maybe find that a LCD to suit can’t be bought. PIC8 with FC5 is OK. But if I do upgrade looks as if I only need the PIC16 and display packs to do this project.

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Protocol converter for graphical LCD

Post by mnf »

Hi,

My five cents worth of help:

I wrote a program that decodes bitmap files for display - so while not exactly analogous to what you are doing may give some help:

The code that reads a single row of a 4 bit file is : (may appear at the end - I haven't got the hang of getting images to appear mid message?) This assumes that each 4 bits are describing one of 16 colours for a pixel (WritePixel uses a lookup table (an array) created using the files colortable) - if each bit is one pixel (on or off) then mask and compare to 0

In pseudocode:

Code: Select all

  loop 4 times 
    data = ....
    mask = %1000
  
    if (mask & data) = 0 
      'blank' pixel
    else
      set pixel
    
    mask = mask >> 1	
  end loop
 

If helpful - I can post the code that handles 1 bit 8 or 24 bit files....
bmap4.JPG
bmap4.JPG (28.21 KiB) Viewed 17059 times
Combining nibbles to form bytes (or indeed bytes to form words) is easy in flow code

In a calculation macro

Code: Select all

  x = (a << 4) + b
Which shifts a left 4 bits and then adds b. Parentheses probably aren't strictly necessary but will prevent unexpected operator precedence 'surprises' :-) So use them where they clarify!

Martin

Thanks to etsdriver for the tip. Just spotted a bug too.. second pixel should be. b& 0x0f rather than .col
Last edited by EtsDriver on Wed Apr 25, 2018 7:18 pm, edited 1 time in total.
Reason: You dont need img tags around post attachment, only when your image is from outside source like postimage or similar. :)

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Thanks Martin. Realised I have a speed problem in that the minimum period of the data clock pulses is 250ns. A 4 bit nibble needs to be read in that time and output as 4 individual pulses on a one bit o/p as well as a clock of 4 times the input data clock. This is really pushing the speed of a PIC and a LCD. With a 64Mhz PIC I only have 16 PIC clocks cycles to:

Service an interrupt triggered by the data clock
In the interrupt macro:
Read the nibble
Parse it to 4 bits
Output each bit serially
Generate and output a 4x clock pulse that falls when the data output is available.
Ideally add 50% dummy bits and clocks to stretch the row by 50%.

Can all that be done in 16 PIC clock cycles? Perhaps a bit faster if instead of parsing it using Martin's code I read it as 4 one bit i/ps into 4 variables. I am doubtful as the interrupt code in partial picture here is already 16 Flowcode commands long without the 50%. A Flowcode command might be at least one line of C. How many machine code commands is that, each of which presumably takes one clock cycle?
Capture.JPG
Capture.JPG (47.08 KiB) Viewed 17006 times
Alternatives may be:

1. To do all this in an external hardware shift register, leaving the PIC to do some other stuff that is less time critical. Not sure the 50% extra is easy to do in hardware but maybe the PIC can add them.
2. Read all the 240 bits for one line into a 240 wide array. As thre is an unusually long flyback period of slightly more than the line period can output it all again at “half speed”. But means have to output the first half of the line at same time as reading the nibbles which I would have thought impossible in 16 clocks. Or just store it and output it all at full speed in the flyback period. Either way, to store it means adding 2 nibbles together and separating again whilst adding the 50% which again is challenging in 16 clocks.
3. Bizarrely the data clocks come in pairs 250ns apart but with a 500ns gap to the next pair. No idea why this is done. Possibly can use that gap by: store nibble 1 on clock 1, store nibble 2 on clock 2, output both nibbles and the 4x clock in the gap. As no need to do reading in the gap have more PIC clocks cycles to use.

Am I correct to assume that as I am only processing 1-8 bits at a time and doing no complex sums there is no speed advantage to using a 64Mhz 16 bit PIC instead of a 64Mhz 8 bit PIC? At most the 16 bit series goes up to 70MHz. So I'd only need a 16 bit to get more RAM if I do have a frame store.
Last edited by echase on Fri Apr 27, 2018 8:19 am, edited 2 times in total.

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: Protocol converter for graphical LCD

Post by kersing »

You are comparing MHz vs Mips. There are 16 bitters able to do at least 140MHz (to run at 70MIPS)
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

http://www.microchip.com/ParamChartSear ... ranchID=20 only lists up to 70 MIPS although it does say DMIPS too. Is that double MIPS? But have found that page lacking as some in production PICS don’t appear there at all.

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: Protocol converter for graphical LCD

Post by kersing »

Generally for 8 bit PICs MIPS = MHz / 4 and 16 bit PICs MIPS = MHz / 2. So a 64MHz 8 bitter does 16 MIPS where the 16 bitters go up to 70 MIPS.
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

So to get 16 instructions into 0.25us I'd need a PIC 16 at 70MIPS. As the real instructions for above interrupt macro are probably 50 or more I'd really need a PIC32 which go up to 250MHz. Although it's getting a bit ridiculous to use a 64 or more pin PIC 32 device when I only use about 6 I/O pins in this application. The 120Mhz /150MIPS PIC32MX470512H is one for which Microchip sell a development PCB http://www.microchip.com/Developmenttoo ... O=DM320103 so is easier to experiment with.

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Protocol converter for graphical LCD

Post by mnf »

For speed you could possibly either use a switch (or a jump table, though not easy in Flowcode)

So in pseudo code:

Code: Select all

b = Read 4bits
Switch on b
0:
Writepixel(0)x4
...
1:
Write Pixel(0)X3
Write pixel(1)
2:
Write pixel(0)X2
Writepixel (1)
Writepixel(0)

....
15:
Writepixel (1)x4
A lot more code but mostly a cut and paste job.


Another approach might be to read the entire frame to memory - then process it ( and write to output) in the delay between frames (assuming a 50hz refresh)
This would make it much less time critical.

Martin

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

mnf wrote:For speed you could possibly either use a switch (or a jump table, though not easy in Flowcode)

So in pseudo code:

Code: Select all

b = Read 4bits
Switch on b
0:
Writepixel(0)x4

Another approach might be to read the entire frame to memory - then process it ( and write to output) in the delay between frames (assuming a 50hz refresh)
This would make it much less time critical.

Martin
I don’t think there is enough time between frames but I have now found that the refresh rate is 70Hz which is unnecessarily high. What I could do is save only alternate frames, as long as does not cause flicker, thus giving lots of time in the missing frame to output it with an even data clock rather than the double pulses. There are a few 70 MIPS PIC16s with enough RAM but only 28 pins that may do this if add the nibbles together into 8 bits words, like dsPIC33EP512MC202. Or doing it a line at a time may be OK.

To clarify the 4 bits are for 4 columns and not 4 colours. The reason to parse them is that the new LCD does not take input for 4 columns at a time so have to send them as 4 consecutive bits, with date clock for each, where a 1 is all 3 colours on to give white and a 0 is all off for black. The bit would be sent simultaneous to all the 16/18 colour lines by paralleling them so all are 1s or 0s. Or at least paralleling all the greens, reds and blues on up to 3 PIC 1 bit o/ps.

Ideally I’d like enough spare processing time to inject some colour into what was just a monochrome display, e.g. if I could detect where the graticule lines are, as evidenced by lots of 0s all in one row or column then I could maybe only turn on one or two 3 colours to make the graticule not a black line. Could only do this if there was a full frame to pattern analyse. I know which rows and columns they are in as it’s a fixed pattern so just need to look at those.

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Protocol converter for graphical LCD

Post by mnf »

Sorry - the pseudo code is just meant to describe the steps required to do what you want to do....

It is easy to do a similar job in Flowcode - create dummy macros for sub routine - build the top level and then work down to the lower level routines. (This is known as "top down programming")

So what I was trying to describe above - in Flowcode:
display.JPG
display.JPG (50.9 KiB) Viewed 16985 times
Note that Flowcode limits switch statements to 10 cases - so unfortunately you'd need a decision to divide into two first first...
I would try using a bitwise mask first - (as mentioned above:

Code: Select all

.mask = 0b1000
...
decision
(.b & mask) == 0
...
.mask = .mask >> 1
)

The code is simpler and I think that the speed will be almost as quick as the switch statement (which adds an (unknown) overhead - and although you would hope otherwise - may be slower for some values?)
You could 'unroll' the loop for a little extra speed

As an aside:

Code: Select all

.b & 0b1000 ...
.b & 0b0100 ...
.b & 0b0010 ...
.b & 0b0001 ...

Using constants for the bitmask would be equally valid - I tend to use a variable partly because I like 'loops' to do the repetitive stuff but also because I (naively) believe that it will be held in a register and access 'may' be quicker than accessing a constant from a memory (or maybe I am too accustomed to optimizing compilers :-) and actually the code retrieves the value, uses it in the & calculation, retrieves it again for the shift then stores it back to memory) Maybe Ben / Leigh could comment on this

Flowcode converts everything into C pretty effectively at one line per macro call (though this does not necessarily relate to only one instruction per macro call!)

I would suggest getting the basics working first ie get the output display working - then get input working to a buffer and get some output reflected onto the display (even if it is just one frame / alternate frames etc).. Colour, display stretching etc can come later if needed!

Martin

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Martin, does not answer your last post but here is a fcf that:

Reads the 2 nibbles on an interrupt.
When that is complete parses 2 nibbles into 8 variables. (But may be able to do the first nibble in the interrupt to save time).
In Main output that as 12 serial bits plus 12 serial clocks (to add the 50%)

The output, which is supposed to fit into the 500ns gap between clock pairs comes to over 100 lines (may be 200) of assembler or C and I have not even included the parsing of the 4 bits into 4 variables. So assuming one assembler or C line is one instruction it’s hard to see this working unless your code is much more efficient than Flowcode.
Scope3.fcf
(20.47 KiB) Downloaded 244 times

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Protocol converter for graphical LCD

Post by mnf »

I converted to use a bit mask. I was a bit unsure where the stretch clocks went out - so I've put them after odd pixels - this might need tweaking....
S_v7.fcfx
(17.29 KiB) Downloaded 258 times
As a question - the clock cycles output will be very short- are you sure on the timing of this - Flowcode does have some overhead - setting a bit in a port calls a macro - so the length is multiple instruction cycles? But still short!

I still suspect that this will be slightly quicker than saving the data out to 8 variables (or an 8 byte array) - unrolling the loop would shave a few cycles (some compilers will do this for small loop counts)

Hope it is of some use.

Martin

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Protocol converter for graphical LCD

Post by mnf »

Other thoughts:

1) I copy the two nibbles to a variable - so that if an interrupt does occur the new data won't ovewrite what we are working on. If the timing is that tight, however, an interrupt occurring will likely mess things up anyway.

2) Replace the Output to port macros with inline C (or Asm - but don't go there yet) directly writing to the port registers would be quicker....

3) Is there an alternative (parallel) display available where you can write 8/16/? bits directly using a single write rather than having to toggle a single bit? (This would surely make life easier!)

Martin

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Hope this works but have included some of your text in italics to make it easier to show what I am replying to.
mnf wrote: I was a bit unsure where the stretch clocks went out - so I've put them after odd pixels - this might need tweaking...
. Think it's correct. Should be, half a nibble, 1 stretch bit, half a nibble, 1 stretch bit, etc. Excuse ignorance but what exactly does the command .i % 2 do?
mnf wrote:As a question - the clock cycles output will be very short- are you sure on the timing of this
Yes very short and have to ensure they don’t fall under the min spec of LCD which is typically 50 - 100ns for the 1 and the 0. (8 x 50 = 400ns so is getting close to the 500ns gap length. In worst case have to add padding instructions to lengthen clocks which makes fitting it all in more difficult. Have to ensure I buy an LCD with the shortest possible clock.
mnf wrote:1) I copy the two nibbles to a variable - so that if an interrupt does occur the new data won't overwrite what we are working on. If the timing is that tight, however, an interrupt occurring will likely mess things up anyway.
Definitely need to finish the 8 bits before the next 8 arrive or else will never catch up with perhaps increasing LCD corruption as the row progresses. I could rewrite your last so it starts to output the first nibble before the second one is read so now have 750ns to output both nibbles, but this would need the 2 nibbles not merging with command data = (Nibble1 << 4) + Nibble2. Is that feasible? This assumes an interrupt in middle of an output clock or data o/p won’t corrupt the LCD. My Both_nibbles_read_flag command are not right and if doing as 2 not merged nibbles may have to be 2 flags or maybe use Clock_counter instead
mnf wrote:2) Replace the Output to port macros with inline C (or Asm - but don't go there yet) directly writing to the port registers would be quicker....
Would help as a Flowcode output box uses about 4 lines of C.
mnf wrote:3) Is there an alternative (parallel) display available where you can write 8/16/? bits directly using a single write rather than having to toggle a single bit?
The word parallel in LCDs is a bit misleading I have found. It either means transferring one pixel as a parallel instruction, as opposed to say SPI, including its colour and address (although generally it just moves on one pixel in the raster scan so don’t have to give the address). Or for some monochrome displays, like the scope’s original, is means transferring 4 columns at a time (some may be 8 bit). But the availability of such monochrome displays is limited. Much easier and cheaper to buy a colour display. Also I don’t know how to add stretch bits in the second case as 4 bits go into PIC and 6 come out. But have to only transmit 4 at a time to LCD so get left with 2 behind to add onto the next 2 bits so gets messy.

One way around the speed problem is to use one PIC to multiply the data clock by 4. Then have a second PIC to parse the data and add the stretch bits. Need though to make sure the 2 are sufficiently synched that the data and clocks arrive in synch at LCD. Roughly halves the burden on each.
Last edited by EtsDriver on Tue May 01, 2018 6:06 am, edited 1 time in total.
Reason: Added quotes for easier readability.

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Scope clock pulses.pdf
(507.93 KiB) Downloaded 244 times
Here is a doc I wrote showing some scope traces measured off the faulty scope with a good Picoscope. You can clearly see the double pulses with a variable gap to next pair. I have assumed no significant gap after each frame as yet to measure that. The refresh rate would be less if there was a gap.

Edward

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Protocol converter for graphical LCD

Post by mnf »

To answer a couple of questions from earlier:

1) the '%' is the mod operator (remainder) so i % 2 will return 0 for i = 0, 2, 4 and 1 (or true) for 1,3,5....

2) Flowcode (v7 at least) does support multidimensional arrays... So for example a BYTE variable declared as:

Code: Select all

x[40][240]
would declare an array of 320 bits (so 1 bit per pixel) by 240 rows. You can also 'simulate' them using a single array (in this example x[9600]) though both are obviously subject to RAM being available. Accessing bytes would then be

Code: Select all

b = x[column / 8][row]
Note that this would be stored in contiguous memory locations so could also be accessed using a sequential read:

Code: Select all

b = x[i]	// Process next 8 pixels....
i = i + 1	
In view of the time limits - buffer a frame to RAM and then output during second frame (ignoring alternate frames).

Use a faster processor.
Use a display with an internal memory buffer and write to that.. I have a very cheap oscilloscope (~£12) that outputs it's trace to a 320 x 240 display (though not at 70Hz) - it uses a 320x240 (262K color) display with what appears to be a 32 bit parallel interface and an ARM Cortex-M3 (STM32F103C8) processor. I tend to use a SmartScope:-)

Replace the screen on the old oscilloscope (ebay's spares or repairs??)

Have you got a working display - ie can you display anything on your new display? Ignore the requirement to read the data in - and see if you can output a test image to the display - then you can decide if there is sufficient time to read the data a line at a time and write it during the 'flyback' or a frame at a time or if some other approach is needed?

Martin

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

Lots of good ideas thank you very much. The next step is for me to actually try some hardware out to see it displays anything. That is going to take some weeks as some of the bits like LCD and ribbon connectors I ordered come from China. When I have something running I’ll probably be back asking more questions.

I did try eBay for a dead one for spares but no joy. Something may pop up later. Problem is that the screen is a known weak spot so may those will have similar problems.

mnf
Valued Contributor
Valued Contributor
Posts: 1188
Joined: Wed May 31, 2017 11:57 am
Has thanked: 70 times
Been thanked: 439 times
Contact:

Re: Protocol converter for graphical LCD

Post by mnf »

Good luck - let us know how it goes...

Martin

echase
Posts: 429
Joined: Mon Jun 11, 2007 11:55 am
Has thanked: 49 times
Contact:

Re: Protocol converter for graphical LCD

Post by echase »

HDM3224L-G Hantronics.pdf
(224.22 KiB) Downloaded 185 times
There is good news and bad news. I paused the development as Hantronic, despite publishing lots of data, could not tell me if the bias voltage for the obsolete display I bought was +30V or -30V and using the wrong one may destroy it. Their current models are either not suitable or impossible to get hold of in one offs.

I’ve more time now due to covid lockdown so I made a guess and got it right. I briefly got a vague approximation of the correct display with the nearly right graticule lines and scope trace but garbled text and numbers. I don’t understand that as it’s not like a I2C/SPI type display where you send it codes for each character, which it can misinterpret. I am just sending it a raster of 0/1 on/off commands for all pixels. So why does it get lines right but not text? One possible explanation is that at 2 MHz data and 70Hz refresh rates it may be on the limit of what the display can accept so it garbles some of the data. The attached spec implies a 1.3 MHz max. Only way round this would be to store a frame in a PIC and output it more slowly as say halving the data rate would not be that visibly different on the display, even on fast moving scope traces.

I chose this monochrome Hantronic 360 x 240 display (Datasheet for a similar one attached) as it’s interface is identical on paper to the scope’s output so no protocol converter is needed unless I want to stretch the image to fully fill the display. The displayed area is now less than 50% of the original area as the new display is smaller (would not fit the case if any larger) and I can only populate 240 x 240 pixels. But both old and new have the same number of displayed pixels so it should be as sharp.

The badder news is that I seem to have shorted a wire and killed the scope's clock pulse so now no longer have a working display. It’s the inside of the main 208 pin processor that has failed so no chance of changing the chip. It does output a few pulses but not nearly enough.

I think I could recreate the clock using the data nibbles into a PIC based phased lock loop. I.e. I read the nibbles into an interrupt and every time one changes it indicates that a clock pulse is needed to make that nibble write into the display. As the nibbles won’t change if there is a white or black block I can maybe guess the blanks as I know it’s about a 2Mhz clock rate. All I need to do is shift that 2MHz up and down say 5% based on the nibble changes and get it timing correct wrt the data. Anyone tried this? I can foresee problems though as a scope trace I posted above shows that the clock pules come in pairs with random gaps inbetween. So if I regenerate an evenly spaced 2Mhz pseudo clock it's not always going to line up with the incoming data pulses

The scope's and new displays's parallel interface is 21 wires wide as follows:

D0 - D3. 4 bit data nibble to fill 4 columns on 1 line at a time.
CL2. Clock pulse at 2Mhz. Scope trace of it is in a post above in doc "Scope clock pulses.pdf". Moves data along four columns for each clock pulse. Confusingly it’s only there 50 % of time as, after writing one frame full, it pauses for about the time it could take to write another. Why? To enable the scope to fill its RAM with the next frame?
CL1. End of line/row pulse. Jumps display to lines 2,3,4 till 240. I.e. the data starts the frame at columns 1-4, row 1, then column 5-8, etc. After column 240 it jumps to row 2 back at columns 1-4.
FLM. Start of frame
M. A slower 50% mark space signal to alternate the bias voltage polarity to give the AC bias.

Plus less difficult to deal with ones:

LCD bias voltages
3.3V power supply
Ground wires.
DOFF. Turns display on/off. Not sure why the scope outputs this as display is never off unless all powered down. Will just tying it to 0 or 1 do?
Temperature. The scope display outputs a display temperature signal but Hantronic doesn’t use it. I suspect it’s used to adjust the contrast voltage slightly to eliminate temperature effects.
Contrast. The scope outputs a menu controlled contrast signal but Hantronic doesn’t read it. I now have a manual trim pot but could later read the scope output to adjust the Hantronic.


The advantage of this interface is that it is fast. The minute I use colour displays or I2C/SPI interfaces I fail to see how my coding skills and Flowcode could process the nibbles and incoming clocks fast enough in a PIC to fill the new display, as some sort of video RAM will need to be filled to convert what comes in into what is needed to go out. But I can see how I could use a PIC to read a few nibbles and average them to work out how to crudely interpolate columns on a 50% stretched display. E.g. if the incoming data is columns 1, 2, 3, 4 the outgoing becomes 50% more columns like 1, 1a, 2, 3, 3a, 4, etc. where 1a is the average of 1 and 2 plus the pixels above and below 1 and 2. So if more than half in that area are black 1a becomes black too. It does not give an even interpolation as there is no 2a, so a straight diagonal line would become slightly stepped, but might look OK.

Front and back views of old and new displays together here. You can see the large central "burn" on the old one which causes it to be almost unreadable. The plastic bag on the new one is meant to prevent shorts between the display's PCB and my interface PCB but did not save the clock line.
Attachments
SDC18537.JPG
SDC18537.JPG (262.48 KiB) Viewed 12452 times
SDC18536.JPG
SDC18536.JPG (279.8 KiB) Viewed 12452 times

Post Reply