Jump to content

tcmichals

Members
  • Posts

    14
  • Joined

  • Last visited

Posts posted by tcmichals

  1. The SPI select is driven by software, ie. drivers/spi.c not hardware.  Looking at spi.c

    1. spi_transfer_one_message
      1. assert CS
      2. setup/clear upper level call backs
      3. call into SPI driver sun6i_spi_transfer_one
        1. clear ISR callbacks etc
        2. setup SPI chip etc
        3. start the transfer.

    So, even if the SPI transfer rate is increased, the about of time from CS is asserted to the first SPI data transfer should be constant (i.e the time it takes to execute the code)

  2. Okay, I have the XR819 driver compiling against https://github.com/megous/linux/(this is the kernel source Armbian appears to have switched to).

     

    Pull request submitted to megous/linux...

     

    Might what to review the patches for the zero:

    https://groups.google.com/forum/#!topic/linux-sunxi/mdrG_TVmzUE

     

    I was doing the same thing:

    - Used patches from SUNXI

    - added Ethernet, and  CPUX regulator support

     

    For u-boot I'm using orangePI-ONE defconfig.  IMHO, The Zero is more like the orangePI-ONE then the OrangePI-PC

     

    FYI: I'm using buildroot.

  3. Yes, since the 4.8.x is completely broken under H3 (I still not understand why), I've switched to sun8i-emac-wip-v5 branch too.

    Now, I'm struggling to make SPI work again, I've fixed the DT, but I get "SPI transfer failed" during tests. It was working fine in 4.7.6 ...

     

    I'm using https://github.com/megous/linux/tree/orange-pi-4.9and applying the following patch https://lkml.org/lkml/2016/10/28/64 

    - Ethernet works

    - I2C works

    - Have not tested SPI, in progress.  

    I've added spi static const struct of_device_id spidev_dt_ids[] = {

    { .compatible = "rohm,dh2228fv" },

    { .compatible = "lineartechnology,ltc2488" },

            { .compatible = "spidev" },  //TCM:FIX  

    to spidev to get around creating a overlay.  I'm still clueless why kernel developers have not made this modification. 

  4. Ok, thanks to @lvmc we fixed this ! Here is how :

     

    apt-get install libusb-1.0-0-dev 
    git clone https://github.com/linux-sunxi/sunxi-tools
    cd sunxi-tools
    make
    

    ==> NOTE : Here I had an error finding libusb, so I udpated the file fec.c

     

    nano fec.c

    And replaced

     

    #include <libusb/libusb.h>

     

    with

     

    #include "/usr/include/libusb-1.0/libusb.h"

     

     

    ==> END NOTE

     

    Keep a backup :

    sudo mv /boot/script.bin /boot/script.bin.old

    Run :

    ./bin2fex /boot/script.bin.old script.fex

    Edit the file script.fex

    nano script.fex

    Look for this line (Ctrl+W to search in nano) :

    vip_dev0_mname  = "gc2035"

    And replace it with :

    vip_dev0_mname = "ov5640"

    Now save and create the bin from the fex :

    ./fex2bin script.fex script.bin
    sudo mv script.bin /boot/script.bin
    sudo chmod 777 /boot/script.bin
    

    reboot, and you're good to go ! 

     

    Uses @lex fswebcam :

    modprobe ov5640
    modprobe v4l2_vfe
    fswebcam --Hflip 1 -r 640x480 -p YUV420P - > cam640x480_1.jpg

    Thanks to @lvmc

    Do you have to reverse the cable? 

  5. I finished all tests on hardware level and it's confirmed that both GC2035 and OV5640 are now fully working!

     

    @lex has been doing an incredible job on Linux drivers, now focusing on frame grabbing compatibility.

     

    What is required to get the OV5640 working on a orangePI PC?  Is it possible to use the latest (sunxi) 4.8.x ?

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines