Best posts made by Theodore Borromeo

Oh shoot! Does Onion have a community manager now!?! Congrats! Just like a real-life Hardware startup

@Boken-Lin @Lazar-Demin
from borromeotlhs/onion-omega:v1

is now available for use in a Dockerfile. it'll contain the entirety of the toolchain per your cross compile environment setup guide.

Regards,
TJ

Assuming you have serial console access or have terminal access from the wifi console, and that your onion omega is connected to the same wifi network. PLEASE NOTE: working node.js is NOT built from openwrt toolchain provided by onion corp., and I am still working on getting that 'container-ized', so that is still TBD.

1.) Download the two files from google drive I linked to, get them over to a mounted usb drive on the onion (i format to ext4). Run:
ln -s /path/to/usb/libv8.so /usr/lib/libv8.so

2.) and then go to:
cd /path/to/usb/

3.) and run:
./node --version

That's about it

OR
pull borromeotlh/docker-onion-omega-nodejs from dockerhub, then:
docker cp over 'node' and 'libv8.so' from /node/nodejs_deploy to your host machine
scp over those two libs onto a usb drive (ext4 formatted is what I used, but ymmv) mounted to on the omega
make a symlink for /usr/lib/libv8.so that points to libv8.so you just scp-ed over
go to usb drive and run './node --version'

https://hub.docker.com/r/borromeotlhs/docker-omega2plus/ Now builds from LEDE 17.01 branch. Use latest tag until I can properly tag it.

@Chris-Ward I compiled node from a completely different process than Onion's buildroot. It is also available at:
borromeotlhs/docker-onion-omega-nodejs

This image will contain the precompiled node and v8 binaries in them, I think in a folder called 'node_deploy'. That image will, I assume, have a working toolchain in it, though not entirely sure it was specifically suited to the onions hardware (tho node and v8 seem to work).

good luck!

@Lazar-Demin If that's what you have, then I already have an omega2 plus lede buildroot within a docker container. . .

You can utilize my containerized buildroot on docker with:
FROM borromeotlhs/omega2

The image was built for omega though, not omega2(+).

tagged a 'v1' image last night. This isn't tested, so I'd recommend you compile your own image with verified settings at your own risk. You will most definitely need to choose a different architecture to build for omega2, but the environment (LEDE) is set up to work.

I make zero guarantees nor warranties. Ymmv. Please consult a doctor and discontinue use if this software causes nausea, discomfort, vomiting or diarrhea.

@Stephen-Tunney docker use, as referenced by myself anyways, is only and always in reference to the host machine you would use to cross compile for the onion omega. Docker does not even officially support the arm work going on, that I think MIPS support is not existent.

@Chris-Ward https://hub.docker.com/r/borromeotlhs/docker-onion-omega-nodejs/

@Lazar-Demin as always, thanks for the response! I literally keep this open waiting for developments as they occur

I am assuming that this information will come, but you seemed to point out something I was worried about:
I have a bunch of static and/or dynamic libraries I want to link with, but without control of a makefile, I can't ensure the resultant application is built/linked properly. This is a slight downside, but, I can just build something that requires static libs myself, at that point, as I'd have more capabilities myself then cloud compile would actually give me.

To that end, I just realized that I could extend the docker container I made up for nodejs compiling to utilize the toolchain and create a arbitrary programs given a directory filled with makefiles/sources/static libs.

Nominally, I could mount a directory of a project via -v flag to draw in any git repo for building in my toolchain container. I could then have a build hook/script within the container or in the git repo that, post-build step, POSTs the results to onion cloud for loading and installation to the omega. This would entail that I also, along with mounting the project directory, perhaps mount the credentials directory for the specific API key I want to post to. . .

Love it! Now that onion cloud/ubus/api integration is up, I feel the community can move at a much faster pace. I feel, though, that perhaps you should invite and open up your design meetings to members of the community (as much as you can without sacrificing your competitive edge) so that community advocates can do this sort of documentation and whiteboarding for you I mean, I'm happy to spitball all my good ideas and all, but I feel you all should get to your core business and allow critical functions to be taken over by your dedicated and fanatical community.

Keep up the good work!

Hey Onion community. Does anyone have an example of valid files that are supposed to be contained in the zip file you drag and drop into cloud compile? Is there a tutorial of what kind of make system we're to expect on the backend when cloud compilation goes down?

Also, can we possibly get a web frontend for the cloud compile that will expose some build options for wrt, funnel those options as environment variables to a docker client, and build custom firmware images on the fly that can then be shuttled over to dev devices via onion cloud integration? The container could easily be built from instructions at: https://wiki.openwrt.org/doc/howto/obtain.firmware.generate

and then, onion could replace critical bootstrap code by unpacking and repacking resultant firmwares (or embed their build instructions into their docker container directly) before they go to device such that onion cloud connectivity is maintained. It would be even more dope if the base firmware could know to put itself into recovery mode before flashing, try to flash a new firmware to a removable usb stick, and if the 'flashing' fails, all a user has to do is remove the usb stick & reboot to get back to a known good configuration. . .

anywhos: where is there more info for cloud compile?

So I used the openWRT toolchain to compile opencv.

http://bit.ly/1O70tg7 - opencv ipk
http://bit.ly/1rAuvPa - test file for opencv ipk

Can anyone take a look at see if this is useful or even works? I am a bit busy from a move, and don't even know where my omega is I posted this on an older thread, but I believe that there isn't really a way to revive a topic that has been dead for so long

@Lazar-Demin I'll do that once I get home, before I try the new wifi sta connection. @chris-mccaslin thanks for the info.

@Dan-L.

// test.js
var GPIOHelper = require('./gpiohelper');

var helper = new GPIOHelper();

//blink LED hooked up to pin0
do {
    setTimeout(helper.setPinSync(0,true), 500);
    setTimeout(helper.setPinSync(1,false),500);
} while (1)

As I don't have access to sleep() (haven't figured out how to do that yet in js), I may be hosing myself by using non-synchronized setTimeout. . . Again, js is not my forte.

I was thinking this would be better:

 // test.js
var GPIOHelper = require('./gpiohelper');

var helper = new GPIOHelper();

function toggle(value) {
     return value == true : false ? true;
}
//blink LED hooked up to pin0
var truthy = false;
do {
    truthy = toggle(truthy);
    setInterval(helper.setPinSync(0,truthy), 2000);
} 
while (1)

Though I left my omega at home so can't test right now

@Dan-L. Cool! I'm honestly not really that great with Javascript yet, just knowledgeable enough to get myself into and out of trouble. However, the reason I bought the omega was the idea that we as the community could define node packages, have node.js on device, and just extend the capabilities for the device with npm.

The solution I stumbled upon did seem to have npm, and can be built with the script:
https://github.com/nneves/openwrt_mips_ar9331_nodejs/blob/master/npm_mips_ar9331.sh

So, when I get time on Monday, I'll probably have to update the Dockerfile for nneve's scripts to build npm too. That should allow us to quickly iterate on stuff, push to npm, and then disseminate that way until official support for a slimmer node.js server comes from Onion, Inc.

Great stuff and great progress!

OK,
Built from source using instructions from:
https://github.com/nneves/openwrt_mips_ar9331_nodejs

https://drive.google.com/open?id=0ByWngkuitN_ZQ3RKUmRIZXNtRE9pd0d5X1FuQUZ4TTZ1cE40
libv8 so
https://drive.google.com/open?id=0ByWngkuitN_ZR0dHUnpLRXNvdjhCV2l1TUVqN2ZYV2F2UG00
node (v0.10.5)

@Boken-Lin I just made it up, but it's something I've not seen in electronics that should exist. Essentially, if you think of the current stacking mechanism, you have the pcb board->plastic riser->pins from stackable expansion->pcb board. This leaves no room for more than one pin to be inserted into any through way on the plastic riser. What you all should have is a tee-ing mechanism. It would be an equivalent length plastic strip in an L shape, with the bottom of the L being pins such that you have a "T". You could then plug in two pins into one "hole" on the original board
drawing:
(insert pin from stackable board here)
|**|
|**L___
|*******] (insert jumpers here)
|
|
(plug into pcb from here)

@Carlos-Sancho Than you should cycle through different colors and think about duty cycles. Do you absolutely need it on ALL THE TIME? Perhaps you can add a pushbutton to bring up a reading? In industrial plants that I've seen, this is what they do as constantly replacing LCD screens (or bulbs, depending on the age of the equipment) gets terribly wasteful and expensive.

And since it is the internet we're connected to, perhaps have an always on message bus, with the screen displaying when the pushbutton is pressed to compare network connectivity. It'd be a quick way to verify that your code or the network hasn't gone stale from a remote monitoring station, and it'd also protect you from burn in.

A final alternative is to add scrolling animations, or cycle which measurement is scrolling via above pushbutton.

Basically, add a button as a "JIT" duty cycle enabler. You'll be happier you did, and you don't even need to write software to create an electronic interrupt using a BJT or whatever. It'd be a nice experiment in low cost/low power/no code solutions.

@Boken-Lin Here's what I get when I try to run the ov519 (ps2eyetoy) driver:
insmod /lib/modules/3.18.20/gspca_ov519.ko :

[  733.050000] gspca_ov519: Unknown symbol gspca_frame_add (err 0)
[  733.060000] gspca_ov519: Unknown symbol gspca_debug (err 0)
[  733.060000] gspca_ov519: Unknown symbol gspca_disconnect (err 0)
[  733.070000] gspca_ov519: Unknown symbol gspca_dev_probe (err 0)
failed to insert /lib/modules/3.18.20/gspca_ov519.ko

and here is what I get when I try to ins mod the manually downloaded ov534 (ps3eye) drivers:

insmod /lib/modules/3.18.20/gspca_ov534.ko 
[  723.300000] gspca_ov534: Unknown symbol gspca_frame_add (err 0)
[  723.300000] gspca_ov534: Unknown symbol gspca_debug (err 0)
[  723.310000] gspca_ov534: Unknown symbol gspca_disconnect (err 0)
[  723.310000] gspca_ov534: Unknown symbol gspca_dev_probe (err 0)
failed to insert /lib/modules/3.18.20/gspca_ov534.ko

My guess as to the issue: perhaps the previous firmware versions @ 3.18.20 did work, but the newer firmwares upgraded the kernels which might have broken the ps2/ps3 gspca drivers. . .

Can we have the gspca drivers for the ps2 and ps3 baked into the firmware? Those are cheap and ubiquitous enough to warrant it, I think

I want to mate an onion to a SNES cart to make a development platform for retro SNES games. I think that the onion2 would have a larger size than any game ever made, but would also allow for wifi connections in game. I have always wanted to be able to do networked multiplayer on the SNES, as they still have one of the best couch co-op games in Super Smash TV

I mainly want to realize the Google April Fool's Day joke in 2012, except on the SNES: https://maps.googleblog.com/2012/03/begin-your-quest-with-google-maps-8-bit.html