@György-Farkas

Many thanks!

I have the standard expansion dock for the Omega 2: https://docs.onion.io/omega2-docs/expansion-dock.html

I am trying to build a mos-fet bi-directional logic level shifter as seen on page 10 of this document: https://cdn-shop.adafruit.com/datasheets/an97055.pdf

My question is about the 3.3v side of the schematic. I have been unable to find any documentation on whether the Omega2 or the Expansion Dock includes pull up resisters for the I2C lines.

Do I need to add these resisters, are they already built into the Omega2/Expansion Dock, or is there some other reason I don't need them? All of the documentation I've read on using I2C with the Omega2 has suggested that the I2C lines should be plug'n'play, but I don't want to risk my Omega2 on an assumption.

I'm trying to use the Omega2 as a jumping off point for better understanding how to get chips to communicate and do things, so any information on how this works (besides standard I2C communication standards) and how the Omega2 differs from the norm would be greatly appreciated.

Thank you.

Just a quick word from some of my own frustrated testing with I2Cdetect:

The reason -q causes the false positives to disappear is because -q is "quick write". It tells you this if you leave out -y, since -y removes the prompt that tells you what's going on.

Conversely, you will get nothing but false positives if you instead use -r, which is "read" the first byte of every address to find out who's where.

I think this has to do with how reading from something that isn't there results in 0xff.

If you've managed to get I2C working with your Omega2, I'd be real interested in hearing what your setup is. I'm about two seconds away from giving up on the I2C libraries and just bit banging to figure things out.

Is there any additional control over the GPIO pins than what is offered in the Omega2 Software Libraries documentation? It feels like the OnionGpio library only offers the control of the gpioctrl command, leaving out the fast-gpio command's pwm and pulse abilities.

If there's another source of documentation out there, I'd be delighted to know about it. So far all of my learning has been controlling simple IC chips as I dip my toes into the world of micro-controllers for the second time. Last time my experience ended in frustration due to a lack of clear documentation of how to control the micro-controller parts from the coding language given (C in this case).

I've been happily avoiding that outcome with all of the -help options and the straight forwardness of linux (and google's help), but I've started growing concerned that when I finally move up to controlling more complex things it's going to fall apart.

Let me know if there's any additional documentation out there you folks are using.

So after trying out quite a few different power ramp circuits from around the web to make an LED "breath", I decided I would give using pwm to change the brightness of the LED. Calling fast-gpio pwm 1 50 50 seemed to have the desired results, and other calls with varying duty percents had the desired effect. The LED would brighten or dim to about what you'd expect calling 10%, 50% or 100%. 50Hz also seemed to be the minimum frequency I could go to before the flicker became noticeable.

So then I wrote a python script to cycle from 1% duty cycle up to 100% and then back down to 1%. The script worked great! I could watch the LED brighten and dim over the course of a few seconds, but the flicker became very noticeable. I figured I'd crank the frequency up, so I set it to 5000 and ran the script again. Again, the flicker showed up. I tried 1000Hz, 2000Hz, numbers in between, but never got the flicker to go away.

So I figured, maybe it's because of the amount of time I'm waiting between duty changes. So I shortened the time between changes from 0.5 to 0.1, then to 0.01, then to 0.001. While the flickers became less noticeable at 0.1, that seemed to be as good as it got. Any subsequent fractions of a second didn't improve the situation.

Is this a limitation of the hardware? Is fast-gpio pwm doing something that causes the pin to go low between calls, creating the flicker? Is there a way around fast-gpio that I can call on to change the pwm duty percentage without re-calling the whole command?

Let me know if you've encountered this too and what you did to get around it! Right now those ramp circuits are looking pretty good...

Code below, in Python:

import os
import sys
import time
import subprocess

duty=1
pulse="50"
sleeper=0.001
min=1
max=100
direction="up"

read="fast-gpio read 2"
pwm="fast-gpio pwm 1 " + pulse + " "

high="> Read GPIO2: 1\n"

os.system("gpioctl dirout 1")
os.system("gpioctl dirin 2")

status = subprocess.check_output(read, shell=True)

while(status != high):
        print(duty)
        if(duty == max):
                direction="down"
                duty = duty - 1
        elif(duty == min):
                direction="up"
                duty = duty + 1
        elif(duty > min and direction == "up"):
                duty = duty + 1
        elif(duty < max and direction == "down"):
                duty = duty - 1
        status=subprocess.check_output(read, shell=True)
        os.system(pwm + str(duty))
        time.sleep(sleeper)

os.system("fast-gpio set 1 0")

For anyone having the same issue, I believe I solved the issue after some tweaking.

The issue seems to be that I wasn't setting pin 3 to be input before trying to read from it.

Adding the line os.system("gpioctl dirin 3") solved the crashing issue. Alternatively you could replace gpioctl dirin 3 with fast-gpio set-input 3.

I'm a little concerned that the error wasn't handled better. I don't know if that fault is on Python or my Omega2, though.

Anyways, happy coding everyone!

Greetings fellow Onioneers!

I've been picking up Python since the ash shell sleep function can't sleep for less than a second and I thought it would be more fun to learn a new language than to relearn one I learned a lifetime ago. That's not to say I'm new to coding. I'm no expert, but I've dabbled for some time.

My issue is coming from a (seemingly) simple script I wrote for Python to play with what I thought would be some simple tasks to eventually build up to a larger project I have in mind a proof of concept if you will.

The script it meant to work as follows:

Script starts 
Pin 0 is set to out, pins 2 and 3 are set to in 
Pin 0 is set high to turn on an LED 
The script loops until the button is pressed, polling pin 2 every .1 second to see if the button has been pressed 
On press, the pin 0 goes low, the script sleeps for 2 seconds 
Script loops until pin 3 reads high, where the script simply stops.

This script doesn't contain anything I haven't used previously in smaller (5-10 line) scripts, but it causes my Omega2 to reboot when run! Is there something in my script in particular that is causing this? I can't read the dump that it gave before restarting, so any direction would be helpful to me.

I am running firmware version 0.1.6 b137 as last I checked, the latest version contained an error that made the Omega2 throw errors when trying to use gpioctl or fast-gpio. If this has changed, let me know!

Here's the code as it was run:

import os
import sys
import time
import subprocess

lampstate = "off"
lamppin = "0"

buttonpin = "2"
stoppin = "3"
loopstate = "start"
#loopstate = "stop" #for debugging

sleeper = "0.1"

readpin = "fast-gpio read "
setpin = "gpioctl dirout-"
high = "high "
low = "low "

os.system("gpioctl dirin " + buttonpin)
os.system("gpioctl dirout " + lamppin)

#sys.exit()
#print("exit did not work")
while(loopstate != "stop"):
        button2 = subprocess.check_output(readpin + stoppin)
        if(button2 == "> Read GPIO" + stoppin + ": 0"):
                loopstate = "stop"
        else:
                button1 = subprocess.check_output(readpin + buttonpin)
                if(button1 == "> Read GPIO" + buttonpin + ": 1" and lampstate == "on" ):
                        os.system(setpin + low + lamppin)
                        lampstate = "off"
                        time.sleep(2)
                elif(lampstate == "on"):
                        time.sleep(sleeper)
                else:
                        os.system(setpin + high + lamppin)

And here's the dump:

root@Omega-9D45:/csm/learning# python button.py
[ 2219.519209] CPU 0 Unable to handle kernel paging request at virtual address 00000098, epc == 00000098, ra == 8004f1fc
[ 2219.529986] Oops[#1]:
[ 2219.532301] CPU: 0 PID: 1773 Comm: python Tainted: G        W       4.4.39 #0
[ 2219.539540] task: 839c5e00 ti: 82fce000 task.ti: 82fce000
[ 2219.545013] $ 0   : 00000000 7ffaa930 00000098 803d0000
[ 2219.550332] $ 4   : 803d1890 00b33790 00000018 00b33790
[ 2219.555644] $ 8   : 1100e400 1000001f 6e656720 74617265
[ 2219.560955] $12   : 62206465 771052b0 00000000 72732079
[ 2219.566268] $16   : 803d1880 803d6100 00b33790 fffffffe
[ 2219.571581] $20   : 00b33788 00b33770 00000017 00b337d0
[ 2219.576893] $24   : 00000000 770cd9c8
[ 2219.582205] $28   : 82fce000 82fcfed8 76ed6000 8004f1fc
[ 2219.587520] Hi    : 00000008
[ 2219.590437] Lo    : 00000000
[ 2219.593361] epc   : 00000098 0x98
[ 2219.596744] ra    : 8004f1fc handle_percpu_irq+0x48/0x80
[ 2219.602125] Status: 1100e402 KERNEL EXL
[ 2219.606113] Cause : 50808008 (ExcCode 02)
[ 2219.610174] BadVA : 00000098
[ 2219.613094] PrId  : 00019655 (MIPS 24KEc)
[ 2219.617154] Modules linked in: pppoe ppp_async iptable_nat w1_therm w1_gpio uvcvideo snd_usb_audio pppox ppp_generic pl2303 nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ftdi_sio cp210x ch341 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG wire videobuf2_v4l2 usbserial usblp usbhid ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda uinput spidev snd_usbmidi_lib slhc rfcomm nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables hidp hid_generic hci_uart crc_ccitt cdc_acm btusb btintel bnep bluetooth snd_soc_simple_card snd_soc_ralink_i2s snd_soc_wm8960 videobuf2_vmalloc videobuf2_memops videobuf2_core hid v4l2_common videodev evdev snd_soc_core ralink_gdma virt_dma mt76x8 ralink_eeprom_api ledtrig_oneshot ledtrig_morse ledtrig_heartbeat ledtrig_gpio ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables msdos snd_pcm_dmaengine snd_compress snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_rawmidi snd_seq_device snd_hwdep snd input_core soundcore vfat fat ntfs autofs4 nls_utf8 nls_iso8859_1 nls_cp437 regmap_i2c dma_shared_buffer ecb cmac usb_storage sdhci_pltfm sdhci leds_gpio ohci_platform ohci_hcd ledtrig_transient ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 jbd2 mbcache exfat usbcore nls_base usb_common crc16 cryptomgr aead crypto_null crc32c_generic crypto_hash
[ 2219.762702] Process python (pid: 1773, threadinfo=82fce000, task=839c5e00, tls=77106e50)
[ 2219.770900] Stack : 01f00006 800c30f8 00000001 00400000 82fcff08 00000007 00000020 8004b6c8
          803cb360 80368188 00000000 770370c8 00001800 80011530 76fe7934 00af46e0
          00000001 7ffaa95f 00000000 80004430 00000001 77c67320 00000001 00000000
          771052b0 00bca800 7ffaa95f 00000000 00000000 7ffaa930 00b337e0 00b337e0
          00b337f0 00b33790 00000018 00b33790 770f013e fefefeff 6e656720 74617265
          ...
[ 2219.807029] Call Trace:
[ 2219.809521] [<800c30f8>] __fdget_pos+0x14/0x60
[ 2219.814066] [<8004b6c8>] generic_handle_irq+0x24/0x3c
[ 2219.819209] [<80011530>] do_IRQ+0x1c/0x2c
[ 2219.823277] [<80004430>] ret_from_irq+0x0/0x4
[ 2219.827696]
[ 2219.829202]
Code: (Bad address in epc)
[ 2219.833179]
[ 2219.834776] ---[ end trace 09977ba32a719a8d ]---
[ 2219.843451] Kernel panic - not syncing: Fatal exception in interrupt
[ 2219.852185] Rebooting in 3 seconds..