Larry Bank

  • Content count

  • Joined

  • Last visited

About Larry Bank

  • Rank
    Elite member

Profile Information

  • Gender
  • Location
    Sarasota, FL
  • Interests
    optimization, classic gaming
  1. That display is easy to work with if you don't need direct Linux/X11 support. What I mean is that I've written code to talk to those LCDs and it can draw text and graphics through direct function calls (e.g. Draw a string a of text at a specific x,y in a specific color). If that's sufficient for your project, give it a try:
  2. Orange Pi One Plus

    Thanks for noticing that. I've got mine sitting on my desk as a paperweight waiting for someone to release a working Linux distro for it. I'll report back my power consumption and speed measurements later today. Ugh - now I remember why I appreciate Armbian so much. The Linux distro provided by OrangePi is 1.5GB, yet somehow is missing everything I need. This may take a while... Update: The board doesn't really seem to have any advantage over H5 boards. The max CPU frequency in the kernel shows as being 1.8Ghz, with the min set to 480Mhz. When pushed by my gcc_perf test, the results didn't fare much better than an RPI3. The power usage is what's really disappointing. The other H2+/H3/H5 boards I've tested usually max out at about 580mA when all 4 cores are cranking. The H6 is supposed to be a 28nm process and I thought that would mean lower power usage. The Orange Pi One Plus maxes out at 830mA when all 4 cores are stressed by gcc. Can anyone else do some testing to see if it matches my results?
  3. RK3399 Orange Pi

    This is even more interesting. Pine64 is apparently going to release a low cost RK3399 board ($60!). Here are the details:
  4. RK3399 Orange Pi $114 with shipping from AliExpress. Interesting board. I don't have a specific use for it, but it's great to see more powerful ARM chips being offered as SBCs.
  5. Help for pyA20 on orange pi zero plus with H5

    Are you willing to give ArmbianIO a try? It has C, Java and Python bindings and should work fine on your board. I'm not sure if your board name is in the list of supported boards, but you can pass it the name of the Orange Pi Zero (which should have the same gpio mapping).
  6. The PhoenixCard tool is the one I was referring to. When I run it, it makes the cursor change to "busy" for one second and then nothing. Is there some secret to install/run it besides unpacking the archive into a directory?
  7. I sent a complaint through AliExpress and Steven Zhou (director of Xunlong) responded that I needed to use his special microsd image burning tool. The tool he directed me to use is supposedly the only way to get Android images onto microsd cards for the board. I downloaded the tool on my Windows 10 laptop and it doesn't even run. I told him this and now he tells me to run the program in a VirtualBox running Windows inside of Linux. I asked if I could use a beta copy of Linux and he said he would not provide one. Basically SOL
  8. That worked - thanks. I just loaded the latest Armbian Next build and it's still messed up. Can someone please fix this?
  9. testers wanted ArmbianIO API proposal

    Hi Stuxnet, Thanks for the encouragement. Richard Hull's project is pure python and doesn't have any additional useful info for me. In fact, his project takes a very simplistic approach to the GPIO numbering and won't work properly on all boards. I'll keep improving ArmbianIO with the goal of it being easy to use and having support for all boards supported by Armbian.
  10. testers wanted ArmbianIO API proposal

    This looks like a solution for 4.x kernel, but what about supporting 3.x? There doesn't seem to be any board-specific info in the /proc directory.
  11. testers wanted ArmbianIO API proposal

    I'll explore fixing the board name situation using your suggestion. Another reason I shared ArmbianIO as open source was for other people to contribute. @sgjava has already made some significant contributions such as Python and Java wrappers for it.
  12. testers wanted ArmbianIO API proposal

    ArmbianIO is not a fork of WiringOP. I wrote ArmbianIO because of the terrible situation with WiringOP and WiringNP. Using the BCM numbering on Allwinner boards is understandable for RPI compatibility, but limits what you can do with non-BCM chips. I thought a fresh start which treats all boards as unique and allows more than 40-pins of GPIO header would be wiser than another "crutch" of a hacked up WiringPi copy. I have a wide variety of boards and ArmbianIO (even running on Raspberry Pi boards) allows a consistent way to work with GPIO/I2C/SPI. I know that when I hook an LED or switch to a GPIO pin, I can run the same code on any of my boards and connect it to the same header pin and it will work without modifying my code. chwe: splited from cause I think it's better to keep this in this thread.
  13. Hardware line is missing on /proc/cpuinfo

    That misses the point of ArmbianIO. The purpose of it is that when you connect your device to pin X (e.g. 1-40) on the GPIO header, you reference X in your code and don't have to deal with the specifics of each SoC/board. The only way to accomplish that is to have a specific pin map for each board and properly identify the board. I recently added a new option that lets you manually specify the board by name if it doesn't see the
  14. Hardware line is missing on /proc/cpuinfo

    There is no "SoC specific pin map". The SoC info is not enough to know the pin map because it's completely arbitrary and up to the board manufacturer. The 40-pin header on the NanoPi boards use different GPIO ports from the 40-pin header on OrangePi boards.
  15. I haven't tried to build a Linux image. There is no serial output with the Android image I tried. Can you share a Linux image for me to test?