- Runs on
nodeJS
- Communicates over
TCP
- TCP server listens on port
7070
-
Download and install nodeJS from nodejs.org
You can check whether it was successfully installed by typingnode -v && npm -v
in the terminal. -
Clone this repo
-
Run
./setup.sh
in the repo's base folder (Internet connection required)
This will setup the subrepo and install the node dependencies. -
To start the server, go into the
server
sub-directory and typenpm start
The default branch for hyped-2020 is develop
For the time being, you will have to ssh
into the BBB, cd
into debug-server/hyped-pod_code
and run your git
commands there.
An option to git pull
and git checkout [branch]
through the mission-control GUI is on our Feature wishlist but not yet implemented.
By default the hyped pod code used for compiling and executing the binary is located in the "hyped-pod_code" directory.
If you wish to run the commands not on your local machine but instead remotely via ssh, send the following message to setup the remote connection.
{
"msg" : "use_ssh",
"host" : "192.168.6.2",
"username" : "hyped",
"password" : "spacex",
"dir" : "~/hyped-2020"
}
- If a connection already exists, it is closed and overwritten.
- If the connection fails, the local machine is used.
Possible responses:
{ "msg": "ssh_connection", "success": <bool> }
Only run the make
command:
{ "msg": "compile_bin" }
Run the make
command with params / flags:
{
"msg": "compile_bin",
"make_params": [
"--ignore-errors",
"--jobs=2"
]
}
Possible responses:
Execute without flags:
{ "msg": "run_bin" }
Execute with custom flags and debug-level (default=3):
{
"msg": "run_bin",
"flags": ["--fake_imus"],
"debug_lvl": 2
}
Possible responses:
- Console Data -> Parsed lines
- Termination
{ "msg": "kill_running_bin" }
Possible responses:
Triggers the Termination response of the binary execution
- Kills all running processes
- Disconnects ssh
- Deletes all temporary data (e.g. ssh connection details)
- Does not disconnect tcp connections. For that a manual restart of the server is required.
{ "msg" : "reset" }
Possible responses:
{ "msg": "reset_complete" }
{
"msg": "console_data",
"payload": <data>
}
Data types:
-
Parsed line(s)
e.g.[ { "line": "18:47:04.393 DBG3[Fake-GpioCounter]: time_after: 0", "time": "18:47:04.393", "log_type": "DBG3", "debug_level": "3", "submodule": "Fake-GpioCounter", "log": "time_after: 0" }, { "line": "18:47:04.393 DBG3[Fake-GpioCounter]: time_after: 0", "time": "18:47:04.393", "log_type": "DBG3", "debug_level": "3", "submodule": "Fake-GpioCounter", "log": "time_after: 0" } ]
Error messages may be split into multiple TCP messages
{
"msg": "error",
"type": <type>,
"payload": {
"message": "error_message",
"stack_trace": "if available"
}
}
Error types:
"server_error"
{
"msg": "terminated",
"task": "command_name",
"success": <bool>,
"payload": "error_message(s)"
}
task
returns the msg
-parameter sent to trigger the specific command.
E.g. when compiling the binary, the TCP response would be
{
"msg": "terminated",
"task": "compile_bin",
"success": true,
"payload": "error_message(s)"
}