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.

Features

  1. Ultra small footprint of final product.
  2. Highly configurable microcontroller, boards and peripherals.
  3. An improvement version of Newlib from eCos RTOS.
  4. An improvement version of Nano-X with FLTK from Georg Potthast.
  5. Full internationalisation support, font engine is based on brand-new text encoding system and text rendering engine.
  6. Precompiled GNU cross-compiler toolchain with visual debugging environment.
  7. Pluggable OS alternatives: μC/OS-II, μC/OS-III, picoOS, NuttX, RTEMS, μClinux, ARM Linux.
Why another IDE for embedded system development?
  1. 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.
  2. 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.
  3. Why another libc?
    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.
  4. Why not Unicode and UTF-8?
    They are too big and stupid, utilized to fool people.
  5. 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.
  6. Why not directly debugging with gdb on terminal?
    Visual debugging feels good.
  7. Support OpenVG, e.g. NanoGUI?
    Yes, of course support if the system has a GPU.
References



Knowledge Transfer

The engine will be sold to an appropriate organisation or individual, in order to better carry out the maintenance, continuous development and distribution of the product. For deeply research, the buyer have full and flexible control of the engine. More details please contact us .