Fighting with RFM12 modules…

Yeah,… because it is really fight…
These modules are cheap, tiny but very painful pain-in-the-ass things.
Datasheets are full of errors, misleads… Provided code samples have errors, they simply don’t work. (it is proven across the Net).

If you’re interested in this kind of fun, you should look at Strobotics blog

I’ll try to post some of my code samples, when I win the battle…

Debugging PIC32 application user interface code

Consider this situation : you’ve connected LCD to your PIC, everything is running smooth, putpixel, fills, clrscr, etc…
Now you’d like to draw some UI elements like labels, texts, buttons, gauges, grids, etc…
One can tell – use Microchip’s GOL Library. Ok – it’s easy, when GOL supports your LCD controller. It’s more complicated when you need to write GOL custom driver to your LCD. That’s the first way.

You can always write your own code, providing you a full set of GUI objects, but there comes a problem : how to debug it easily, without thousands of programming your poor PIC and lazy, terribly slow debugging with tools like ICD-2,etc…

Solution is pretty easy – do it on your well known x86 platform 🙂
For example, install DevC++, install Allegro DevPak, use allegro template to create main.c, add your PIC GUI files to project, use #ifdef __PIC or #ifdef __PIC32MX to exclude PIC specific code and provide LCD driver layer that works with Screen bitmap from allegro. Fast, convenient way. When your library will be bug-free, it will be ready to compile in MPLAB C Compiler…

PIC32 & its ADC10 module

It should be a piece of cake, but when you look into details …
Even if you look deeper into datasheets, you wouldn’t find the statement – DO NOT USE PGED1/C1 to debug your application if using ADC module.

Why ? I don’t know, but it seems to have something with VRef+/- function bound to PGED1/C1 pins (AN0/AN1).
Yeah, I’ve set VCFG correctly to AVDD/AVSS…

Jizz, two days lost…

Initialization of MeSSI LCD…

Today, i’ve found that not only proper RESET signal timing is required to initialize such LCD properly, but also there should be correct driving of power lines to LCD (+1.8V, +2.5V).
Your design should include power switches, driven by your MCU to achieve control over power sequence of LCD.

I’ll investigate it and share my findings soon…

Update #1 : I’m not so sure about this now…
Update #2 : I’m almost sure that it doesn’t matter at all 🙂

Time to post some details

Here you have interface schematic & pcb i’m using to prototyping :

Schematic:
sch_e51
PCB:
pcb_e51_lcd2

Schematic is totally based on BikeRk6’s one, posted here : http://www.elektroda.pl/rtvforum/topic1344700.html

PIC32 Code – Nokia E51 Library:
LCD_E51.ZIP
PIC32 Code – test workspace
test_e51lcd.zip’

Consider this code as pre-alpha release 🙂 It’s dirty, it’s uncommented. It works only partially -> depending on your LCD… You may find it similar to Microchip’s graphics library… it isn’t totally unintended 🙂

Have fun, feel free to improve it!

Controller type consideration about LCDs

E51?: LCD ACX559AKM-7 (SONY?)- code 4851025 : controller compatible partially with LDS285 (but probably it is not LDS285)
6500c: LCD LS8303164 (SHARP) code 4850198 : more compatible with LDS285 (responding to DISCLK command properly)
E65: LCD LS022Q8UX04 (SHARP) : partial compatibility with LDS285

No one of them have built-in LED driver (no one responded to LEDCTRL command of LDS285)…

UPDATE:
It seems that these LCDs are compatible to this controller : http://hw.cz/files/redaktor130/MC2PA8201pdf.pdf

Using Tearing Line Output from Nokia LCD

Nokia LCDs mentioned in this blog has tearing line output feature. It can be used to synchronize MCU->LCD writes with LCD display memory scan pointer.
What for? To prevent showing partially content we want to write to LCD’s display RAM.

Problems :
A) your MCU should be fast enough to stream whole framebuffer to LCD within TE (Tearing Effect line output) pulse -> then, LCD read pointer won’t start scanning the frame before whole MCU->LCD transfer ends.
OR:
B) your MCU should be fast enough to stream whole framebuffer to LCD between n and n+2 TE pulses -> then LCD read pointer starts before write to LCD display memory occurs and write pointer will be always behind read pointer of LCD’s memory controller.

If your MCU isn’t fast enough to meet these requirements, tearing would always appear…

TE pulse width is given by LCD’s frame refresh rate (default ~60Hz).
At 60Hz frame scan time is about 16ms. Full frame is 320x240x3 bytes = 230400 bytes. To be able to write full framebuffer during two frame scan time (option B) your MCU should have data computation & throughput speed ~7 MB/s…
Well, it is impressive in the world of cheap and easy MCUs, even PIC32s 🙂

Using Nokia BB5 LCD with PIC32

Short brief :
source : http://www.elektroda.pl/rtvforum/topic1344700.html
help :
– Leadis reference to LDS285 : http://www.trulydisplays.com/tft/driveric/IC%20Spec%20LDS285.pdf
– Microchip toolz & CPUs
objective : using Nokia’s LCD with Microchips CPUs

Finally, objective achieved 🙂

Findings :
“Modern” BB5 Nokias are using MIPI’s MeSSI bus between MPU and LCD controller.
Although obtaining MeSSI specification from MIPI can be hard for hobbyist, bus is 100% compatible with popular 8080 Interface = Mode2 Parralel Master Port in PIC32… 🙂
LCDs of E51 or E65 are pin-to-pin compatible, many others (BB5-style) has the same pinout and connector.

Pros:
– 320x240x24bit LCDs
– integrated controller with DDRAM (no need to waste MPU RAM for storing display data)
– cheap solution (~8-10$ for a piece of glass)
– simple interface, really 🙂

Cons:
– such LCD require relatively high computational power

more info incoming soon…