JavaScript right on the hardware

Re:JavaScript right on the hardware by brianpgordon on Wednesday August 14, 2013 @07:06PM (#6215014)

Looks like the JavaScript bindings for Tessel are better. Comparing the demo for blinking an LED:

  var b = require('bonescript');
  var state = 0;

  b.pinMode("USR3", 'out');
  setInterval(function() {
    state = state ? 0 : 1;
    b.digitalWrite("USR3", state);
  }, 100);

  var tessel = require('tessel')
  tessel.led(1).blink()

If they can give human-friendly names to stuff like "USR3" and "P9_40" and "P9_36" out of the box, then I'd say they've added some value.

[ Parent | on HN ]

Re:JavaScript right on the hardware by zhemao on Wednesday August 14, 2013 @07:31PM (#6215169)

But that's a library issue, not a hardware issue. It shouldn't be difficult to write a wrapper for bonescript that turns the first example into the second example.

[ Parent | on HN ]

Re:JavaScript right on the hardware by wyager on Wednesday August 14, 2013 @08:14PM (#6215365)

And what happens when you need to specify a pin mode on the Tessel? If you don't have at least tri-state support (which isn't compatible with human-friendly abstractions like "blink"), you're going to burn out a lot of sensors.

Most modern microcontrollers have anywhere from 3 to 5 possible pin states, and I don't think it's possible to safely wrap these up in a nice, human-friendly function like "blink".

For example, on a lot of ARMs, you have:

In, no pull

In, pulled up

In, pulled down

Out, up

Out, down

and on AVRs, you have

In, no pull

In, pulled up

Out, up

Out, down

You necessarily have to have ugly secondary functions like "pinMode".

[ Parent | on HN ]

Re:JavaScript right on the hardware by tcas on Wednesday August 14, 2013 @09:13PM (#6215572)

Also: peripheral muxing, interrupts in input mode, connecting a timer as PWM output to a pin (which is basically what blink is probably doing). In input mode it might also have schmitt triggering.

Where's the blink getting the timer from? What happens if I update the main PLLs? I'll refrain from making assumptions however until I can see their driver libraries. I'm hopeful, but having played around with the 1830 it's not a simple chip.

[ Parent | on HN ]