We have used "PEG", the C++ version, from Swellsoftware for many years. It is commercial software, not free, but the underlying screen driver can use just a pointer to graphics memory and they provide many sample drivers for different types of graphics hardware. We wrote our own custom driver(s) for our proprietary hardware, using the sample drivers as reference. We have always had some sort of RTOS, but I believe PEG+ can also operate without an OS.
By the time you incorporate some third party solution you could have just written it yourself.
For most if not all environments the screen is just a two dimensional array of pixels. Sometimes palletized sometimes not, but that doesnt matter, you can write yours however you want.
There is tons of free code out there for drawing lines and arcs, etc.
The killer may be fonts but I think you will find that a third party app will chew up all of your memory just doing fonts, you are resource limited so you will want to pre-compute the fonts and just copy the bits.
Make a two dimensional array of data, do all of your work on your favorite host at first, it is trivial to save .bmp files if you want to see what you are drawing, and trivial to turn a series of .bmp files into a video if you want to watch some action.
If you use generic C, and no libc calls (write your own memcpy, memset, etc) this code will run anywhere, on the host for development and on the target.
Fonts are going to be your killer you have to pre-compute them but manage to squeeze that info down into as small as you can, and at runtime extract the data and copy the bits for each letter into the virtual screen as fast as you can.
Or just buy one of the many lcd solutions that do all of this for you and you simply send it commands like draw "Hello World!" at some (x,y) using blue as the foreground and white as the background.
Basically I think the non-os solutions are still going to use too many libraries and be too big for your specific application. 2d arrays of bytes or pixels are trivial to manage yourself. Even if you are writing an application for a desktop platform I would do it this way and at the last minute copy the fully renedered screen update to some os dependent library (allows for maximum portability from one OS or not to another).
If your requirements for interactivity and GUI widgets are very modest (or you're OK with designing your own widgets), have a look at LibGD. Draw the image you want to appear on the screen using the library's functions, and then write it to the frame buffer using gdImagePngToSink().
The important thing you should be concerned about is the controller of the LCD and touchscreen. There is an abundance of C libraries (not free) for that task. A quick google got me these results: Simplify Technologies and Ramtex.
If you want to find something open source, then start from your controller's type and search embedded devices forums (even if it isn't ARM, you could easily port C code). Some suggestions:
Also, some kit manufactures offer an SDK (both with and without Linux) with their boards. Purchasing a board usually gives you the license to use the code. Search for development boards with the same LCD controller.
Not free, but good on low resource systems: http://www.tat.se and their products Kastor and Cascades. It only requires a pointer to video memory, malloc and something that looks like a file system. The last two requirements are not absolutely necessary either. No operating system is required.
For the smallest possible footprint you should really consider RamTEX. I have used it on two projects with 8-bit PICS. The ROM space was about 35K in my applications with ~1K for RAM (amount depends on whether you need RAM buffering for the display). ROM space depends on the graphical features you want or need.
They provide full source and the one-time price is quite good, less than $1000 (note that the prices listed on their web site have to be converted to dollars, or whatever your currency is). There are no royalties or per-product restrictions.
They provide a number of different size and style fonts and basic drawing calls (line, pixels, box, etc.). It does not have any defined "objects" such as buttons or menus, but I was able to implement a pop-up menu without too much trouble. It does support "viewports" that can be used to define text boxes, menus, etc, each with their own attributes.
It also comes with a simulator that runs on a PC so you can develop display code on your desktop before moving to an embedded system.
You probably need to compress fonts using Run Length Encoding (RLE). See the .pcx file format for examples, although it's probably best to design a custom RLE. You didn't specify the bit depth of the LCD, but fonts need either one bit per pixel if antialiasing isn't needed, or a maximum of three BPP with antialiasing. Every character has to have it's own width because monospaced text is not nice. You should render directly from the RLE compressed font to the screen, using an optimized routine.
SDL is a very portable graphics libary. It's used in embedded Linux systems, but I think it can be used without an OS. The nice thing about SDL is that you can use Windows / Linux to develop and test your UI, and later target your embedded system. No changes to application code needed!
You could also use the Anti-Grain Geometry library (http://www.antigrain.com/about/index.html) on top of SDL. With a 16 or 24 bit LCD it produces stunning graphics. It might be just a bit too large for your environment, because my executable on a ARM/Linux system was about one megabyte. It contained SDL, AGG and libfreetype2 for font rendering. AGG is also a little slow, but produces beautiful results.
(old question, but I wanted to post my findings on the subject)
For high-quality graphics, Anti-Grain Geometry is a good choice. It compiles to about 50kB and can be customized to write into all kinds of framebuffers and rendering devices: http://www.antigrain.com/
For user interface, Gwen appears a good choice. It is easily portable and can be customized to render either bitmap skinned controls or just rectangle/circle/line forms: https://github.com/garrynewman/GWEN
Then if you are also selecting an RTOS, NuttX has it's own graphics subsystem and widget toolkit: http://nuttx.sourceforge.net/
My guess is that something like FreeDOS, combined with DJGPP as a toolchain, and Allegro as a graphics library might conceivably fit into 512k of flash and still do a reasonable job (I'm assuming you have an x86 which has several Mb of ram here)
But these things are very x86 specific (Allegro is not though).
It is tricky to get a Linux kernel and a useful amount of userspace software inside 512k (but possible to get SOMETHING in)
easyGUI is a GUI graphics software/library specifically designed to work on small(er) Embedded Systems.
No operating system needed. A basic cyclic executive is enough. 512kb of Flash should be more than OK. The library easyGUI provides is very flexible in helping to minimize the amount of Flash you need.
Supports fonts, graphics, bitmaps, touch screens and a bunch of video controllers out of the box.
Plus it is really cheap (no licensing fees, just a flat amount per seat) and comes with a PC program to design screens and generate code. The PC program takes a while to get used to but in the end it is very nice to try certain things out on the PC and then just generate and watch it run on your target.
They have a demo app on their website. It is worth checking it out.
发布评论
评论（11）
我们多年来一直使用 Swellsoftware 的“PEG”（C++ 版本）。 它是商业软件，不是免费的，但底层屏幕驱动程序可以仅使用指向图形内存的指针，并且它们为不同类型的图形硬件提供了许多示例驱动程序。 我们使用示例驱动程序作为参考，为我们的专有硬件编写了自己的自定义驱动程序。 我们一直都有某种 RTOS，但我相信 PEG+ 也可以在没有操作系统的情况下运行。
在这里查看：http://www.swellsoftware.com/
祝你好运，
We have used "PEG", the C++ version, from Swellsoftware for many years. It is commercial software, not free, but the underlying screen driver can use just a pointer to graphics memory and they provide many sample drivers for different types of graphics hardware. We wrote our own custom driver(s) for our proprietary hardware, using the sample drivers as reference. We have always had some sort of RTOS, but I believe PEG+ can also operate without an OS.
Check it out here: http://www.swellsoftware.com/
good luck,
当您合并一些第三方解决方案时，您可能已经自己编写了它。
对于大多数（如果不是全部）环境，屏幕只是二维像素阵列。 有时托盘化有时不托盘化，但这并不重要，你可以随心所欲地写你的。
有大量的免费代码用于绘制直线和弧线等。
杀手可能是字体，但我认为您会发现第三方应用程序会耗尽您所有的内存，只是做字体，您的资源有限，所以您会想要预先计算字体并复制这些位。
制作一个二维数据数组，首先在您最喜欢的主机上完成所有工作，如果您想查看正在绘制的内容，保存 .bmp 文件很简单，将一系列 .bmp 文件转换为一个如果您想观看一些动作，请观看视频。
如果您使用通用 C，并且没有 libc 调用（编写您自己的 memcpy、memset 等），则此代码将在任何地方运行：在开发主机上和目标上。
字体将成为你的杀手，你必须预先计算它们，但设法将这些信息压缩到尽可能小，并在运行时提取数据并将每个字母的位尽快复制到虚拟屏幕中。
或者只需购买为您完成所有这些操作的众多液晶解决方案之一，您只需向其发送诸如绘制“Hello World！”之类的命令即可。 在某些 (x,y) 处使用蓝色作为前景，白色作为背景。
基本上，我认为非操作系统解决方案仍然会使用太多的库，并且对于您的特定应用程序来说太大。 字节或像素的二维数组很容易管理。 即使您正在为桌面平台编写应用程序，我也会这样做，并在最后一刻将完全重新渲染的屏幕更新复制到某些操作系统相关库（允许从一个操作系统或不允许到另一个操作系统的最大可移植性）。
By the time you incorporate some third party solution you could have just written it yourself.
For most if not all environments the screen is just a two dimensional array of pixels. Sometimes palletized sometimes not, but that doesnt matter, you can write yours however you want.
There is tons of free code out there for drawing lines and arcs, etc.
The killer may be fonts but I think you will find that a third party app will chew up all of your memory just doing fonts, you are resource limited so you will want to pre-compute the fonts and just copy the bits.
Make a two dimensional array of data, do all of your work on your favorite host at first, it is trivial to save .bmp files if you want to see what you are drawing, and trivial to turn a series of .bmp files into a video if you want to watch some action.
If you use generic C, and no libc calls (write your own memcpy, memset, etc) this code will run anywhere, on the host for development and on the target.
Fonts are going to be your killer you have to pre-compute them but manage to squeeze that info down into as small as you can, and at runtime extract the data and copy the bits for each letter into the virtual screen as fast as you can.
Or just buy one of the many lcd solutions that do all of this for you and you simply send it commands like draw "Hello World!" at some (x,y) using blue as the foreground and white as the background.
Basically I think the non-os solutions are still going to use too many libraries and be too big for your specific application. 2d arrays of bytes or pixels are trivial to manage yourself. Even if you are writing an application for a desktop platform I would do it this way and at the last minute copy the fully renedered screen update to some os dependent library (allows for maximum portability from one OS or not to another).
如果您对交互性和 GUI 小部件的要求非常适中（或者您可以设计自己的小部件），请查看 LibGD。 使用库的函数绘制想要在屏幕上显示的图像，然后使用 gdImagePngToSink() 将其写入帧缓冲区。
If your requirements for interactivity and GUI widgets are very modest (or you're OK with designing your own widgets), have a look at LibGD. Draw the image you want to appear on the screen using the library's functions, and then write it to the frame buffer using gdImagePngToSink().
您应该关心的重要事情是液晶显示屏和触摸屏的控制器。 有大量的 C 库（不是免费的）可以完成该任务。 快速谷歌给我带来了这些结果：简化技术和Ramtex。
如果你想找到开源的东西，那么从你的控制器类型开始，搜索嵌入式设备论坛（即使它不是 ARM，你也可以轻松移植 C 代码）。 一些建议：
此外，一些套件制造商在其主板上提供了 SDK（无论是否带有 Linux）。 购买主板通常会授予您使用代码的许可。 搜索具有相同 LCD 控制器的开发板。
The important thing you should be concerned about is the controller of the LCD and touchscreen. There is an abundance of C libraries (not free) for that task. A quick google got me these results: Simplify Technologies and Ramtex.
If you want to find something open source, then start from your controller's type and search embedded devices forums (even if it isn't ARM, you could easily port C code). Some suggestions:
Also, some kit manufactures offer an SDK (both with and without Linux) with their boards. Purchasing a board usually gives you the license to use the code. Search for development boards with the same LCD controller.
不是免费的，但适用于低资源系统： http://www.tat.se 及其产品 Kastor 和级联。 它只需要一个指向视频内存的指针、malloc 和一些看起来像文件系统的东西。 最后两个要求也不是绝对必要的。 不需要操作系统。
Not free, but good on low resource systems: http://www.tat.se and their products Kastor and Cascades. It only requires a pointer to video memory, malloc and something that looks like a file system. The last two requirements are not absolutely necessary either. No operating system is required.
为了获得尽可能小的占地面积，您应该真正考虑 RamTEX。 我已经在两个 8 位 PICS 项目中使用了它。 在我的应用程序中，ROM 空间约为 35K，RAM 约为 1K（数量取决于显示是否需要 RAM 缓冲）。 ROM 空间取决于您想要或需要的图形功能。
他们提供完整的源代码，一次性价格相当不错，不到 1000 美元（请注意，他们网站上列出的价格必须转换为美元，或者任何您的货币）。 没有版税或每个产品的限制。
它们提供了许多不同大小和样式的字体以及基本的绘图调用（线条、像素、框等）。 它没有任何定义的“对象”，例如按钮或菜单，但我能够轻松实现弹出菜单。 它确实支持“视口”，可用于定义文本框、菜单等，每个视口都有自己的属性。
它还配备了一个在 PC 上运行的模拟器，因此您可以在迁移到嵌入式系统之前在桌面上开发显示代码。
For the smallest possible footprint you should really consider RamTEX. I have used it on two projects with 8-bit PICS. The ROM space was about 35K in my applications with ~1K for RAM (amount depends on whether you need RAM buffering for the display). ROM space depends on the graphical features you want or need.
They provide full source and the one-time price is quite good, less than $1000 (note that the prices listed on their web site have to be converted to dollars, or whatever your currency is). There are no royalties or per-product restrictions.
They provide a number of different size and style fonts and basic drawing calls (line, pixels, box, etc.). It does not have any defined "objects" such as buttons or menus, but I was able to implement a pop-up menu without too much trouble. It does support "viewports" that can be used to define text boxes, menus, etc, each with their own attributes.
It also comes with a simulator that runs on a PC so you can develop display code on your desktop before moving to an embedded system.
您可能需要使用运行长度编码 (RLE) 来压缩字体。 请参阅 .pcx 文件格式的示例，尽管最好设计自定义 RLE。 您没有指定 LCD 的位深度，但如果不需要抗锯齿，字体需要每像素一位，或者在抗锯齿时最多需要 3 BPP。 每个字符都必须有自己的宽度，因为等宽文本不太好。 您应该使用优化例程直接从 RLE 压缩字体渲染到屏幕。
SDL 是一个非常便携的图形库。 它用于嵌入式Linux系统，但我认为它可以在没有操作系统的情况下使用。 SDL 的好处是您可以使用 Windows / Linux 来开发和测试您的 UI，然后再针对您的嵌入式系统。 无需更改应用程序代码！
您还可以使用 Anti-Grain Geometry 库 (http://www.antigrain.com/about /index.html）位于 SDL 之上。 借助 16 或 24 位 LCD，它可以产生令人惊叹的图形。 对于您的环境来说，它可能有点太大了，因为我在 ARM/Linux 系统上的可执行文件大约为 1 MB。 它包含用于字体渲染的 SDL、AGG 和 libfreetype2。 AGG 也有点慢，但会产生漂亮的结果。
You probably need to compress fonts using Run Length Encoding (RLE). See the .pcx file format for examples, although it's probably best to design a custom RLE. You didn't specify the bit depth of the LCD, but fonts need either one bit per pixel if antialiasing isn't needed, or a maximum of three BPP with antialiasing. Every character has to have it's own width because monospaced text is not nice. You should render directly from the RLE compressed font to the screen, using an optimized routine.
SDL is a very portable graphics libary. It's used in embedded Linux systems, but I think it can be used without an OS. The nice thing about SDL is that you can use Windows / Linux to develop and test your UI, and later target your embedded system. No changes to application code needed!
You could also use the Anti-Grain Geometry library (http://www.antigrain.com/about/index.html) on top of SDL. With a 16 or 24 bit LCD it produces stunning graphics. It might be just a bit too large for your environment, because my executable on a ARM/Linux system was about one megabyte. It contained SDL, AGG and libfreetype2 for font rendering. AGG is also a little slow, but produces beautiful results.
（老问题，但我想发布我在该主题上的发现）
对于高质量图形，反颗粒几何是一个不错的选择。 它编译后约为 50kB，可以自定义写入各种帧缓冲区和渲染设备：
http://www.antigrain.com/
对于用户界面，Gwen 似乎是一个不错的选择。 它易于移植，并且可以自定义以渲染位图皮肤控件或仅渲染矩形/圆形/线条形式：
https://github.com/garrynewman/GWEN
然后，如果您还选择 RTOS，NuttX 有它的自己的图形子系统和小部件工具包：
http://nuttx.sourceforge.net/
(old question, but I wanted to post my findings on the subject)
For high-quality graphics, Anti-Grain Geometry is a good choice. It compiles to about 50kB and can be customized to write into all kinds of framebuffers and rendering devices:
http://www.antigrain.com/
For user interface, Gwen appears a good choice. It is easily portable and can be customized to render either bitmap skinned controls or just rectangle/circle/line forms:
https://github.com/garrynewman/GWEN
Then if you are also selecting an RTOS, NuttX has it's own graphics subsystem and widget toolkit:
http://nuttx.sourceforge.net/
我的猜测是，像 FreeDOS 这样的东西，与作为工具链的 DJGPP 和作为图形库的 Allegro 相结合，可能适合 512k 闪存，并且仍然可以完成合理的工作（我假设您有一个 x86，这里有几 Mb 的内存） ）
但是这些东西是非常特定于 x86 的（Allegro 不是）。
在 512k 内获取 Linux 内核和大量有用的用户空间软件是很棘手的（但可以获取一些东西）
My guess is that something like FreeDOS, combined with DJGPP as a toolchain, and Allegro as a graphics library might conceivably fit into 512k of flash and still do a reasonable job (I'm assuming you have an x86 which has several Mb of ram here)
But these things are very x86 specific (Allegro is not though).
It is tricky to get a Linux kernel and a useful amount of userspace software inside 512k (but possible to get SOMETHING in)
您应该尝试一下easyGUI。
easyGUI 是一个 GUI 图形软件/库，专门设计用于小型嵌入式系统。
无需操作系统。 一个基本的循环执行器就足够了。 512kb 的 Flash 应该足够了。 easyGUI 提供的库非常灵活，有助于最大限度地减少您所需的 Flash 数量。
支持字体、图形、位图、触摸屏和一堆开箱即用的视频控制器。
另外，它非常便宜（没有许可费，每个席位只需固定金额），并附带一个用于设计屏幕和生成代码的 PC 程序。 PC 程序需要一段时间来适应，但最终在 PC 上尝试某些东西然后生成并观察它在目标上运行是非常好的。
他们的网站上有一个演示应用程序。 值得一试。
You should give easyGUI a try.
easyGUI is a GUI graphics software/library specifically designed to work on small(er) Embedded Systems.
No operating system needed. A basic cyclic executive is enough. 512kb of Flash should be more than OK. The library easyGUI provides is very flexible in helping to minimize the amount of Flash you need.
Supports fonts, graphics, bitmaps, touch screens and a bunch of video controllers out of the box.
Plus it is really cheap (no licensing fees, just a flat amount per seat) and comes with a PC program to design screens and generate code. The PC program takes a while to get used to but in the end it is very nice to try certain things out on the PC and then just generate and watch it run on your target.
They have a demo app on their website. It is worth checking it out.
512kb 很小。 祝你好运！
您可能想尝试将 dsl 与 mplayer. 后者不需要 GUI 来显示电影。 我猜它还可以显示图像。
尽管如此，我担心这对你的闪光灯来说太过分了。 也许这些链接的来源会有所帮助。
512kb is small. Good luck!
You might want to try a dsl combined with mplayer. The latter does not need a GUI to display a movie. I guess it could also display images.
Nonetheless I fear it will be too much for your flash. Maybe the source of these links will help.