Jump to content

usual user

Members
  • Posts

    421
  • Joined

  • Last visited

Community Answers

  1. usual user's post in use push button on orange pi, via GPIO was marked as the answer   
    How to wait for a button press is outlined here.
    If you want to be able to write code that is device-agnostic, you'll need to set up generic gpio-line-names.
    See here for reference.
    With that in place e.g.:
    gpiomon --num-events=1 con1-08 && my-script will be able to run on any device that has the gpio-line-names set up in the same way.
    I.e. will wait at pin 8 of the first extention connector for an event.
  2. usual user's post in Basic IR setup on OPi3-lts was marked as the answer   
    I'm guessing you're configuring the rc only after XWindow is already started, that way the input event device can't be added as an XWindow input device at times.
    Load the rc keymap during the boot process by adding it to /etc/rc_maps.cfg.
    E.g.:
    * rc-empty your-config-name.toml as last line added.
     
  3. usual user's post in The ole power-off button using gpio question - AML-S905X-CC was marked as the answer   
    gpiomon is your friend, e.g.:
    sudo gpiomon --num-events=1 gpiochip1 97 && poweroff  
  4. usual user's post in [HELP] LYRICS MONITOR PROJECT was marked as the answer   
    The hard work is already done, the kernel enumerates your IR device. Basically, only a suitable keymap is missing to emit the key codes you want. Each IR remote control sends different scan codes and each user expects different keycodes that are triggered at the touch of a button, so it is up to each user to create a corresponding keymap. Use ir-keytable -s rc1 -tp all from the v4l-utils ackage to determine the scan codes and assign them a keycode in e.g. a MXQ-PRO-4K.toml (man rc_keymap). If the MXQ-PRO-4K.toml located in the /etc/rc_keymaps directory is also registered in /etc/rc_maps.cfg, it will be loaded at system startup and the remote control will work out-of-the-box, e.g.:
    * rc-empty MXQ-PRO-4K.toml  
  5. usual user's post in Converting file to ISO was marked as the answer   
    I don't know Android and can't therefor help here, but I'm sure an experienced Android user can also use it to transfer an image to an sd card. However, if you are able to write an image to a USB flash drive, use a micro SD to USB adapter with a device whose system you are familiar with to write to an SD card. It is then the same procedure that you already know.

  6. usual user's post in Odroid N2+ - Forever Circle was marked as the answer   
    I have prepared an extlinux.conf. Mount the Armbian SD card partition and create an /extlinux directory in the root filesystem of the Armbian SD card. Then copy the attached extlinux.conf in.
    Download this  kernel package and unpack it with this command in your Armbian SD card /usr/lib/modules/ branch:
    tar -C ${mountpiont}/usr/lib/modules/ -xzf 5.19.0-0.rc6.46.fc34.aarch64.tgz Boot with the SD card and report if this changes anything.
  7. usual user's post in Muxing GPIO on Hummingboard i2eX on 5.x kernel was marked as the answer   
    IMHO I think from version 5.10.0 the path won't change again because generic node names have been around since then. Therefore, the same DTBO can always be applied. But as long as the hardware setup doesn't change, there's no reason to ever change the DTB. Therefore, after an update, restoring the DTB from a persistent location  would also be an option.
    But I guess you will have more fun to keep having the boot.scr magic in place. And tinkering with boot.scr magic opens even the option to load the DTB from the persistent location direct or choose a different DTB file name that wouldn't be overwritten.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines