Simultaneously running more than one sample application

Environment: ConnectEM Development Board

A theoretical question for a real world problem…

Suppose I need to run two sample applications on the board simultaneously (for arguments sake let’s say naftpapp and naserial).

Can I do this by running the two applications completely separately, as two separate processes?

If yes, how is this done?

If no, do I need to effectively write one application that combines the functionality of both naftpapp and naserial together?

Or, is the solution to write the functionality of naftpapp and naserial into separate threads?

Thanks for any input.

Let me guess…you’re new to programming???

The three questions you are asking are essentially the same question. If you need an application which encompasses the features provided by the two mentioned applications, simply merge the source code together. With NET+OS we are talking about a multi-threaded operating system.

You will end up with an new application containing seperate threads for the FTP and serial functionality.

Sounds like you might be in need of a good book on embedded programming, or perhaps a programming book in general. I can recommend a couple of good ones if you are interested. You could, perhaps, even read the documentation that is provided with the development kit.


> Let me guess…you’re new to programming???

Ok a fair response given how I phrased the question.

(I have about 10 years experience developing for non-embedded UNIX and Linux targets and a couple of years experience writing to an embedded Linux target. I am new to developing in a NET+OS environment.)

I realize that in a general context your reponse is correct – that any of the methods I suggested result in the same end result. It’s just a question of design.

On a previous embedded Linux system on which I worked, to start separate processes one simply started the processes (“applications”) at startup. No threads were necessary.

But, if I understand with NET+OS, the image which runs on startup has one location for starting applications (by applications I mean for example naftpapp). All applications are started from applicationStart().

Since there is only one applicationStart() point in an image.bin file, in order to have (for example) the two sample applications run simultaneously, they must each be started as separate threads.

Or, is there alternative?

I appreciate any input. Thanks.

The function applicationStart() is where your application begins. This is where you will spawn all of the threads that make up your end application.

Take a look at any of the example applications that make use of the function/macro tx_thread_create(). This is the primary function which ‘kicks’ off a new thread.

Another good example is the Digi Weather Station ( The source code for this demo can be requested via the URL:

The weather station makes use of several application threads.

My recommendation is to start by running and looking at the source for the various example applications provided. Then review the various provided documents, starting with the NET+OS 6.3 Programmer’s Guide (GNU) followed by NET+OS 6.3 BSP Porting Guide (GNU) documents.


No, NetOS is really a library, not an OS. You only get one program.


On Topic: I think it’s all been said. Only way to realize that with netOS is to create seperate threads.

Slightly off Topic:

> Take a look at any of the example applications that
> make use of the function/macro tx_thread_create().
> This is the primary function which ‘kicks’ off a new
> thread.

Is there any good documentation about the reentrency of the NetOS Api nad library functions ?

I’ve read in the forum about some trouble with the multi threading and begin to wonder how to effectively make up an applications that uses a bunch of threads in a safe way (lock all not threadsafe functions).
If there are big parts of the Api non-reentrant then this is a serious problem because basically you’d need to wrap every library function into another function which locks the original function.
This would also make it harder to combine 2 thread based applications together because you’d have to spend much more time into the thread safety considerations

I have not used the current NetOS (latest for me is 6.0a), but reentrancy is a big issue.

Biggest problem was the select() function. This would lock up between threads. I posted a fix for this a while back. Cameron says that this is fixed in 6.3.

I also had to do a mutex for serial I/O to keep it from interrupting itself. Actually I had to play a bit with thread priority and timeslicing, but that was because I was using 30+ threads. :slight_smile:

Multithreading otherwise works quite well. Slows things down a lot, but that is to be expected. Make sure that you put some wait cycles in there.



thanks for the quick response.
I already read about the select problem, nice to hear that this is fixed in 6.3 (which I’m actually using).

Basically my application will also use a lot of threads (at the moment I expect about 25) so I think I’ll fall in a lot of pitfalls you fell into before me :slight_smile:

Is the reentrancy documented somewhere ? I just found information in the CLib docs, but didn’t find anything about the NetOS Api itself. I assume the threadx Api is threadsafe, but don’t have a clue about the rest.

Oh, and are there any expieriences how this is with the Green Hills Libraries, because I think we’ll use Green Hills once the Project finally kicks off.


Basically you will have to do trial and error to determine if anything has reentrancy problems. As of 6.0, the only ones that I had problems with were in TCP/IP. I ported SSH Server which is the bulk of my application and required a lot of hacking. I finally solved it by using mutex wrappers for a lot of the TCP/IP functions (select(), send(), recv()).

If you are porting something to NetOS, the other big issue is that there are a lot of missing functions.

inet_aton(), getaddrinfo(), freeaddrinfo(), getnameinfo(), gethostbyname(), gethostbyaddr(), getservbyname(), getimeofday(), pipe(), socketpair(). ICMP classes. Note that the DNS functions that are internal are broken as of NetOS 6.0a (I had to rewrite them). I never did get pipe() or socketpair() to work properly.

mkdir(), rmdir(), opendir(), readdir(), rewinddir(). These are implemented in the core as NAFS calls, but need a wrapper to be compatible. Also the FLASH0/ needs to be prepended for them to work.

All the passwd functions - getuid(), geteuid(), setuid(), seteuid(), getpwnam(), getpwuid(), etc.

Also if you are using SSL, NetOS only has a partial port. For anything using AES or anything besides what is needed for https, it needs to be reported.

As for the original subject of this thread, I solved the single app problem by creating all the specific applications as C++ classes (SSH, Telnet, Nist, etc) that automatically clean up after themselves. Essentially putting a OS type launch for each of these applications.

Good luck on your app.