Posts made by Bryan Hilterbrand

Thank you Maximilian for your help!

I found more information in another post, and I don't know why they haven't included this information in the Cross-Compiling for the Omega documentation.

José Luis Cánovas included these instructions in his Docker SDK post:

You must add the onion feeds (work in progress for my docker image, in the meantime do it manually) to the file feeds.conf.default (check WereCatf's first_time_setup.sh), update the feed and add the onion packages:
scripts/feeds update -a
scripts/feeds install -a
Then, from make menuconfig select the onion libraries (Onion -> Libraries/Utilities -> select as [M]odule).
...
[run make here to compile the toolchain]
...
When make finishes, an ls staging_dir/target-mipsel_24kc_musl/usr/lib/ (note the penultimate /usr/ directory) shows:

omega@dee42fad6a75:/lede$ ls staging_dir/target-mipsel_24kc_musl/usr/lib/
[...]  liboniondebug.so [...]  libonioni2c.so [...]  libonionspi.so [...]

and many more onion and non-onion libraries.

And inside staging_dir/target-mipsel_24kc_musl/usr/include/:

omega@dee42fad6a75:/lede$ ls staging_dir/target-mipsel_24kc_musl/usr/include/                                         
[...] onion-spi.h   [...]   onion-debug.h   [...]   onion-i2c.h   [...]

Note: I didn't need to add the Onion feeds to the feeds.conf file - the scripts/feeds script worked without any modifications.

I wish it were a little more clear about which libraries, etc. to select on the make menuconfig, because I found multiple items that were related to I2C. So I just picked the ones that looked right...hopefully that doesn't mess me up too much.

Okay, now we're getting somewhere! I don't have any libonionXXX libraries in my cross compiler toolchain. How do I get them in my toolchain?

I used the "Cross-Compiling for the Omega" article to set up a cross compiler environment in Ubuntu, and I was able to get a HelloWorld executable to run on the Omega 2+. I want to move on to some more challenging territory and create an executable to talk to I2C devices, but I can't figure out how to get I2C support in my cross compiler environment. Any hints/tips would be greatly appreciated!

Thanks,
Bryan

Austin, this looks great! Thanks for the code.

I will be hooking up a similar device to my Omega2+ soon (an AM2315). Did you have to use a pull-up resistor or any other parts when you hooked up the BME280 to the Omega2?

I stumbled across a possible wifi fix for some people. Our wireless network is on 192.168.3.X, and I happened to notice that the ethernet bridge stub is pre-configured as 192.168.3.1. I changed the ethernet bridge stub IP address to 192.168.5.1 (a network we don't use), and my wifi started working.

If you're having wifi issues on a 192.168.3.X network, try editing /etc/config/network, look for the 'wlan' interface, and change "option ipaddr '192.168.3.1'" to "option ipaddr '192.168.5.1'" (or some other network not in used).

Software serial is often problematic even at low speeds due to the multi-tasking nature of Linux.

Have you thought about getting a proto board and wiring up an I2C UART?

@PK-Shiu, you're right, oled-exp should be updated as well. oled-exp is the command line tool for accessing the OLED screen, so it doesn't matter when you're using Python.

opkg upgrade oled-exp --force-depends

Thank you, @Lazar-Demin, it appears to be working great!

Here's my test program for those who are interested.

#!/usr/bin/python

import OmegaExpansion.oledExp as oled

oled.driverInit()
oled.setDisplayPower(1)
oled.setDisplayMode(0)
oled.setImageColumns()
oled.clear()

oled.setCursorByPixel(0, 0)

oled.writeByte(0x3C)
oled.writeByte(0x42)
oled.writeByte(0x89)
oled.writeByte(0xA1)
oled.writeByte(0xA1)
oled.writeByte(0x89)
oled.writeByte(0x42)
oled.writeByte(0x3C)

I'm ignoring the status return from writeByte (and probably a few other API's too). The output should be a tiny face on the OLED. I tried to do a smiley, but there wasn't enough space in an 8x8 block

Bryan.

Not only did I have to force my Onion to update the Python OLED library, I also had to force it to update the C library:

opkg upgrade libonionoledexp --force-depends

@Zheng-Han, thank you - that sounds better! Tony's post made me think that there weren't any easy connections to the DIP pins.

@Anthony-Wakefield, so the proto expansion board is just a proto board with a DIP connector and there aren't any connections between the DIP connector and the rest of the proto board?

If that's the case, how are you supposed to access the pins if you're stacking boards?

@Rudy-Trujillo it looks like a number of people have used USB cameras. I'm curious why that isn't a good solution for you?

Thank you @Lazar-Demin!

@Boken-Lin no problem on reading, but I'd still like a way to send a byte (or a list of bytes) to the screen. That would allow me to make my own fonts, special characters, or images to send to the OLED screen.

Thanks @Boken-Lin! That fixed the garbage along the right side of the screen.

Now is there any chance I can get an interface to write a byte to an individual column and page? Extra credit if I can read the byte that is currently there!

Bryan

I finally got around to hooking up the OLED screen and playing around with it. I created a small, Python program to write a simple message to the screen. First, there are some random bits set on the right edge of the screen. Is this a hardware problem or a problem with the Python clear()?

#!/usr/bin/python
import OmegaExpansion.oledExp as oled

oled.driverInit()
oled.setDisplayPower(1)
oled.setDisplayMode(0)
oled.clear()

oled.setCursor(0, 0)
oled.write("Hello")
oled.setCursor(2,0)
oled.write("World!")

Produces the following screen:

So is there a way to get rid of the pixels that are lit up?

Is there a way to write individual bytes (from Python) to produce my own characters?

Thank you!
Bryan

@Boken-Lin said:

Which operating system are you using currently?

I'm using Ubuntu (Kubuntu) 15.10 64-bit (AMD64). My OS is running under VMWare, so there's a fair chance I could match whatever environment you told me to. I will note that compiling OpenWRT using your instructions (Setting Up the Cross Compile Environment) took well over an hour in VMWare!

I'm puzzled like Kit Bishop why OpenWRT won't just run an executable, but I'm used to cross-compiling to uClinux so there must be some differences. I'm going to start playing around with adding a small package to see if I can get something to run on the Omega.

Boken,

I read through the link you provided about the cross-compile environment. It looks like you have to download and compile the entire OpenWRT OS just to get the cross-compile environment.

I'm not interested in tinkering with the OS or creating packages at this point - I just want to compile some small executables. Isn't there a cross-compile toolchain somewhere that would just allow me to compile executables?

Bryan