Larry Bank

Members
  • Content Count

    159
  • Joined

  • Last visited

1 Follower

About Larry Bank

  • Rank
    Elite member

Profile Information

  • Gender
    Male
  • Location
    Sarasota, FL
  • Interests
    optimization, classic gaming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Larry Bank

    How to use ADXL345 linux drivers?

    If you can't get that going, you can use my project as a starting point. Talking to the ADXL345 over I2C is extremely easy and writing your own code will allow you to have better control of it. Here's my code: https://github.com/bitbank2/accelerometers
  2. Larry Bank

    GPIO Troubles

    The pin mappings in my ArmbianIO project exist because I own those boards. I just don't happen to own any Olimex boards. You're welcome to make a pin mapping table for your board(s) and do a pull request on Github. I'm happy to add contributions to the project. As Martin says, the AllWinner GPIO pins are numbered in a fixed pattern, so it's easy to create a pin mapping table from the schematic for your board.
  3. Larry Bank

    Which SBC to choose for music creation?

    I agree with @TonyMac32. The NanoPi or Orange Pi boards are plenty of CPU power and memory to do what you need. Audio processing normally doesn't require much RAM nor CPU (relative to an ARM board). It's too challenging a task for an AVR or ESP32 although a Cortex-M may be able to do it. There is more audio latency on Linux than a purely embedded solution and it's worse on ARM than on x86 boards. Using the SDL audio system, you'll probably see 100-250ms of latency when generating real time audio and pushing it out of the HDMI or analog out. It's really hard to avoid on Linux. I'm not sure about the jitter. If you don't starve the CPU with your other tasks, the audio driver should be able to reliably output the samples. If you don't need analog inputs, then you can probably avoid adding an Arduino AVR to the project. Touch buttons and a breath sensor can be implemented as digital devices, not analog.
  4. I just released some new code on github to play animated GIF files directly on a Linux framebuffer or SPI LCD (using my SPI_LCD code). It doesn't have any 3rd party dependencies and can easily be made to run on systems with no operating system or file system. This is part of my imaging library that I've been working on for more than 20 years. I'm slowly releasing parts of it as open-source. This code was sliced out of a much larger project which supports a whole bunch of image formats. https://github.com/bitbank2/gif_play Comments/feedback welcome.
  5. Larry Bank

    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.
  6. Larry Bank

    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
  7. 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)
  8. Larry Bank

    Armbian-Stretch and IR-Remote?

    I created a NEC IR code receiver. It's really pretty simple. The IR receiver on These ARM SBCs is just a digital signal connected to a GPIO pin. I shared a demo program on GitHub here: https://github.com/bitbank2/ir_receiver
  9. Larry Bank

    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
  10. Larry Bank

    Pushing the I2C SSD1306 OLED to its limits

    Sorry for being thick, but exactly what does that entail? Just adding a "param" line to armbianEnv.txt?
  11. Larry Bank

    Pushing the I2C SSD1306 OLED to its limits

    I'm porting this code and my OLED animation to Armbian. It runs rather slow at 100Khz I2C speed. Has anyone found a way to easily change the I2C speed on Mainline kernel Armbian without doing a custom build?
  12. Larry Bank

    Display ili9341 on H5

    Are you able to use SPI_LCD + BB-CP in place of fbtft+fbcp?
  13. I wrote a blog post about speeding up drawing on the SSD1306 display by bit-banging the I2C protocol. The code is for Arduino, but it has useful info about my iterative process of optimizing code that some of you may find interesting: https://bitbanksoftware.blogspot.com/2018/05/fast-ssd1306-oled-drawing-with-i2c-bit.html
  14. Larry Bank

    Display ili9341 on H5

    Now I'm confused. Are you using SPI_LCD + BB-CP or fbtft + fbcp?
  15. Larry Bank

    Display ili9341 on H5

    I like your idea, but think it might be easier to make a separate document; people tend to just run make and not look any further. It might be better to add a parameter to the make to specify the board name and then it will print a quick message about the pin numbering. To connect multiple SPI displays is not a problem. What and how do you want to display information on them? My SPI_LCD library allows you to write code which draws directly on the display. Having multiple virtual framebuffers would probably cause some performance issues for the board.