Using more digital pins on M4?

Discussion in 'UDOO NEO' started by Maurice, Nov 6, 2016.

  1. Maurice

    Maurice Active Member

    Joined:
    Oct 13, 2015
    Messages:
    394
    Likes Received:
    87
    Has anybody got around trying to use more digital pins on M4? Being a noob on dts and such I'm not really sure how to do it. I already get stuck at finding the requiring dtsi files...
     
  2. Maurice

    Maurice Active Member

    Joined:
    Oct 13, 2015
    Messages:
    394
    Likes Received:
    87
    Note that the documentation states
    , but there is no such file as imx6sx-udoo-neo-external.dtsi, there is a file imx6sx-udoo-neo-externalpins.dtsi though in /arch/arm/boot/dts...
     
  3. Maurice

    Maurice Active Member

    Joined:
    Oct 13, 2015
    Messages:
    394
    Likes Received:
    87
    I'm following the instructions, but I'm wondering about the part with changes to be made to the pin map in wiring_digital.c:
    I assume that if I want all pins to M4 I need to uncomment and include this. But, do these pins then work as I2C on M4?
     
  4. Maurice

    Maurice Active Member

    Joined:
    Oct 13, 2015
    Messages:
    394
    Likes Received:
    87
    I've changed in wiring_digital.h:
    #define ARD_NMAX_DIO 36

    and added in wiring_digital.c:
    {ARD_DIO14, ARD_DIO14_MUX_GPIO}, // 14 SDA
    {ARD_DIO15, ARD_DIO15_MUX_GPIO}, // 15 SCL
    {ARD_DIO16, ARD_DIO16_MUX_GPIO}, // 16
    {ARD_DIO17, ARD_DIO17_MUX_GPIO}, // 17
    {ARD_DIO18, ARD_DIO18_MUX_GPIO}, // 18
    {ARD_DIO19, ARD_DIO19_MUX_GPIO}, // 19
    {ARD_DIO20, ARD_DIO20_MUX_GPIO}, // 20
    {ARD_DIO21, ARD_DIO21_MUX_GPIO}, // 21
    {ARD_DIO22, ARD_DIO22_MUX_GPIO}, // 22
    {ARD_DIO23, ARD_DIO23_MUX_GPIO}, // 23

    {ARD_DIO24, ARD_DIO24_MUX_GPIO}, // 24
    {ARD_DIO25, ARD_DIO25_MUX_GPIO}, // 25
    {ARD_DIO26, ARD_DIO26_MUX_GPIO}, // 26
    {ARD_DIO27, ARD_DIO27_MUX_GPIO}, // 27
    {ARD_DIO28, ARD_DIO28_MUX_GPIO}, // 28
    {ARD_DIO29, ARD_DIO29_MUX_GPIO}, // 29
    {ARD_DIO30, ARD_DIO30_MUX_GPIO}, // 30
    {ARD_DIO31, ARD_DIO31_MUX_GPIO}, // 31
    {ARD_DIO32, ARD_DIO32_MUX_GPIO}, // 32
    {ARD_DIO33, ARD_DIO33_MUX_GPIO}, // 33
    {ARD_DIO34, ARD_DIO34_MUX_GPIO}, // 34
    {ARD_DIO35, ARD_DIO35_MUX_GPIO}, // 35



    I've tried reading input from pins 35,34,33 and 16. 33 and 16 were ok, 34 and 35 did nothing.
    Also, is 35 the maximum? The row goes to 47.
     
  5. Masquime

    Masquime New Member

    Joined:
    May 4, 2017
    Messages:
    13
    Likes Received:
    3
    Hello Maurice,
    As you, I need to use more digital pins on M4, and I saw those instructions but I still need some help : ( I have a Neo basic board)
    - I didn't found the imx6sx-udoo-neo.dtsi file
    - I don't know how to open and read it
    - I don't know how to recompile the kernel

    So, I'm a noob, thanks for your help.
     
  6. Maurice

    Maurice Active Member

    Joined:
    Oct 13, 2015
    Messages:
    394
    Likes Received:
    87
    What is the operating system you are running on? I'm on Ubuntu, I'm not sure how other (non-Linux) operating systems work.
    For getting the toolchain and other stuff you have to follow the steps in Advanced topics in the UDOO Neo documentation.
     
  7. Masquime

    Masquime New Member

    Joined:
    May 4, 2017
    Messages:
    13
    Likes Received:
    3
    Maurice, I'm on Ubuntu too.
    Finally, I found files here .
    I modified them. Then, I tried to compile .dts using that command line :
    dtc -I dts -O dtb -o path/<devicetree name>.dtb path/<devicetree name>.dts
    But I get an error : unable to parse input tree
    I also try this advanced topics : https://www.udoo.org/docs-neo/Advanced_Topics/Compile_Linux_Kernel.html
    But the gcc-arm-linux-gnueabihf installation failed.
    Is there a way to only compile device trees or I have to compile the entire kernel ? That's I don't understand...

    Edit : It was painful for me, but it works now. It seems that I don't need gcc-arm-linux-gnueabihf because another version of a cross compiler was installed. (I followed the advanced topic)
     
    Last edited: May 12, 2017
  8. Dirk

    Dirk New Member

    Joined:
    Jan 31, 2019
    Messages:
    1
    Likes Received:
    1
    After a few day's and a lot of anxiety I got it working too.

    Finally I realised that the wiring_digital.c and wiring_digital.h are needed in the compilation of the Arduino-code. So.. when programming your code from an external PC, that's the place where these files have to be modified then.
    In my case (under Windows) they were in users\current_user\AppData\Local\Arduino15\packages\UDOO\hardware\solox\1.6.7\variants\udooneo.
     
    waltervl likes this.
  9. Matt_Neo

    Matt_Neo UDOOer

    Joined:
    Jun 14, 2019
    Messages:
    15
    Likes Received:
    9
    Hi,

    There’s lots of good progress here (and thanks for that!), but seems many of us have had trouble with this and so I’ve put together a complete guide from all the different threads… except it’s not quite working so hoping that one of you that made it all the way through can add the final piece by telling me what I’ve missed or done wrong…

    GOAL: Trying to move two of the external pin banks from the A9 to the M4 (all of the pins 16 to 33 on J4 and J6).

    Therefore we followed the instructions at:
    https://www.udoo.org/docs-neo/Arduino_M4_Processor/Use_more_digital_pins_on_M4.html
    https://www.udoo.org/docs-neo/Advanced_Topics/Compile_Linux_Kernel.html

    As well as forum topics:
    https://www.udoo.org/forum/threads/help-me-please.11802/
    https://www.udoo.org/forum/threads/using-more-digital-pins-on-m4.5146/#post-23479

    Although it seems the steps have been done right - the final result doesn’t seem to be working. However there are still many gaps in the instructions so I’ll list everything I’ve done in detail and hope you can tell me what’s missed or done wrong. I’m going to copy excerpts from those instructional sources above (in italics) and put QUESTIONS inline in bold. If someone can please point out the last missing piece then we’ll have a complete guide in one place which will be great for the community!


    STEP 1: Install the required packages

    sudo apt-get update

    sudo apt-get install gawk wget git diffstat unzip texinfo gcc-multilib \

    build-essential chrpath socat libsdl1.2-dev xterm picocom ncurses-dev lzop \

    gcc-arm-linux-gnueabihf


    (ignore error messages for build-essential and gcc-arm-linux-gnueabihf)


    STEP 2: Get the kernel sources from GitHub

    Create a develop folder


    mkdir udoo-dev
    cd udoo-dev


    QUESTION: We assume this folder can be created anywhere in the udooer directory?

    then download the sources:

    git clone https://github.com/UDOOboard/linux_kernel
    cd linux_kernel
    The default branch 3.14-1.0.x-udoo is the one where we are working on for the UDOO QUAD/DUAL. It is based on 3.14.56 Freescale community kernel.
    QUESTION: Is this also correct for UDOO NEO?


    STEP 3: Modify imx6sx-udoo-neo-externalpins.dtsi file

    Inside the source files downloaded in previous step, located at: (SAVE FOLDER)/udoo-dev/linux_kernel/arch/arm/boot/dts

    There will be a file: imx6sx-udoo-neo-externalpins.dtsi
    (note this is not quite the same name as given in the official documentation)

    Open it and modify by commenting out the lines for the GPIOs you want to remove from the A9. Ours were to add comments to all these lines:

    //MX6SX_PAD_NAND_DATA06__GPIO4_IO_10 0x80000000// {{external-gpio-16}}
    //MX6SX_PAD_NAND_DATA07__GPIO4_IO_11 0x80000000// {{external-gpio-17}}
    //MX6SX_PAD_SD4_DATA6__GPIO6_IO_20 0x80000000// {{external-gpio-18}}
    //MX6SX_PAD_SD4_DATA7__GPIO6_IO_21 0x80000000// {{external-gpio-19}}
    //MX6SX_PAD_SD4_CLK__GPIO6_IO_12 0x80000000// {{external-gpio-20}}
    //MX6SX_PAD_SD4_CMD__GPIO6_IO_13 0x80000000// {{external-gpio-21}}
    //MX6SX_PAD_SD4_RESET_B__GPIO6_IO_22 0x80000000// {{external-gpio-22}}
    // MX6SX_PAD_CSI_PIXCLK__GPIO1_IO_24 0x80000000// {{external-gpio-23}}

    //MX6SX_PAD_CSI_VSYNC__GPIO1_IO_25 0x80000000// {{external-gpio-24}}
    //MX6SX_PAD_CSI_HSYNC__GPIO1_IO_22 0x80000000// {{external-gpio-25}}
    //MX6SX_PAD_CSI_DATA00__GPIO1_IO_14 0x80000000// {{external-gpio-26}}
    //MX6SX_PAD_CSI_DATA01__GPIO1_IO_15 0x80000000// {{external-gpio-27}}
    //MX6SX_PAD_CSI_DATA02__GPIO1_IO_16 0x80000000// {{external-gpio-28}}
    //MX6SX_PAD_CSI_DATA03__GPIO1_IO_17 0x80000000// {{external-gpio-29}}
    //MX6SX_PAD_CSI_DATA04__GPIO1_IO_18 0x80000000// {{external-gpio-30}}
    //MX6SX_PAD_CSI_DATA05__GPIO1_IO_19 0x80000000// {{external-gpio-31}}
    //MX6SX_PAD_CSI_DATA06__GPIO1_IO_20 0x80000000// {{external-gpio-32}}
    //MX6SX_PAD_CSI_DATA07__GPIO1_IO_21 0x80000000// {{external-gpio-33}}


    I made no other changes to the file, saved it and closed.


    STEP 4: Load the default kernel configuration

    ARCH=arm make udoo_neo_defconfig
    QUESTION: Is this command supposed to be issued when you’re in the (SAVE FOLDER)/udoo-dev/linux_kernel directory?


    STEP 5: Compile Device Trees

    QUESTION: Is it necessary to recompile the whole kernel for this to work? We assumed it would not be and skipped that step, along with the following steps to recompile the modules and copy the kernel to the SD card.

    ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make dtbs -j5
    QUESTION: Is this command supposed to be issued when you’re in the (SAVE FOLDER)/udoo-dev/linux_kernel directory?


    Step 6: Copy .dtb files to the boot directory

    At this point there will now be a whole bunch of new .dtb files in the directory: (SAVE FOLDER)/udoo-dev/linux_kernel/arch/arm/boot/dts

    Copy all the .dtb files that start with “imx6sx-udoo-neo” (there should be 32 files in all) and paste them into: /boot/dts

    As things progressed and tried many different things we also copied all 32 of those files into: /boot/dts-overlay

    For those not familiar with Linux - you won’t be able to copy the files to /boot/.. through the graphical interface. You’ll have to use the command line “cp” command (with sudo) as per: https://www.cyberciti.biz/faq/copy-command/



    Next…

    I understand that there are still steps remaining to enable control of those pins from the M4 side (modifying wiring_digital.h and wiring_digital.c), but my expectation at this point was that (after a reboot) pins 16 - 33 should be disabled from the A9’s perspective and for example when we tried to issue a command from the terminal such as:

    cat /sys/class/gpio/gpio22/direction

    It should return “No such file or directory” like it does when you try to access one of the pins normally assigned to the M4.
    QUESTION: Is it correct that this is the response we should expect at this point? Or if not - how can we verify whether the previous steps were successful?

    (Note that I also tried to output on those pins (from terminal) and that still works too.)

    I did go ahead and follow through with the modifications to wiring_digital.h and wiring_digital.c, but as those seem pretty straightforward and I suspect the problem occurred during the earlier steps, we’ll leave that out of this discussion.


    Any help you can give will be so much appreciated! I’ve spent days of frustration on this as the members above also expressed… if one of you can provide the last missing piece then we’ll have a complete, detailed guide here and spare those that follow from the same ordeal.
     
  10. Matt_Neo

    Matt_Neo UDOOer

    Joined:
    Jun 14, 2019
    Messages:
    15
    Likes Received:
    9
    So in parallel I've been discussing this with Udoo support. We came to the following (although not fully satisfying) short terms workable solution... The solution is that following the procedure above along with the ending part about the modifications to the M4 side (which I omitted for being straightforward) - that will result in both cores having control over the GPIO pins. For my immediate application this seems to be acceptable. You just have to make sure you're not trying to control the same pin as an output from both cores at the same time - if you drive it HIGH from one core and LOW from the other there will be an internal short and likely damage to the board. Udoo support commented that this 'dual control scheme' (my phrase not theirs) is ok as long as you're using the pins as just plain GPIOs, but not if you're using the more complex interfaces like I2C or PWM etc. At least that's my interpretation of their comments, *probably you should be cautious if you're going to use this scheme.*
     
    waltervl likes this.
  11. kacem berriah

    kacem berriah New Member

    Joined:
    Aug 23, 2021
    Messages:
    3
    Likes Received:
    0
    I followed the steps to 6 steps, then I found that I only have files.DTS and dtsi, no dtb files did I miss something ?
     

Share This Page