3 ms·
Looks like the JavaScript bindings for Tessel are better. Comparing the demo for blinking an LED: var b = require('bonescript'); var state = 0; b.pinMod
by brianpgordon 13y ago
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);
vs
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.
- zhemao 13y agoBut 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.
- wyager 13y agoAnd 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".
- tcas 13y agoAlso: 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.