According to this post in broken english by famous user @sinovoip Banana Pi M2+ chose a partially incompatible pin mapping for the 40 pin GPIO header. They seem to use

Pin#  | GPIO  | Function  | Pin#  | GPIO  | Function
---   | ---   | ---       | ---   | ---   | ---
01    | ---   | SYS_3.3V  | 02    | ---   | VCC_5V
03    | A-12  | TWI0_SDA  | 04    | ---   | VCC_5V
05    | A-11  | TWI0_SCK  | 06    | ---   | GND
07    | A-06  | PWM1      | 08    | A-13  | UART3_TX/SPI1_CS
09    | ---   | GND       | 10    | A-14  | UART3_RX/SPI1_CLK
11    | A-01  | UART2_RX  | 12    | A-16  | UART3_CTS/SPI1_MISO
13    | A-00  | UART2_TX  | 14    | ----  | GND
15    | A-03  | UART2_CTS | 16    | A-15  | UART3_RTS/SPI1_MOSI
17    | ----  | SYS_3.3V  | 18    | C-04  | ---
19    | C-00  | SPI0_MOSI | 20    | ----  | GND
21    | C-01  | SIP0_MISO | 22    | A-02  | UART2_RTS
23    | C-02  | SPI0_CLK  | 24    | C-03  | SPI0_CS
25    | ----  | GND       | 26    | C-07  | ---
27    | A-19  | TWI1_SDA  | 28    | A-18  | TWI1_SCK
29    | A-07  | ---       | 30    | ----  | GND
31    | A-08  | ---       | 32    | L-02  | ---
33    | A-09  | ---       | 34    | ----  | GND
35    | A-10  | ---       | 36    | L-04  | ---
37    | A-16  | ---       | 38    | A-21  | ---
39    | ----  | GND       | 40    | A-20  | ---

And that's what all Orange Pi use:

 

 

 

 

That means GPIO definitions in fex file (provided by famous 'Team BPi') are wrong and at least it would explain why I failed a few weeks ago reading out 1-Wire slaves since GPIO pin 37 is connected to PA16 instead of PA20.

 

Their fex file still does not reflect these 'findings' (a hardware manufacturer being surprised that his own pin mappings are different than intended? Or just the usual 'we don't give a shit about documentation or correct hardware description'?) and some other changes let me believe that the best idea is to drop Armbian support for this board (eg. audio defined as active but there is no audio out, now the redefined audio_pa_ctrl to share the same pin as the recovery key and so on -- you can't trust their way to describe the hardware)

I think don't give a shit pretty much sums it up - they want to push hardware out then move onto the next product... at least with the original Raspberry Pi there is continuity. Some of these boards could be so good with some consistency and medium term support. No chance of Node-Red nodes for most of these...  however I have at least now mapped most of the IO pins for the NEO and the M2+ - which is a start.  

Today I had to realize that the same that applies to Banana Pi M2+ also applies to NanoPi M1: different pin mappings on 40 pin header compared to Orange Pis:

 

This is NanoPi M1 according to FA's own wiki entry:

 

 

So if we look at physical pin 37 for example, then this pin is wired to pin PA20 on Orange Pis, to PA16 on BPi M2+ and PA09 on NanoPi M1

 

Pin 37 is historically used for 1-Wire on Orange Pis (not our decision but we decided to keep with loboris' settings since otherwise all available tutorials would not work any more). Let's have a look how the vendors define GPIO pins in their hardware descriptions:

• NanoPi M1: 1-Wire is assigned to PA20 but this is physically routed to pin 29 on the header, so to get 1-Wire working on NanoPi M1 with these settings pin 29 instead of 37 has to be used to attach sensors to
• Banana Pi M2+: 1-Wire also assigned to PA20 but PA20 routed to physical pin 40 on the header

How to deal with that? If we at Armbian would decide we want to use physical pin 37 on all H3 boards for 1-Wire we would have to change our fex settings so that w1_para section would read 'gpio = 9' for NanoPi M1 and 'gpio = 16' for Banana Pi M2+

 

But then 3 different versions of WiringOP would be necessary and based on the decisions taken by the vendors still not everything would work an average RPi user expects. That's really a mess with 40 pin GPIO headers being advertised as 'RPi compatible' and then showing differences here and there.

I do not know anything about Gpio Settings, but it is interesting to me, that there is a physically connection from PA17 to pin 26 on the NanoPi M1. That means it should be possible to connect a simple SPDIF output to it. On the Oranges PA17 is connected to Pin 4 on the Camera port (CSI-PWR-En  C14). Is ist possible to reroute the PA17 on the Oranges to a pin on the 40 Pin Header?

 

Regards

Is ist possible to reroute the PA17 on the Oranges to a pin on the 40 Pin Header?

 

Most probably not without a soldering iron

 

Why not choosing another pin, eg. the last defined GPIO (40 on the header, PG07)

• Change this to 18: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepipc.fex#L223
• Comment/delete this line: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepipc.fex#L242
• Enable SPDIF and let it use PG07: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepipc.fex#L664-L665

For the list of modules have a look at the Beelink X2 (where SPDIF is confirmed to work)

This solution sounds promissing, choosing another Pin was exactly what i wanted to get .....

I crashed my only toslink transmitter so i can t  check things further. Connecting a RCA Connector does not work.

I will report back and start new thread in case it works. (just have to wait for new Transmitters)

 

Regards

I have tried two different Toslink Transmitters (both are working on the Odroid C2) but i none of them is working on the orangepipcplus.

It seems that it is not that easy to get the SPDIF Signal on another Pin.

 

Nevertheless it was worth a try.

 

Regards

Most probably not without a soldering iron

 

Why not choosing another pin, eg. the last defined GPIO (40 on the header, PG07)

• Change this to 18: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepipc.fex#L223
• Comment/delete this line: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepipc.fex#L242
• Enable SPDIF and let it use PG07: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepipc.fex#L664-L665

For the list of modules have a look at the Beelink X2 (where SPDIF is confirmed to work)

 

That's not possible. The OWA interface (which is what they call SPDIF in the Allwinner datasheet) can only use PA17, there is no other routing/multiplexing option.

 

The same holds true for any other hardware peripherial of the chip. Check chapter 3.7 of the datasheet, "GPIO Multiplexing Functions". And if you do direct register access to set up pin functions, check chapter 4.22/4.23 to see what register settings are required to chose what pin is selected for which function/peripherial.

 

The case of 1-Wire sensors etc. is different, since that is implemented in software (the H3 does not have a 1-Wire peripherial), and thus can be placed on any generic GPIO pin.

 

Greetings,

 

Chris

Check chapter 3.7 of the datasheet, "GPIO Multiplexing Functions". And if you do direct register access to set up pin functions, check chapter 4.22/4.23 to see what register settings are required to chose what pin is selected for which function/peripherial.

 

Thanks for clarifying this! Highly appreciated.

 

So we can call the NanoPis more OWA/SPDIF friendly compared to the other H3 devices (Beelink X2 being one exception since it already features the connector) where one would have to use a pin on the camera connector and a solder iron...

Ha, it seems that the BananaPI M2+ _does_ have the SPDIF output. I just checked the datasheet: https://drive.google.com/drive/folders/0B4PAo2nW2KfnflVqbjJGTFlFTTd1b1o1OUxDNk5ackVDM0RNUjBpZ0FQU19SbDk1MngzZWM?tid=0B4PAo2nW2Kfndjh6SW9MS2xKSWs. I was checking it because i was wondering why the heck they would use a PA pin on the cam header, whereas the NanoPI's just use all the PE signals, since PE has everything that is needed for the camera (it's the cam interface, after all).

 

Turns out they made a a rather nasty typo. Check page 2, upper-left. In the chip symbol itself you see PA17/SPDIF_OUT/PA_EINT17, over the signal line they put the label "SPDIF_OUT", but they named the  signal itself "PA16", probably by mistake. On page 9 then you see that signal PA16 ends up on pin 37 of the expansion header.

 

So, according to the schematic the SPDIF output on the BananaPi M2+ is on pin 37 of that header, mislabelled as PA16.

 

Greetings,

 

Chris

Ha, it seems that the BananaPI M2+ _does_ have the SPDIF output. I just checked the datasheet: https://drive.google.com/drive/folders/0B4PAo2nW2KfnflVqbjJGTFlFTTd1b1o1OUxDNk5ackVDM0RNUjBpZ0FQU19SbDk1MngzZWM?tid=0B4PAo2nW2Kfndjh6SW9MS2xKSWs. I was checking it because i was wondering why the heck they would use a PA pin on the cam header, whereas the NanoPI's just use all the PE signals, since PE has everything that is needed for the camera (it's the cam interface, after all).

 

this link is for the BPI-M3, but you are right, BPI-M2 does have the SPDIF on Pin 37 of Con2 as you can see here  on Page 13..

Re

gards