pako

I am not 100% sure that I will answer this question accurately and truthfully. In my opinion, the BCM numbering on Orange Pi boards makes no sense (I don't use it myself in principle). This only makes sense for Raspberry Pi boards (BCM is short for Broadcom - the manufacturer of the SoC on RPi boards). OrangePi.GPIO is "RPi.GPIO drop-in replacement library for Orange Pi Boards" and its original author (Jeremie-C) apparently wanted (for Allwinner SoC boards) to maintain some degree of compatibility with the original RPi.GPIO library. I actually only made a fork (but extended and fixing some bugs) of the mentioned Jeremie-C project and I did not change the numbering methods introduced by the author. I prefer to use BOARD numbering, which in my opinion makes the most sense (e.g. it greatly facilitates the portability of code between different Orange Pi boards). SOC numbering can also be beneficial in some cases. The SOC number of a GPIO pin can be easily calculated if you know the pin name (like PH18). You can find the procedure here. Or you can use the "GPIO" column from the table for the relevant OPi board from this page.

Hi Cryptimo! I haven't tried it, but I assume it should work. Unfortunately, I don't own OPi 3 LTS, so I can't even try it. I looked in the documentation and I see that fortunately the GPIO layout on the header is exactly the same as on the older OPi 3. When compiling, you can proceed as described on the page https://github.com/Pako2/OrangePi.GPIO. I only have one patch that I haven't published yet (but I have it ready including the H616/OPi Zero 2 support adding). For newer versions of Python (3.9 and greater) command sudo python setup.py install usually ends with the error message error: command 'aarch64-linux-gnu-gcc' failed with exit status 1. In that case, the compilation command must be modified as follows (for boards with H6): sudo CFLAGS="-fcommon" python3 setup.py install --force-h6 Please write here how it went. If there is a problem, I will try to solve it. Pako

I return to this old topic. Perhaps someone will be interested in my contribution. I have successfully modified the library https://github.com/Jeremie-C/OrangePi.GPIO, so it also works for H6. You can find the modified library here: https://github.com/Pako2/OrangePi.GPIO.

So I figured it out. Maybe someone will have the same situation. The solution is simple: 1) command cat < /proc/bus/input/devices - it gives a different result, if the USB sound card is plugged (device "sunxi-ir" is shifted down) ! 2) I had to edit the file /etc/lirc/hardware.conf. There I originally had the line DEVICE="/dev/input/event2". Now (with attached USB sound card) I had to change it to DEVICE="/dev/input/event3".

I encountered a strange problem and I do not know what to do: When I am restarting my OPI with inserted USB audio card, then LIRC does not work. When I am restarting my OPI without inserted USB card and this USB card I put only later after a restart, then LIRC works. Can anyone advise how to proceed? I need to insert USB audio card permanently (it's inside the device).

I thank you for your soothing words. I guess it's not so hot. See this communication older than 10 years: https://lists.gt.net/linux/kernel/679919 However - I think it would not be so. For us it's called skeleton in the closet.

Thank you for answer. I maybe wrong to express (my English is very poor, I use Google translator for support). It may not be a problem HW because it works very well. I am only concerned about the message, that it is deprecated. Maybe it can happen, that (after some upgrades, for example) it stops working ? That is why I am asking. It is ATtiny2313. The clock is calibrated 8 MHz oscillator. If I used baud rate 115200, so the error (deviation from the nominal rate) is 8.5%. It seems to me too much.

I need to use non-standard baud rate (125000) on the serial port. Communication works very reliably, but dmesg says: "Python sets custom speed on ttyS1. This is deprecated." What should my attitude towards it? Can I ignore it? I read, that it is necessary to make some changes in the "asm/termios.h". It is necessary ? Could it be a normal part of the kernel? Moreover - I do not know how to do it. Thanks.

Thank you for answer. This is interesting information and I'm a little confused. I recently installed Armbian and I often doing the update / upgrade. So now I downloaded the latest Armbian for OPI Zero and I made a completely new installation from scratch. However, initially it seemed that the situation has not changed: I had only one SPI device (spidev0.0) and it not worked. After decompile script.bin I found in the file script.fex that this device is mapped to inaccessible GPIO ports (as it was before). Then I edited script.fex, enabled second SPI devices and then compiled new file script.bin. This time I was successful and finally I have a functioning device spidev1.0 ! Thank you!

Hi! I'm new here. First, I apologize for my poor English. I encountered the same problem with OPI Zero. I edited script.fex according to your pattern, but when I compile it, I have no SPI device then. So I wanted to use compiled script.bin, but the url https://transfer.sh/QRpQI/script.bin is not already available. Can you help me, please ? Thanks