MitchD

Members
  • Content Count

    35
  • Joined

  • Last visited


Reputation Activity

  1. Like
    MitchD reacted to Larry Bank in Testing NanoPi NEO Core for gaming potential   
    I retested with NanoPi's Linux distro and it has USB OTG and analog audio working by default.
  2. Like
    MitchD reacted to Larry Bank in Testing NanoPi NEO Core for gaming potential   
    Update: Everything working now. These issues are resolved:
     
    1) Constant hangs were due to the cheap wifi adapter. It would hang the ssh session after 5-10 minutes of use. Switched to a better one and it now works reliably
    2) GPIO didn't behave the same as other systems. I had to add lseek(handle, 0, SEEK_SET) before each read from a GPIO pin. I should have done it earlier, but other machines seem to work without needing that
    3) Now I need to solder a 3.5mm socket onto the analog audio out to hear the output...
     
    Here's a video of it in action:
     
    https://photos.app.goo.gl/zLZS3Pw3iABCXVkK9
     
  3. Like
    MitchD reacted to Larry Bank in Testing NanoPi NEO Core for gaming potential   
    Today's project is trying to get my game emulator to run on the NanoPi NEO Core board. Lots of exposed I/O, but I'm getting random hangs and some odd behavior with the latest Armbian. In the photo is a ILI9342 (landscape version) 2.3" display and some ugly protoboards I created to allow reliable wiring + sockets for the Core board. I just updated my SPI_LCD project to include support for both the ILI9342 and the Core board's strange header: https://github.com/bitbank2/SPI_LCD
     
    I had to wire the USB-A socket to the header because the OTG port is not properly enabled (in the available Armbian build). If I spent some time messing with it, there's probably a bunch of patches to get it working, but soldering 4 wires seemed like the quicker fix for me.
     
    I'll keep you posted on my progress (if anyone is interested)
     
     

  4. Like
    MitchD reacted to mboehmer in Thanks for the fish!   
    Hi guys,
    some months ago I implemented an Odroid C2 as readout controller for a scientific instrument.
    Lot of people were kind and helped me with some problems with Armbian, especially eMMC and PWM.
     
    Today, finally, we managed to have our instrument (two strings with several Odroid C2 and other stuff) deployed.
    It is sitting now at 2628m depth in the Pacific Ocean, and will go operational the next days.
     
    Here we are... I think I can announce the deepest Odroid so far (cry loud if I'm wrong :) )
    In the picture you just can see the Titanium housing with two glass covers attached to the string.
     
    Again, thanks for the fish :)
     
    Michael

  5. Like
    MitchD reacted to mindee in NanoPi NEO4   
    Just a little bit list, more detail would be done on wiki soon.
    1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
    2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
    3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
    4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
    5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
    6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
     
    Both have:
    1. PCIe x2 pin-out
    2. eMMC module connector
    3. GigE port.
    4. TypeC is for power supply and OTG.
    5. HDMI-A & MicroSD slot.
    6. Big CNC heat sink, with two side 1/4 screw hole
  6. Like
    MitchD reacted to mindee in NanoPi NEO4   
    Not the final version.

     
    Update(8/24/2018): It's time to deal with NEO4, this picture is not the final version. NEO4 will have PCIe x2 and eMMC connector too, and a MIPI-CSI. But the dual-layer USB connector  will share USB 3.0 & USB 2.0, Type-C take another USB 3.0.

  7. Like
    MitchD reacted to Larry Bank in Pushing the I2C SSD1306 OLED to its limits   
    Thanks for the response. I took the path of least resistance and tested it on a Raspberry Pi Zero. On that platform I can edit the /boot/config.txt to change the I2C speed. It maxes out at 400Khz no matter what value you give it. That's fast enough to do decent animation:
     
     
    I wrote a blog post and shared the code on github:
     
    http://bitbanksoftware.blogspot.com/2018/05/practical-animation-on-i2c-ssd1306.html
     
  8. Like
    MitchD reacted to Larry Bank in UC1701 LCD library   
    I just released a new C library to draw text and graphics on the UC1701 128x64 monochrome LCD. It makes use of my ArmbianIO library to manipulate the GPIO lines:
     
    https://github.com/bitbank2/uc1701

  9. Like
    MitchD got a reaction from Selim Özdemir in To reduce the boot time   
    The only way to get it to boot in under 2 seconds is to use a toolchain like Yocto or Buildroot. I can boot my nanopi neo (same CPU) in about 3 seconds using buildroot. There is a steep learning curve, though. 
  10. Like
    MitchD reacted to MartinKeppler in Enabling LCD in u-boot Kernel 4.7.2   
    So, now I can tell you how to enable LCD in u-boot and DT.
     
    First getting the source of armbian from https://github.com/igorpecovnik/lib
    Open the file sources/u-boot/v2016.09/configs/Bananapi_defconfig and add:
    CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:24,pclk_khz:30000,le:40,ri:40,up:29,lo:13,hs:48,vs:3,sync:3,vmode:0" CONFIG_VIDEO_LCD_POWER="PH12" CONFIG_VIDEO_LCD_BL_EN="PH8" CONFIG_VIDEO_LCD_BL_PWM="PB2" Now LCD is enabled in u-boot. But it will not switch on backlight, because backlight uses pwm and pwm is disabled per default in DT. So you also have to add:
    &pwm { pinctrl-names = "default"; pinctrl-0 = <&pwm0_pins_a>, <&pwm1_pins_a>; status = "okay"; }; Ready!
    But be aware, LCD only turns on if there is no HDMI Monitor plugged in!!
     
    Ok, hopping some one else of you can use this stuff.
  11. Like
    MitchD reacted to MartinKeppler in Enabling LCD in u-boot Kernel 4.7.2   
    Okay Guys,
     
    I've got a little success. My display is on now. I think the worst thing I could do, was to let HDMI plugged in and HDMI monitor switched on. Only by luck, I saw, that my display is working when HDMI monitor is switched of.
    Now, I will search for the correct solution and post it here soon.
     
    Yours Martin
  12. Like
    MitchD reacted to Larry Bank in I2C not working on Orange pi zero   
    Thanks for mentioning that @Igor, I share a lot of code, but rarely get any feedback that people are using it.
  13. Like
    MitchD reacted to Strontium in Orange Pi Zero (H2+/H3) TV Out on Mainline, WORKING   
    Just an update, X installs and runs fine on the Orange PI Zero using my patch.  HOWTO:
     
    Install a desktop using
    sudo tasksel
    after its all finished properly, reboot.  You will then get this:
    https://imgur.com/a/seu9t

    if you want to change video mode, you can do it with xrandr like this:
    DISPLAY=:0 xrandr --output Composite-1 --mode NTSC DISPLAY=:0 xrandr --output Composite-1 --mode PAL You only need the "DISPLAY=:0" if you are doing the mode setting from a ssh terminal.

    Supposedly xrandr can scale the desktop and move it around (which could help with the overcan problem) but i couldn't get it to work in the 5 minutes I allocated to testing it.
  14. Like
    MitchD reacted to Strontium in Orange Pi Zero (H2+/H3) TV Out on Mainline, WORKING   
    Well it took me longer than i hoped but i have managed to forward port icenowys code for TVE on the H2+/H3 to mainline armbian.  It seems to work totally fine, with a few caveats.
    First: Sample images of it in action -> https://imgur.com/a/vXQEM
    Second: the patch itself -> https://github.com/stevenj/h3-tve/tree/v0.0.11
    Third a prebuilt image for Orange Pi Zero: -> https://github.com/stevenj/h3-tve/releases/tag/v0.0.11
     
    Howto:
    just put the patch into userpatches for the sunxi-next kernel, and build.  it should apply cleanly. Its for H2+/H3.  I have only tried it on a orange pi zero, but it should work on all H2+/H3 boards.
     
    You then need to edit /boot/armbianEnv.txt
    add tve to overlays to enable it.  the driver will only run and enable tv out when the tv out devices are specifically enabled, so i created an overlay which does this.  If you want to turn TV out off, just remove tve from the overlays line.
    My armbianEnv.txt overlays looks like this:
    overlays=usbhost2 usbhost3 tve If you want copious amounts of DRM debug info in your logs, add this as well:
    extraargs=drm.debug=0xF Its not needed, unless you really want the debug info.
     
    Notes:
    1. The default mode is PAL, with 720x576 resolution.  Thats outside of normal PAL displayable area, and so the screen overscans.
    I dont know how to correct this, although its mostly just annoying with terminals.
    I also don't know how to change the video mode to NTSC.
     
    2. The standard font is a bit thin for composite video, and causes slight strobing and color impurity.  Its because PAL needs pixels to be a certain MINIMUM width or color information can not be properly encoded.
    A way to resolve this is use :
    # apt-get install fbterm ... $ fbterm -s 20 This will run a terminal which is easy to change the font, and pick a bigger one.  its much easier to read.  Look at the help for fbterm to work out everything it can do.
     
    3. I used the program "fim" to display the test images.  there are others for doing stuff on the terminal.
     
    4. I haven't tried X.  I am not interested in running an X terminal on a TV, but it should probably work fine.
     
    Other than that it all seems good.  I originally tested my hardware with the legacy kernel, and the image quality from this patch seems superior to what the legacy kernel produces. (legacy was noisy)
     
    The only other thing you need to know is Orange Pi Zero is missing filter circuity from its Composite Output, the most important thing you need to do is put a 50 ohm resistor between the signal and GND.  i soldered one inside my RCA connector, it fits fine and isn't too difficult.  IF you don't do this the image will bloom and look like total crap, so you have been warned.
     
    As this patch allows TVE to be enabled/disabled through use of the Device Tree overlays, i think it should be fine if the Armbian devs want to include it.  I am happy to clean out some of the debug messages i added if they are interested in making a standard part of the build.  If not, its easy enough to build your own image, just follow the guides on how to rebuild armbian.
     
    EDIT: I need to mention, all props go to Icenowy Zheng who wrote the original driver.  I just tweaked the device tree stuff and got it in a state where it can apply cleanly to the armbian mainline kernel and build system.
    Original code is here:
    https://github.com/Icenowy/linux/tree/tve-v2
  15. Like
    MitchD reacted to arre in RT patches for sun8i kernel?   
    Hi all,
     
    Just wanted to share that I got the realtime patch working on an Orange Pi Zero on 4.18.8
    I used the armbian build environment and the official RT patch.
     
    A few tricky points were the CPU govenor and CPU operating points automatically switching by default, causing the realtime behavior to be really bad (max spikes around 3000 in cpu test).
    By patching the device tree to only use a fixed operating point, I achieve the following output:
    Linux orangepizero 4.14.8-rt9-sunxi #1 SMP PREEMPT RT Sat Jan 6 14:36:31 CET 2018 armv7l armv7l armv7l GNU/Linux /root/rt-tests/cyclictest -p 80 -t5 –n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.85 0.49 0.22 4/168 3083 T: 0 ( 3079) P:80 I:1000 C: 3297 Min: 8 Act: 17 Avg: 16 Max: 66 T: 1 ( 3080) P:80 I:1500 C: 2198 Min: 8 Act: 24 Avg: 15 Max: 50 T: 2 ( 3081) P:80 I:2000 C: 1648 Min: 8 Act: 11 Avg: 16 Max: 60 T: 3 ( 3082) P:80 I:2500 C: 1318 Min: 8 Act: 12 Avg: 15 Max: 44 T: 4 ( 3083) P:80 I:3000 C: 1098 Min: 9 Act: 17 Avg: 18 Max: 57  
    If anyone is interested, I used this realtime kernel to run a virtual wifi guitar amplifier on the orange pi zero.
    I documented the entire thing on http://arre234.blogspot.be/2018/02/linux-portable-wifi-guitar-amp-on.html , including the device tree and cpu govenor stuff.
     
    Hope this helps anyone
     
    Arnout
  16. Like
    MitchD reacted to René Kliment in Mali support announced for mainline (Allwinner SOC's)   
    This is my very dirty script that seems to work for me: https://gist.github.com/renekliment/707ea4a2dc3f11fc15ed8085f506c57e
  17. Like
    MitchD reacted to sgjava in Using Python, CFFI and libgpiod for cross SBC GPIO access   
    On my journey to finding the best solution for cross SBC/cross language GPIO support I went through the same issues as Python by the C side author did it seems and landed on CFFI. This is faster than ctypes and seem more natural to program with. ctypesgen (the code generator) doen't really support Python 3, so I've hit a dead end there. It seems like JNA is still the best choice for Java bindings, so I'm sticking with that for now. In any event I threw together a button press app that uses CFFI and libgrpiod. I'll be updating my bindings project to support this soon.
     
    libgpiod version 1.1.devel
    Name: gpiochip1, label: 1f02c00.pinctrl, lines: 32
    Press button within 5 seconds
    Falling edge timestamp 02/10/2018 19:49:05
    """ Test blocking event using built in button ------------- Should work on any board with a button built in. Just change chip and line value as needed. """ import sys, time from argparse import * from cffi import FFI parser = ArgumentParser() parser.add_argument("--chip", help="GPIO chip number (default 1 '/dev/gpiochip1')", type=int, default=1) parser.add_argument("--line", help="GPIO line number (default 3 button on NanoPi Duo)", type=int, default=3) args = parser.parse_args() ffi = FFI() # Specify each C function, struct and constant you want a Python binding for # Copy-n-paste with minor edits ffi.cdef(""" enum { GPIOD_LINE_EVENT_RISING_EDGE, GPIOD_LINE_EVENT_FALLING_EDGE, }; struct timespec { long tv_sec; long tv_nsec; }; struct gpiod_line { unsigned int offset; int direction; int active_state; bool used; bool open_source; bool open_drain; int state; bool up_to_date; struct gpiod_chip *chip; int fd; char name[32]; char consumer[32]; }; struct gpiod_chip { struct gpiod_line **lines; unsigned int num_lines; int fd; char name[32]; char label[32]; }; struct gpiod_line_event { struct timespec ts; int event_type; }; const char *gpiod_version_string(void); struct gpiod_chip *gpiod_chip_open_by_number(unsigned int num); struct gpiod_line *gpiod_chip_get_line(struct gpiod_chip *chip, unsigned int offset); int gpiod_line_request_falling_edge_events(struct gpiod_line *line, const char *consumer); int gpiod_line_event_wait(struct gpiod_line *line, const struct timespec *timeout); int gpiod_line_event_read(struct gpiod_line *line, struct gpiod_line_event *event); void gpiod_line_release(struct gpiod_line *line); void gpiod_chip_close(struct gpiod_chip *chip); """) lib = ffi.dlopen("libgpiod.so") print "libgpiod version %s" % ffi.string(lib.gpiod_version_string()) gpiod_chip = lib.gpiod_chip_open_by_number(args.chip) # Make sure GPIO chip opened if gpiod_chip != ffi.NULL: print("Name: %s, label: %s, lines: %d" % (ffi.string(gpiod_chip.name), ffi.string(gpiod_chip.label), gpiod_chip.num_lines)) gpiod_line = lib.gpiod_chip_get_line(gpiod_chip, args.line) # Verify we have line if gpiod_line != ffi.NULL: consumer = sys.argv[0][:-3] if lib.gpiod_line_request_falling_edge_events(gpiod_line, consumer) == 0: timespec = ffi.new("struct timespec*") timespec.tv_sec = 5 print("Press button within 5 seconds") rc = lib.gpiod_line_event_wait(gpiod_line, timespec) if rc == 0: print("Timed out") elif rc == 1: event = ffi.new("struct gpiod_line_event*") # Read event off queue lib.gpiod_line_event_read(gpiod_line, event) if event.event_type == lib.GPIOD_LINE_EVENT_RISING_EDGE: print("Rising edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Falling edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Unable request falling edge for line %d" % args.line) lib.gpiod_line_release(gpiod_line) else: print("Unable to get line %d" % args.line) lib.gpiod_chip_close(gpiod_chip) else: print("Unable to open chip %d" % args.chip)  
  18. Like
    MitchD reacted to MX_Master in OpenRISC core (AR100) for the real-time tasks   
    Service monitoring and restart functionality can be made by any ARM Linux program or script.
     
    If you want to be shure that Linux OS is running normally, you can use a combination of ARM Linux program and ARISC program. If linux program didn't answering to ping from ARISC program, the ARISC program can restart whole device.
     
    I will use the ARISC firmware just for GPIO toggling. My ARM Linux program periodically will send to ARISC a commands to generate exact number of pulses on the specific GPIO pins, with specific frequency rate. 
  19. Like
    MitchD reacted to MX_Master in OpenRISC core (AR100) for the real-time tasks   
    Thanks again to the jernej.
     
    Finally i got what i want. Now I can upload a firmware and run the ARISC core without any problems with armbian mainline kernel.
     
    Here is a test firmware source - https://github.com/MX-Master/h3-firmware/blob/test_3/main.c (simple leds blinking)
    Here is the uboot script source - https://github.com/MX-Master/h3-firmware/blob/test_3/fixup.cmd
     
    If somebody wants to test it.. the firmware blob and compiled uboot script can be found here
    https://github.com/MX-Master/h3-firmware/raw/test_3/h3-firmware.zip
     
    Tested with Orange Pi One and Armbian mainline image.
  20. Like
    MitchD reacted to Xalius in Kickstarter: Allwinner VPU support in the official Linux kernel   
    Free Electrons (now Bootlin ;/) have launched a Kickstarter to get the work on the Allwinner VPU (Video Processing Unit) off the ground again...
     
     
    https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel
  21. Like
    MitchD reacted to Tido in Different take on armbian-config   
    I agree with regard on the HELP, but the graphicle interface of yours is way too much - in my humble opinon.
    A review of current interface sounds good, but always keep low maintenance in mind.
    Days only have 24hrs
  22. Like
    MitchD got a reaction from Igor in Different take on armbian-config   
    I'm familiar with the armbian-config tool and while I think its cool, it may not be the best thing for the beginner. The hardest part of beginning anything is not knowing what you don't know. I've begun writing a simple tool using curses and python which hopefully disambiguates some of the features of each board. I'm currently focusing on H3 boards, since thats what I have and I'm most familiar with them.  Currently I have the ascii art and setup for the Orangepi PC, One, Zero, and Nanopi Neo. 
     
    The idea is to use the arrow keys to navigate, spacebar to select, 'b' for back, and (most importantly) 'h' for help. The help menu should have enough information to get a beginner going. 
     
    I'm currently working on the USB OTG section, and I'm trying to get all the configfs information on the internet into one place.  Having the option to have any amount of USB OTG gadgets selected is really cool, and I'm not sure a lot people know about it. I'm hoping to make the configuration easy, like selecting radio buttons.
     
    If anyone thinks this is cool (or that it sucks), let me know. Its still in development.
    Here is a gif of it in action:
     


     
    You can find the (in-progress) repo here: https://github.com/MitchRatquest/armbian-helper
  23. Like
    MitchD got a reaction from gnasch in Different take on armbian-config   
    I'm familiar with the armbian-config tool and while I think its cool, it may not be the best thing for the beginner. The hardest part of beginning anything is not knowing what you don't know. I've begun writing a simple tool using curses and python which hopefully disambiguates some of the features of each board. I'm currently focusing on H3 boards, since thats what I have and I'm most familiar with them.  Currently I have the ascii art and setup for the Orangepi PC, One, Zero, and Nanopi Neo. 
     
    The idea is to use the arrow keys to navigate, spacebar to select, 'b' for back, and (most importantly) 'h' for help. The help menu should have enough information to get a beginner going. 
     
    I'm currently working on the USB OTG section, and I'm trying to get all the configfs information on the internet into one place.  Having the option to have any amount of USB OTG gadgets selected is really cool, and I'm not sure a lot people know about it. I'm hoping to make the configuration easy, like selecting radio buttons.
     
    If anyone thinks this is cool (or that it sucks), let me know. Its still in development.
    Here is a gif of it in action:
     


     
    You can find the (in-progress) repo here: https://github.com/MitchRatquest/armbian-helper
  24. Like
    MitchD got a reaction from chwe in Different take on armbian-config   
    I'm familiar with the armbian-config tool and while I think its cool, it may not be the best thing for the beginner. The hardest part of beginning anything is not knowing what you don't know. I've begun writing a simple tool using curses and python which hopefully disambiguates some of the features of each board. I'm currently focusing on H3 boards, since thats what I have and I'm most familiar with them.  Currently I have the ascii art and setup for the Orangepi PC, One, Zero, and Nanopi Neo. 
     
    The idea is to use the arrow keys to navigate, spacebar to select, 'b' for back, and (most importantly) 'h' for help. The help menu should have enough information to get a beginner going. 
     
    I'm currently working on the USB OTG section, and I'm trying to get all the configfs information on the internet into one place.  Having the option to have any amount of USB OTG gadgets selected is really cool, and I'm not sure a lot people know about it. I'm hoping to make the configuration easy, like selecting radio buttons.
     
    If anyone thinks this is cool (or that it sucks), let me know. Its still in development.
    Here is a gif of it in action:
     


     
    You can find the (in-progress) repo here: https://github.com/MitchRatquest/armbian-helper
  25. Like
    MitchD reacted to sgjava in Build libgpiod the "New GPIO Interface for User Space"   
    OK, I whipped up a simple Python program using a thread to wait for an edge event while the main program is doing something else. https://github.com/sgjava/libgpiod-extra/blob/master/python/buttonthread.py
     
    You can pass --chip with GPIO chip number and --line for the line (pin) where your built in button is located. Really no need for IRQs since the events are queued and the thread is waiting on the edge to happen. You can use the thread to do a callback using OOP and an Observer pattern. This is more elegant than having C callback to Python, Java, etc.