lanefu

Hmm I'm so torn now.... the python minimum viable solution is appealing for most mortals and I would figure C nerds are just going to do what they're going to do regardless--but these guys have interrupt support working now for the C stuff, so I guess there is a bit of polish going on Especially now that I've realized Zhaolei's WiringOP is more maintained that I originally thought.... https://github.com/zhaolei/WiringOP/commits/h3

I traced through the Pi Zero Schematics and mapped the 26 pins to their AllWinner ID/function 1 - 3.3v 3 - PA12 (TWI0_SDA/DI_RX/PA_EINT12) 5 - PA11 (TWI0_SCK/DI_TX/PA_EINT11) 7 - PA6 (SIM_PWREN/PWM1/PA_EINT6) 9 - GND 11 - PA1 (UART2_RX/JTAG_CK0/PA_EINT1) [IO-0] 13 - PA0 (UART2_TX/JTAG_MS0/PA_EINT0) [IO-2] 15 - PA3 (UART2_CTS/JTAG_DI0/PA_EINT3) [IO-3] 17 - 3.3v 19 - PA15 (SPI1_MOSI/UART3_RTS/PA_EINT15) 21 - PA16 (SPI1_MISO/UART3_CTS/PA_EINT16) 23 - PA14 (SPI1_CLK/UART3_RX/PA_EINT14) 25 - GND 2 - 5v 4 - 5v 6 - GND 8 - PG6 (UART1_TX/PG_EINT6) 10 - PG7 (UART1_RX/PG_EINT7) 12 - PA7 (SIM_CLK/PA_EINT7) [IO-1] 14 - GND 16 - PA19 (PCM0_CLK/TWI1_SDA/PA_EINT19) [IO-4] 18 - PA18 (PCM0_SYNC/TWI1_SCK/PA_EINT18) [IO-5] 20 - GND 22 - PA2 (UART2_RTS/JTAG_DO0/PA_EINT2) [IO-6] 24 - PA13 (SPI1_CS/UART3_TX/PA_EINT13) 26 - PA10 (SIM_DET/PA_EINT10) So according to the FEX there's like 2 GPIO Pins enabled by default? Pin12(PA7) and Pin26(PA10)? [gpio_para] gpio_used = 0 gpio_num = 2 gpio_pin_1 = port:PA07<1><default><default><0> gpio_pin_2 = port:PA10<1><default><default><0>

so should the end game be to just have a good python library and sysfs for shell- or are we interested in wiringPi for C and python?

I think RPi.GPIO is differently and strictly python. WiringPI's roots come from emulating arduino stuff.. It seems to be the most comprehensive library as far as offering C libs, Shell Tools, python bindings, etc. I'm game to target a different lib if needed tho.. I just did it for python

Alrighty -- WiringOtherPi task thread here

It's time to unify GPIO for the other PIs with WiringOtherPI and bundle it with Armbian! Inspired from these discussions: https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/page-4#entry20302 http://tech.scargill.net/banana-pi-m2/#comment-27946 Goals WiringPI GPIO support for most AllWinner H2/H3 boards using legacy kernel WiringPI GPIO support for most AllWinner H2/H3 boards using mainline kernel Compatiblity with code using WiringPI dependencies Make my Orange Pi Zero blink my christmas lights Produce a distro-friendly package to be included with Armbian releases Todos Compile todos from other discussions Resources WiringOtherPi Repo Armbian Github issues for clerical purposes Jernej's read_fex tool OrangePi Py20.GPIO Fork Another Py20.GPIO Fork that supports OrangePi Zero And I'll just tag a few smart people here: @tkaiser @martinayotte @jernej

Challenge Accepted. WiringOtherPi here we come... As you know I only barely know what I'm doing, but there's plenty of bright minds to steer us straight. I'll scribble some things and kick off a task. I need to do some groking on how much different GPIO stuff is or isn't with mainline

Is there a H2 datasheet floating around like the awesome H3 datasheet that has all the possible pin functions etc? I got some zeros in the other day and I'm going to see if i can make my WiringPi-Python-OP build work with it... which i think means i'll go ahead and fork WiringOP this weekend and take a stab at it. Also i noticed (as you mentioned on another post) that bin2fex fails on the zero fex. Should I try to find an older bin2fex or newer?

I got dorky and ordered one of each new one.... both Zero models and a PC2

That's delightfully insane.

Ohhh.... so instead of soldering zero Ohm resisters to the magnetics. I could solder in a buck converter at those pads?

So i'm still not totally grokking the physical aspect of the SPI flash....... I dont see any spots for where it would go, but I also have no idea what it would look like, or how I would add it myself.....

Hmm.... yeah I have a real PoE switch.. i'm still getting mixed information about whether or not 100mbit Passive PoE will work with it or not. A while back I used a trendnet Active-PoE splitter to run some Ones and even 2e... worked quit well.. but still like 15 bucks. I fiddled with the CSI camera then and it was just such a bummer--even when I somehow made CedarX work.... The Rpi CSI camera just worked so well by comparison, that I gave up on CSI for Opi and fiddled with some USB h264 camera modules that were an okay compromise. I haven't followed up on Lex's efforts over the past few months.... I probably should.

have you tried VyOS? it's hard to go back to DDWRT--- if you don't care about integrated wifi.

i'm super excited about the POE.... combine that with a cheap h264 USB camera module and a cheap network camera appears.

I'll do some digging and see what I can figure out

Okay here's a few bread crumbs. You're going to have to patch the u-boot dts file for your board and make sure the resulting dtb is what u-boot is using. look for arch/arm/dts/sun8i-h3-orangepi-pc.dts in the u-boot source pulled with your ambian build tools and hopefully you can just switch the &uart0 refernces to &uart1 or whatever http://orange314.com/images/thumb/c/cf/Opi_gpio.png/500px-Opi_gpio.png I haven't done it, but please share your success--i've been curious about leveraging alternate UARTS.. I'm still confused about whether or not you can have more than 1 active UART with the h3

how often do you want to perform builds for all boards? Tapatalk thinks its important to tell you im using tapatalk from a phone.

Use the Orange Pi One armbian image and get your Opi on the network then follow their generic linux procedure..the dependecies look straightforward https://www.domoticz.com/wiki/Linux this step may step may get a bit bumpy because systemd is used now instead of init.d, but cross that bridge when you get there https://www.domoticz.com/wiki/Linux#Starting_Domoticz_automatically_when_the_system_boots

I took a glance at the project.. It certainly seems feasible.. you're way ahead of me now. Good luck and please share your success!

Yeah looks quite feasible. I might have to fiddle with the serial device name. I'm not sure of the opi console is sharing the uart with the GPIO or not... worst case scenario you disable serial console and take over the device func main() { var wg sync.WaitGroup // Set our UART vars comport := flag.String("serial", "/dev/ttyAMA0", "Serial device to use") comspeed := flag.Int("baud", 9600, "Serial baudrate") debug := flag.Bool("debug", false, "Enable verbose debugging")

theres python bindings for WiringOp https://gist.github.com/lanefu/f16a67195c9fa35c466c6b50cdaeadea Tapatalk thinks its important to tell you im using tapatalk from a phone.

there are some existing posts on the forum with building in a container that discuss the loopback problem. Tapatalk thinks its important to tell you im using tapatalk from a phone.

I have a similar issue with my plus 2e on mainline kernel. I havent tested wired with recent legacy kernel.. It may be an issue with most recent u-boot not initializing the phy correctly. Unfortunately I haven't had time to dig into it. anyway there's your breadcrumb.

yeah my thinking wasn't making sense.... However your thinking does and I think I get it now. thank you