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

Quote
user=dpffan

Since the dockstar doesn't have buttons, I want to 'borrow' the buttons from the Parrot to serve as input.
Will probaby need some glue code/shell script .

Great idea, I ordered a parrot two days ago and I want to do the same as yours. Can be parrot's buttons readed throught the input layer at /dev/input/eventx ???

it is not difficult to code a python script to listen at one of those events, performed by button inputs, and then run a custom script to communicate with remote server ( my pogoplug or your dockstar )

My idea is:

when the parrot-button is pushed the computer calls a bsd-socket client who tries to communicate with custom server on one of those non-ussed ports. the pogo, which is listening in this port for clients, acts changing the input of /dev/fb0 (changing the screen whole image). Working as a slideshow when button pressed.

programming in bsd sockets is not so difficult it you look at here first!!

When my parrot arrives I'll share my homework here...

pazos Wrote:
>
> Great idea, I ordered a parrot two days ago and I
> want to do the same as yours. Can be parrot's
> buttons readed throught the input layer at
> /dev/input/eventx ???
>
> it is not difficult to code a python script to
> listen at one of those events, performed by button
> inputs, and then run a custom script to
> communicate with remote server ( my pogoplug or
> your dockstar )
>

I did a quick hack of the original code by this blog author at pastebin.

Parrot

./button-input; echo $? | nc 172.16.61.3 3333

Dockstar

echo $(nc -lp 3333)

The program works by polling the GPIO ports for the button status , returns the button press with the exit code and uses netcat to relay the exit status over to the dockstar.

The guys at freenode #df3120 reported somebody is working on proper /dev/input/eventx support but that is WIP so this quick hack will suffice for now.

great! thanks for share

petergunn Wrote:
-------------------------------------------------------
> Expertsetup Wrote:
> --------------------------------------------------
> -----
> > If there is a way to use the AX206 units as a
> term
> > I would actually love to hack this as a
> comparison
> > of 2205 vs AX206, which seems interesting.
>
> I'll probably port st2205term at some point as
> the
> larger AX206 devices have a nice resolution/price
> but the two units I have are currently not
> supported
> by hackfin's hack.
>
> -PG


so did you :) ?

Nope - I think the devices I have are both still unsupported.

Parrot DF3120s seem to be the way to go for larger displays now :-)

-PG

petergunn Wrote:
-------------------------------------------------------
> Nope - I think the devices I have are both still
> unsupported.
>
> Parrot DF3120s seem to be the way to go for larger
> displays now :-)
>
> -PG
https://github.com/Xalior/DF3120, Xalior is doing some development work for an updated rootfs for the parrot and some simple apps.

hello,
I need help for this DPF, I need the setings for that flash, it´ a Winbond 25Q80, and the profiles.py don´t have inside the Winbond 25Q80 parameters !! it´s in linux hack !! in windows it´s the same error, flash not accept !!
wen I run the hack i have this:


Opening generic SCSI device '/dev/sg3'
Reading flash...
done
Found matching version info
Identifier: pearl
Now patching. There is no 100% guarantee that your device will
work after doing this. You must never unplug the device from USB while
it is being updated.
Are you sure you take all risks and that you want to continue?
Type 'yes' to continue > yes
Copying sector from 0x000000 to 0x1f0000...
Patching sector addr 1f0000 with jmptbl_pearl.ihx
Patching sector addr 180000 with fw_pearl.ihx
Analyzing module 37...
CRC32 does not match: 0x10b64e2b
DPF might not be completely patched.

I need the parametrs for that flash Winbond 25Q80!!
some one can help me ?

Hey, I just got my hands onto a 2.4 inch dpf (DigiView V240).
I haven't read about it being hackable anywhere.

my dmesg and lsusb results are pretty much the same as the ones from Factran.

but i haven't even been able to dump the firmware as it gives me a "Expected response 8 on cmd 1, got 0x20!" error.

seems that it really doesn't have the st2205 chip.

Hi guys,

after quite some inactivity on the ax206 DPF repository, I have synced up some changes, as announced on http://tech.section5.ch/news/?p=77. Sorry, this was due for months, but since noone really had contributed code, I was lazy..

In short:

• You can build the entire alternative firmware from scratch with free linux tool
• It is no longer required to hack the frame using the scripts (but you have to determine the screen type)
• Bricking is no more a problem, you can program almost all DPF flashes with the new HID bootloader support. Just hold MENU, press RESET and plug in to USB.

You'll find all up to date stuff here:

svn co https://dpf-ax.svn.sourceforge.net/svnroot/dpf-ax dpf-ax

Again, as noted in various places, please don't send requests like "Can you fix my DPF" or "Would you kindly program an mp3 encoder for me" :-). I simply have no time, so: read the source, Duke. And send in patches, if you like.

hackfin Wrote:
-------------------------------------------------------
> You'll find all up to date stuff here:
>
>

> svn co
> https://dpf-ax.svn.sourceforge.net/svnroot/dpf-ax
> dpf-ax
>

>
Thanks for making the effort to update the code for alternative firmware and HID bootmode.
But is restore.py mentioned in the README missing from source?

restore.py fw_<your DPF type>.bin -f

I presume it's calling bootload from bootload.c. Do we need the netpp source as well - it is referred to in the Makefile. Is this the dependency: http://www.section5.ch/netpp. Linked here

For changes to the Makefile to support other lcd types, are you referring to this line?

headers: ax206.h ax206.inc ili9163.h ili9320.h otm3225.h otm3225.inc 

dpffan Wrote:
> For changes to the Makefile to support other lcd
> types, are you referring to this line?
>

> headers: ax206.h ax206.inc ili9163.h ili9320.h
> otm3225.h otm3225.inc 
>

I found config.h, this is the equivalent/replacement in ver2.0develop for profiles.py from the earlier version?
There is support for 3 LCD controllers.

define LCD_CONTROLLER_ILI9163B
define LCD_CONTROLLER_ST77XX
define LCD_CONTROLLER_OTM3225
define LCD_CONTROLLER_ILI9325

But the header file for ST77XX is missing from source. though a strings command on lcd.lib revealed lcd_st77xx_init.rel.

dpffan Wrote:
> I found config.h, this is the
> equivalent/replacement in ver2.0develop for
> profiles.py from the earlier version?
> There is support for 3 LCD controllers.
>

> define LCD_CONTROLLER_ILI9163B
> define LCD_CONTROLLER_ST77XX
> define LCD_CONTROLLER_OTM3225
> define LCD_CONTROLLER_ILI9325
>

I think I figured it out, edit this line in Makefile

ifndef TYPE
TYPE = white
endif

to match the DPFMODEL definition in config.h
An example

#if defined (DPFMODEL_white)
#	define LCD_128x128
#	define LCD_CONTROLLER_ILI9163B
#	define LCD_ORIENTATION_RGB RGB_DOWN
#	define BUTTON_SWAP
#	define DEFAULT_ORIENTATION ROT_UP

Pending hackfin's upload of restore.py, I'll try this out soon.

Hi,

I've added some missing files to the repo (see fw/ folder).
netpp is used only to generate the header files from our internal XML database, you don't need it. I'm afraid that the XML stuff can't be currently opensourced, that's why all LCD stuff is packed into this lib for now. But you can easily write your own initialization routines and handlers, see "API" tag in lcd.h
I'm sorry I can't document this any further, time is simply running away :-(
But I'd be happy to grant other developers access to the repo.

Cheers,

- hackfin

Compiling to .rel was fine but linking to form the final main.ihx failed with a series of

?ASlink-Warning-Cannot open library module ./T 02 9F 00 00 00 8D 00 00 01 74 09 2A F8 86 03 74.rel
?ASlink-Warning-Cannot open library module ./R 00 00 00 16 F1 21 02 00 03 F1 21 06 00 03.rel
?ASlink-Warning-Cannot open library module ./T 02 A9 0A 2A F8 86 04 8C 05 E4 FC FE EB 42 04 EE.rel

and similiar errors. I messed with bootstrap.lnk , Makefile and attempted to resolve these but to no avail.

I will look at sdcc documentation closely to see if I can resolve them. A quick google didn't reveal anything.

Now that's very strange. It seems aslink is getting total garbage. Can you see what's in tmp.lnk? Looks like it is filed with hex crap from elsewhere. I have no clue though where this might happen. Did it work before?

Hi,

Just a checkout and an "make all" give me an error on the focal and focal_landscape firmware build :

Building focal
ar: creating libdpf.a
py_device.c: In function ‘Device_eraseflash’:
py_device.c:135:7: warning: unused variable ‘full’ [-Wunused-variable]

?ASlink-Warning-Undefined Global '_lcd_ili_setorientation' referenced by module 'init'
make[1]: *** [main.ihx] Erreur 2
cp: impossible d'évaluer « fw_focal.ihx »: Aucun fichier ou dossier de ce type
--------------------------------------
Building focal_landscape
ar: creating libdpf.a
py_device.c: In function ‘Device_eraseflash’:
py_device.c:135:7: warning: unused variable ‘full’ [-Wunused-variable]

?ASlink-Warning-Undefined Global '_lcd_ili_setorientation' referenced by module 'init'
make[1]: *** [main.ihx] Erreur 2
cp: impossible d'évaluer « fw_focal_landscape.ihx »: Aucun fichier ou dossier de ce type

If I remove focal and focal_landscape from src/buildall.sh, everything seems to be build.

My build env is up-to-date Debian SID AMD64 with sdcc 2.9.0
Any clue ?

Thanks.

etatto Wrote:
-------------------------------------------------------
> My build env is up-to-date Debian SID AMD64 with
> sdcc 2.9.0
> Any clue ?

Thanks etatto. Once I had the same version of sdcc, I had the same errors. I took one of the created fw bin file and attempted to flash. I had commented out the flash detect in restore.py

Found AX206 DPF (bootloader)
Erase full flash...
Reading USB: Resource temporarily unavailable
Traceback (most recent call last):
  File "fw/restore.py", line 32, in <module>
    flash_restore(d, data)
  File "fw/restore.py", line 12, in flash_restore
    d.eraseFlash() # erase full flash
SystemError: 146:(ffffff92): Unknown error

Seems like the 25Q80SCP that my ax206 dpf used is not supported. The openschemes folks have extended Windows's ProgSPI flashlib.ini with its definition. I guess I need to do the same for dpf-ax?

Hi.,

Have a loot at bootload.c and include/spiflash.h, if your flash uses other commands, you might have to implement an option and extend flash_probe_hid() for other flash support.
Most of the flashes I know should be compatible with the ST protocol though. I've only come across one flash that was different. Forgot where I put that DPF though..
Good luck,
- hackfin

hackfin Wrote:
-------------------------------------------------------
> Hi.,
>
> Have a loot at bootload.c and include/spiflash.h,
> if your flash uses other commands, you might have
> to implement an option and extend
> flash_probe_hid() for other flash support.
Luckily the problem proved to be much simpler once I looked at flash_probe_hid. I think the loading of spilib.bin failed due to path issues so I copied it everywhere - wasn't sure which folder it was supposed to be, relative to restore.py or libdpf.a or somewhere else.

Found AX206 DPF (bootloader)
Manufacturer: Apple
Size        : 1 MB
Erase full flash...
Flashing sector 0...
Flashing sector 1...
Executing applet..

I had a resulting white screen which I think is a sign of the wrong setting for the lcd?

@dpffan : Are you building everything without error or have you remove, like myself, the 2 focale firmware from the buildall.sh, which gave me build errors ?

@eatto: I have the same errors. To illustrate, the clue is in the binary blob lcd.lib

grep lcd_ot_setorientation *
init.c:	lcd_ot_setorientation(which);
lcd.h:void lcd_ot_setorientation(unsigned char which);
Binary file lcd.lib matches

But for the error

grep lcd_ili_setorientation *
init.asm:;	init.c:114: lcd_ili_setorientation(which);
init.asm:	lcall	_lcd_ili_setorientation
init.c:	lcd_ili_setorientation(which);
init.lst:                            918 ;	init.c:114: lcd_ili_setorientation(which);
init.lst:   00C1 12s00r00            921 	lcall	_lcd_ili_setorientation
init.rel:S _lcd_ili_setorientation Ref0000
init.rst:                            918 ;	init.c:114: lcd_ili_setorientation(which);
init.rst:   12C1 12 00 00            921 	lcall	_lcd_ili_setorientation
init.sym:    _lcd_ili_setorientation                                        **** GX
lcd.h:void lcd_ili_setorientation(unsigned char which);
main.map:  0C:0000    _lcd_ili_setorientation
main.map:?ASlink-Warning-Undefined Global '_lcd_ili_setorientation' referenced by module 'init'

lcd.lib is missing the definition for lcd_ili_setorientation.

Just ignore the lib_ili and focal build option stuff for now. I might check that in again, once I get it tested (need to get my hands on one of those focal frames first. Mine broke..)

Hi,

I am trying to re-compile firmware for pearl and always end up with a wrong screen size. I tried "TYPE = pearl" and "TYPE = pearl_landscape". Both versions compile and link fine. After flashing I get a partly red and blue screen with unreadable (mirrored?) text. Running "detect.py" detects the display but gives a screen size of 128x128.
The pre-compiled firmware from http://tech.section5.ch/files/fw_pearl_landscape.bin works perfectly.

Am I missing something?

superelchi

Hi superelchi,

you're not missing anything. It was a bug with precompiled values. Rev6 in the repo should now work with all frames in (almost) all modes.
Cheers
- hackfin

Thanks hackfin!

Pearl (portrait & landscape) working now!

superelchi

hackfin Wrote:
-------------------------------------------------------
> Hi,
>
> I've added some missing files to the repo (see fw/
> folder).
> netpp is used only to generate the header files
> from our internal XML database, you don't need it.
> I'm afraid that the XML stuff can't be currently
> opensourced, that's why all LCD stuff is packed
> into this lib for now. But you can easily write
> your own initialization routines and handlers, see
> "API" tag in lcd.h
Thanks, rev 6 is good and all versions of known lcd compile nicely. I also managed to restore to stock firmware with restore.py I'm trying to make sense of this code in lcd.h to support my lcd driver which is still not supported.

// API
#if LCD_WIDTH != LCD_HEIGHT
#	if (DEFAULT_ORIENTATION == ROT_RIGHT) || (DEFAULT_ORIENTATION == ROT_LEFT)
#		define disp_blit     MANGLE2(_INTERNAL_TAG, landscape, blit)
#	else
#		define disp_blit     MANGLE2(_INTERNAL_TAG, portrait, blit)
#	endif
#else
#	define disp_blit     MANGLE(_INTERNAL_TAG, blit)
#endif
#define init_sequence MANGLE(_INTERNAL_TAG, initseq)

void disp_blit(void);
extern __code unsigned char init_sequence[];

What is the structure of init_sequence values?
For example for ili9341, is it something like this? Ref: LCD Driver

const BYTE ILI9341_init[] = {
23, // 23 parameter sets

3,  INTERFACE_CONTROL,          0x01, 0x01, 0x00,
3,  UNDOCUMENTED_0xEF,    0x03, 0x80, 0x02,
3,  POWER_CONTROL_B,   0x00, 0xF2, 0xA0,
4,  POWER_ON_SEQUENCE_CONTROL, 0x64, 0x03, 0x12, 0x81,
5,  POWER_CONTROL_A,   0x39, 0x2C, 0x00, 0x34, 0x02,
2,  DRIVER_TIMING_CONTROL_B, 0x00, 0x00,
3,  DRIVER_TIMING_CONTROL_A,    0x85, 0x10, 0x7A,
1,  POWER_CONTROL_1,   0x21,    //VRH[5:0]  
1,  POWER_CONTROL_2,   0x11,    //SAP[2:0];BT[3:0]
2,  VCOM_CONTROL_1,    0x3F, 0x3C,
1,  VCOM_CONTROL_2,    0xC6,       // 0xD2
1,  PIXEL_FORMAT_SET,    0x55,
1,  MEMORY_ACCESS_CONTROL,  0x08,
2,  FRAME_RATE_CONTROL,   0x00, 0x1B,
2,  DISPLAY_FUNCTION_CONTROL, 0x0A, 0xA2,
1,  ENABLE_3G,     0x00,    // 3Gamma function disable
1,  GAMMA_SET,     0x01,    // Gamma curve selected
15, POSITIVE_GAMMA_CORRECTION, 0x0f, 0x24, 0x21, 0x0F, 0x13, 0x0A, 0x52, 0xC9, 0x3B, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00,
15, NEGATIVE_GAMMA_CORRECTION, 0x00, 0x1B, 0x1E, 0x00, 0x0C, 0x04, 0x2F, 0x36, 0x44, 0x0a, 0x1F, 0x0F, 0x3F, 0x3F, 0x0F,
0, WRITE_MEMORY,
0, SLEEP_OUT,  // exit sleep   
0xFF, 120,   // delay 120msec
0, DISPLAY_ON  // display ON
};

Are there any ways to identify LCD drivers for unsupported ones? Thanks for your effort.

Hi dppfan,

Initialization sequences look like

#include "mylcd.h" // These are the register defines of your LCD
#include "lcduser.h"

#pragma codeseg LCDAUX
#pragma constseg LCDAUX


__code unsigned char mylcd_initseq[] = {
        CMD_CS, CMD_CS,
        DELAY(10),
        CMD_RESET | LOW,
        DELAY(10),
        CMD_RESET | HIGH,
        DELAY(25),
        CMD(SleepOut),
        DELAY(20),
        CMD(FrameRateControl1),
                DATA(3), 2, 0x35, 0x36,

        /* fill in more initialization data */
        CMD_END

The command defines are found in lcduser.h

There are some ways to identify unknown LCDs, but it is a bit unreliable. You can send some kind of "READID" command to most LCDs and they will answer with a code. However, this is far from standard, moreover, the ID codes are in OTP which is often not even programmed by many display manufacturers.
So you can only guess from the command set (possibly from the disassembly) and by comparing with existing data sheets.

hackfin Wrote:
-------------------------------------------------------
> So you can only guess from the command set
> (possibly from the disassembly) and by comparing
> with existing data sheets.
Arvid left a comment at openschemes and this clue on identifying the lcd initialization code for the lcd.

To get the right screen driver for your DPF when building the SDK firmware:

1 Extract the firmware bin file from your DPF with Dermaik’s Dump Tool.
2 Search for 75 EC 00 53 EA E8 53 EB FD in the extracted file. This corresponds to the initialisation of the LCD port. The rest of the code should correspond to the initialisation sequence for your LCD. I used PowerGREP 4 to search for the code.
3 Disassemble the code and find the best match in LcdInit.asm or LcdInitTbl.asm files in the sub directories of DPF206_AllFunction\Lcd\. Most LCD chips seems to have many of the same control instructions, but the parameters differs. Make sure that the number of parameters for the commands SET_COLUMN_ADDRESS (0x2A) and SET_PAGE_ADDRESS (0x2B) matches sine these commands are used in OpenWin.asm and OpenWindow_Read.asm. I used a hex2bin tool to get the hex dump from PowerGREP into binary and DIS8051 for disassembly.
4 Copy the sub diretory and edit your LcdInit.asm or LcdInitTbl.asm in accordance with the disassembled sequence.
5 Update LcdComm.asm for your screen resolution
6 Edit DPF206_AllFunction\config.ini: add the line “export LCDDIR =” and insert a hash (‘#’) before the export for the currently enabled LCD in the section
7 build your firmware and load it onto your DPF

Now you should have a perfect picture, allthough I found that I could improve it by changing the gamma correction (commands 0×26, 0xE0 and 0xE1)

I will attempt to duplicate this in Linux with hexdump, grep and d52 and the earlier version of dpf-ax with the reverse scripts.

For the Coby firmware which I grabbed from openschemes, I found the 75 ec 00 53 ea e8 53 eb fd sequence at dump37.asm at offset 4963b.

X1330:	mov	_p3dir,#0x0	; 1330   75 ec 00   ul.
	anl	_p1dir,#0xe8	; 1333   53 ea e8   Sjh
	anl	_p2dir,#0xfd	; 1336   53 eb fd   Sk}
	clr	_LCD_CS		; 1339   c2 a1      B!
	clr	_LCD_RST	; 133b   c2 90      B.
	mov	a,#0x96		; 133d   74 96      t.
	lcall	X16b3		; 133f   12 16 b3   ..3
....

I assume everything before the ret instruction is the lcd initialization sequence? To use it in the alternative firmware for dpf-ax, I will need to write a new mylcd.c, mylcd.h and update the .lnk file? Thanks for any hints

hackfin Wrote:
-------------------------------------------------------
> Hi,
>
> I've added some missing files to the repo (see fw/
> folder).
> netpp is used only to generate the header files
> from our internal XML database, you don't need it.
> I'm afraid that the XML stuff can't be currently
> opensourced, that's why all LCD stuff is packed
> into this lib for now. But you can easily write
> your own initialization routines and handlers, see
> "API" tag in lcd.h
> I'm sorry I can't document this any further, time
> is simply running away :-(
> But I'd be happy to grant other developers access
> to the repo.
>
> Cheers,
>
> - hackfin

Hi hackfin,

dont't know if you have seen my firmware patches/mods to the 0.12devel over in the german vdr-portal. I would like to contribute a couple of things to the new 0.2 fw, like adding a splash-screen, change of usb-serial numer, etc. I've already implemented an additional - bigger - font and started with a little more "user friendly" menu (like the buildwin one). If you're interested, please let me know. You can reach me here or by my sourceforge-account ("superelchi").

superelchi