[GRLUG] Remote control of ARM development board

[rodney nunya]

I am curious if anyone has any suggestions on how best to control a board
such as a Beagle Bone, rasberry pi or similar.

I am looking at a setup where I want to interact with multiple ARM based
linux boards from my PC. The idea is I want to run CLI based commands on
the Linux boards and return the response to the PC. I may want to run
multiple programs at the same time on the linux board and return a large
amount of data at times. The PC will make determinations on the data
returned and decide to run other programs based on the need.

I am wondering what is the fastest non LAN connection I could make between
the ARM and the computer. Most of the boards I looked at have USB 2.0 ports
and they have a serial console available.
What I am considering at this time is to build a specialized "switchboard"
type program on the Linux boxes that would run the programs and look for
the responses and communicate with a program on the PC that would then
decide which programs to run and such.

Basically I am looking to use ARM boards as a sort of data collector for
the PC and the PC will make determinations based on the information
returned and go from there. It may start with one device getting
information and 2 others sitting idle waiting for something to happen and
when something is detected on the one getting information then the PC calls
up one of the idle computers to perform actions.

I will be making use of CLI based programs already in existence and
controlling everything from the PC with a custom program using a graphical
based interface to display the data to the user.

In design this system would use 2-3 different arm boards but in practical
use I could be making use of dozens of ARM boards from the PC with the ARM
boards doing data collection and calculations on the data and allow the PC
to sit mostly idle as a controller.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20131018/e4b8f921/attachment.html>