Please upgrade your Yún - latest is 1.3

I fear that would transform setup questions into virtualbox questions :) And debian issues won't be over anyway, since newer packages would require additional prerequisites. It has already happened when we added node packages

@mytrant - you need v8m if you want node.js, if you don't you can disable all the options under Languages->Node.js and then it will let you disable v8m. Or you can work with the 1.0.0 release (see below) which doesn't have node.js, you should end up with something very close to the prebuilt images.

@federico - I might add to your footnote "even then there may be undocumented changes, prepare to learn!"

This brings to light a fact I did not realize even though it is obvious. When you pull from the git https://github.com/arduino/openwrt-yun you get the latest, greatest, PERHAPS buggiest thing available.

If you want to work with the code at a particular point you can use something like git checkout -b release 1.0.0 right after you clone.

To switch back you can use the copy SHA link by the latest commit. At this exact moment in time that would be:

 git checkout -b f58425387a0ce96bb709489f526dfaf0dae2e1af
git pull origin f58425387a0ce96bb709489f526dfaf0dae2e1af

I would say somebody needs to improve the OpenWrt tutorial on build root, set up a tutorial on working with things such as debian VM and linino/Yun on a build root in a VM but I learned long ago that it is best to replace "somebody needs to" with "I cheerfully volunteer to" ;-)

noblepepper:
This brings to light a fact I did not realize even though it is obvious. When you pull from the git GitHub - arduino/openwrt-yun: A custom version of OpenWrt, targeted to the Arduino Yún you get the latest, greatest, perhaps buggiest thing available.

Wow! Buggiest!
I know (and sadly accepted) that openwrt build sometime fails, but just really sometime. May you elaborate? Why buggiest?

1.0.0 is different from the latest * only in that it downloads the list of packages from another git repo, GitHub - arduino/openwrt-packages-yun

  • and soon to be become 1.1.0 thanks to your run-avrdude fix

Since I suspect the git thing may be the source of trouble, I switched the feeds URL to svn https://github.com/arduino/openwrt-yun/commit/8ad03f07d3c11ce2eda7d00c152730c20672ba68

Federico

Thank you for your instructions and footnote - the comment on using the same base world makes sense.

Having worked with other buildroot worlds, I should have followed all the notes to a 'T'.

OpenWRT has enough different build practices (different - not a normal use of Makefile, not a clear path to rebuild sections...) that adding any new changes is not to be recommended.

Thanks to all for any assistance given on these forums as well, it is a good community to ask questions in.

Using hypervisor compare with bear metal will lost % performance, and different type hypervisor will be vary. Worst case you got hit by 80%

|500x379

http://en.wikipedia.org/wiki/Hypervisor

VMware Workstation and VirtualBox is type 2 hypervisor will be suffer more than type 1 hypervisor.

OpenVZ might be best fit: it does not have the overhead of a true hypervisor, it is very fast and efficient. The disadvantage with this approach is the single kernel. All guests must function with the same kernel version that the host uses. My personal experience only lost 5~10%.

http://en.wikipedia.org/wiki/OpenVZ

Oddly enough am now timewasting....

installed Virtualbox, Debian Wheezy and went to run the following:

apt-get install git subversion build-essential asciidoc \
    fastjar flex gawk libgtk2.0-dev intltool zlib1g-dev \
    genisoimage libncurses5-dev libssl-dev ruby sdcc unzip \
    bison libboost-dev libxml-parser-perl libusb-dev bin86 \
    bcc sharutils openjdk-7-jdk mercurial cvs bzr npm

Got the result:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: unable to locate package npm

Any thoughts on an attempt to build openwrt-yun on the same world?

While I agree with Federico that using the standard build environment will eliminate many problems, I have had a good experience with Ubuntu. I do have to Google occasionally to find the source of an error but I avoid learning vm's and relearning Debian dogma. I am on the last 13.?? Ubuntu but I expect 14.04 won't be too much trouble.

[quote author=Federico Fissore link=topic=235360.msg1725979#msg1725979 date=1400250481] Wow! Buggiest! I know (and sadly accepted) that openwrt build sometime fails, but just really sometime. May you elaborate? Why buggiest? [/quote] Because it is the latest and greatest! It's the nature of the beast. If you want to be on the bleeding edge you need to be prepared for some issues.

While I envy some of the things you get play with, some of the comments I have seen make me hope you wear asbestos underwear. I am extremely impressed with the yun and what the team has put together.

I also added some emphasis to the perhaps in the original post, it's not ALWAYS the buggiest.

noblepepper:

[quote author=Federico Fissore link=topic=235360.msg1725979#msg1725979 date=1400250481]
Wow! Buggiest!
I know (and sadly accepted) that openwrt build sometime fails, but just really sometime. May you elaborate? Why buggiest?

Because it is the latest and greatest! It’s the nature of the beast. If you want to be on the bleeding edge you need to be prepared for some issues.

While I envy some of the things you get play with, some of the comments I have seen make me hope you wear asbestos underwear. I am extremely impressed with the yun and what the team has put together.

I also added some emphasis to the perhaps in the original post, it’s not ALWAYS the buggiest.
[/quote]
For the record:
I understood your “perhaps buggiest” remark as “latest and greatest”. There is no way to guarantee “regressionless progress”.
Best regards
Jantje

mytrant: Got the result:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: unable to locate package npm

mytrant, you're absolutely right! I've been fooled by the differences between debian and ubuntu once more. I've changed the prerequisites section replacing apt-get with a script that does the first setup.

I'm running a build with a fresh debian just now. If everything goes well, I'll report later tomorrow evening

It worked fine :)

Guys, I want to report that I tested the bridge using fileio with the downgraded opwnwrt and a 145 kilobyte text file and it worked perfect :)

@Federico:

1) so without adding any resistors to the yun, what is the best way to know that the linux side has finished booting? 2) has the speed of the bridge been improved in anyway? If not, how can it be?

THANK YOU

Sincerely

Rodolfo Magnus

rmagnus: 2) has the speed of the bridge been improved in anyway? If not, how can it be?

you kind of like went from windows 7(linino) to xp(openwrt). how can it not be it is faster? Best regards Jantje

I read 144,000 characters in 30 seconds from the SD card .... through the bridge...... so roughly 4,800 chars per second.

it is fast.......

you are right

What I have not found is a safe way to make sure the linux side has booted without the resistor.

THANK YOU

Rodolfo

rmagnus: Guys, I want to report that I tested the bridge using fileio with the downgraded opwnwrt and a 145 kilobyte text file and it worked perfect :)

Yeah! 8)

Jantje: you kind of like went from windows 7(linino) to xp(openwrt). how can it not be it is faster?

XD

rmagnus: 1) so without adding any resistors to the yun, what is the best way to know that the linux side has finished booting?

I have an entry in my backlog about https://gist.github.com/wayoda/db3c023417757f726088 but it's still unplanned

rmagnus: 2) has the speed of the bridge been improved in anyway? If not, how can it be?

That's a kind of an open question. I would like to have a recipe for making it go 10x faster without losing functionalities, but I'm still scratching my head. Any hints are more than welcome

@federico I also tried reading the same 146K bytes at the same time I was playing sound with the madplay player and it worked perfect. You could see somewhat slowed performance but less than I expected. I will keep testing and report back......

I have a question here: I need to look for keys on the Linux datastore using bridge.get () from the arduino side but I don´t want to stop until the key appears there. Is there a way I can do that? Can I just "peek" to see if the key is there and if not, continue with something else? THANK YOU

rmagnus: I have a question here: I need to look for keys on the Linux datastore using bridge.get () from the arduino side but I don´t want to stop until the key appears there. Is there a way I can do that? Can I just "peek" to see if the key is there and if not, continue with something else? THANK YOU

I would "get" in the loop and do something if the key is found and has the right value

Thank you Federico, if I call bridge.get() function the program will stop if the key is not there yet.

What I want is something like Serial.available() or a way to call bridge.get() where the program does not stop if the key is not found, it returns false or -1 but keeps going.

Is that possible?

The documentation I have found on bridge is very scarce. Maybe I am looking on the wrong place.

Grazie

SIncerely

Rodolfo Magnus

@Rodolfo, You might upgrade Linux datastore to Memcached. In computing, Memcached is a general-purpose distributed memory caching system. It could delivery 10~20 time speed boost than Mysql.

opkg update #updates the available packages list
opkg install memcached
/etc/init.d/memcached  start
/etc/init.d/memcached  enable
opkg update #updates the available packages list
opkg install python-openssl #adds ssl support to python
opkg install distribute #it contains the easy_install command line tool
easy_install python-memcached
nano /mnt/sda1/memcacheyun.py
#!/usr/bin/python
import memcache
mc = memcache.Client(['127.0.0.1:11211'], debug=0)
mc.set("some_key", "Some value")
value = mc.get("some_key")
print value
mc.set("another_key", 3)
mc.delete("another_key")
mc.set("key", "1")   # note that the key used for incr/decr must be a string.
mc.incr("key")
print  mc.get("key")
mc.decr("key")
print  mc.get("key")
root@Arduino:chmod 755 /mnt/sda1/memcacheyun.py
root@Arduino:/mnt/sda1/memcacheyun.py
Some value
None
2
1