LCD screen for your dockstar (cheap! <$5)

OK, so it works with

export	LCDDIR = RFD128128

in the SDK's Config.ini. I've been able to build the FW and flash it, everything seems to work as it should, no LCD offset or garbled pixels, contrast and backlight is fine, too.

Here's the LcdInit.asm file for this screen type:
http://pastebin.com/us9V0D5t

sairon Wrote:
-------------------------------------------------------
> Thanks superelchi, that was quick!
> It woked (kind of) but the screen was too dark. I
> think the contrast settings are wrong or
> something.
>

Did you try to adjust the backlight (setup-menu)?

superelchi

Yes, but it made only a tiny (near to none) difference, the screen was still almost unreadable.

sairon Wrote:
-------------------------------------------------------
> Yes, but it made only a tiny (near to none)
> difference, the screen was still almost
> unreadable.

What about this fw? Better?

superelchi

Yep, that's much better. The only "bug" I can see is that the "eyes" image has some lines damaged at the bottom and they're white (not an issue with screen driver, when I choose solid black background it displays normally). However, this is only a small cosmetic bug, so not a big deal.
https://dl.dropbox.com/u/62238161/IMAG0119.jpg

Has anyone used these for something useful?

I am very tempted to buy one but have not seen a clear use for it yet. I still have a few projects I am having fun with these devices, and might need a new one soon.

optim Wrote:
-------------------------------------------------------
> Has anyone used these for something useful?
>
Most people will use the frames as lcd4linux displays. Some other forums use these as VDR LCD displays. st220term/ax206term allows the frames to be used as small terminals.

This wiki lists the other options.

I'm using de dpf with lcd4linux as a status-display on my device. The device being a (ohoh...) router with OpenWRT. Sorry about that; it not being a Dockstar. I'm a 'lurker' in this forum because of the amazing support of superelchi. Thanks very much for that. (edit: and off course petergunn and ax206geek)
The router is in use as a portable 3G-router/ WiFi-AP. The dpf shows some system-information about memory and cpu but above all info about the 3G-dongle (huawei); quality and usage per day and month because of the max. data-usage/month.
I have other embedded Linux projects running with LCD's that will be replaced by a dpf but that will be too much off-topic and even off-this-forum :)

Ed



Edited 1 time(s). Last edit at 06/25/2012 03:10AM by C4Vette.

Worklog of hacking AVLabs AVL969S which is a 1.5inch 128x128 ax206 frame.

python identify.py ~/avlabs-avl969s.bin 
Looking for firmware.............: Found (buildwin, 128x128 px).
Looking for known version info...: None.
Looking for Openwin..............:
OpenWin        at 0x1280 (0x000682), len 0x51, CRC = 0x2c33f515
Written to openwin_tmp.bin.
Looking for LcdIniTbl............:
Module 36:
LcdInit (Tbl)   at 0x14a2 (0x04a172)
Module 50:
LcdScheduleTbl  at 0x14c9 (0x04b675), len 0x00
LcdContrastTbl  at 0x14ca (0x04b676), len 0x09
LcdContrastTb2  at 0x14d4 (0x04b680), len 0x0b
LcdBacklightTbl at 0x14e0 (0x04b68c), len 0x16
LcdIniTbl       at 0x14f9 (0x04b6a5), len 0x70, CRC = 0x31fac453
Written to lcdinitbl_tmp.txt.
Looking for known signatures.....:
None.

Sorry, no matching dpf found.

The resultant firmware after hacking is attached to the post. The patch file to apply to revision 26 of dpf-ax is also attached.

The output of identify.py after patching:

python identify.py ~/avlabs-avl969s.bin 
Looking for firmware.............: Found (buildwin, 128x128 px).
Looking for known version info...: None.
Looking for Openwin..............: Found.
Looking for LcdIniTbl............: Found.
Looking for known signatures.....: Found.

Your dpf is compatible with model avlabs_avl969s.

Hi ax206geek,

committed your patch to SVN. Thx.

superelchi

BTW: nice to have an extra subforum for displays. Now we can stop using this spaghetti-thread and post new findings/questions in separate threads. Many thanks!



Edited 1 time(s). Last edit at 06/25/2012 05:11AM by superelchi.

@superelchi, thanks for the commit.

Can you explain a little on the latest changes to backlight in the code and how it works?

ax206geek Wrote:
-------------------------------------------------------
> Can you explain a little on the latest changes to
> backlight in the code and how it works?

I'll try - as far as I understand it. :-)

"Older" lcds (like the ones in pearl, focal, etc.) use a pwm-signal to control the backlight brightness. Here only the ratio between on and off time of the signal matters, frequency does not (more or less).

"Newer" lcds (like the ones in dx21334a/b or newer linkdelight dpfs) control backlight brightness by the frequency of the signal. If the signal frequency is outside the range the lcd needs, backlight will stay off.

Implementing this was a bit tricky, because hackfin uses the RTC (32,768 kHz) to generate the pwm signal. The needed frequency for the "newer" lcds is much higher, so I had to switch to sys-clock as signal source. Sys-clock has a base frequency of 24 MHz but can be doubled to 48 Mhz - what we do to speed things up a bit. If USB is disconnected (and the dpf runs on battery) the clock is reduced to 12 MHz to save power. The frequency tables extracted from the buildwin fw are based on 24 MHz, so frequency- and pwm-values have to be adjusted to the real sys-clock and recalculated on USB connect/disconnect. Thats why you can see a brief flicker if brightness is changed or USB is connected/disconnected. Also (because of rounding errors) there is a slight brightness difference between connected and disconnected USB. This flicker and brightness difference is not visible with the original buildwin fw. Haven't found out why up to now.

If you think, thats all - wait: my newest toy (this dpf) uses a pwm-signal but also the frequency must be in a certain range! Oh boy...

superelchi



Edited 1 time(s). Last edit at 06/27/2012 09:47AM by superelchi.

meltwater Wrote:
-------------------------------------------------------
> I kept getting
> sdcc: /usr/lib/libstdc++.so.6: version
> `GLIBCXX_3.4.15' not found (required by sdcc)
> When I tried to build and couldn't find a package
> to fix it (building on a Raspberry Pi, which is
> probably half the problem).


Hello, can you explain a bit as resolved, I have also an RPI and I can not run the LCD.

Thanks

superelchi Wrote:
-------------------------------------------------------
> If you think, thats all - wait: my newest toy
> uses a pwm-signal
> but also the frequency must be in a certain range!
Thanks for the detailed explanation but I have a feeling this is out of my depth...

superelchi Wrote:
-------------------------------------------------------

>
> What about this fw? Better?
>
> superelchi

@superelchi , did you ever get to committing the change to SVN for this LCD?

ax206geek Wrote:
-------------------------------------------------------
> @superelchi , did you ever get to committing the
> change to SVN for this LCD?

Ups, thought I've done that already. :-o
Will do it tomorrow togeteher with some other changes.

superelchi

Hey everyone!

@superelchi

I have a coby dp151bw. I've flashed coby_dp151_white, but I get a black screen. I also tried several other firmware images... agk_violet produces colored stripes. Perhaps this is a different version of the 151. Back on original firmware for now

dump of my original firwmare:

http://db.tt/QCoZMUeW

python identify.py full.bin
Looking for firmware.............: Found (coby, 128x128 px).
Looking for known version info...: None.
Looking for Openwin..............: Found.
Looking for LcdIniTbl............: None.
WARNING: This is no "standard" buildwin software!
Looking for known signatures.....: None.

Sorry, no matching dpf found.

superelchi Wrote:
-------------------------------------------------------
> But - as I said before: integrating dpflib in its
> current state into an existing project is really a
> mess (sorry again, hackfin). What we need is to
> convert libdpf to a shared library like
> "libdpf-ax.so". This shared lib and its headers
> can be installed to standard location like
> /usr/local/lib and /usr/local/include. Did a rough
> version of this a while ago, but never found the
> time to finish it (yet)...
>
> Only after this is done it makes sense to think
> about integrating it into lcd4linux svn.

There is already a copy of drv_dpf in lcd4linux svn. This patch seemed to be contributed by folks working on fli4l. In dpf-ax svn, python's makefile already calls this: include $(DEVLIB)/unixdll.mk and I've been copying libdpf.so from dockstar to Raspberry Pi.

@mrlinux

I do not have access to a decent computer atm. Vacation. :-)
Will have a look next week when I'm back.

superelchi

@superelchi

By all means, enjoy your vacation (:

I've been trying to figure it out myself but I get exotic looking errors when compiling the firmware for some reason. Fixed a few, so at least I'm getting some practice. Hopefully I'll have a few decent changes by the time you get back

Mrlinux

Finally got firmware to actually build for me. For the sake of google researchers, these were my problems:

1) A Makefile used "pyversions", which I don't have on my system. Edited the makefile to hardcode my python library directory as a workaround

2) My SDCC was too old, had to upgrade it to 2.9.0. Otherwise I was spammed with ASLINK errors

3) I did not have intelhex installed (https://launchpad.net/intelhex/)

4) flash.c gave a warning about a bad cast. Not sure if upgrading to SDCC 2.9.0 would have surpressed this error, but a change is at least required for SDCC 2.5. Line 216 of src/flash.c must be changed from

__idata BYTE *pi = ( BYTE *) &g_config;

to

__idata BYTE *pi = (__idata BYTE *) &g_config;

Now for the hard part... figuring out what to tweak to get my device working.

Mrlinux

superelchi Wrote:
-------------------------------------------------------
> No, sorry no working udev rule at hand. It was a
> request from users over at the i-have-a-dreambox
> forum. Never used different serials myself.
> But connecting more than one display works without
> an udev rule. Libdpf will access the first (by
> linux) detected display as "USB0", second one as
> "USB1", etc. The only problem is, that the order
> of detection may change on next reboot or
> if a display is connected/disconnected. I would
> guess that the detection order can be fixed with
> an udev rule and different serials (anyone done
> this?).
I walked the /sys/bus/usb/devices tree and by matching the device ID with dmesg output, figured out the udev syntax for serial no is ATTRS{serial}

ATTRS{idVendor}=="1908", ATTRS{idProduct}=="0102", ATTRS{serial}=="001"

After that you can invoke a specified program with PROGRAM , ie udev rules

Success! I got my coby dp151BW working with dpf-ax (:

Thanks go to hackfin, superelchi and whoever wrote support for coby_dp151_white and abeyerr_black, which I studied and compared with my firmware dump.

These should be the required files to make the dpf-ax firmware work correctly on a coby_dp151_BW:

http://db.tt/H0gtU2WC

Please add support for this device to the repo if possible. If there's anything else I need to patch for this to work with identify.py or whatever, please let me know.

Thanks.

Mrlinux

Hi everyone,

I have two small picframe-keychains bought to be used with lcd4linux. Both are based on the AX206 chip, so it's cool.

The first one comes from DX.com ( The 27893 ) so I was confident it would work. But it didn't, and had to follow the wiki instructions. Now it does. Attached is an archive with the non-modified firmware (but it's in Chinese I'm not really sure where it comes from, result of previous attempts), the custom firmware (disp and devel) and the source file. I'll try to make a patch later. The contrast is pretty bad, btw :/

The second one comes from eBay (can't remember the seller :/), no brand, no name, no mark on it and is not recognized:.

O_O 22:29:30 [redox@RedoX ~/dpf-ax/trunk]$ sudo python2 ./fw/identify.py /dev/sr2 
Detecting & reading dpf flash...
Opening generic SCSI device '/dev/sr2'
Manufacturer: Winbond
Size        : 1 MB
Reading 100000 bytes...
Flash written to file 'full.bin'.

Looking for firmware.............: Found (buildwin, 128x128 px).
Looking for known version info...: None.
Looking for Openwin..............:
OpenWin        at 0x1280 (0x000662), len 0x51, CRC = 0xa27e3c21
Written to openwin_tmp.bin.
Looking for LcdIniTbl............:
Module 36:
LcdInit !NOTBL! at 0x14a2 (0x049172)
Module 50:
LcdScheduleTbl  at 0x156d (0x04a7e3), len 0x00
Invalid LcdIniTbl!
None.
WARNING: This is no "standard" buildwin software!
Looking for known signatures.....:
None.

Sorry, no matching dpf found.

Backup and restore work. I've tried all the existing custom firmwares, there's only one that doesn't output a black screen it's "fw_disp_focalprice144.bin" which give just a yellow line (4-5 pixels high) at the bottom of the screen.

I'll try to reverse it (like MrLinux did with his coby dp151bw) but seems harder than the first one. If anyone has any idea/help, I'd be really thankful =)

Thanks a lot to everyone involved in this project !

@mrlinux
Thanks, will add coby_dp151_bw on next svn commit.

@RedoX
Thanks for dx27893_2. Will add this also on next commit.
Please try attached fw for your second dpf.

superelchi



Edited 1 time(s). Last edit at 07/24/2012 05:53AM by superelchi.

Well, one word: Awesome !!!

Thanks a lot, it works perfectly. (and contrast is much better than on my other DPF)

You're really doing a wonderful job with theses devices...

Thanks !

@RedoX

Could you try attached fw for your DX dpf? Contrast should be better...

superelchi

Well I didn't ask for more, everything was working but... you're really doing wonders, contrast is back to normal thanks to you =)

Can't wait to see the source to understand what you did. I hope you didn't waste too much time on this...

Many many thanks to you superelchi =)

Commited changes for new models to svn.

@RedoX
No wonder at all. Just patched lcdinit for your display to fix a flaw in current dpf-ax - contrast setting for displays is currently not supported out of the box. Working on it...

superelchi

Hi there,

does there exist a working hack for this display (dont know from where I bought it, long time ago...)?

root@debian:~/dpf-ax-trunk/trunk/fw# python detect.py /dev/sr0
Opening generic SCSI device '/dev/sr0'
Manufacturer: SST
Size        : 2 MB

[ 3001.039421] usb 1-1.3: new full-speed USB device number 7 using orion-ehci
[ 3001.203275] usb 1-1.3: New USB device found, idVendor=1908, idProduct=0102
[ 3001.210201] usb 1-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=0
[ 3001.217545] usb 1-1.3: Product: Digital Photo Frame
[ 3001.222477] usb 1-1.3: Manufacturer: BUILDWIN
[ 3001.240195] scsi2 : usb-storage 1-1.3:1.0
[ 3002.246487] scsi 2:0:0:0: CD-ROM            buildwin  Photo Frame     1.01 PQ: 0 ANSI: 2
[ 3002.263818] sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
[ 3002.274633] sr 2:0:0:0: Attached scsi CD-ROM sr0

root@debian:~/dpf-ax-trunk/trunk/fw# python identify.py full.bin
Looking for firmware.............: Found (buildwin, 128x128 px).
Looking for known version info...: None.
Looking for Openwin..............: Found.
Looking for LcdIniTbl............: Found.
Looking for known signatures.....: None.

Sorry, no matching dpf found.

Here is the full.bin: http://www.file-upload.net/download-4596736/full.bin.html



Thanks in advance