Jump to content

jscax

Members
  • Posts

    43
  • Joined

  • Last visited

Everything posted by jscax

  1. My findings so far (some of the previous findings are wrong): - Audio will work on one channel only. No matter whether is LINEOUTR or LINEOUTL connected, but OPI0 is allowing only one channel alone, otherwise the board will crash horribly. The green status light glows a little bit then turn off and the board reboots. Seems like a bad short circuit or something. I tested LINEOUTR and LINEOUTL alone and both are working. So there's something wrong in the stereo configuration. - Audio loops were caused by bad settings on the alsamixer. Now I'm able to start playback in background and open multiple ssh sessions. Attached the screenshot of my alsamixer working settings. ("DAC Reverse": what?) Now I would like to have working stereo sound. Welcome to ARMBIAN 5.38 stable Ubuntu 16.04.4 LTS 4.14.18-sunxi analog-codec layer enabled in /boot/armbianEnv.txt Any hint?
  2. audio is continuing to work using only one channel. The audio will enter in loop when more than one ssh instance is created. If I create first ssh instance then start the music and leave this alone there's no problem. If I then connect with a second ssh I have audio loop. [update] from the attached imaged seems like we need some electronics to make this work? correct? I'm using a PAM8403
  3. I have the same issue but I'm not resolving. I'm not connecting left and right negative toghether. If I understood correctely and that was the issue there. I've negatives from speakers (left/right) connected separately on their negative. I've enabled analog-codec I can see the audio card but can't play sound but noise and then crash when attempt to start to play. [update] It works connecting the "LINEOUTL" pin only! Connecting even the LINEOUTR channel results in a kernel panic and reboot when you attempt to play something. Has anyone gone into this? Solution? After some playing time, like 20 seconds it crashes even in LINEOUTL alone configuration. It's like repeating the same 0.2seconds of song forever and only solution is to turn off the electricity. thank you
  4. it's a super easy/normal uart communication and it just works following the datasheet protocol specification
  5. ok, the uart layeroverlay should be a good point to start with thank you
  6. Hi all, I'm trying to understand how to make an infrared tx/rx module working. This is the module: https://www.aliexpress.com/item/5V-IR-Infrared-Remote-Decoder-Encoding-Transmitter-Receiver-Wireless-Module/32528109291.html Is there a way to make this works in userspace? Overlays? From the docs I was only able to understand how to enable existing overlays. I enabled cir, this is from my armbianEnv.txt: overlays=cir i2c0 but I don't know how to configure pins: which is rx which tx. Do I need to write down a new/custom overlay? I think that configuring pins is crucial to enable IR communication at some level but I don't know how and where. In the OPi0 world seems like all IR is about the expansion board which I don't have and I don't need because what's important to me is to send IR signal, more than receiving. Last but not least I found this: https://github.com/Aschhoff/Orange-Pi-Infrared which is pyA20 powered and so root dependent and I would like to find a rootless solution, if possible. Please, can someone point me in some direction? thank you very much and pardon me for being such a newbie asshole
  7. did you went on this? is it all working? thank you
  8. I have not updated yet. I can't understand if this can affect my OPI zero or not. Can you please point this out?
  9. yep https://github.com/rm-hull/OPi.GPIO this library do that but in my experience need to be patched ( ) with the "sleep" hack to work.
  10. my findings about my Orange Pi Zero so far... create group gpio if you do not have one and then add the users you need to it vim /lib/udev/rules.d/60-python3-gpio.rules: KERNEL=="spidev*", GROUP="spi", MODE="0660" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chown -R root:gpio /sys/devices/platform/soc/1c20800.pinctrl && chown -R root:gpio /sys/devices/platform/soc/1f02c00.pinctrl && chmod -R ug+rw /sys/class/gpio && chmod -R ug+rw /sys/devices/platform/soc/1c20800.pinctrl && chmod -R ug+rw /sys/devices/platform/soc/1f02c00.pinctrl'" Reboot to test it directely from bash. Then this library had my attention: https://github.com/rm-hull/OPi.GPIO I had to patch it because as it is it was not working and I had once again a permission issue from userspace. Inside OPi.GPIO/OPi/sysfs.py you can import time then add a little bit of sleep: def direction(pin, dir): assert dir in [IN, OUT] #insert sleep time.sleep(0.1) path = "/sys/class/gpio/gpio{0}/direction".format(pin) with open(path, "w") as fp: if dir == IN: fp.write("in") else: fp.write("out") In this way the library is working rootless, in the userspace. This solution works for my relays but I don't know if I can read DHT22 sensor with this library (implementing all the stuff eventually). If I understood correctly this is "slow" way to access GPIO not compatible with DHT22 readings. A workaround should be I2C sensor (which I have and I plan to integrate in the future) and for which I hope I will have rootless access with no issue. At the moment for the DHT22 readings I've gone the visudo sudoers way so the www-data user can run a bash script from python context as root. I feel dirty a little bit I have to work this out in another way.
  11. ___ ____ _ _____ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) | \___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/ |___/ Welcome to ARMBIAN 5.35 user-built Ubuntu 16.04.3 LTS 4.13.16-sunxi System load: 0.07 0.02 0.00 Up time: 3:15 hours Memory usage: 10 % of 493MB IP: xx.xx.xx.xx CPU temp: 40°C Usage of /: 3% of 233G [ 0 security updates available, 8 updates total: apt upgrade ] Last check: 2017-11-26 00:00 [ General system configuration (beta): armbian-config ] Last login: Wed Nov 29 09:38:35 2017 from x.x.x.x This is what I see at login. Omg.. someone switched the baby at birth maybe?? I have to wait a few days for the test as I'm waiting a shipment with an microSD card...
  12. Just note I "forced" a kernel switch from 3.x to 4.13 (next) You're right I'm sorry, here the original error: python3 setup.py install running install running build running build_py running build_ext Detected processor: Allwinner sun8i Family (Probably Allwinner H2+/H3) error: [Errno 2] No such file or directory: '/etc/armbian-image-release' thank you
  13. I'm using the stable image ("Ubuntu server – legacy kernel") from here https://www.armbian.com/orange-pi-zero/ I changed the setup.py because otherwise it throws error trying to access non-existent file For userspace GPIO access I think I would try to reproduce the /dev/gpioSOMETHING approach, where you can manage broader user access permissions without issues. But I don't know where to start from. At very high level I think this is something I can obtain with a kernel module but I can't find anything. thank you
  14. from setup.py def check_board(): """ Detect board type (added by chwe17) """ boardinfo = open("/etc/armbian-image-release", 'r') I don't have /etc/armbian-image-release What I should search for instead? Do I need to install some utility tools? uname -r 4.13.16-sunxi cat /etc/debian_version stretch/sid cat /etc/os-release NAME="Ubuntu" VERSION="16.04.3 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.3 LTS" VERSION_ID="16.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial Orange Pi Zero Do you think it's possible to access GPIO from userspace? thank you
  15. You are right, I'm using the orangepi_PC_gpio_pyH3 library too I'm impressed we need root to access the GPIO, it's a little bit like you need root to play an mp3 I hope we can find an alternative
  16. I googled the world searching for a way to access GPIO without root in the userspace but I can't find anything useful can anyone help? I even tried changing permission of /dev/mem just to try with chmod 777, chown but no way to access GPIO without sudo.
  17. Hi all, I'm trying to access the GPIO from python context and I absolutely need to do it in a rootless way. (WSGI apache module) I'm a newbie and noticed that this is the library command causing the error inside the python library: Code: Select all fd = open("/dev/mem", O_RDWR); I do have /dev/mem on my armbian distro and clearly the access to /dev/mem is root limited, what's worst I don't have /dev/gpiomem Is there a way to create /dev/gpiomem so I can add the apache user to gpio group and solve this? Do I need to configure and compile a kernel by myself? please help me, thank you
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines