I have noticed several posts relating to issues with using opkg to install packages.

So I thought some reminders/hints relating to its usage may be appropriate:

1. MOST IMPORTANT opkg does NOT remember its package list over a reboot/power off. Therefore it is essential that before trying to install a package you do:

   opkg update
   

   then try the install again

2. Some of the repositories in /etc/opkg/distfeeds.conf are commented out and the package you want may be in one of these commented out repositories. So, edit this file and rerun opkg update before trying to down load a package that has failed.
   Not sure why some are commented out, probably systems still in a bit of a state of flux pending updates.

3. The following command is your friend when looking for what you want:

   opkg list | grep <partial-name>
   

   where <partial-name> is part of what you think the package may be called.
   This will give you a list of all packages that have <partial-name> somewhere in their name.
   A package is not always called exactly what you think it might be

4. Do:

   opkg help
   

   to get a list of all the opkg options and commands and spend a bit of time exploring them and their usages.

Enjoy

After battling with this for quite some time, I finally have success with what I've been wanting to do
Ended up being quite straightforward - I think I got bogged down in all the intricacies of building OpenWRT packages when all I wanted to do was build some basic C/C++ programs that would run on the Omega.

For the record, in case it is of help to others, this is what I ended up doing based largely on the info in:http://techfindings.one/archives/1487
For the record my host system for the compilation is a pretty standard KUbuntu-14.04 system running in a VM under VirtualBox

• Download the tool chain from https://s3-us-west-2.amazonaws.com/onion-cdn/community/openwrt/OpenWrt-Toolchain-ar71xx-generic_gcc-4.8-linaro_uClibc-0.9.33.2.Linux-x86_64.tar.bz2
• Unpack it to some suitable directory (referred to below as <tc_dir>)
• Set up environment variables as follows (I put this in my ~/.profile file so it was always there):
• • PATH=<tc_dir>/OpenWrt-Toolchain-ar71xx-generic_gcc-4.8-linaro_uClibc-0.9.33.2.Linux-x86_64/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/bin:$PATH
• • STAGING_DIR=<tc_dir>/OpenWrt-Toolchain-ar71xx-generic_gcc-4.8-linaro_uClibc-0.9.33.2.Linux-x86_64/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2
• • export STAGING_DIR
• Create your c program - e.g. test-prog.c
• Compile the program using (e.g.): mips-openwrt-linux-uclibc-gcc test-prog.c -o test-prog
• Transfer the output file (test-prog) to your Omega using you favourite tools.
• On the Omega in the directory you placed the file, run it by: ./test-prog - and there you are

I'm sure there will be other issues (e.g. using a makefile with multiple sources; access to libraries; building dynamic link libraries which I will want too), but these are all pretty standard development issues now that I have the code cross-compilation working.

I have produced an extensive suite of code providing the Omega with access to GPIO pins, I2C devices and attached Arduino systems.

All code and documentation is available in GIT Hub at https://github.com/KitBishop/Omega-GPIO-I2C-Arduino

In summary, this provides the following:

Omega-GPIO-I2C-Arduino

A suite of libraries and programs that provide access on the Omega to GPIO pins, I2C devices and connected Arduino systems.

The components that make up the suite are:

• libnewgpio – a C++ library for access to Omega GPIO pins
• libnewi2c – a C++ library that provides Omega access to I2C devices
• libarduino – a C++ library that provides Omega access to Arduino systems connected via I2C; makes use of the libnewi2c library on the Omega and requires use of arduino-omega based code on the connected Arduino
• arduino_omega – source for an Arduino C++ library to run on an Arduino to allow access from the Omega libarduino code
• iotemplate – a template for a C++ program that can be used as the basis for user written code that makes use of libnewgpio and/or libnewi2c and/or libarduino libraries on the Omega
• i2cscan – a simple standalone program that scans for the existence of I2C devices connected to the Omega. Makes use of the libnewi2c library
• gpioirq – a simple standalone program that triggers execution of user supplied commands on interrupt(s) from Omega GPIO pins. Makes use of the libnewgpio library
• gpioexpled – a simple standalone program for control of the Omega Expansion Dock LED. Makes use of the libnewgpio library
• omegaio – a sophisticated standalone program that provides full command line access to the functionality in libnewgpio, libnewi2c, libarduino libraries on the Omega. Provides some basic scripting facilities

See file Omega-GPIO-I2C-Arduino.pdf for overview documentation

This new code supersedes that previously published at https://github.com/KitBishop/new-gpio which is no longer supported.

@Steve-Fister , @Andrew-Nixon I agree as well.

I hope no one minds, but because it seems to me that Cooler IoT solution is so out of place, I have sent an email to the people responsible for the awards at the email address referenced under Contacts on the http://iotawards.postscapes.com/rules site (support@postscapes.com) indicating that it seems out of place along the lines of @Steve-Fister 's comment.

@Frederic-Baumann Hi, a few comments and pointers on programming in C/C++ for Omega:

1. The Omega does not have sufficient memory resources to run a C/C++ build tool chain
2. Since you are on Windows (as I am), your best bet is to set up a VM (VirtualBox or Vmware) running a standard Linux distribution - I use Kubuntu 14.04 and run cross compilation from there. It is possible to gain direct access to the Omega from the Linux VM so long as the VM networking is set up correctly.
3. The following two posts may be of assistance to you - they cover what I am successfully doing for cross compilation of C/C++ code for the Omega:
   • https://community.onion.io/topic/9/how-to-install-gcc/20
   • https://community.onion.io/topic/125/using-netbeans-to-compile-c-c-code-for-omega

Hop these help

Using pivot-overlay (or pivot-root) on a USB drive is a good way to give yourself more usable system disk space. There has recently been some communication about this for the Omega2

When attempting to follow the Omega1 instructions at https://wiki.onion.io/Tutorials/Using-USB-Storage-as-Rootfs problems have arisen over the ability to install the block-mount package and it has been surmised (by me as well as others :-() that a different method was needed for the Omega2

I can now indicate that the original Omega1 instructions as above work so long as you do the following to get block-mount: This is all using the latest system image 0.1.8 b451:

1. Edit the file /etc/opkg/distfeeds.conf and un-comment the line:

   src/gz reboot_core http://downloads.lede-project.org/snapshots/targets/ramips/mt7688/packages
   

2. After making this change, re run:

   opkg update
   opkg install block-mount
   

Then the instructions in https://wiki.onion.io/Tutorials/Using-USB-Storage-as-Rootfs work fine on the Omega2 - I've done all this and it works

I also have no reason to believe that this would not also work with an SD card.

I would agree with @fossette .
Additionally, suitable batteries are available from Adafruit that come with the right kind of connector:

• 2000 mAh - https://www.adafruit.com/products/2011
• 2500 mAh - https://www.adafruit.com/products/328
• 4400 mAh - https://www.adafruit.com/products/354
• 6600 mAh - https://www.adafruit.com/products/353

I have used the 2500 mAh one with the Power Dock for quite some time and it works well

The most common cause of relays sticking is because of micro-welding of the contacts caused by arcing when the contacts close/open.
This can occur even when the current being switched is within the rating of the relay.
This micro-welding can usually be broken by suitable mechanical shock - i.e. giving them a knock
When the circuit being driven is subject to an increased current surge on making contact - e.g. when switching an incandescent bulb, the initial cold current can be significantly greater than the normal operating warm current

Normal suggestions to minimise this micro-welding are:

• Try driving the relay with a higher current so the relay operates faster closes faster to reduce possible arcing time - though I don't see how this could be done with the Relay Expansion
• Use a relay with a stronger return spring so it opens faster to again reduce arcing time - again not possible on the Relay Expansion without physically replacing the relays
• Use some suppression across the contacts to reduce the arcing - e.g. connect a capacitor across the contacts (i.e. from the In to OUT connections) - I am not enough of an electrical engineer to suggest a suitable value for the capacitor but it should have a voltage rating high enough for the circuit being switched and if switching AC it should NOT be an electrolytic capacitor.

Finally, if the problem really is being caused by the relays on the Relay Expansion not being rated highly enough for the circuit being switched, you could use the Relay Expansion relays to switch separate external relays that have a higher rating

@Gwena56 As promised, I have sorted out the code for the 16x2 LCD.

Some photos:

In the photos, the wires are:

• black - ground
• red - 5v
• green - I2C SCL to Omega Pin 20
• yellow - I2C SDA to Omega Pin 21

The software (attached below) should be usable on any 16x2 or 20x4 LCD that has I2C interface provided by LMC1602 or similar.
Depending upon your actual LCD device, you may have to change the configuration in the source code in the file i2clcd16x2.cpp as described in that file and re-build the application.

The code is provided in the following files:

• i2clcd16x2-src.tar.bz2 - contains all required source code including a Makefile. To build the code you will need to have set up cross compilation as described in :
  • https://s3-us-west-2.amazonaws.com/onion-cdn/community/openwrt/OpenWrt-Toolchain-ar71xx-generic_gcc-4.8-linaro_uClibc-0.9.33.2.Linux-x86_64.tar.bz2
  • https://community.onion.io/topic/9/how-to-install-gcc/22

You will probably need to edit the Makefile to give the location of the toolchain

• The important source files are:

  • I2cAccessSystem.cpp - provides general access to I2C on the Omega
  • I2CDevice.cpp - provides a class to represent a specific I2C device
  • LCD_I2C.cpp - provides a class to represent a specific I2C LCD

• The filei2clcd16x2 is a built program that works for my I2C LCD device, but you may need to modify and re-build it if your device is different.
  This program is a very simple program to display two lines of text on the LCD and is run as ./i2clcd16x2 "<line-1-text>" "<line-2-text>"

Hope this is all helpful - let me know if I can help further.

@Anthony-Naddeo I agree with @Brian-Piersel. On my system / and /root are not read only:

Doing:

• cd /
  ls -l
  Clearly shows /root as drwxr-xr-x - i.e. full access as root - the only user that you can use on the Omega (see belwo)

• mount
  Shows rootfs on / type rootfs (rw) - i.e. / is mounted for read and write

So, unless there is something wrong/odd with you Omega, you can just use /root for your own files
However, before doing so, I would urge that you ensure that your Omega is upgraded to the latest firmware using the command oupgrade - earlier versions of the firmware would cause the contents of /root to be lost over an oupgrade

Regarding adding other users: The Omega runs a very much cut down version of Linux - OpenWrt - originally intended for embedded systems such as routers and the like. As such, it does not have the capabilities for adding additional users. Everything has to be run as root

Finally, regarding available space: if you are concerned about insufficient space on your Omega, you can increase space using a USB drive and following the instructions described here: https://wiki.onion.io/Tutorials/Using-USB-Storage-as-Rootfs
I have done this using a 32GB USB thumb drive and it works well. This will add effective disk space up to the size of your USB drive.
If you need more usable RAM space, you can even set up your Omega with a swap drive using information described in: https://community.onion.io/topic/9/how-to-install-gcc/47
I am currently doing this to provide 1GBytes of swap space

@Lazar-Demin Absolutely fantastic! Thank you very much

Have upgraded to b266 and everything works perfectly - including my GPIO IRQ and test program.

My IRQ code is basically an extension to the code I have previously posted for new GPIO access (https://community.onion.io/topic/143/alternative-c-code-for-gpio-access) with the addition of IRQ handling capabilities.

Because it may be of use to others, I will do the following:

1. Send the test program and needed library with some basic documentation on its use in a separate post
2. Later, update the package and details in https://community.onion.io/topic/143/alternative-c-code-for-gpio-access with the latest sources and full documentation

@Rudy-Trujillo Further to the good comments from @Andrei-Railean the following tips about opkg may be helpful (but always do a opkg update first):

• opkg list takes wild cards, so a similar effect can be had by doing (e.g.): opkg list *python*
• opkg info <package> is helpful for details about a particular package
• Using opkg without any commands or parameters will give a helpful summary of the available commands and parameters

In case anyone is interested, this is a brief report on my progress with Java on the Omega.
What I have done so far:

• Set up my Omega to have more space for /overlay directory on a USB drive using the pivot-overlay method described in https://wiki.onion.io/Tutorials/Using-USB-Storage-as-Rootfs
• Installed jamvm using:
  • opkg update
  • opkg --force-depends install jamvm
    Note that --force-depends is needed to deal with kernel/repo version mismatches - it doesn't seem to cause any problems with this
• Using NetBeans 8.1 (on my host KUbuntu system) created a small Java project and built it
• Copied the resultant .jar file to my Omega
• Ran the .jar file using:
  jamvm -jar <jar-file-name>

It all ran exactly as hoped

I will now proceed with the following:

• Based on the work I am doing on my new GPIO access code (https://community.onion.io/topic/143/alternative-c-code-for-gpio-access) I will be producing some C++ JNI code
• Write some Java classes that will access this GPIO JNI code to provide direct Java access to GPIO
• As and when I get to it I will do similar for access to I2C etc.

I have produce some alternative C++ code for accessing GPIO since I wanted some additional capabilities over those provided by fast-gpio.

Rather than detailing what I have done in this post, I attach to this post an archive file (new-gpio.tar.bz2) that contains all the relevant files including documentation in the file PDF new-gpio.pdf included in the archive.

Note that this is an ongoing work and there will be updates in the future.

I would be most interested in any comments, feedback etc. from others.
Attached file: new-gpio.tar.bz2

@patrick-gunderson Great, thanks.

Pity there is still not decent clarity between Omega1 (e.g. as at https://wiki.onion.io/Documentation/Hardware/Technical-Drawings/Omega-and-Expansions-Technical) and Omega2 (e.g. as at https://github.com/OnionIoT/technical-drawings)

Also:

• Despite the existence of drawing at https://github.com/OnionIoT/technical-drawings, it is a pity that some of the links in the Hardware Overview section (at https://docs.onion.io/omega2-docs/hardware-overview.html)are dead
• The Arduino Dock 2 drawing in https://github.com/OnionIoT/technical-drawings at https://github.com/OnionIoT/technical-drawings/blob/master/Mechanical/OM-D-ARD.PDF are clearly thos of the original Arduino Dock and don't match the image at https://raw.githubusercontent.com/OnionIoT/Onion-Docs/master/Omega2/Documentation/Hardware-Overview/img/arduino-dock-alone.jpg - e.g. the drawings don't show the GPIO header

@Costas-Costas @Steven-Brent Using a USB drive is a good way to go (I use it all the time) but note that there is a small issue with the instructions at https://wiki.onion.io/Tutorials/Using-USB-Storage-as-Rootfs which were originally for the Omega1 and you should also see my post https://community.onion.io/topic/1295/more-system-disk-space-using-pivot-overlay-and-pivot-root-on-the-omega2

@Jun-Cao I can confirm that the trick with /etc/sysupgrade.conf works
I did the following:

• Created two directories in /
  • /testa
  • /testb
• Changed /etc/sysupgrade.conf to have line:
  • /testa/
• Ran oupgrade -force
  Note that the -force option forces an upgrade to occur even if it isn't needed
• Checked the directories after the upgrade:
  • /testa still existed - it was named in /etc/sysupgrade.conf
  • /testb no longer existed - it was not named in /etc/sysupgrade.conf

@Ahmed-Mkadem I compile C/C++ using cross compilation on a Linux system (I use Kubuntu).
Some details can be found at https://community.onion.io/topic/9/how-to-install-gcc/22

You may also be interested in the set of C++ libraries and programs I have produced for perfroming GPIO, I2C and Arduino access on the Omega. The full set of these can be found at https://github.com/KitBishop/Omega-GPIO-I2C-Arduino The various documentation .pdf files therein give more details.

You might in particular look at the template program that is included in the above referenced package - see https://github.com/KitBishop/Omega-GPIO-I2C-Arduino/tree/master/iotemplate and its documentation at https://github.com/KitBishop/Omega-GPIO-I2C-Arduino/blob/master/iotemplate/iotemplate.pdf

Hope that helps

@Dan-Dickerson Unfortunately, I don't know a way to do this directly.
The cross compilation systems that you need are all only available for Linux systems.
While there are methods of running Linux programs under Windows (e.g. cygwin, msys) the cross compilation systems require the underlying OS to be case sensitive for file names and Windows in only case preserving, not case sensitive.

There is an indirect way that I use and which works but is a bit of a hassle.
While I normally work under Windows, I am quite happy using Linux systems. So, I have set up a Kubuntu Linux system running in a VM (I use VirtualBox) under Windows and do my Omega program compilation in the Kubuntu VM. Once it is all set up, it is reasonably usable and flexible.
I use a combination of command line to run make on Makefiles and the Netbeans IDE under Linux to produce the Omega code with the cross compilation systems.
I can access my Omega directly from the Linux VM and also have access (should I need it) to files on the host windows system.

@Gary-Saini It is possible to use other IDE's.
For example, I use Netbeans IDE running under Kubuntu.
For compiling C/C++ it is necessary to install the cross compilation environment and setup Netbeans to reference the environment. The resulting built binary file can then be transferred to the Omega (using e.g. scp) and run from there. While it is also possible to set up Netbeans to also transfer the binary automatically to the Omega.
Netbeans projects can be used to either use the standard C/C++ build methods or to use a specific hand crafted Makefile - I generally use the Makefile method (it is a bit easier to set up and I have a template Makefile that I tailor to any specific project). I have done this to build standalone programs and both static and dynamic libraries.
I have also used Netbeans to build Java programs (for running on the Omega under jamvm).