Jump to content

Vancouver

Members
  • Posts

    19
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Vancouver got a reaction from Igor in NanoPi Duo2 usbhost not working   
    Ok, just switched to 5.83.190426:
     
    :~$ lsusb
    Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 004 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
    Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
     
    So everything seems fine now.
     
    Thank you very much for your support!
     
  2. Like
    Vancouver got a reaction from gnasch in SPI issue with Banana Pro/A20   
    Hi together,

    I spent a lot of time in understanding the SPI driver architecture, and I came to the conclusion that I cannot gain the performance required for my application while using this linux SPI driver. Maybe I am wrong with that, but each SPI transfer requires traversing a driver architecture of three levels (spi-sun4i.c, spi.c, spidev.c) with many function calls in between. Even if the time for a pure SPI data transfer is determined by the SPI clock frequency only, the setup time before starting the transfer is significantly longer.
    This does not play a role as long as we want to readout a temperature or inertial sensor a few ten times per second, but for controlling a QVGA tft display it is definitely too slow.

    The display in question (see http://admatec.de/pdfs/C-Berry_0.pdf)is shipped with a demo software for the Rapsberry Pi, and on an Raspberry (an old model B+) I interestingly do not have any performance issues. The display runs as expected with about 2-3 fps. So I looked into their source code and found that they bypass the kernel's driver architecture. The software is based on the BCM2835 library which seems directly write into the peripheral registers via /dem/mem. In the BCM library documentation is said

    "In order for bcm2835 library SPI to work, you may need to disable the SPI kernel module [...]"

    There is a port of the bcm2835 library available for the Banana which claims to be fully compatible, but in fact the Banana version takes the long way over the linux driver which is about 10 times slower.

    In order to come to a solution, I went the same way as the Raspberry software and handled all the SPI and GPIO stuff via the /dev/mem interface. The display performance is comparable to the Raspberry version now. However, accessing peripheral registers directly from the user space is clearly a nightmare from the kernel's point of view. So I decided to go the clean way and changed it into a separate kernel driver. Somebody already wrote a framebuffer driver for this display on the Raspberry again. I modified this driver and replaced the BCM specific parts by the A20 register interface. Then I build a kernel version without any SPI driver (except mine). There is still some potential or enhancement, for example I  take control over some GPIO pins even if the GPIO register space is occupied by another driver. Here I have to take care not to change any GPIOs used by other devices. However... it works.

    It was a very long way to come here, but I think this is the best way. I tested some small demo applications using pygame. The speed is as I would expect from an SPI connected display.



     
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines