Jump to content

Larry Bank

Members
  • Posts

    161
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Larry Bank got a reaction from gounthar in I finally mapped the GPIO on the OPZ+2 (H3)   
    The documentation on the Orange Pi Zero Plus 2 is somewhat scarce. I couldn't find information on the GPIO map for the 26-pin header anywhere, but I manually mapped it. I did this with an LED on each successive pin and testing through the /sys/class/gpio driver until I found the one to control it. This caused a bunch of resets and eventually corrupted my sd card, but I got the info
     
    Each of the numbers below is the GPIO number used for /sys/class/gpio. For example, 110 means gpio110. The list is by pin number from 1 to 26. A value of -1 means unavailable (as far as I could discover):
     
    -1, -1, 12, -1  (pin 1,2,3,4)
    11,-1,6,0 (pin 5,6,7,8)
    -1,1,352,107 (pin 9,10,11,12)
    353,-1,3,19 (pin 13,14,15,16)
    -1,18,-1,-1 (pin 17,18,19,20)
    -1,2,14,13 (pin 21,22,23,24)
    -1,110 (pin 25, 26)
     
    I've added this table to my SPI_LCD project to make it easier to use for generic GPIO access without having know the details of working with the sysfs kernel driver: https://github.com/bitbank2/SPI_LCD
     
    P.S. The red LED on the board is mapped to GPIO17
     
  2. Like
    Larry Bank got a reaction from ali vali in OpiZero-Plus2 -H3 experimental ?   
    Please see my forum post here:
     
    I mapped the majority of the pins on the OPZ+2 (H3). The GPIO numbers are quite different from the OPZ. Let me know if you have any questions
     
  3. Like
    Larry Bank got a reaction from c.mah in ArmbianIO API proposal   
    I was chatting with @tido about ways to help the Armbian community and I came up with the idea of a common C library to access the I2C, SPI and GPIOs of all supported boards. There are of course kernel drivers to communicate with these things, but there are differences between boards that this API could help smooth out. For example, different CPUs (and boards) map the GPIO pins very differently. Projects such as WiringOP and WiringNP try to copy the Raspberry Pi library, but this is also flawed because it's based on the BCM283x GPIO numbering. What I propose is to create a set of simple functions for accessing GPIO pins using the physical pin number as a reference. On all boards, the 5V pin will be considered pin 2 and the numbering goes from there. There are also sometimes pushbuttons present on the board which are mapped to GPIO inputs. These are also covered by my API. Much of the code is already written and I will release it shortly.  I'm posting this topic to get feedback and to reach out to people who might make use of this. Here is a list of the functions so far:
     
    int AIOInit(void);
    void AIOShutdown(void);
    const char * AIOGetBoardName(void);
    int AIOOpenI2C(int iChannel, int iAddress);
    int AIOOpenSPI(int iChannel, int iSpeed);
    int AIOCloseI2C(int iHandle);
    int AIOCloseSPI(int iHandle);
    int AIOReadI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
    int AIOWriteI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
    int AIOReadSPI(int iHandle, unsigned char *buf, int iCount);
    int AIOWriteSPI(int iHandle, unsigned char *buf, int iCount);
    int AIOReadWriteSPI(int iHandle, unsigned char *inbuf, unsigned char *outbuf, int iCount);
    int AIOReadButton(void);
    int AIOAddPin(int iPin, int iDirection);
    int AIORemovePin(int iPin);
    int AIOReadPin(int iPin);
    int AIOWritePin(int iPin, int iValue);
  4. Like
    Larry Bank got a reaction from MitchD 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.
  5. Like
    Larry Bank got a reaction from MitchD 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
     
  6. Like
    Larry Bank got a reaction from MitchD 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)
     
     

  7. Like
    Larry Bank reacted to TonyMac32 in Small monochrome displays   
    Little follow-up:  I agree completely with @Larry Bank, the Nokia 5110 displays are terrible, the HX1230 is very nice.
  8. Like
    Larry Bank got a reaction from gounthar in ArmbianIO API proposal   
    I was chatting with @tido about ways to help the Armbian community and I came up with the idea of a common C library to access the I2C, SPI and GPIOs of all supported boards. There are of course kernel drivers to communicate with these things, but there are differences between boards that this API could help smooth out. For example, different CPUs (and boards) map the GPIO pins very differently. Projects such as WiringOP and WiringNP try to copy the Raspberry Pi library, but this is also flawed because it's based on the BCM283x GPIO numbering. What I propose is to create a set of simple functions for accessing GPIO pins using the physical pin number as a reference. On all boards, the 5V pin will be considered pin 2 and the numbering goes from there. There are also sometimes pushbuttons present on the board which are mapped to GPIO inputs. These are also covered by my API. Much of the code is already written and I will release it shortly.  I'm posting this topic to get feedback and to reach out to people who might make use of this. Here is a list of the functions so far:
     
    int AIOInit(void);
    void AIOShutdown(void);
    const char * AIOGetBoardName(void);
    int AIOOpenI2C(int iChannel, int iAddress);
    int AIOOpenSPI(int iChannel, int iSpeed);
    int AIOCloseI2C(int iHandle);
    int AIOCloseSPI(int iHandle);
    int AIOReadI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
    int AIOWriteI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
    int AIOReadSPI(int iHandle, unsigned char *buf, int iCount);
    int AIOWriteSPI(int iHandle, unsigned char *buf, int iCount);
    int AIOReadWriteSPI(int iHandle, unsigned char *inbuf, unsigned char *outbuf, int iCount);
    int AIOReadButton(void);
    int AIOAddPin(int iPin, int iDirection);
    int AIORemovePin(int iPin);
    int AIOReadPin(int iPin);
    int AIOWritePin(int iPin, int iValue);
  9. Like
    Larry Bank got a reaction from tkaiser 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
     
  10. Like
    Larry Bank got a reaction from tkaiser 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)
     
     

  11. Like
    Larry Bank got a reaction from CabröX in Animated GIF player for framebuffer and SPI LCD   
    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.
     
  12. Like
    Larry Bank got a reaction from tkaiser in Animated GIF player for framebuffer and SPI LCD   
    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.
     
  13. Like
    Larry Bank got a reaction from MitchD 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
     
  14. Like
    Larry Bank got a reaction from jscax 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
     
  15. Like
    Larry Bank got a reaction from TonyMac32 in 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
     
  16. Like
    Larry Bank got a reaction from Vincen in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    It will probably be months (years?) of software problems before a decent Linux distro works on it, but I ordered one anyway  
  17. Like
    Larry Bank got a reaction from Gravelrash in HX1230 LCD (96x68 monochrome)   
    I just received a couple of these inexpensive LCD displays ($1.82 each shipped). They are very low power and look good. I've got them working on Arduino and will now be converting the code to Linux. If anyone is interested in these, let me know. I'll edit this post to add the github link when it's ready.
     

  18. Like
    Larry Bank reacted to Igor in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU
  19. Like
    Larry Bank got a reaction from TonyMac32 in ArmbianIO API proposal   
    I just published a simple C project to make use of the IR receiver (either on-board or connected to an arbitrary GPIO):
     
    https://github.com/bitbank2/ir_receiver
     
    It's basically the simplest C code to receive IR codes without the use of external libraries or kernel drivers. It depends on a reasonably accurate system clock. This works fine on Armbian running on OrangePi boards, but doesn't work on my RPI3B.
  20. Like
    Larry Bank reacted to chwe in Why is the Tinker Board GPIO ports so slow?   
    Attachments are not visible... 
     
    to my knowledge, we don't deliver wiringPi with armbian.. So, did you install it or do you use TinkerOS (whitch is no part of Armbian)?
     
    From a quick google search, I might be wrong, but tinkers wiringPi has a 'fallback' to sysFS (/sys/class/gpio) and RPis wiringPi is based on gpiomem (writing direct to the SoCs registers). sysFS in known to be slower than gpiomem. 
     
    in development branch we do provide a rootless gpiomem access, but at the moment you have to build those images on your own.
    https://github.com/armbian/build/pull/907
     
    You might build your own image and test wiringPi again and look if this speeds up the process. Just as a side-note, I've only tested if it works, I didn't do any performance tests, simply cause I don't have any oscilloscope to 'benchmark' the speed.  
     
    How to build images:
    https://docs.armbian.com/Developer-Guide_Build-Preparation/
    How to switch to development branch:
    LIB_TAG="development"
     
    Edit:
    and otherwise, you can test ArmbianIO from @Larry Bank which is also based on sysFS but might be a bit more 'lightweight'.. Not sure, cause I didn't do 'benchmarking' and I don't know if somebody ever tried to get at it's limit.. 
  21. Like
    Larry Bank got a reaction from TonyMac32 in ArmbianIO API proposal   
    ** Update **
    I just added support to the ArmbianIO project for accessing the on-board IR receiver (connected to GPIO PL11 on many Orange Pi boards). Use the macro "IR_PIN" when reading the signal from the receiver (instead of specifying the header pin number). I will be releasing a demo app shortly which receives NEC ir codes without the use of the LIRC driver. My demo app will allow you to connect any IR receiver to any available GPIO pin or use the built-in one if present. The IR codes can be received with a simple 1-bit port without the use of a UART by simply timing the on/off signal to a reasonable margin of error using the Linux clock functions.
     
  22. Like
    Larry Bank got a reaction from chwe in ArmbianIO API proposal   
    ** Update **
    I just added support to the ArmbianIO project for accessing the on-board IR receiver (connected to GPIO PL11 on many Orange Pi boards). Use the macro "IR_PIN" when reading the signal from the receiver (instead of specifying the header pin number). I will be releasing a demo app shortly which receives NEC ir codes without the use of the LIRC driver. My demo app will allow you to connect any IR receiver to any available GPIO pin or use the built-in one if present. The IR codes can be received with a simple 1-bit port without the use of a UART by simply timing the on/off signal to a reasonable margin of error using the Linux clock functions.
     
  23. Like
    Larry Bank got a reaction from chwe in RPi SenseHAT on Tinkerboard   
    I wrote some C code to talk to the sense hat from Armbian. The display works fine and so do the sensors:
     
    https://github.com/bitbank2/sense_hat_unchained
     
     
  24. Like
    Larry Bank got a reaction from MitchD 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

  25. Like
    Larry Bank got a reaction from guidol in Real time clock DS3231   
    It's not a battery soldered on to that small module, it's a tiny supercapacitor
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines