eCos on macOS

Packaged solution, with new libc and GUI, full stack for embedded system development.

The IDE for embedded system development based on QEMU and Microwindows (Nano-X). Ultra lightweight solution, make your development as flexible as possible, make your software as small as possible.
It is not just an embedded RTOS system, or another smartwatch platform, it is the infrastructure for next generation computer system, from 8-bit small embedded system to server cluster.
Brand-new text encoding system, text rendering and layout engine, and font engine, without Unicode data, no big font file.


Why another IDE for embedded system development?

* Why not Javascript, Node.js?
Actually they're heavy solution, not designedly suitable for realtime system. Pebble smartwatch is not as its appearance that concise lightweight as its inside because of V8 and Node.js that made it huge and bloated. JerryScript from Samsung is the solution for IoT is great but still fat. No one want to use Eclipse the famous Java IDE as a plain text editor. Lua is the world widely used embeddable scripting language that the complete runtime of it is less than 200KB. Small is beautiful, OSASK is a small operating system designed for x86 computers which only 80KB.

* Why not emWin, μCGUI or STemWin, or C/PEG, Qt/Embedded and Android/Skia?
They are too expensive or too big, just like IBM's ClearCase the famous SCM system is actually an expensive CVS.

* Why another libc?
First, we still need C runtime and C libraries. In fact, we've developed an advanced libc named elibc to support UTF-8 encoding that completely compatible with the interface defined in standard libc, but it has been deprecated. The traditional C Library and size reduced libraries by many vendors can not support the new designed text encoding system or even the UTF-8 encoding. They usually come with some very disgusting garbage files if they full support Unicode. About the Unicode garbage data files, please refer here and here. And most of the modern programming languages that be used in embedded systems also contain these disgusting data. They are not smaller enough, we need an advanced practical C runtime environment for embedded system or common Desktops.

* Why not Unicode and UTF-8?
They are too big and stupid, utilized to fool people.

* Why another text rendering engine?
Big font file is a bloated burden, e.g, mupdf is excellent and small, but the attached font files are really garbage, very big, about 40MB. Usually 5MB to 60MB size of the traditional font file is too big with the result that they're not suitable for embedded system or embedded in other software. Text rendering engine without big font file means store big font data in external storage device (e.g. EEPROM, SD card, Flash etc) is not necessary. On the other side, the widely used rasterizer lack the features, even in recent FreeType version 2.8.

* Why not directly debugging with gdb on terminal?
Visual debugging feels good.

* Support OpenVG, e.g. NanoGUI?
Yes, of course support if the system has a GPU.