Search the Community

Try this https://github.com/wertyzp/WiringNP It's my environment $ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" $ cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=nanopineo BOARD_NAME="NanoPi Neo" BOARDFAMILY=sun8i VERSION=5.60 LINUXFAMILY=sunxi BRANCH=next ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage

My problem of the ethernet connection is solved with the projectoarduino solution. I have another question about the WiringNP library: to match the version of Nanopi WiringNP library uses information found in this path /sys/class/sunxi_sys/ info_sys, I find the file info_sys only on the xenial image of FriendlyElec. Is there an equivalent file of this one in Armbian's image?

Hi @all, I currently try to build a door-opener with a NanoPi Neo and a MFRC522 Rfid-Module. Unfortunately I don't get the SPI working. I loaded the newest Armbian-Debian from the Website: uname -r = 4.14.18-sunxi and downloaded the SPI-library for NanoPi: https://github.com/wertyzp/WiringNP By using armbian-config I activated "pwm", "sei-add-cs1", "spi-jedec-nor" and "spi-spidev". The problem: If I try to activate SPI with gpio load spi I get the following error-message: modprobe: FATAL: Module spi-sun7i not found in directory /lib/modules/4.14.18-sunxi gpio: Unable to load spi-sun7i So it seems that wiringNp doesn't use "spi-dev" but "spi-sun7i" and I tried to install it from source from: https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.90/spi-sun7i.c Unfortunately I can't find out how to write the Makefile so that I can compile the .ko-file and install the driver. Can you help me writing the Makefile or have another idea how I could solve the problem? Thanks in advance and greetings, Latze

I2C protocol, which is needed for this device, is supported but disabled by default. Use armbian-config to enable the appropriate I2C port or edit .fex file (decompile-edit-compile) /boot/script.bin if you are using old legacy 3.4.y kernel. RPi GPIO is on Raspberry Pi. I am not aware of Python libraries, but officially is this what you get: https://github.com/friendlyarm/WiringNP

No. Sorry, I must not have been clear. GPIO works fine on Armbian. There is only an issue with board detection using WiringNP because of difference in /proc/cpuinfo. Thanks for the boot explaination. I really appreciate your help.

Hi Igor, I had done the GPIO test with WiringNP with their nanopi-k1-plus_eflasher_4.14.0_20180511.img. Their WiringNP GPIO library worked on that. I hacked on the WiringNP to use same "board version" (a NanoPi thing) as their OS uses and the GPIO works fine on the K1 armbian nightly test version you made, at least the GPIO stuff for what I am doing. I see on the K1Plus page that the 1080P is marked as fixed. Can you make a new nightly build with this fix or is it checked in and I should make it. Thanks.

Hi Igor, While you are in there, can you please look at the /proc/cpuinfo. If I use the OS from NanoPi for K1 I get a different CPU id. I am able to use WiringNP with the NanoPi OS, but not the Armbian OS. I need to try to hack the WiringPi to make sure only CPU ID and Revision are the problem, but rest of GPIO library works. The NanoPi OS reports as one Hardware and Revision field: Hardware: Allwinnersun50iw2Family Revision: 0 Armbian K1 reports as multiple Hardware and no Revision field: Hardware: sun50iw1p1 and Revision line is missing Since the format of /proc/cpuinfo seems very differnt, not sure who is "right" Thank you. --------------- complete /proc/cpuinfo from NanoPI OS: processor : 0 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 1 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 2 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 3 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware : Allwinnersun50iw2Family Revision : 0000 Serial : 0000000000000000

Hi i did some comparison of NanoPi NEO Kernel 3.4 (Jessie) and kernel 4.4 (Stretch). - Looks like the temperature limit controlling of 4.4 is not working as good as 3.4 (on 4.4 Kernel the CPU reaches more than 85 °C!) - GPIO (wiringPi) has less performance (-4%) - SPI has better performance (10%) - CPU performance is ~6% better (nbench, maybe the newer compiler) - consumption is besser on Kernel 3.4, especially on halt state I did a fork for wiringpi Library to make it work on Armbian Jessie and Stretch https://github.com/mstroh76/WiringNP (so far only for NEO)

ArmbianIO is not a fork of WiringOP. I wrote ArmbianIO because of the terrible situation with WiringOP and WiringNP. Using the BCM numbering on Allwinner boards is understandable for RPI compatibility, but limits what you can do with non-BCM chips. I thought a fresh start which treats all boards as unique and allows more than 40-pins of GPIO header would be wiser than another "crutch" of a hacked up WiringPi copy. I have a wide variety of boards and ArmbianIO (even running on Raspberry Pi boards) allows a consistent way to work with GPIO/I2C/SPI. I know that when I hook an LED or switch to a GPIO pin, I can run the same code on any of my boards and connect it to the same header pin and it will work without modifying my code. chwe: splited from https://forum.armbian.com/topic/6197-hardware-line-is-missing-on-proccpuinfo/ cause I think it's better to keep this in this thread.

Happy new year everyone, I am working on a project where I want to control two brushed DC motors equipped with a magnetic encoder and driven by a H-bridge circuit. All this has to be done on a tiny arm board (with enough cpu power for other computations), and I decided to go for the NanoPi NEO Air. I compiled the actual mainline Kernel with realtime capability (turned PREEEMTIVE on in menuconfig, hope that's enough) and debian streched. One issue might be the tight and constraining timing when sampling the magnetic encoder, which generates two 1.6kHz (about 0.6ms) pulses for each motor. I guess it would be best to get an interrupt generated at each rising edge for one signal/pin. The second signal indicated the direction of the motor and can get read within the interrupt routine. All this has to be done two times because of the two motors. So does anyone know if this is possible on the NanoPI with RT Linux? On the other side I am just looking around what ways there are to access the GPIO pins and found several like WiringNP (aka WiringPi and others), wiringX, GPIO via SysFS, and maybe others. I prefer writing my application in ansi C ... so which way to access the GPIOs would you recommend? I appreciate every feedback.

There is 2 Repository. https://github.com/friendlyarm/WiringNP https://github.com/wertyzp/WiringNP friendlyarm's WiringNP have a mapping bug. gpio of pin#35 and #36 won't work. static int pinToGpio_m1 [64] ={ 0, 6, // 0, 1 2, 3, // 2, 3 200, 201, // 4 5 1, 203, // 6, 7 12, 11, // 8, 9 67, 17, //10,11 64, 65, //12,13 66, 198, //14,15 199, -1, //16,17 -1, -1, //18,19 -1, 20, //20,21 21, 8, //22,23 // 13, 9, //24,25 /nopnop2002 16, 9, //24,25 // 7, 16, //26,27 /nopnop2002 7, 13, //26,27 15, 14, //28,29 19, 18, //30,31

I had the same issue with wiringNP on nanoPi NEO. The issue was resolved by adding a line to the file "boardtype_friendlyelec.c" in the array "BoardHardwareInfo gAllBoardHardwareInfo[]" The line added is: {"sun8i", 0, NanoPi_NEO, "NanoPi-NEO-Armbian", "-1(-1)"}, The critical parameter is the -1(-1), which is the board type reported by the kernel for this board. I have not carried our thorough testing, but the gpio readall reports properly and I am able to toggle outputs and read inputs correctly using the gpio command.

I do not know if the peripherals I think are right, but let me tell you. my peripherals is mpu-6050(accleration + gyro-sensor) Now i using H3 chip and i don't know manufacturer my processor is ARMv7 Processor rev 5 (v7l) hardware is sun8i i used this Wiring - git clone git://github.com/wertyzp/WiringNP and my gpio -v is Copyright (c) 2012-2014 Gordon Henderson This is free software with ABSOLUTELY NO WARRANTY. For details type: gpio -warranty Banana Pro Details: Type: Model A, Revision: 1.2, Memory: 1024MB, Maker: LeMaker That's all I know.

There is also now WiringNp which has PWM. Possibly that is bit banged but if not insepection might lead to details on how they got it working.

Just an FYI. There is now a version of the wiring API called WiringNp for the NanoPi... http://wiki.friendlyarm.com/wiki/index.php/WiringNP:_WiringPi_for_NanoPi https://github.com/wertyzp/WiringNP

I'm trying to set the Pin G11 on a NanoPi Neo, previously configured as input, to output in C++ by mapping the PIO function register into the virtual memory with mmap and setting a single bit. As per the Allwinner H3 Datasheet the following hardware addresses are specified: Similar to the Raspberry Pi's function register, the Pin knows at least two states: 000: input 001: output ... In my Script, I'm therefore trying to set the 12th bit of the PG Configure Register 1. Here's my C++ code: struct peripheral { unsigned long addr_hardware; int map_size; int mem_fd; void *mem_map; volatile unsigned long *addr_virtual; int map() { if ((mem_fd = open("/dev/mem", O_RDWR | O_SYNC)) < 0) return -1; // map addr_hardware=0x01C20000 into /dev/mem if ((mem_map = mmap(0, map_size, PROT_READ | PROT_WRITE, MAP_SHARED, mem_fd, addr_hardware)) == MAP_FAILED) return -1; // store virtual address with offset of 0x800, which was rounded down before addr_virtual = (volatile unsigned long *) mem_map + 0x800; return 0; }; void unmap() { munmap(mem_map, map_size); close(mem_fd); }; }; int main() { // initialize peripheral at rounded down PIO base address peripheral gpio {0x01C20000, 4096 * 10}; // map PIOs into virtual memory if (gpio.map() == -1) return -1; // output current value of PG Configure Register 1 cout << bitset<32>(*(gpio.addr_virtual + 0xDC)) << endl; // set 12th bit *(gpio.addr_virtual + 0xDC) |= (1 << 12); // output value of register after setting the 12th bit cout << bitset<32>(*(gpio.addr_virtual + 0xDC)) << endl; gpio.unmap(); return 0; } Unfortunately, my code does not work. When I configure the Pin G11 as Output (via WiringNP), the displayed value doesn't change. I'm checking the proper functionality of my code with an LED (it should turn on when state is changed from IN to OUT because it is set to HIGH). When I run the script again, the content of the PIO Configure Register has changed to its previous state. When altering the map_size, I get the following results (spaces added for better readability): > gpio {0x01C20000, 4096 * 2} < 00000000 00000000 00000000 00000000 < 00000000 00000000 00010000 00000000 > gpio {0x01C20000, 4096 * 10} < 00000000 00000000 00000000 00110011 < 00000000 00000000 00000000 00110011 I am expecting the following result: > gpio {0x01C20000, 4096 * 10} < 00000000 00000000 00000000 00110011 < 00000000 00000000 00010000 00110011 Any help would be very appreciated