rdmenezes / remote-testbed

Automatically exported from code.google.com/p/remote-testbed
0 stars 1 forks source link

Add support for controlling motes via external programs #6

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This feature will allow MCH to support mote platforms where the ability to
stop, start, and reset the mote requires and external program to run.

MCH already has code for running an external program when programming the
motes with a new flash image, which could either serve as a template for
this or be generalized to work for both cases. However, these commands will
not need to output to the mote console and it might be simpler to keep it
separate or just factor out the fork+exec part.

To lower the configuration and hardcoding of the external control programs
they could be specified via the UDEV mote hierarchy either in a file named
"control" (or similar) taking subcommands such as "program", "stop" and
"start" as well as the path to the flash image for the "program" command.

Original issue reported on code.google.com by jonas.fonseca on 25 Oct 2007 at 4:33

GoogleCodeExporter commented 9 years ago

Original comment by jonas.fonseca on 14 Nov 2007 at 10:37

GoogleCodeExporter commented 9 years ago

Original comment by jonas.fonseca on 14 Nov 2007 at 2:10

GoogleCodeExporter commented 9 years ago
This somewhat depends on issue 17, since that issue will require that
SerialControl::program() is changed to use exeve(). These changes should also 
include
 refactoring SerialControl::program() into taking the args[] and environment[] arrays
needed by execve() as arguments and finally rename program() to run() or 
something
more suitable.

Original comment by jonas.fonseca on 16 Nov 2007 at 10:37

GoogleCodeExporter commented 9 years ago
Note, the execve() changes have been merged and the basic interface for 
controlling
motes via external programs should be there as of commit
08073799c7083cd7b90607309317ed684225ecdb.

One thing to we need to figure out is how to handle the start and stop confirm
messages that will have to be delayed until the program ends. This is already 
done
for programming but we obviously need to track which kind of command we are 
have been
running.

Original comment by jonas.fonseca on 22 Nov 2007 at 1:01

GoogleCodeExporter commented 9 years ago

Original comment by spin...@gmail.com on 27 Nov 2007 at 8:26

GoogleCodeExporter commented 9 years ago

Original comment by jonas.fonseca on 23 Feb 2008 at 8:06

GoogleCodeExporter commented 9 years ago
Fixed in commit 122677557750375e4cc0d2d2d0063dfbcff5a3f3 and
53286c6d0a1babc9d655aa684afbb4e9d7e0e57c

Original comment by jonas.fonseca on 10 Mar 2008 at 1:23