Today, support get an interesting question, how long is the VoCore lifetime?
I think this is an important question for the people want to use VoCore2 as part of their production.

As we promised, VoCore2 life is not end until the chip stop production. Mainly VoCore2 have three chips, one DDR2, one CPU, one NOR flash, DDR2 and NOR flash are widely used in many area, so we can think it will keep production forever. The only problem is CPU.

VoCore first version is using RT5350F which is almost stop production by mediatek/ralink. I said ‘almost’, because we still able to buy it from MTK(not recycle chip, the new one). The only problem is its price is increased a lot, almost double of MT7628.

Chip companies such as mediatek will not allow their chips suddenly death, that is not good for themselves and not good for their loyal clients. Normally mediatek will increase the chip price month by month if they decide to end one production. One day, the old chip price will be higher than the new one, so why pay much to use old slow one but not the new fast low power consume one? At that time people will start to upgrade their production. For RT5350, this process is over three years.

Actually VoCore old version is still in production, but price is much higher than the one based on MT7628. When RT5350F price is same as MT7628, I removed VoCore from site, because MTK is giving a clear signal: we are going to stop, do not use it anymore.

MT7628 is coming around four years, it still have over 10 years lifetime, so no need to worry about VoCore2 🙂
note: MTK is not stupid, why stop a cash cow? unless nobody use it already.:)

[embedyt] https://www.youtube.com/watch?v=s_GzLm7CrEk[/embedyt]

OK, littlevgl is working pretty well. 🙂
We should disable tab animate, that is really laggy.

I find many good library.

Actually directFB is an good choose but currently it can not compile at all.

First is the one from China, named GuiLite, it has everything I need and its code is really simple, performance is good.

Second is littlevgl, very good interface and light weight.

Third is uGFX, also light weight but not totally free, for test and study it is free.

4th, μGUI, it is too light weight for VoCore2 🙂

I like C better than C++, so I’d like to choose one from littlevgl & uGFX if no better find.

Now the screen is working, I need to find a good UI library for this screen.
Currently candidates are:

1. Qt embed.
2. SDL2.
3. miniGUI.

Qt embed consume a lot of memory and disk space, normally one application will take 10MB.
SDL2 is not designed for embed device UI.
miniGUI is a good project, but I did not use it before, might be hard to combine.

My display is true color and vocore2 has 128MB memory and cpu speed is good, can show beautiful user interface than the 51/ARM based single chip microcomputer. So maybe my best choice is Qt.

…but I am not sure if Qt is light enough to run on this, try first.

Qt has nice support to compile it 🙂
http://doc.qt.io/qt-5/embedded-linux.html#configuring-a-specific-device

Qt is based on DirectFB, looks like directFB.org is abandoned, source code still valid at github.

Maybe I can directly use directdb?

[embedyt] https://www.youtube.com/watch?v=3PT_6n-tnek[/embedyt]

mirror part of the display for windows, macos, linux.

Trouble, trouble… framebuffer can not work normal in VoCore2.
I guess openwrt has some limit of the /dev/ node size.

My plan of driver is like this:

Kernel Side                    User/Client Side            Display
Framebuffer (memory)  ->read   vodisp agent app     ->     libusb 
                      <-write  other framebuffer app

For max compatible and speed, I use Simple Framebuffer driver in Linux kernel. Actually it just a free memory space used to store video data.

vodisp is a simple server read from frame buffer and send data by libusb to USB screen. And other application depends on frame buffer can directly write to frame buffer.

This should work, but get weird issue. When I write 1152000 bytes to framebuffer, I find Linux is dead, looks like internal deadlock.

This is really critical bug, even though USB display is still working, but can not compilable with framebuffer app， that is a great lose.

[embedyt]https://youtu.be/RpzJ3UnTP6c[/embedyt]

I grab some frames from the famous movie “Beauty and Beast”, now it is clearly show the screen can play video so smooothly.

But nothing is that smooth… I get a bad news from my screen provider, the screen has out of stock, all I can get is eight units…

I have to order new samples from another provider, but the screen is customized, so not sure when I can get the mass production…

Bug fixed. Now it is stable 🙂
Test frame rate again, it is around 20~20.5fps, emm, it does not reach my target 24fps, still have space to optimize.

I send two pictures to the screen in a loop and use my phone record 5 seconds(slow motion), count frame by frame, it is 102 frames.

[embedyt]https://youtu.be/6zqGlMJCh9g[/embedyt]

Next step, write Linux driver and use frame buffer driver.

PS: looks like it is so smoothly from blog 1 to 6, step by step… actually the develop process is so painful and hopeless… I spend over two months full time on this. I had the thought of giving up over thousands times…
I can not go this far without my family’s encouragement.
Finally, the result is so beautiful, can not believe I made this! crying like a baby. T-T

Still picture, 50% chance works.

Moving picture, shit always happens. It is really moving, but it should show static still image.

[embedyt] https://www.youtube.com/watch?v=H_8iSRbW08Q[/embedyt]

PS: I use phone camera recorded 240fps video, and use ffplay count every frame, true 25fps and true 24bit color.

Hopefully I can fix it today. Looks like there are some data corrupt or timing issue. :p

The three days I have made a great process.

Backlight PWM control is working now and the screen can reach at least 24fps. I checked send 144 frames time is 5.8s.

This is a simple code I do the test:
first create three random pictures, and then use libusb bulk mode send it to the screen. Totally 48 loops and every loops send three “true color” pictures. Also a video of the test is attached.

#define FRAMESIZE		((unsigned int)800 * 480 * 3)

...


    buf1 = (unsigned char *)malloc(FRAMESIZE);
    for (i = 0; i < FRAMESIZE; i++)
        buf1[i] = (unsigned char)(rand() & 0xff);
    buf2 = (unsigned char *)malloc(FRAMESIZE);
    for (i = 0; i < FRAMESIZE; i++)
        buf2[i] = (unsigned char)(rand() & 0xff);
    buf3 = (unsigned char *)malloc(FRAMESIZE);
    for (i = 0; i < FRAMESIZE; i++)
        buf3[i] = (unsigned char)(rand() & 0xff);

    for(i = 0; i < 48; i++) {
        // send to out endpoint 2.
        code = libusb_bulk_transfer(handle, 0x02, buf1, FRAMESIZE, &trans, 1000);
        if (code) {
            printf("output endpoint2 error code: %d, %d\n", code, i);
            return code;
        }
        code = libusb_bulk_transfer(handle, 0x02, buf2, FRAMESIZE, &trans, 1000);
        if (code) {
            printf("output endpoint2 error code: %d, %d\n", code, i);
            return code;
        }
        code = libusb_bulk_transfer(handle, 0x02, buf3, FRAMESIZE, &trans, 1000);
        if (code) {
            printf("output endpoint2 error code: %d, %d\n", code, i);
            return code;
        }
    }

The screen is 80% done, I think I can fix rest bugs very soon 🙂

[embedyt]https://youtu.be/zA81GuyK6qY[/embedyt]