From time to time we receive emails asking about our embedded system support: do we support this operating system or that architecture or an unusual compiler?
The usual answer to these questions is a simple yes: ASN1C and XBinder support most embedded configurations. Usually we need to know a bit about the target system configuration to make a firm answer:
- the host and target operating systems
- the target architecture and ABI
- the target compiler and, if applicable, the C runtime library
- any special build options
Our local resources are usually sufficient to make a custom build, though it's often useful to be pointed to a freely-available compiler to make sure that no unexpected complications arise.
In this way we have built embedded libraries for all of our target languages (C/C++, C#, and Java) across multiple architectures and operating systems: Android, iOS, different versions of embedded Linux, NIOS2, QNX, Symbian, Windows CE, and vxWorks for ARM, MIPS, PowerPC, SH3/4, Xscale, and others. Some of our customers have also adapted our libraries for use with custom operating systems and compilers, too.
From the beginning we have written our runtime libraries with a "least common denominator" philosophy that minimizes the use of features that would compromise their portability across different systems, and that explains in no small part why they have found widespread adoption among diverse platforms.
We write our C runtime libraries in ANSI-compliant C, and our generated code is also ANSI compliant. As a consequence, the same code that runs on an iPhone or iPad may be used without modification on Android and Windows—and pretty much everything else in between. And while most of our sales for embedded systems target C and C++, we also produce CLDC-compliant versions of our Java runtime library alongside the same one that runs under Android using the Dalvik VM. Our C# libraries have been used in a variety of compact configurations, too.
If you're exploring the use of ASN.1 on your embedded systems, we'd advise you to take some time to precisely describe your development and deployment platforms. We have found two significant barriers in the delivery of embedded kits:
- The same vocabulary is often used for different instruction set architectures—ARM is a great example of this, since it is a family of architectures. Some implementations, for example support only software floating point, while others support hardware and even vector floating point operations.
- Compilers vary in their adherence to standard APIs; commonly their libraries exclude POSIX or Windows sockets, for example, or standard calls for obtaining the time and date.
In each case, our build options change to provide a compatible kit.
If you're curious about your own configuration, let us know: we'll be glad to talk to you about it.