2

Please note: Even though I'm specifically talking about an RTOS called Embox here, and even though I'm talking about AVR/ARm, I think this question can be answered by anybody whose ever done a fair amount of C-based MCU programming.

Say I have an MCU running Embox on it. Now, I'd like to write 2 executables, and 1 static library (used by both programs) in C and deploy all three artifacts to the MCU/RTOS. I have a few very-similarly-related questions/concerns (hence my choice to make this one question instead of 4):

  • What formats of executables and libraries does Embox require, and how can I tell? EXE/SO?
  • How does one compile a C program into an executable/library format (again, perhaps EXE/SO) that is compatible with Embox? For instance, I'm on a Windows machine with GCC provided by MinGW. I don't think I'd be able to write a program for Linux and then deploy it to a Linux machine. I'd need a Linux machine for that. But if the machine I'm deploying to is a simple RTOS/MCU, how do I develop on one platform/architecture (Windows) and make binaries that are compatible on another?
  • How does one deploy the executables to the MCU such that the RTOS can run the 2 apps at startup?
  • How does a user interact with the RTOS? Shell/SSH/console?
3

What formats of executables and libraries does Embox require, and how can I tell?

Embox is a configurable OS and one can create separate kernel image and user application. But since MCU has rather small memory size, most embedded RTOSes including Embox link all software (kernel, apps etc.) to a single image by default.

How does one compile a C program into an executable/library format (again, perhaps EXE/SO) that is compatible with Embox?

You should setup make and a cross-compiler. Then you have to configure Embox (choose a desired template) with make confload-xxx. And finally build the image with a command make. After that you can find the image in a file ./build/base/bin/embox. Here is a short [getting started][1] page.

How does one deploy the executables to the MCU such that the RTOS can run the 2 apps at startup?

Although Embox creates a single image you can have several apps in it. Unlike most RTOSes in Embox you can have several main routines. This feature is enabled by using a special build system. Embox consists of set of modules and each module is described using a DSL language. There is an 'application' type of module. If a module is marked as an 'application' the build system strips main symbol away and replaces it with <package-name>_<module-name>_main. Also the build system adds the new symbol and the application name to a special applications registry, so that you can run your application from the Embox shell or in some other way.

How does a user interact with the RTOS? Shell/SSH/console?

Embox has a built-in shell and you can access it through UART (COM port), for example. Embox also has telnet and httpd apps which you can interact through. Also Embox has a port of sshd (with dropbear project), but I think it's not the easiest way to communicate with MCU.

4

What formats of executables and libraries does Embox require, and how can I tell?

By reading the documentation. Note that some (most?) kernels designed for embedded use might not even support loading executables from files. They may require applications to be compiled-in to the kernel image.

[...] how do I develop on one platform/architecture (Windows) and make binaries that are compatible on another?

This is called cross-compilation. Essentially, you need to install what's called a "toolchain" that will produce binaries in a target system. Compiling for the host system is just a special case. gcc specificially is of course designed to allow installation of multiple toolchains in different paths on the same system.

How does one deploy the executables to the MCU such that the RTOS can run the 2 apps at startup?

As mentioned above, the applications may be expected to be compiled-in to the kernel. You may be restricted to a single main() that would have to fork() and exec() to start a concurrent processes. For many microcontrollers, even processes can't be supported properly; only some form of kernel data protection exists. Usually you get only threads.

How does a user interact with the RTOS? Shell/SSH/console?

Usually just buttons and LEDs, until you hook up something like SPI that would allow you to communicate with a computer. On some development boards, it is supported to have a basic serial connection through a debugging (and programming) USB port. But the protocols used are usually specific to the application. Essentially, you get to program your own "shell" to run on the MCU that handles the commands and writes the output.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.