6 Replies Latest reply on Oct 20, 2014 2:26 PM by mhahn

    MRAA - UART information is not defined for Edison?


      I am using the MRAA library in some of my projects for the edison.  Currently specifically for using SPI and GPIO pins for the ILI9341 TFT display (Adafruit 2.8" TFT breakout in this case).


      Now starting to work with an XBee that is on an Seedstudio XBee shield, which has TX/RX on pins 0 and 1 (Edison Arduino).  So I thought I would use the UART code in mraa to at least initialize the IO Pins associated with the UART.  So I tried calling mraa_uart_init(0);


      I was not sure it was working correctly as the call returned a NULL pointer. So I took a look through the code.  What I think I found, is the mraa information for the uart is not the the Edison board (intel_edison_fab_c.c) but is in the intel_galileo_rev_d.c.  That is in the galileo file you see things like:





          mraa_board_t* b = (mraa_board_t*) malloc(sizeof(mraa_board_t));

          if (b == NULL)

              return NULL;


          b->phy_pin_count = 20;

          b->gpio_count = 14;

          b->aio_count = 6;

          b->uart_dev_count = 2;



          b->def_uart_dev = 0;

          b->uart_dev[0].rx = 0;

          b->uart_dev[0].tx = 1;

          b->uart_dev[1].rx = -1;

          b->uart_dev[1].tx = -1;


      But as I mentioned I don't see any of this information defined, so the mraa_uart_init call fails.

        • 1. Re: MRAA - UART information is not defined for Edison?

          need to check: btw which version of mraa do you have?

          (e.g. "opkg info libmraa0")

          • 2. Re: MRAA - UART information is not defined for Edison?

            Package: libmraa0


            Provides: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0

            Replaces: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0

            Conflicts: libmraa-dev, libmraa-dbg, libmraa-doc, libmaa-dev, libmaa-dbg, libmaa-doc, libmaa0

            Status: install user installed

            Section: libs

            Architecture: i586

            Maintainer: Intel IoT-Devkit

            MD5Sum: 618a685808833c4d6be19e81e69f67af

            Size: 194690

            Filename: libmraa0_0.5.0.25_i586.ipk

            Source: https://github.com/intel-iot-devkit/mraa

            Description: mraa built using CMake

            Installed-Time: 1413246939


            Note: the initial posting of this thread was also based on sources up on github.  I did a sync on my machine (github for windows) of the project to look at the sources.



            • 3. Re: MRAA - UART information is not defined for Edison?

              Quick updates; In case anyone else is interested


              Some updates were added to MRAA today to make sure that the devices are properly setup.  I am getting some results with my commander test program, but it is very sluggish, acting like it is not properly getting all of the inputs.  My guess is that this is not an MRAA issue, but maybe how my code is interacting with the underlying serial driver.


              My Arduino version of it appears to run fine using the XBee shield, but not having much luck yet with linux version.  I am finding some differences on how I have interacted with other linux boxes.  Example I turned off buffering as I did not want to wait until buffer full to get data...


              Wanted to also check out if it would work with an FTDI based USB to serial XBee adapter, so I plugged one in.  Did not work until I installed driver from AlexT's repo.  When I redirected my test program to use the usb device it is working great.  So I need to figure out what the differences are.  May look over how the Arduino code is talking to the serial driver.



              1 of 1 people found this helpful
              • 4. Re: MRAA - UART information is not defined for Edison?

                if you see any issues with mraa maybe you could build a tiny reproducer program and share what you get?

                also journalctl output would be helpful to understand what's going on with mraa.

                • 5. Re: MRAA - UART information is not defined for Edison?

                  Yes thanks,


                  I agree that a simple program to reproduce would be a help.  I have my somewhat less than simple Commander test program, which is very similar to what the Serial object does on the Arduino side, which creates a thread to process data from the uart.


                  I am actually in the process of debugging the MRAA code now.  Before I thought that it was properly setting up the UART, but I think I was mistaken.  It was sort of working before for me as I had previously run an Arduino sketch to test it out, which pre-init the IO pins.  I rebooted but forgot to remove the sketch program which restarted and reinit the stuff.


                  When tracing through the Arduino init code, I see that it setup:

                  For pin 0

                      /sys/class/gpio/gpio248 with direction=out, value=0

                      /sys/class/gpio/gpio216 with direction=out, value=0

                      /sys/kernel/debug/gpio_debug/gpio130/current_pinmux = mode1

                  For pin 1

                      /sys/class/gpio/gpio249 with direction=out, value=1

                      /sys/class/gpio/gpio217 direction=in

                      /sys/kernel/debug/gpio_debug/gpio131/current_pinmux = mode1


                  When tracing through the MRAA init code, it properly sees that pins 0, 1 are associated with the only UART, it then maybe does some init stuff on them, but first it checks

                  if (plat->pins[pos].uart.mux_total > 0) but in the edison board def we have:

                  b->pins[0].uart.mux_total = 0;
                  b->pins[1].uart.mux_total = 1;


                  So for pin 0 it does nothing, for pin 1 it calls mraa_setup_mux_mapped, but that function relies on meta.mux[mi].pin so in this case something like:

                  b->pins[1].uart.mux[0].pin needs to be defined, but I don't think it is.


                  After this call it then calls a new post process function, which does setup the pin muxs for linux pins 130 and 131 which is correct.  Note when I run this test program,

                  If I look at /sys/class/gpio

                  None of the gpio pins (gpio248, gpio249, gpio216, gpio217) are exported...


                  Still debugging  will also post this back on github