Closed OLLYDOTDEV closed 4 years ago
talk about
what you tryed to get C++ to get user input via web interface
and why I settlated on using live phasing
with the aim here being to control the mode via a given input via a GUI(graphical user interface) . I needed to work out what was I going to use for the GUI. So over the past 4 days have consisted of test what forms of backend software can run on the RPI W running Kali Linux (arm6l).
The first option It tried to get working was a node.js. this would have been great as it non-blocking asynchronous back-end API but would have allowed direct integrating with my C++ but the RPI W is running on the ARMV6 RISC CPU architecture and when also combined with also using an older Linux kernel you are unable to install nodejs. (yes also in docker this was not able to be executed when using another distro )
the next option that research show was to host the server with C++ while this does work it is with frameworks like Crow,µWebSockets,Mongoose,Boost Beast , cpprestsdk
while I tested most of them only having 512MB of ram restricted to already compiled binaries and well there are hard to come by and the only other option was to cross-compile them for ARM6L but due to this project being due in 2 weeks this is not sufficient time to set that up.
so that consider I was left with a basic web server, was one option to use the Nginx web server but for some reason, it was not able to find any files on the SD card.
In the End, Had to use the backup plan for when all else failed (because well that what happened) so for this pack up plan I am using is apache2 webserver. this at first didn't work when setup but after reinstalling it then worked just fine.
with the host working. I am next able to now write the code that will allow the user to interact via a web GUI.
the reason why it was decided to utilize a web interface was that most modern devices will be able to interface to control it allowing for greater usability
for the frontend, it will HTML and maybe some CSS, as the aim it functionally with less focus on the Aesthetics
the backend will be run of PHP as being a general-purpose scripting language it works well with the integration of C++ CLI with the UNIX Terminal. as it is able directly to call and execute files, again this helps with usability as it helps to show the system status and allow to more diverse usage. this is done with shell_exec()
while this would run the code it wouldn't show the user(as it is a blocking function ) if anything has been/is running there for i am using to look for non blocking version of this command
while shell_exec()
does call the function it is a blocking function. therefor It doesn't give an output till the end of the script has been reached, this is an issue as the code that needs to be executed is in a forever loop and therefore will never reach the end and inturn never give an output. so the alternatives are being considered as a nonblocking function.
options are
javascript using EventSource
using pcntl_fork this makes a child process PHP PDI
or the Linux command at in use with shell_exec()
First, I needed to install the at
package
sudo apt-get install at
then needed to remove www-data
from /etc/at.deny
(this allows the at
command to be executed from the web browser)
with that I can call my C++ function with shell_exec('/projects/Project-Birdseye-DTX-2020/CODE/Release/WebServer/commands/ALL.sh | at now 2>&1');
but while when tested the PHP script from a CLI it runs just fine but the issue happens to be that the running RPI need to be run as sudo as it is using the SPI interface and the SPI libray can only be run as root (sudo) so this was the fix added data-www to have root perms
using shell_exec('sudo /projects/Project-Birdseye-DTX-2020/CODE/Release/WebServer/commands/ALL.sh | at now 2>&1');
calls a external bash script that first off kill any other scripts that would interfere with its functionality.
timeout 5 sudo ps -ef | grep ./../RPI/RPI | grep -v grep | awk '{print $2}' | xargs kill
then the compiled RPI.cpp is executed sudo ./../RPI/RPI ALL
and with that code is being called from the web browser. but to make it more
flexible I will be implementing the use interface to the allow section of the different modes. this will consist of a simple gui
to allow the nonblocking operation for the front end. PHP-FPM had to be setup
after that as talk about previously, the at
command will be called on page load as this allows us to run code on a separate CPU processes allowing for a asynchronous command execution. the commands that at
executes is read from a file stored in /projects/Project-Birdseye-DTX-2020/CODE/Release/WebServer/commands/
this in has are a set of bash file that are then run to asynchronous run RPI software.
here in the index.php
,
From here if you for example click on the ALL link then
the code from all.php
is run
<?php
require('assets/Control.php');
Control();
echo shell_exec('sudo at now -f /projects/Project-Birdseye-DTX-2020/CODE/Release/WebServer/commands/all.sh ');
home();
?>
the page starts off by calling the Control()
function this displays the Control panel
Next with shell_exec()
called the at
command to start running RPI asynchronously.
Then to end everything the home()
function is called this used JavaScript to redirect the browser to the index page this server the purpose of updating the GUI to show run Processes.
this increasing the Usability due to the system status being displayed - Implications
As a user I should be able to make a choice on what mode the ROMS is in. (the data for this will come from #29 ) so ROMS knonws how the data will be handled