I am looking on a platform with more memory than PandaII, and I would like to keep the low price on the 2.4" tft lcd like fez touch…
Basically, how to interface cobra/EMX with those screens? I guess that except the re-wiring, the fez touch driver (http://www.tinyclr.com/codeshare/entry/301) can be used . OK, but :
1)This driver uses Parallel port, on panda, there are 8 pins optimized for that. Is it the case on Cobra/EMX?
2)The LPC2478 used on emx has hardware support for various LCDs… including the 16bits like fez touch (www.nxp.com/documents/user_manual/UM10237.pdf) is there any GHI/community exemples on how to use it, or is the only LCD supported is the 3.5" lcd sold for the cobra ? In that case, if I want to get the best of the hardware, I have to develop myself with RLP specific native fez touch lcd driver for the cobra… But it would help if I have not to do it from scratch…
the Touch is not an LCD that uses the inbuilt controller in EMX, it has its own controller onboard, so you wouldn’t connect it like either the LCD 4.3" or 3.5" variants Cobra is set up to handle. You would therefore just need to wire the pins up as general IO pins instead of using the LCD pins.
[quote]
the Touch is not an LCD that uses the inbuilt controller in EMX, it has its own controller onboard, so you wouldn’t connect it like either the LCD 4.3" or 3.5" variants Cobra is set up to handle. You would therefore just need to wire the pins up as general IO pins instead of using the LCD pins. [/quote]
Yes, I understand that fez touch ans variants are not made for cobra, Indeed I guess that it is technically possible to interface it and get good performances, since lpc2478 includes a hardware controller for LCD (see p281 of www.nxp.com/documents/user_manual/UM10237.pdf)
The interesting question is : What performance can we hope and what effort is required to connect fez touch style screens on cobra?
It seems, but maybe GHI people will provide us some additional info on the way parallel port is managed… maybe it is possible to implement it throughRLP if it is not existing?
RLP is definitely an(the) option. The very first version of the driver for that display was bit banging the IOs and it was slow on Panda (that is when the idea of adding ParallelPort for that purpose was born btw), but with Cobra it can be a different story.You have to try it.
Thank you Architect… Indeed, writing a native driver for RLP is a hard job… so I have those solutions to meet my needs:
Find a small cheap (less than 50$) lcd screen wich is compatible with cobra/emx (if protocol is compatible and just rewiring is needed it is not a problem)
->Can you advise some workarounds/constructors doing lcd screens wich could work with emx, even with hard modifications?
2)Implement a native parallel port ( but I guess that it is some C bit banging? Or there is some parallelport feature in lpc24xx that I did not see?)
Implement a native LCD RLP driver, ( hard job even if I have basically the skills for doing simple things in RLP : native timers, PWM, interrupts and so on…) Do you have any workarounds, or exemple code in order not starting from scratch? LPC2478 user manual shows that it is possible, but I was unable to find any native exemple of c lcd driver for the lpc2xxx familly…
I think screens with TFT parallell RGB interface should work on the emx. In the near future I’ll try to connect a custom 2inch LCD so might post my findings here when I’m at it.
->Yes I think too. My issue is that I wold like to use small and cheap tft screens and that parallel RGB is for 3.5" screens minimum… the cheapest wich could do the job is this one, but too big for my needs: 3.5 inch Standard TFT without Touchscreen
I will probably do the same with a 2.8" 16bits LCD and either post here…
Yes, but I guess that if parallel RGB interface is not 24bits, is can not be used directly on cobra (or you think there is a chance that just connecting 3x6 bits screens on 3x8 bit cobra will work ? it should be great but i don’t think it is possible) and I am afraid that the conclusion is the same that any other not compatible screen : Do the driver yourself…
Of course it will, just don’t connect the lower bits, for 8 to 6 bit, don’t use the lower two bits. The R,G and B bus output the intensity for a single pixel each clock cycle.
Choose a screen with parallel RGB interface so you don’t have to create your driver in software and loose hardware accelerated screen updates
… The performance loss would be enormous.
Right , I just realized that ! Indeed, the RGB interface is 16bits ( “R5G6B5” 65k colors) according to schematics : http://www.ghielectronics.com/catalog/product/240
So every screen with the inteface “parallel RGB + hsync/vsync/clk” without driver should be ok, right?
Just need to rewire signals and check that the screen has the same resolution… and manage specific features of backlight if it is not the same thing than FEZ-TFT Expansion board…
About the EZ-TFT Expansion board, since lcd controller is inside the EMX, we agree that its just wiring signals to cobra, and manage touch and backlight?
So basically Fez touch screen could be used if we could remove the included ILI9340 lcd controller and rewire signals ! (far to be an easy operation)
So this one should be ok, for ex : 3.5 inch Standard TFT without Touchscreen
The difficulty is to find a screen without controller at the proper size, because most of the <=2.8inch screens that I see have a ILI9XXX built inside…
You can even modify the resolution. You also might have to change polarity of sync signals.
I also hope it’s just some rewiring, applying correct power and translate signal levels if needed. I can’t tell you that screen will work, because it’s also my 1st attempt
For touch, if you want high precision, you could use a spi touch controller like the ads7843 instead of internal adc. Of course for small screens, this might be overkill.
The screen I’ll be using needs 2.0V, 2.8V and 9.3V for backlight. I have an other 3V3 for EMX. I need to convert all tft signals from 3V3 to 2.0V, so wish me luck
What confused me with your 2inch screen is that according to the datasheet :
-it seems to have a tft driver and interface (p3) and that we can (we must?) send instructions on 8bit (pin #8 A0 , in tab p13)
-it has a 18-bits bus, hsync, vsync, clock signals accessible …
So I don’t understand if there is yes or not a controler? What is your feeling with it?
The datasheet of the LCD mentions a TFT driver: EPSON S1D19120 ( http://www.kyocera-display.com/SiteImages/PartList/CONTROLLER/S1D19120%20Series%20Technical%20Manual%20Rev1.1.pdf ) . Since the controller can use different interfaces, you’ll need to setup the controller (select interface, set resolution, etc). To communicate with the controller you can use an 8 bit databus (multiplexed with the RGB bus). But, you can also do it through SPI, which is what I am going to do.
I’m aware that this is not an easy screen to begin with, but I want to give it a try…
I finally order a TFT screen and I will try it as soon as I have received it and the appropriate connector: http://www.avnet-embedded.eu/fileadmin/user_upload/Files/Displays/Colour_TFT/UMSH-8252MD-1T.pdf
Indeed, I am a bit puzzled on the way to control it: It has a parallel RGB interface with HSync/VSync/Clock just like the fez tft 3.5" shield, but according to the documentation, (not sure I correctly understand it) I have to send serial SPI commands to allow access to this interface… I am a bit surprised to not have directly access to parallel interface…
->Has someone some experience with this way of controlling TFTs? Is it an usual way to work?
->I continue to look for other solutions to put a tft screen on a custom shield. A good starting point should be to know what is the LCD used on GHI 3.5" shield? I did not find this info in the online documentation…
->WouterH : Did you get some success with your screen?
@ cca: I’m currently trying to get my screen to work. Backlight works OK, and I can communicate over SPI (can read out status etc, so that works). But my screen stays white. At first this looks very nice, but after two days of white, it starts getting annoying
