EihiS

May 24, 2013

Raspberry PI : Cheap LCD display MOD

Filed under: Raspberry 3.14 — Tags: , , , , , , , , — admin @ 11:28 am

In this article, i’m going to explain how to connect a raspberry Pi to a cheap LCD display taken from a broken or old DVD player.

The output of the RasPI (video-composite output) is used to send video datas to the LCD panel, and one must configure the /boot/config.txt file of raspbian linux to set the correct width and height for the LCD panel.

This ‘MOD’ for Pi can be applied to many cheap LCD panels one can found into broken or unused DVD players around there : ebay, trash containers and so on.

For my specific case, i had a PROline DVD player , model DVDP650W.it has a video-in jack plug. that’s why i figured out that it should be possible to make it become a kind of mini- tv monitor, by extracting only the video decoding and driving parts.

Once opened, you will find many parts (dont be offraid by that, we are going to clean up that..)
The main board can be removed. The mechanical DVD reader head also. Carefully unpluggin the internal connectors, and removing all blocking screws around ther, you should end up with a kit of PCBs wich are :

The main PCB assembly : Not used

The main PCB assembly : Not used

Notice the input power jacks : 12V . that’s what we will have to power the LCD driver board with. AC/DC adapter directly plugged to the LCD driver board. Tha PCB assembly can be put away - not needed anymore.

This is the LCD driver BOARD. carefully remove the cables going to the LCD panel ( the connector is unlocked by pulling up the greyish/maroon plastic part)

This is the LCD driver BOARD. carefully remove the cables going to the LCD panel ( the connector is unlocked by pulling up the greyish/maroon plastic part)

We need that part, obviously. we also need the CCFL inverter board and the LCD panel itself :

LCD panel model PW065XS4

LCD panel model PW065XS4

The LCD panel’s datasheet is HERE

Now, we just need to reassemble all parts into something looking usable . i’ve used a plastic panel quickly drilled to let the LCD’s flat outlet and CCFL wires going from the front face to the backface where i have fixed the PCBs needed.

SO, ending up with something like that :

Front

Back

Back

You can check all the parts you need :

- the CCFL inverter (top left of the picture) , connected to the LCD driver board

- the 2 potentiometer ’satellite’ pcbs : one for brightness, the other for colour adjustment, connected to the board

- the LCD panel’s flat outlet re-plugged onto the LCD driver board.

Now, for that particular LCD driver board, here is the PINOUT :

LCD driver board power and signal connector

LCD driver board power and signal connector

From left to right, :

1 - LCD on/off.  if let open , LCD is ON. if you put this pin to ground, you’ll put it OFF (CCFL backlight off )
2- Videocomposite GROUND
3-Videocomposite-IN SIGNAL
4-Main GROUND
5-POWER INPUT (+12V)

pin 2 can be tied to pin 5.
I recommend re-using the old cable (6 wires) and solder you wires on it, so you can plug/unplug freely that input part to the PCB assembly.
For the videocomposite signal, just iron a RCA plug (the yellow ones) on it, to be able to connect it to the Raspberry PI’s videocomposite output.

Once done, and once Raspbian linux /boot/config.txt file has been update with the parameters that fit this LCD display, you’ll be able to avec something like that on your homemade mini LCD display :

RaspBian boot done ..

RaspBian boot done ..

And see LXDE’s look :

What a big screen ! :-P

What a big screen ! :-P

Before you end up with that, edit the /boot/config.txt file  and ensure to have this parameters in it :

#lcd panel is 1200×234, but 1200 is for RGB so real size in pixels is 1200/3

framebuffer_width=400

framebuffer_height=200

# values found by trying many. looks the best to avoid flickerings

overscan_left=2

overscan_right=-6

overscan_top=-18

overscan_bottom=-15

sdtv_mode=2    # sets videocomposite output to PAL signal

sdtv_aspect=3    # sets video_composite output to 16:9 format

If anything was going bad ( screen becomes unreadable) , the best is to learn how to use SSH to edit/save and reboot the Pi from a distant computer before applying and testing the display. (take a look at BitVise free SSH software )

Have a nice moding, guys.

stay tuned.

314159265358979323846264338327950288
419716939937510582097494459230781640
628620899862803482534211706798214808

February 22, 2013

BareMetal : a log of the project

Filed under: Raspberry 3.14 — Tags: , , , , , , , — admin @ 11:08 am
  • feb 22 , 2013

Using C code and inline ASM , after a week of victory-and-failure , i’m able to start a code from zero (boot) level.

The file (.img) is compiled using the  hard-floating-point option.
Inline assembly is used for critical accesses ( read/write to the mailbox for video init )

Pointer’s code is used to set GPIO’s functions (input / output ) , set state of the outputs, read states of the inputs.

I have to say that my current way to work is quite complicated :

  1. type C code or asm into leafpad of the RasPI
  2. compile from console on the PI
  3. connect from the pc to the pi through psftp.exe : login, pass…
  4. copy my kernel.img from the Pi to the pc’s SD card that’s plugged into
  5. stop the Pi , unplug the Raspbian SD card from it, plug the SD with my kernel.img
  6. restart the Pi : check of new code works ok or failed ( can be really driving you crazy if not!)
  7. stop the pi, unplug the SD with my kernel, re-plug the SD with the Raspbian, replug my kernel’s SD to the Pc,  then reboot linux and go back to 1.

Kind off…. hard job.
I’ll purchase another Pi soon, because it will ease the work.
Parts of my code come from different sources inspirations. I dont want to re-invent the ‘butter cutter’ ( impossible to translate, thats a french expression).

So, here are 2 pictures taken with my BM code running.

On the first, you can see the output of a test-matrix video output :

And the most interresting , my CCD project’s output now that the USB interrupts (and others) are not interrupting the dump process when hardware’s running : phantom sync’s have disappeared. great ! :D

Finally, here is how Pi is tortured at the hardware level ( prototype was initially built to work with FT2232 module connected to intel coreI7 running the control software side )

314159265358979323846264338327950288
419716939937510582097494459230781640
628620899862803482534211706798214808

February 8, 2013

RasPi-B : Some speed tests using GPIOs

Filed under: Raspberry 3.14 — Tags: , , , , , — admin @ 9:24 am

This post deals with speed tests run , using GPIOs of the RasPI.
My job deals with hardware and software design for industry products , and one of my latest projects has to deal with floating point multiplication.
To be clear enough, on a special device currently under development, i have to use an 512 bytes input matrix that’s passing thru a neuron network with hidden layers.
Experiment have proved that i can’t use a PIC18 ( for instance 18F4550 @ 48MHz ) because of it’s lack of speed doing the computations ( 512 times multiplying 2 floats then adding result to a counter , this operations two times, in the shortest time possible ).
Speed of computation is a major subject for that project, because the device operates in ‘real-time’ ( computation’s lag introduced by the device must not exceed 1ms )

So, the tests results i’ll post here, will always be related to a 512 time-related loop.

Test configuration :

  • using low_level memory access ( direct access to the GPIO port in memory )
  • program is compiled using gcc, with -mfloat-abi=hard
  • program is executed in SU mode ( else we won’t be able to access to /dev/mem ) , under the LXDE (forget the interrupts lags, we’ll deal with it later )

TEST 1 : simple float variables :

the vars:

float t_result;
float t_a;
float t_b;

the test prog part :

t_result=0;
t_a=-0.15849;
t_b=0.000042;
// there we set one of the GPIO output to Hi
for (i=0;i<512;i++) { t_result+= t_a * t_b ; }
// there we set the GPIO output to Low

results : Using that configuration for test, i get 35 microseconds (GPIO lo/hi/lo toggle time) for computation.

TEST 2 : 2 Arrays of float variables

the vars :
float t_result;
float rx[512];
float mx[512];

the test prog part :

t_result=0;
// there we set one of the GPIO output Hi
for (i=0;i<512;i++) { t_result+=rx[i] * mx[i] ; }
// there we set the GPIO output to Low

results : Using that test prog, we get 60 microseconds for computation ( some interrupts happening while computing, that time can extend to 100 microseconds from time to time ).
If we run the same test from the root console, we get 55 microseconds , up to 85 microseconds if the loop is halted by an interrupt request while computing.

The interrupts are an issue for applications who are time-critical.
My current hardware project involves a linear CCD reading, and using C code with SDL  plus the wiringPi library (drogon.net) gives results that dont satisfy me. The CCD exposure time must be the same from one reading to another, so the CCD dump must be done at strict periodic intervals of time, and that goal can’t be achieved using the normal environment, because of the bunch of interrupts happening very often. the main problem comes from the USB thread, wich is taking much time to poll for USB events.

Below is a picture of the oscilloscope’s probing the CCD output.

And a closer look at the problem :

One can easily see the main timing ( bright lines) , while the ‘phantom’ like trace is the CCD’s analogic output when time as been stretched because of an interrupt occuring.

Because time was greater during that interrupt, the CCD exposure time was a little higher than the one without interrupts, thus truncating the CCD’s output values.

The 100 microseconds time between each CCD read is the time for the C program to update the screen ,using SDL wich is initialised with a 0 value instead of SWSURFACE nor HWSURFACE on screen init.

That way,the SDL_Flip() is not needed.
The Frame buffer is updated when you access it.
It creates flickering when used like this, but the main loop then don’t gets stuck waiting for a vertical refresh and hangin on the CCD read sequence) .

i could kill the USB thread before using my prog, but i’ve choosed to try coding at bare-metal level instead,because i don’t need USB devices connected to the Pi for now.
Yes this is ambitious.
But we have to believe and make. Isn’t it ?

314159265358979323846264338327950288
419716939937510582097494459230781640
628620899862803482534211706798214808

cat{ } { post_272 } { } 2009-2015 EIhIS Powered by WordPress