Hi all,

 

Running Armbian Ubuntu 18.04 with stock neo2 4.19.20 kernel
I tried installing https://github.com/friendlyarm/WiringNP but after installation `gpio readall` says : "This NanoPi model is currently not supported."

However all the wiki's and the Github page says it's supported.......?

 

I can see GPIO in the sys fs at /sys/class/gpio/ but I was hoping to have an easier time with it than manually exporting each pin and calculating offsets for pins with scraps of info online etc.

Objective 1: Read a high/low 3.3v/0v status from a GPIO

 

Objective 2: Read an analog voltage, using an ADC. Does the H5 include an ADC?
When I look in http://wiki.friendlyarm.com/wiki/images/d/de/Allwinner_H5_Datasheet_V1.0.pdf
Page 13 says 2.1.4.9.KEYADC
* Analog to digital converter with 6-bit resolution for key application

* Maximum sampling frequency up to 250 Hz

* Supports general key, hold key and already hold key

* Supports single , normal and continuous work mode

 

I don't need high speed sampling, don't need interrupts, the simpler and easier the implementation the better.

Any help will be much appreciated

 

PS: How to fix friendlyarm/WiringNP

friendlyarm/WiringNP is not accepting issues on their github repo, but it seems to be the best fork out there.
How can we get them to accept issues and how can we fix the issue?

http://forked.yannick.io/friendlyarm/WiringNP

1 hour ago, Lope said:

Read an analog voltage, using an ADC. Does the H5 include an ADC?

Interesting ! But I've never look at it before ...

Details are at page 284 : https://linux-sunxi.org/images/a/a3/Allwinner_H5_Manual_v1.0.pdf

 

1 hour ago, Lope said:

manually exporting each pin and calculating offsets for pins with scraps of info online

All SoC from Allwinner are using the same scheme (from http://linux-sunxi.org/GPIO ) :

Quote

(position of letter in alphabet - 1) * 32 + pin number

 

Thanks @martinayotte

friendly arm WiringNP ref: http://wiki.friendlyarm.com/wiki/index.php/WiringNP:_NanoPi_NEO/NEO2/Air_GPIO_Programming_with_C#Shell_Script

I debugged WiringNP.
Either my kernel is showing wrong info, or WiringNP code doesn't work.

When I `cat /proc/cpuinfo` I get this

processor    : 0
Processor    : AArch64 Processor rev 4 (aarch64)
Hardware    : sun50iw1p1
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

 

You see my NanoPi Neo2 with H5 SoC reports Hardware is sun50iw1p1

But on line 61 of WiringNP/wiringPi/boardtype_friendlyelec.c it says: {"sun50iw1p1", 0, NanoPi_A64, "NanoPi-A64", "0"},

So the code says that CPU name corresponds to the A64 SoC...

So just to get WiringNG working, I changed the line to: {"sun50iw1p1", 4, NanoPi_NEO2, "NanoPi-NEO2", "1(0)"},
 

Then underneath line 135: GetKeyValue(isGotRevision,p2,"Revision",revision,revisionMaxLen);

I added line 136: if (isGotRevision==0) GetKeyValue(isGotRevision,p2,"CPURevision",revision,revisionMaxLen);

(just hax to make it work)

Now `gpio readall` gives me

 

+-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+
 | BCM | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | BCM |
 +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
 |     |     |     3.3V |      |   |  1 || 2  |   |      | 5V       |     |     |
 |  12 |   8 |  GPIOA12 |  OFF | 0 |  3 || 4  |   |      | 5V       |     |     |
 |  11 |   9 |  GPIOA11 |  OFF | 0 |  5 || 6  |   |      | 0v       |     |     |
 | 203 |   7 |  GPIOG11 |  OFF | 0 |  7 || 8  | 0 |  OFF | GPIOG6   | 15  | 198 |
 |     |     |       0v |      |   |  9 || 10 | 0 |  OFF | GPIOG7   | 16  | 199 |
 |   0 |   0 |   GPIOA0 |  OFF | 0 | 11 || 12 | 0 |  OFF | GPIOA6   | 1   | 6   |
 |   2 |   2 |   GPIOA2 |  OFF | 0 | 13 || 14 |   |      | 0v       |     |     |
 |   3 |   3 |   GPIOA3 |  OFF | 0 | 15 || 16 | 0 |  OFF | GPIOG8   | 4   | 200 |
 |     |     |     3.3v |      |   | 17 || 18 | 0 |  OFF | GPIOG9   | 5   | 201 |
 |  64 |  12 |   GPIOC0 |  OFF | 0 | 19 || 20 |   |      | 0v       |     |     |
 |  65 |  13 |   GPIOC1 |  OFF | 0 | 21 || 22 | 0 |  OFF | GPIOA1   | 6   | 1   |
 |  66 |  14 |   GPIOC2 |  OFF | 0 | 23 || 24 | 0 |  OFF | GPIOC3   | 10  | 67  |
 +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
 | BCM | wPi |   Name   | Mode | V | Physical | V | Mode | Name     | wPi | BCM |
 +-----+-----+----------+------+---+-NanoPi-NEO2--+------+----------+-----+-----+

 +-----+----NanoPi-NEO2 USB/Audio-+----+
 | BCM | wPi |   Name   | Mode | V | Ph |
 +-----+-----+----------+------+---+----+
 |     |     |       5V |      |   | 25 |
 |     |     |  USB-DP1 |      |   | 26 |
 |     |     |  USB-DM1 |      |   | 27 |
 |     |     |  USB-DP2 |      |   | 28 |
 |     |     |  USB-DM2 |      |   | 29 |
 |     |     |    IR-RX |      |   | 30 |
 |  17 |  19 |  GPIOA17 |  OFF | 0 | 31 |
 |     |     |  PCM/I2C |      |   | 32 |
 |     |     |  PCM/I2C |      |   | 33 |
 |     |     |  PCM/I2C |      |   | 34 |
 |     |     |  PCM/I2C |      |   | 35 |
 |     |     |       0V |      |   | 36 |
 +-----+-----+----------+------+---+----+

 +-----+----NanoPi-NEO2 Debug UART-+----+
 | BCM | wPi |   Name   | Mode | V | Ph |
 +-----+-----+----------+------+---+----+
 |   4 |  17 |   GPIOA4 | ALT5 | 0 | 37 |
 |   5 |  18 |   GPIOA5 | ALT5 | 0 | 38 |
 +-----+-----+----------+------+---+----+

Which is all well and nice. But WiringNP doesn't contain any code for doing an ADC capture from the H5.

On page 69 of https://linux-sunxi.org/images/a/a3/Allwinner_H5_Manual_v1.0.pdf

It shows the KEYADC pin name/number is AA5.
It doesn't look like NanoPi Neo2 has exposed pin AA5.
If so, that's incredibly lame. It's one of the strengths H3/H5 have over RbPi (having ADC) would be such a shame if we can't use it.

On the Neo2 Pinout I don't see AA5 http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2#Access_GPIO_Pins.2FWirings_with_WiringNP

 

It looks like the simplest GPIO pin to use for my first objective (read a digital input pin) is GPIOA6, because it has no other function (no serial ports etc) it's linux pin 6.
I tried `gpio export 6` in successfully. `gpio readall` changes it from OFF to IN.

17 minutes ago, Lope said:

It doesn't look like NanoPi Neo2 has exposed pin AA5.

Right ! It as a small pullup R63 ...

You can use a small ADC attached to I2C, such as MCP3021 or MCP3221, they have even better resolution.

@martinayotte when you say R63 do you mean it's possible to modify the board to use AA5?

Thanks for the recommendations of ADC's.

What about using one of the audio inputs for measuring my analog voltage?
The Audio connector has these 2 pins:

1 MICIN1P Microphone Positive Input

2 MICIN1N Microphone Negative Input

Do you know if anyone has used a microphone successfully with this SoC or Neo2 kernel?

1 minute ago, Lope said:

when you say R63 do you mean it's possible to modify the board to use AA5?

Yes, by removing this R63 and solder tiny wire on the floating pad. But usually those SMT resistors are so small, I wouldn't try myself ...

It is much easier to use MCP3221 ...

5 minutes ago, Lope said:

What about using one of the audio inputs for measuring my analog voltage?

Audio port are usually AC coupled, so no way to measure DC voltage level...

2 minutes ago, martinayotte said:

Yes, by removing this R63 and solder tiny wire on the floating pad. But usually those SMT resistors are so small, I wouldn't try myself ...

It is much easier to use MCP3221 ...

Strange how they connected the ADC to 3.3v. Seems so unnecessary? I wonder why they bothered running a trace at all?

Is it to prevent issues if it's left floating?

 

1 minute ago, martinayotte said:

Audio port are usually AC coupled, so no way to measure DC voltage level...

Yes, I just thought of that, thanks.

14 hours ago, Lope said:

Is it to prevent issues if it's left floating?

I doubt, but if I was the designer, I would have it pulled down instead with a test point, that way resistor would not be needed to be removed ...

Regarding the "This NanoPi model is currently not supported."

Looks like this is a mistake in WiringNP/wiringPi/boardtype_friendlyelec.c or
As Lope wrote above, I looked at the /proc/cpuinfo and fix it by changing h3_kernel4 in mentioned file accordingly:
-----
int getBoardType(BoardHardwareInfo** retBoardInfo){
.....
// const char* h3_kernel4 = "Allwinnersun8iFamily"; // originsl
const char* h3_kernel4 = "Allwinner sun8i Family"; // changed
-----