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.

I think this might be an obvious question, but ... where is the armbian test image? I have a Nano Pi NEO in hand, and I really want to get armbian on it (especially after spending a few hours running the Friendly ARM Ubuntu release).

@trewq please share anything that might help others who plan on getting their own neo (mine is on the way ;-))

Did you read through the pinned thread [Tutorial] Orange Pi One - adding USB, analog audio out, TV out, mic and IR receiver at the top of the forum? I know it has some information on audio; hopefully it has something pertaining to your issue.

I just saw that and was starting to comment here so it wasn't a dangling thread. I'll manipulate the mclk argument to see the different effects it has on various resolutions.

I think I have a bad gc2035 module that I'll soon put aside, but there's something odd I don't understand. Since it's cheap it doesn't merit a lot of attention, but I've got something that doesn't make sense to me. If you understand, please let me know. An image at 800x600 is messed up with horizontal stripe artifacts (fswebcam -r 800x600 -p YUV420P -> foo-800x600.jpg) But an image at 1280x720, while blurry, does not have the stripe artifacts (fswebcam -r 1280x720 -p YUV420P -> foo-1280x720.jpg) Why aren't stripe artifacts in the higher resolution? I thought the sensor was completely trashed, but it produced a halfway decent image when asked to produce at a resolution unreasonably high for it's capabilities. Shouldn't I get more artifacts at higher resolutions?

Using all brand new equipment (an Orange Pi One, gc2035 cam on expansion board, 5V3A power supply, and fresh jessie server image updated/upgraded to 5.16) I can verify that steps suggested by @lex work and I can get a nice image from my CSI video cam with fswebcam. domo arigatou gozaimasu

I would also like to thank everyone too. I haven't been derided for asking silly questions (and, trust me, I KNOW some of them are dumb; but I'll only stay ignorant until I ask and learn). Suggestions are quick and varied, and necessary changes are quickly implemented. I consider this an ideal environment. I found this forum because I'm exploring different form factors. So many choices! My recent experience is with the orange pi one, but I'm really excited about the NanoPi Neo. I found the discussion in another thread about that interesting so I ordered two, and when I get them I plan on following the suggestions to test armbian.

Your suggestions worked. I added (well, uncommented) the following two lines in /etc/modules gc2035 vfe_v4l2 And created /etc/modprobe.d/gc2035.conf with the following options gc2035 hres=0 mclk=34 The modules now load as I'd like across reboots.

Your magic incantations work perfectly! I added "gc2035 hres=0 mclk=34" and "vfe_v4l2" to /etc/modules and rebooted, but that didn't seem to have the same effect as when they were added manually. Perhaps /etc/modules doesn't like arguments? If so, is there a way to make it stick? Should /etc/modules accept arguments? Also, "-p YUV420P" seems critical for fswebcam. I'll study up on that this weekend so I'll know more about that soon. On a minor note, I may have damaged my little camera by checking, undoing, redoing, rechecking, undoing, and redoing the cables countless times trying to be sure I didn't have things loose or in backwards. My jpg image has a lot of bright green horizontal stripes across the bottom. I have another new orange pi one, camera, and power supply, so I'll set that up from scratch to verify. My power supply is 5V3A, so I don't think that should be a problem. The main thing is that I can get images!!!!

You're right. But I think my comment might be misunderstood; The only reason I mentioned raspbian is that some of us are new to armbian and have historical references in the old world. I can see where it might be seen as a slight, but that is not my intention! I've become rather fond of armbian in the last few weeks and plan on continue to use it in the foreseeable future and sometimes I bring the old way of doing things to the new environment, even when, in this case, it's was unnecessary.