aliceander

WiringNP looks like it should work; compiles and installs, gpio readall run ok, and I can compile apps including the library. The problem may be with the app. I'm running https://github.com/bigjosh/NeoUart with one neopixel with connections [GND pin 6,VDD pin 1, DIN pin 8 (GPIO 14, TX UART), DOUT unconnected]. Runs ok on a raspi model b+, but when I run on a neopi neo it spins a processor at %100 and hangs. I remember that orange pi's had their pin orientation rotated oddly (180), so I verified the pinout, but the neo seems to follow expected orientation. My armbian-release and os-release are the same as @nopnop2002. I'll review @Tido's suggestion this morning.

I'm having trouble porting some WiringPi programs to my NanoPi Neo. I have an original neo v1.0 running the latest armbian stretch (as of Oct 04 2018). Have tried several, including mstroh76/WiringNP, and can compile, but programs hang when executed. I'm okay if this is the deep-end of the pool but I wanted to verify that I an indeed in deep waters or if I'm doing something dumb and really in the shallow waters and all I have to do is stand up to get my head out of the water. Which WiringPi library should I be using for C language programs on a NanoPi NEO v1.0 running a recent Armbina Stretch release?

Thank you … that's one thing I can check off as confirmed.

I'm almost certain … but to be absolutely certain I'll attach a keyboard and display to the Orange Pi One and re-run the tests; hopefully I'll see something obvious and figure out the answer. And since I'll have a head on it for these tests I'll try configuring wifi without ever using a physical ethernet connection. I guess worst case is that I'll have to configure the device with a head attached, and then remove it later for headless operation. In the meantime, let me say something I'm inferring from your response -- that nmtui "is" a correct way to configure wifi in a current mainline release, and that the configuration should be saved and applied to subsequent reboots. I may be reading between the lines, and if I'm wrong please point out my error.

Hardware: Orange Pi One with a CF-WU810N (Realtek 8188eus) USB WiFi dongle Software: [MAINLINE] - ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.14.14-sunxi Goal: Configure and run the Orange Pi One HEADLESS (using a physical ethernet during initial configuration) I've been away from armbian for awhile, so it looks like I've got some catching up to do. I'm running a headless Orange Pi One with a CF-WU810N (Realtek 8188eus) USB dongle. Since it's headless I use a physical ethernet cable to get access and make initial configuration. From the documentation (https://docs.armbian.com/User-Guide_Getting-Started/#how-to-connect-to-wireless) I use nmtui-connect to specifiy my ssid and provide my key. That all works. For a few moments. If I unplug the physical ethernet cable the system freezes. And if I reboot access to the wifi network is not remembered. In the old days I would have setup a wpa_supplicant file, but I don't think that's currently recommended. Given I want to use this headless (with a temporary physical ethernet during configuration): - Should I be using nmtui to configure my WiFi? - How can I make the nmuti-connection persistent (e.g. remember ssid/password across reboots)? And thank you for the continued work. It's neat to see all the updates.

Ah, yes, I can see how that happened. I've always been impressed by the system you guys created. Not only do you support a kajillion different devices, you have a build ready to use by the time a brand new board has had the time to be delivered to my house. And even though it was clear that mainline was not supported, I was guilty of coming to the forum to seek solutions for mainline issues. I'm sorry I contributed to the problem. I may look into building my own, or at least look into it since I'm interested in learning the process, but I'm mostly thrilled to hear that a mainline kernel release is in the forecast. One month is not long, and I realize that will probably slip out more than a month, but just knowing that it's coming soon makes me happy. Thank you for the explanation.

I've been away from armbian for a few months and came back to build a new project with my orange pi one but the nightly/recent mainlines builds seem to have stopped. I need a mainline kernel, and can grab one that's a few months old, but I wanted to be sure they haven't been moved. I'm not complaining! Just asking. With the number of boards available with armbian there has to be a lot of overhead doing nightly builds with few users, so it's not too surprising to see a change. I looked thru the sticky notes, but could not find a relevant post. Thanks!

OMG -- I think I just understood your point! The backlight might be powered by the 3v pin on the display. I've been applying power to the display's 5v pin and not connecting the 3v pin. It kind of makes perfect sense. I'll try this as soon as I get home. And thank you for repeating the information until I got it.

Got a display that looks like the one in the OP but it's really dim. It's almost like the backlight is not on. I'm on an Orange Pi One with a 5V3A power supply. To init the display I ran modprobe fbtft_device name=itdb28 speed=48000000 fps=30 rotate=90 gpios=reset:20,dc:1,wr:3,cs:10,db00:0,db01:14,db02:2,db 03:21,db04:18,db05:19,db06:8,db07:9 My test python script is: #!/usr/bin/env python import pygame, osfrom time import sleep os.putenv('SDL_FBDEV','/dev/fb8') pygame.init() screen = pygame.display.set_mode((0,0)) screen.fill((0,0,180)) rfont = pygame.font.SysFont(None,30) size = screen.get_rect() resolutiontext = rfont.render("%d x %d" % (size[2],size[3]), 1, (255,255,255)) resrect = resolutiontext.get_rect() resrect.centerx = size.centerx resrect.centery = size.centery screen.blit(resolutiontext, resrect) pygame.display.flip() sleep(5) pygame.quit() I've followed @Melanrz's hookup instructions to the best of my ability but something must be wrong. Assuming I got the connections right, how can I control the backlight to see if that's the problem (how to turn on/turn off the backlight)? Or, is there something else?

Was unsuccessful when using an orange pi one. Dmesg has entries which look like a good spi device being registered, but the display only flickered a little - no images at all. Has anyone interfaced one of these Arduino displays with an orange pi one?

Am I missing something here? I am not interested in making this an AP, just a end node device on my network which has nothing to do with being an AP. Right? One of the other threads in this forum made it clear that this is not an appropriate device for an AP, and they pointed out a site that could be used to find one. Why does the conversation keep coming to AP with this device. It's LOW END! Did I misunderstand? I'm interested in using this in home IoT projects and would like to send send receive some commands and data over my home wifi. I'm not using it as a tool to improve my network infrastructure, nor do I think that's it's design goal. I used to add a USB wifi connector to my old raspberry pi's -- maybe I could do that with this if it's on-board wifi is not usable.

I'm interested in low volume short distances so I might be able to use the on-board wireless. If I have trouble I'll run an Ethernet cable. My gawd, some of those devices are HUGE compared to the tiny zero. In fact it might be possible to put the zero inside the alfa's housing. lol

I just ordered a couple of Orange Pi Zero systems to use in small IoT projects. Reading the forum I see the wireless for Orange Pi Zero might have issues. But some of the posts wanted to use it as an AP. That's not my case, I'll test them when they get here, but just how bad is it? I will not have a heavy load, but I would like something stable. When push comes to shove should I plan on using an Ethernet cable rather than the wifi?

Thank you for spelling it out again. I now have armbian 5.16 running on a NanoPI NEO. Smiles all around ....

I'd misunderstood about the state of development for the neo (that's my own fault of course). Thank you for the pointers and the explanation. I'll read through the posts to get a better feel for the overall situation. The Ubuntu image provided by Friendly ARM works okay and can be used until there are other options.