WhyCan Forum(哇酷开发者社区)

价格如果能做到F1C100S那样，踢我一下。

内置硬件PNG解码？这个好评！不过价格多少？

把图片等资源跟代码分离，采用延迟加载方式，需要用到的时候才去加载到RAM。先把固件程序加载到RAM并EXEC，然后在用到图片的时候再读取到RAM中缓冲起来。

打字错了，是PhoenixGUI，我自己开发的一个GUI。

不计价格因素的话肯定NUC972更适合驱屏，GD32H7只有1M SRAM，怎么能玩得爽？NUC972有32M或者64M内存，这是专业驱屏的芯片。

100S驱屏还是很能打的。

能用C/C++开发吗？不能用C/C++开发的不看好。

现在客户要求产品必须用国产芯片，台湾产的都不行。国产芯片的春天来了。

想工业控制就专业工业控制，想驱屏幕就专业驱屏，性价比要突出，否则干不赢同行竞品。驱屏的话不要加那么多工业控制的东西提高了成本又用不上。

BOM不仅用来指示大小端还用来指示文本编码。开发过文本编辑器的都有体会，如果文本文件的开头没有BOM那么就只能靠猜，当然UTF8编码总是能够猜对的，因为它有自编码规则，但是ANSI CODEPAGE和UTF16就不是那么好猜了。编辑器每次都靠从头猜到尾来判断文本编码对效率来说也不好，假如编译器每打开一个源文件就要猜一次，那编译一个大工程也是够累的，当然有些编译器不愿意去猜，只承认ANSI编码。
顺便提一下，KEIL这个IDE以前是支持BOM的，到了5.x后好像取消了对BOM的支持，这样一来用户就变得不方便了。其实检测文件头的BOM只不过是几行代码的事情，我实在想不明白为什么他们不愿意支持这个功能。Win平台上的文本编辑工具绝大多数会支持BOM，连最简单的记事本都能够支持BOM，这才是以用户为中心的做法。

看到了你这个贴的内容，我彷佛又回到了多年前开发文本编辑器的时光。赶紧到网上搜索一下，发现很多下载网站竟然还在提供我开发的编辑器下载。
楼主热血沸腾勇气可嘉，祝楼主一切顺利！

@海石生风
我的话没矛盾啊？
“双缓冲仍然要等待垂直刷新同步的”
---这句话说出了避免画面撕裂的做法，需要在垂直刷新中断里更新画面内容，否则即使是双缓冲也仍然会造成画面撕裂的。
“只是GUI渲染好一帧以后不应该呆呆的等待垂直刷新中断的到来，应该把渲染好的FB放入队列，在垂直刷新中断里面更换屏幕FB地址”
---这句话说出了解决办法，就是在垂直刷新完成中断里由ISR来更换FB的地址，而不是让软件自己等待中断的到来。

不错的参考资料，感谢楼主开源。

听说SSD资料不开放，那没法玩。

@海石生风
话不能这么说的，RTOS相对于linux还是比较小规模的，规模小自然就比较好控制。linux核心和驱动崩溃了怎么保护？难道不一样的道理？

采用3缓冲VPOST硬件切换framebuffer，能用的。这芯片的主打功能就是门禁视频监控。最新的N9H26（N32926的马甲）的H264解码能力有了加强。

你越是不说我越是想知道，bing一下，原来GC9034=上海国芯。

好奇那个蒙圈开发板是什么来的？可以解释一下吗？

今日特意测试了一下这份代码，把它移植到了VC++上面跑了一下。
代码大致没有什么问题，但是建议考虑一下不同编译器之间的兼容性。
移植到VC上时为了方便把库代码改成了CPP后缀，并且改动了一些地方。
1、改成CPP是因为函数内变量声明位置比较随意，标准C不通过。
2、cg_array_ensure由宏改成了模板函数，因为VC++里面malloc需要强制转换。
3、min/max宏改了。
4、SW_FT_MSB用VC++的intrinsic改写了。
5、库代码当中所有malloc的地方加了强制类型转换。

libcg_test.zip

运行速度怎么样？可以跟lua比吗？

@达克罗德
目前多数GUI都只支持按下、移动、抬起这三个触摸事件，按道理在GUI层面并不耗时。建议检查底层的驱动程序，内置ADC和外置触摸IC的表现也会很不同。如果是内置ADC的话采样率、防抖算法都会有影响。我的经验是如果想画线不断点，坐标采样率需要每秒80-100次左右。

我手中的这份LVGL是8.1版本，这是它的硬件抽象层，可以看到它并没有对硬件加速很感兴趣，主要还是依赖软件来执行。
真正专业的HAL应该能够利用硬件矩形填充（包括阿尔法填充）、硬件BLT操作（包括blend），硬件像素格式转换（RGB565/ARGB888/YUV422等）、硬件2x2矩阵操作(旋转、缩放、平移、剪切等)、硬件光标等。如果硬件不支持那就用软件完成。

但是这些东西可能会提高驱动移植的难度，而且也提高了对资源的需求，所以LVGL优先选择了小巧的方向。LVGL还有一些分散的代码利用STM32/NXP的硬件加速，不过很不规范，所以我猜想他们会继续改版。

LVGL不支持这些东西不是它的错，它的定位是小资源硬件平台。1080P这种高分辨率场合还是不要为难它了，毕竟MPU不仅仅要做GUI绘制还要处理其它事务，Fill/Blend/BitBlt这些繁重的任务最好还是硬件来完成。

/**
 * Display Driver structure to be registered by HAL.
 * Only its pointer will be saved in `lv_disp_t` so it should be declared as
 * `static lv_disp_drv_t my_drv` or allocated dynamically.
 */
typedef struct _lv_disp_drv_t {

    lv_coord_t hor_res;         /**< Horizontal resolution.*/
    lv_coord_t ver_res;         /**< Vertical resolution.*/

    /** Pointer to a buffer initialized with `lv_disp_draw_buf_init()`.
     * LVGL will use this buffer(s) to draw the screens contents*/
    lv_disp_draw_buf_t * draw_buf;

    uint32_t full_refresh : 1;       /**< 1: Always make the whole screen redrawn*/
    uint32_t sw_rotate : 1;          /**< 1: use software rotation (slower)*/
    uint32_t antialiasing : 1;       /**< 1: anti-aliasing is enabled on this display.*/
    uint32_t rotated : 2;            /**< 1: turn the display by 90 degree. @warning Does not update coordinates for you!*/
    uint32_t screen_transp : 1;      /**Handle if the screen doesn't have a solid (opa == LV_OPA_COVER) background.
                                       * Use only if required because it's slower.*/

    uint32_t dpi : 10;              /** DPI (dot per inch) of the display. Default value is `LV_DPI_DEF`.*/

    /** MANDATORY: Write the internal buffer (draw_buf) to the display. 'lv_disp_flush_ready()' has to be
     * called when finished*/
    void (*flush_cb)(struct _lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p);

    /** OPTIONAL: Extend the invalidated areas to match with the display drivers requirements
     * E.g. round `y` to, 8, 16 ..) on a monochrome display*/
    void (*rounder_cb)(struct _lv_disp_drv_t * disp_drv, lv_area_t * area);

    /** OPTIONAL: Set a pixel in a buffer according to the special requirements of the display
     * Can be used for color format not supported in LittelvGL. E.g. 2 bit -> 4 gray scales
     * @note Much slower then drawing with supported color formats.*/
    void (*set_px_cb)(struct _lv_disp_drv_t * disp_drv, uint8_t * buf, lv_coord_t buf_w, lv_coord_t x, lv_coord_t y,
                      lv_color_t color, lv_opa_t opa);

    /** OPTIONAL: Called after every refresh cycle to tell the rendering and flushing time + the
     * number of flushed pixels*/
    void (*monitor_cb)(struct _lv_disp_drv_t * disp_drv, uint32_t time, uint32_t px);

    /** OPTIONAL: Called periodically while lvgl waits for operation to be completed.
     * For example flushing or GPU
     * User can execute very simple tasks here or yield the task*/
    void (*wait_cb)(struct _lv_disp_drv_t * disp_drv);

    /** OPTIONAL: Called when lvgl needs any CPU cache that affects rendering to be cleaned*/
    void (*clean_dcache_cb)(struct _lv_disp_drv_t * disp_drv);

    /** OPTIONAL: called to wait while the gpu is working*/
    void (*gpu_wait_cb)(struct _lv_disp_drv_t * disp_drv);

    /** OPTIONAL: called when driver parameters are updated */
    void (*drv_update_cb)(struct _lv_disp_drv_t * disp_drv);

    /** OPTIONAL: Fill a memory with a color (GPU only)*/
    void (*gpu_fill_cb)(struct _lv_disp_drv_t * disp_drv, lv_color_t * dest_buf, lv_coord_t dest_width,
                        const lv_area_t * fill_area, lv_color_t color);

    /** On CHROMA_KEYED images this color will be transparent.
     * `LV_COLOR_CHROMA_KEY` by default. (lv_conf.h)*/
    lv_color_t color_chroma_key;

#if LV_USE_USER_DATA
    void * user_data; /**< Custom display driver user data*/
#endif

} lv_disp_drv_t;

联阳的SDK资料很齐全，价格也可以，不过联阳也是只做大客户不跟散客玩的，比全志做的还严格。

lvgl的架构不适合高要求的场合，它明显是为了低端设备设计的。为了省内存和简化移植驱动架构显得很简陋，在低端设备上对RAM占用和代码体积非常敏感，那样做是可以理解的，但在高要求场合这简陋的驱动架构明显不够看了。

是不是因为linux系统的原因？在RTOS上有试过吗？

解压出错啊，楼主快赔钱！

有些跳转是为了让CPU刷新内部指令队列，跳一下它就会重新译码指令了。

反汇编破解应该不是很难，但是不知道有没有加壳或者加校验防修改，如果有这些东西就要花很多精力了。

rtos的优势是标准化开发流程，模块化的开发降低了开发难度从而提高软件质量。那些简单的工程一目了然也用不着这么讲究，但一个较复杂的工程不用rtos的话会让人第一时间对质量产生疑问。

可能楼主用的是SVG矢量图片。

这种花屏的问题是没有对CACHE执行同步操作，要么每次更新显示内容后执行一次sysFlushCache，要么将framebuffer地址的最高位置1（ |= 0x80000000），这是告诉N329x芯片不要CACHE这个地址指向的数据。

很讨厌那些人在技术论坛发表政治问题的帖子，污染技术论坛，现在想畅所欲言谈论技术都那么难。

好多这种贴都是虎头蛇尾，希望楼主与他们不一样。

源代码用的竟然是匈牙利表示法，我个人很喜欢这种表示法，看代码很轻松，一天要看大量代码的人会喜欢的。

华为不是神，研发IPC不会比别人干得更好的，就算好一点也不会是颠覆性的好。华为在谈软总线，就是利用通信实现总线HUB，把各种IOT设备集中起来，不知道他们有没有干成这件事。如果能够成功倒是很牛逼，IOT设备将会有一个统一的规范协作起来，不再使用零散的协议各自为政了。

我觉得linux能够成功离不开机遇，当年IBM等公司（也就是玩unix大型机的那帮家伙）需要一个能够降低成本的东西对抗微软的侵食，就像今天的智能手机对Windows市场的侵食，刚好遇到了linux，两者一拍即合。

C++本地编译的速度都那么慢了，解释C++的速度能让人满意吗？解释型C脚本的速度都比js/lua慢那么多，何况是C++？

在“ZLG致远电子”的视频号里有视频DEMO，AWTK GUI看起来不是很流畅，毕竟已经800M主频了。

虽然玩Windows编程很多年了，但是我一直对C#没有好感。Win10的计算器等小程序用C#重写以后启动都变得慢慢吞吞的。

电阻屏触摸采样率200有点浪费了，正常情况下80-120就能保证画线不断了。如果不需要画线等连续追踪坐标的操作，只需要点击操作，可以设定更低的数值。

精神上支持一个，创业不易

NVTFAT_API.pdf

文档来了。
不过新唐的裸机SDK代码很烂的，NVTFAT没有源代码而且还跟Nand Flash/SPI Flash/SD等驱动耦合得很严重，总之就是烂。

为啥要“wait 10 seconds”？

应该是用了FreeType显示矢量字体来做图标吧？

矢量字体可以上IconMoon网站(https://icomoon.io/app/#/select)免费定制，非常方便。
在主页点击右上角的“IcoMoon App"就进入编辑界面，默认进入”IcoMoon Free“免费图标集，也可以选择其他免费图标集，选择好需要的图标点击”Generate Font“就可以生成TTF字体文件。

试试这样：
CreateInfo.dwExStyle = WS_EX_TOOLWINDOW | WS_EX_CLIPCHILDREN;

“UI 描述文件和主题文件使用高效的二进制格式，解析在瞬间完成。”

随着版本迭代，直接使用二进制格式导致的版本兼容性问题会让你焦头烂额，维护成本大大增加。

N9H26不就是原来的N32926？
价格相比N32926有没有便宜了？

说慢的去看看新唐官方的裸跑DEMO。

clock()是啥？觉得这种sleep的实现效果很飘忽。

pdb文件可以不要的。

做串口屏如果没有USB device接口是很麻烦的，现在业界流行用USB下载工程。

我需要usb device接口，请问楼主的板可以提供这个接口吗？

开源的怎么禁？印度已经把RISC-V指令集作为国家指令集，怎么禁？
开源的东西只是一个引子，真正的成果是后面无私奉献的人不断做出贡献。

这种汇编语法太恶心了，还是觉得英特尔的汇编语法合理。