What WEB Server is running on the BBB out of the box?

Hi Mark,

It's a node.js based server. It is well worth reading up on node.js, if you like to code in JavaScript. Basically the server is written in JavaScript (example here). So, it's not the same as Apache/Lightttpd because some code is required to create the server - node.js is a platform, not a web server - but it is not a lot of code (just a few lines).

EDIT: Sorry, just noticed it was answered by agrahambell

shabaz I was reading that exact page you linked to earlier tonight.. The one thing that struck me is that the docs don't obviously cover the simple case of having a directory of flat files that you just want to be able to send to a browser..  Sure you can see that it can be done, but it appears that node makes even the simple stuff just as complex as the complex stuff.  I realise node is trying to be an web-app engine much like a cgi script or a php generated page, but what about all of the simple static stuff like images?

The dumb 'Hello World' example that's only a few lines just leaves the feeling that things just became a lot more complex with no real explanation of why that would be a good thing. What am I missing here?

Yes and where is this "flat page".  I've been poking around on the BBB to find where these .js  and BoneScript files are stored. With my limited Linux skills I can't find them.  I've tried searching for a known file like "demo_blinkled" but that doesn't get found with the find command.  I've probed every directory I can see and I haven't found them yet.

It would be nice to have a simple 'HowTo' on where to load my .js and BoneScript files, and how to link it to a new start page at 192.168.7.2/foobar_whatever.

Thanks

Hi Selsinork,

You're right, I'd noticed that too recently. Not sure where to find a good general purpose server implementation in JS. I can't recall where I originally saw it, but I've been using 'readFile' as in this example:

var fs = require('fs')
function handler (req, res)
{
    reqfile=req.url.substr(1);
    fs.readFile(progpath+reqfile,
  function (err, data)
  {
    if (err)
    {
      res.writeHead(500);
      return res.end('Error loading index.html');
    }
    res.writeHead(200);
    res.end(data);
  });
}

Still, I'm not sure if this is the 'best practice' method or if anyone has better refinements and a more fuller implementation -  e.g. the above just implements just two response codes. At a minimum I've been doing a URL check however, just so that the URL looks to contain an allowed path.

Hi Selsinork,

You're right, I'd noticed that too recently. Not sure where to find a good general purpose server implementation in JS. I can't recall where I originally saw it, but I've been using 'readFile' as in this example:

var fs = require('fs')
function handler (req, res)
{
    reqfile=req.url.substr(1);
    fs.readFile(progpath+reqfile,
  function (err, data)
  {
    if (err)
    {
      res.writeHead(500);
      return res.end('Error loading index.html');
    }
    res.writeHead(200);
    res.end(data);
  });
}

Still, I'm not sure if this is the 'best practice' method or if anyone has better refinements and a more fuller implementation -  e.g. the above just implements just two response codes. At a minimum I've been doing a URL check however, just so that the URL looks to contain an allowed path.

I found this on my BB. I hope it helps.

root@beaglebone:/var/lib/cloud9# cat README.md
Getting started
===============
Bonescript is a node.js library for physical computing on embedded Linux,
starting with support for BeagleBone.

Information on the language is available at http://nodejs.org.

To get started, try running 'node blinkled.js' on a BeagleBone.

Additional documentation is available at http://beagleboard.org/bonescript.

The concept is to use Arduino-like functions written in JavaScript to
simplify learning how to do physical computing tasks under embedded Linux
and to further provide support for rapidly creating GUIs for your embedded
applications through the use of HTML5/JavaScript web pages.

Installation
------------
Bonescript comes installed on your BeagleBone.  If you are looking to update
to the latest revision, use 'opkg' to perform the update:

````sh
opkg update
opkg install bonescript
````

Support for other distributions is a work in progress.

Launching applications persistently
-----------------------------------
To have your applications launch on startup, simply drop them into the
/var/lib/cloud9/autorun folder.  Moving them out of that folder will kill
the processes.  You are expected to only drop in already bug-free apps into
this folder as there isn't a good way to perform debug on them.

Note on code state
==================
There's still a lot of development going on, so be sure to check back on a
frequent basis.  Many of the fancier peripherals aren't yet supported
except through performing file I/O.

Directory layout
----------------
* attic: Stuff not to throw away, but not in a good state
* demo: Examples showing how to use the BoneScript library
* etc: Configuration files to be placed in target distro
* node\_modules: Library code
* systemd: Configuration files for systemd to start services
* test: Automated test code

Template
========
For a Bonescript application, you must currently manually 'require' the
bonescript library.  Functions are then referenced through the object
provided back from require.

I started out trying to provide Arduino-like setup/loop functions, but the
idea really isn't a good match for JavaScript.  Using JavaScript's native
flow works best, but the familiar functions are enough to give you a boost
in your physical computing productivity.

Here's an example:

````javascript
var b = require('bonescript');

b.pinMode('P8_12', b.INPUT);
b.pinMode('P8_13', b.OUTPUT);

setInterval(copyInputToOutput, 100);

function copyInputToOutput() {
    b.digitalRead('P8_12', writeToOutput);
    function writeToOutput(x) {
        b.digitalWrite('P8_13', x.value);
    }
}
````

The 'P8\_12' and 'P8\_13' are pin names on the board and the above example
would copy the input value at P8\_12 to the output P8\_13 every 100 ms.

API
===
When a callback is provided, the functions will behave asynchronously.
Without a callback provided, the functions will synchronize and complete
before returning.

Digital I/O, Analog I/O, and Advanced I/O
-----------------------------------------
* analogRead(pin, [callback]) -> value
* analogWrite(pin, value, [freq], [callback])
* attachInterrupt(pin, handler, mode, [callback])
* detachInterrupt(pin, [callback])
* digitalRead(pin, [calback]) -> value
* digitalWrite(pin, value, [callback])
* getEeproms([callback]) -> eeproms
* pinMode(pin, direction, [mux], [pullup], [slew], [callback])
* getPinMode(pin, [callback]) -> pinMode
* shiftOut(dataPin, clockPin, bitOrder, val, [callback])

Bits/Bytes, Math, Trigonometry and Random Numbers
-------------------------------------------------
* lowByte(value)
* highByte(value)
* bitRead(value, bitnum)
* bitWrite(value, bitnum, bitdata)
* bitSet(value, bitnum)
* bitClear(value, bitnum)
* bit(bitnum)
* min(x, y)
* max(x, y)
* abs(x)
* constrain(x, a, b)
* map(value, fromLow, fromHigh, toLow, toHigh)
* pow(x, y)
* sqrt(x)
* sin(radians)
* cos(radians)
* tan(radians)
* randomSeed(x)
* random([min], max)

Note on performance
===================
This code is totally unoptimized.  The list of possible optimizations that run
through my head is staggering.  The good news is that I think it can all be
done without impacting the API, primarily thanks to the introspection
capabilities of JavaScript.

Eventually, this is planned to enable real-time usage, directly from
JavaScript.  The plan is to attact the ability to use this programming environment
in real-time on several fronts:
* Enabling multiple loops and analyzing them to determine if they can be off-
  loaded to a PRU.  This will be the primary mechanism for providing real-time
  servicing of the IOs.
* Providing higher-order services that utilize the standard peripherals for
  their intended use:
  - Serial drivers for I2C, SPI, UARTs, etc.
  - analogWrite for PWMs using hardware PWMs, timers, kernel GPIO drivers, etc.
* Adding real-time patches to the kernel

The JavaScript language provides some features that I think are really cool
for doing embedded programming and node.js does some things to help enable
that.  The primary one is that the I/O functions are all asynchronous.  For
embedded systems, this is especially useful for performing low-latency tasks
that respond to events in the system.  What makes JavaScript so much easier
than other languages for doing this is that it keeps the full context around
the handler, so you don't have to worry about it.

Short-term issues
=================
* The state of the ARM Linux kernel with regards to handling loading drivers
  using devicetree is still in a lot of flux.  Many of the interfaces
  Bonescript utilizes are being rewritten and refactored.

Thanks for the reference, I'd not seen that file. I've not used bonescript much so far (apart from a demo a long time ago), but it's great. And reading that file, it contains more functions that I remembered. It is like an I/O library for node.js. So far I've usually written I/O in C, and called it from node.js but bonescript will essentially do the same thing more directly, so bonescript is the cleaner way and means only one language to use!

I posted that thinking I had found what I was looking for, but it turned out not to be the case. The autorun directory was empty.  While the file is cool, what I really want is to find out how the link to 192.168.7.2  is associated with the on board files as 192.168.7.2/Support/bone101.

If I could find those figin' files I'd be happy.  When I do find them I suspect there'll be a Start type page which I can copy and modify to link my web page.  Then somehow I'll be able to add a path to 192.167.7.2 to my files and Bonescript controls.

Something like /192.168.7.2/MyPages.

The example code pasted above is close to what you need. Personally I start up a separate instance using node, and have it listen on a different port. That way I don't need to touch the existing code and can start from a clean slate.

If you want to see an example of that, see this code. You'll see in the index.js file what I did to provide web server capability (but on a different port, 8081 in my case).

If you want to modify the existing server, that should be possible, but I've not had a need to attempt it so far.

EDIT: edited to add a more direct link.

Cool.  More her than my simple needs to spit out my own web page.

How did you associate your code with http://xx.xx.xx.xx:8081/index.html

Did the "npm install socket.io" command set up the path to your files at 8081?

I see you changed your link.  I was lucky enough to see the original to:

Building a Frequency Synthesiser

The new link takes me to the code directly but deprives everyone from seeing your really cool project.

Hi Mark,

The index.js file uses an 'app.listen(8081)' command to set that (unlike a web server like Apache, there is no config files and all behavior has to be programmed, in this case it is programmed in the index.js file). You won't need the socket.io stuff, just lines 1-33 of the code should work fine (you can delete line 4). Also, delete line 21 which forces all requests in my case to always respond with a single file index.html.

With those changes, the code should be close to what you need.

Thanks Shabaz,

I'll play with a smaller version of this and see what I can come up with.  Thanks for all the help.

Hi Mark,

No problem, let us know if it works out.