start/stop the application on embedded system from another computer

Hi friends,

I wrote a program on an embedded system and have trouble controlling it from my Linux host connected to this embedded system through network.

  1. Close the terminal, not the application

I can start a terminal on my Linux host, telnet the embedded system and start the application. However, as soon as I close the terminal on the Linux host, the application will terminate too. How can I keep the application running after I close the terminal? I definitely want it to be running independent of my Linux host actions.

  1. Start the application as embedded system turns on

Currently I can start the application from the Linux host. However, I won't have a Linux host in the field and I want the application to be automatically turned on as the embedded system powers up. What should I do to make the embedded system load and start the application for me?

  1. Monitor the application

When I start the application on the embedded system from a terminal on my Linux host, the terminal displays the standard outputs (produced by C++) from the application. That's how I monitor the application now. However, if the application is already running, how can I catch and display the standard outputs on the Linux host? Can I start a terminal and then somehow catch the outputs?

  1. Keyboard control the application

How can I strike certain keys from my Linux host and control (start/ stop/resume) the application on the embedded system? Should I first start a terminal and connect to the application? What kind of functions should I write in the application?

I just started building applications on Linux and embedded systems a month ago and have these rudimentary questions. I greatly appreciate any help you can give to me,

Sam

Reply to
Sam
Loading thread data ...

Start application with init / rc mechnism.

Have the application provide a web interface (html) to the user (either it's a web server itself or it uses a standard web server program)

-Michael

Reply to
Michael Schnell

Yes the user has a standard web server program (IE & Firefox). Could you give me more details on init/rc and the web interface? They're all new concepts to me. Maybe you could give me a few key words to search for?

Thanks, Sam

Reply to
Sam

to connect to remote systems from a pc or pc that is connected to an embedded system ,we got to connect through minicon in linux.minicon is just an interface like telnet in windows. first know about minicon .....................

bye siva

Reply to
siva

Threading.

It depends on the type of design. Powerup the system , Boot up of the hardware(basic initialisations), Handle the control to the application.

Modify the init files accordingly. Instead of transferring the startup control from the linux to the embedded system, have a mini bootloader like application in the RAM that will transfer the control to your embedded system after performing the basic sanity checks for your embedded system. If you do not want something similar to a mini bootloader, then you directly invoke the application after restart by configuring the reset vector of your embedded system accordingly. Set the Entry Point of your application in the linker script or pass it as a parameter while compilation. You can also have different modes of booting your embedded system based on the various varieties of the reboot(warm,cold,etc) supported by your embedded system hardware(processor).

Lot of methods are available.

1) If your application is generating outputs/logs in the serial port then, try connecting a serial port. 2) If your application generates outpus/logs on an ethernet , then try using web logic. Webserver logic. CORBA can also help you. It depends on the type of your requirement.

It depends on the type of requirement / on the type of system that you are working on.

It depends on the type of communication

1) RS232 2) Ethernet 3) Wireless etc. CORBA can also help you. It depends on the type of your requirement / on the type of system that you are working on.

Karthik Balaguru

Reply to
karthikbalaguru

Try nohup to start your application.

Create a startup script in /etc/rc.d/init.d. To automatically start you application create a symbolic link from rc3.d to the startup script, with the naming convention as used in these directory ([SK]60, where S is start and K is Kill and the number defines the order in which the startup scripts are executed.

Use a web server, as indicated by other people, or have you application create a telnet like interface, where you can connect to and enter commands and view the status.

Kind regards, Johan Borkhuis

Reply to
borkhuis

This is a web _client_ (browser). The web _server_ is a program at the other site (here in your embedded device) that sends html pages to the browser.

In the device you either use some html _server_ code (and provides an appropriate port in the TCP/IP stack) in your application. Or you run a standard webserver program (there are some that especially are designed for embedded applications) and your application communicates with same via the "CGI" interface (or even uses "LUA").

Don't you have a Linux PC ?

This is the way the Linux kernel starts the applications. The kernel starts a program (which/where is given by default or can be defined by the Kernel start parameters). Here very often a standard program is used, which interprets an "initab" text file and according to same starts lots of user programs. Often one of them is a command line interpreter. Same can run script files. Here again the "RC" mechanism defines multiple scrip files in multiple directories that are aware of many environment variable settings and start lots of programs accordingly. (RC of course needs a decent disk size. It is used in supposedly all PC Linux distributions.)

Hope this helps.

-Michael

Reply to
Michael Schnell

If you just want to start a remote application rather then control it via a telnet session, in particular keep the remote application executing after closing the telnet session, then you should try to start it as background process: # (telnet): & (notice the '&')

This will decouple the remote process from the telnet session.

Kai

Reply to
Kai Schories

nohup is a Unix command that is used to run another command while suppressing the action of the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. It is most often used to run commands in background as daemons.

Another possibility is to use screen. Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the users terminal.

Normal Linux distributions have init / rc mechanisms to start the system services. Add a start script for your application to the /etc/inid.d/ directory and change system starting settings so that it will start when system boots up at the suitable time (after the services that it needs have started). Check the documentation of the Linux distribution you use. Start scripts are one thign where there is quite variation between different Linux distributions.

You can do this for example with screen tool. Start screen. Start your application it it. Detach screeen.

Log in some later time and resume later to that screen session. You will see what was pritned to screen when you wer away (there is a scrollback history etc.).

That's one way to do that. Maybe not always the best, but has worked well many times with Unix/Linux system (I have used screen normally on non-embedded server systems).

One way to do that is to write the application as normal console application that takes the input from standard input. Do read characters from stdin (if there is any).

Then do the screen trick to connect and disconnect the terminal from the application.

I have done that quite much longer time...

--
Tomi Engdahl (http://www.iki.fi/then/)
Take a look at my electronics web links and documents at 
http://www.epanorama.net/
Reply to
Tomi Holger Engdahl

Thank you all for the help. It seems that there are quite a few solutions to my problems.

The solutions that I've tried so far and worked are:

  1. I can use "nohup telnet ipAddress &" to connect to a remote embedded system and start an application on that system. The application is independent of the terminal I used to start it because there is no "hang up."

  1. I inserted a few commands in /etc/rc.d/rc.local to start the application I intended. The system will start the application in the last stage of its booting process. Note that I have to export environment variables before the command line to start the application.

Thanks again. I will try the other solutions too.

Sam

Reply to
Sam

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.