eclipse/mraa

Linux Library for low speed IO Communication in C with bindings for C++, Python, Node.js & Java. Supports generic io platforms, as well as Intel Edison, Intel Joule, Raspberry Pi and many more.

Eclipse Mraa - Low Level I/O Communications Library for GNU/Linux platforms

Eclipse Mraa (Libmraa) is a C/C++ library with bindings to Java, Python and JavaScript to interface with the I/O pins and buses on various IoT and Edge platforms, with a structured and sane API where port names/numbering match the board that you are on. Use of libmraa does not tie you to specific hardware. Since board detection done at runtime you can create portable code that will work across the supported platforms.

The intent is to make it easier for developers and sensor manufacturers to map their sensors & actuators on top of supported hardware and to allow control of low level communication protocol by high level languages & constructs.

The MRAA project is an Eclipse IoT project. A detailed project description can be found here.

Supported Boards

X86

• Galileo Gen 1 - Rev D
• Galileo Gen 2 - Rev H
• Edison
• Intel DE3815
• Minnowboard
• NUC 5th generation
• UP
• UP Squared
• Intel Joule
• IEI Tank
• ADLINK IPi-SMARC X86
• UP Xtreme

ARM

• Raspberry Pi
• Banana Pi
• Beaglebone Black
• phyBOARD-Wega
• 96Boards
• ADLINK IPi-SMARC ARM
• Radxa CM3
• Radxa E25
• Radxa ROCK 3A
• Radxa ROCK 3B
• Radxa ROCK 3C
• Radxa ROCK 5A
• Radxa ROCK 5B
• Radxa CM5 IO
• Rock Pi 4
• Orange Pi Prime

MIPS

• Linkit Smart 7688
• Onion Omega2

FPGA

• DE10-Nano

USB

• FT4222
• Firmata

I2C

• GrovePi

Mock

• Generic simulated board

JSON platform

• Platform loading

RISC-V

• VisionFive

Installing on your board

Installing on Ubuntu

Here is a PPA for installing on Ubuntu Xenial or Bionic: https://launchpad.net/~mraa/+archive/ubuntu/mraa

sudo add-apt-repository ppa:mraa/mraa
sudo apt-get update
sudo apt-get install libmraa2 libmraa-dev libmraa-java python-mraa python3-mraa node-mraa mraa-tools

Running MRAA tools or applications on Ubuntu systems requires elevated permissions (e.g. run with sudo).

Install on Arch Linux

There is an AUR package for mraa here: https://aur.archlinux.org/packages/mraa

Install on openSUSE or SLE

For the latest versions of openSUSE and SLE the project is distributed via native repositories and can be installed by developers with:

sudo zypper install mraa mraa-devel

For ARM boards use:

REPO="openSUSE_Tumbleweed"
if test "$(arch)" == "aarch64"; then
  REPO="openSUSE_Factory_ARM"
fi
sudo zypper ar http://download.opensuse.org/repositories/hardware/$REPO/hardware.repo
sudo zypper in mraa

A full list of packages and instructions for installing MRAA for various openSUSE releases can be found here.

Install on Fedora Linux

There is an mraa package in the main Fedora repository so it can be dnf installed in all recent Fedora releases. The Node.js and Python 3 bindings are packaged as separate packages.

sudo dnf install mraa nodejs-mraa python3-mraa

Installing for Red Hat Enterprise Linux, CentOS and Other Linux Distributions

The MRAA project does not currently distribute official binaries for RHEL or CentOS so developers will have to compile the project from sources as described in the next section.

For testing and development purposes it may be possible to share and install .deb and .rpm packages across similar Linux builds.

Compiling

See documentation on building

Examples

See the examples available for various languages

Debugging

Sometimes it just doesn't want to work, let us try and help you, you can file issues in github or join us in #mraa on freenode IRC, hang around for a little while because we're not necessarily on 24/7, but we'll get back to you! Have a glance at our debugging page too.

API Documentation

Contact Us

To ask questions either file an issue on Github or send an email to our mailing list. You must be subscribed to the list before you can post. You might also catch us on the mraa channel on freenode IRC.

See the Contribution documentation for more details.

Changelog

Version changelog here.

mraa's Issues

~

Edison mraa_gpio_write is a lot slower than digitalWrite

I was doing some testing of the mraa_gpio_write to see the speed of it and it currently is a lot slower than doing digitalWrite in the Arduino environment. Something in the order of 19us versus .4us
More details with test cases and logic analyzer output up on the thread:
https://communities.intel.com/thread/56516

Note: looking through Arduino code, it is using a fast GPIO interface to the PCI device. I may try to play with the MRAA code to implement, but if someone beats me to it...

uart on edison arduino breakout (and miniboard) cannot be set

@KurtE correctly discovered we don't support uart setup on edison. First step is to not crash on uart creation if not supported in board definition and next step is to make it work :). See @KurtE's branch for a rudimentary fix.

mraa_uart_init is failing on Edison Breakout Board

It seems that mraa_uart_init is always returning NULL, as tristate is NULL.

intel_edison_fab_c.c
mraa_board_t*
mraa_intel_edison_fab_c()
{
    mraa_board_t* b = (mraa_board_t*) malloc(sizeof(mraa_board_t));
    if (b == NULL)
        return NULL;

// This seciton will also check if the arduino board is there
tristate = mraa_gpio_init_raw(214);
if (tristate == NULL) {
    syslog(LOG_INFO, "edison: Failed to initialise Arduino board TriState,\
            assuming Intel Edison Miniboard\n");
    if (mraa_intel_edsion_miniboard(b) != MRAA_SUCCESS) {
        free(b);
        return NULL;
    }
    return b;
}

intel_edison_fab_c.c
mraa_result_t
mraa_intel_edison_uart_init_post(mraa_uart_context uart)
{
    return mraa_gpio_write(tristate, 1);
}

gpio.c
mraa_result_t
mraa_gpio_write(mraa_gpio_context dev, int value)
{
if (dev == NULL)
    return MRAA_ERROR_INVALID_HANDLE;

Apparently, mraa_uart_init NULL value is coming from mraa_gpio_write, as dev=tristate=NULL

[API] Support writing on SPI bus in anything other than 8bit

Intel Breakout board - pin defined wrong

I believe that this definition is wrong for the breakout board:

strncpy(b->pins[pos].name, "J18-8", 8);
b->pins[pos].capabilites = (mraa_pincapabilities_t) {1,1,1,0,0,0,0};
b->pins[pos].gpio.pinmap = 182;
b->pins[pos].gpio.mux_total = 0;
b->pins[pos].pwm.pinmap = 3;
b->pins[pos].pwm.parent_id = 0;
b->pins[pos].pwm.mux_total = 0;
pos++;

I believe the 182 is supposed to be 183

can't find libmraa.so.0 in the default installation path!

1-First, I cloned your repo then CMake and make as you illustrated here:
https://github.com/intel-iot-devkit/mraa/blob/master/docs/building.md
and i didn't found libmraa.so.0 in /src/local/lib.

2-I installed the package as here:
https://github.com/intel-iot-devkit/mraa#installing-on-your-board
but i couldn't find where the installed lib is.

3-Finally, I am doing this because I am trying to link a library of mine with your library, So what should I do, regarding iam using makefile not cmake?
Thanks in advance.

Output of mraa_pin_mode_test looks strange on Intel Edison

I am porting mraa to freepascal, I am doing some small test-apps, one app displays the pin and the capabilities of the pin with a call to mraa_pin_mode.

The result looks a little strange, Fast GPIO is always 0 and UART is also 0; 12 pins are marked as AIO capable.
When I look at the board structure then gpio_count is 14 but all 20 pins are gpio capable. Same with AIO, 6 in aio_count and 12 when I do mraa_pin_mode_test

Pin Functionality: GPIO PWM FGPIO SPI I2C AIO UART
Pin 00 supports: 1 0 0 0 0 1 0
Pin 01 supports: 1 0 0 0 0 1 0
Pin 02 supports: 1 0 0 0 0 1 0
Pin 03 supports: 1 1 0 0 0 1 0
Pin 04 supports: 1 0 0 0 0 1 0
Pin 05 supports: 1 1 0 0 0 1 0
Pin 06 supports: 1 1 0 0 0 0 0
Pin 07 supports: 1 0 0 0 0 0 0
Pin 08 supports: 1 0 0 0 0 0 0
Pin 09 supports: 1 1 0 0 0 0 0
Pin 10 supports: 1 0 0 1 0 0 0
Pin 11 supports: 1 0 0 1 0 0 0
Pin 12 supports: 1 0 0 1 0 0 0
Pin 13 supports: 1 0 0 1 0 0 0
Pin 14 supports: 1 0 0 0 0 1 0
Pin 15 supports: 1 0 0 0 0 1 0
Pin 16 supports: 1 0 0 0 0 1 0
Pin 17 supports: 1 0 0 0 0 1 0
Pin 18 supports: 1 0 0 0 1 1 0
Pin 19 supports: 1 0 0 0 1 1 0
r

mraa_i2c_read_word_data only returns a byte...

If you look at this function in i2c.c
You will see:
return 0xFFFF & d.byte;

I believe it should be:
return 0xFFFF & d.word;

Note: in my case with playing with the I2C Compass does not help me as this assumes: LSB, MSB, but the compass data is MSB, LSB...

minnowboard max support

Being worked on in github.com/whbruce/mraa. Will support calamary lure and low speed expansion header

gpio isr on pin2 & 3 on galileo gen1 is unreliable

I2C: Frequent, but inconsistent write failures, reporting MRAA_ERROR_INVALID_HANDLE

I've been encountering MRAA_ERROR_INVALID_HANDLE failures with every I2C device I try. The result is inconsistent: sometimes a write will fail, sometimes it won't. Sometimes writes just fail completely and that inevitably leads to a seg fault. What are the conditions that could cause this? I followed the call graph back to ioctl(), but that's as far as I've gotten to this point.

failed to build mraa

hello, I am confused when I build the mraa library. I just follow the step as the building.md said, it is like follow:

mkdir build
cd build
cmake ..
make

But error occurs when doing make task, like follow:

[ 46%] Swig source
swig error : Unrecognized option -javascript
swig error : Unrecognized option -node
Use 'swig -help' for available options.
make[2]: *** [src/javascript/mraajsJAVASCRIPT_wrap.cxx] Error 1
make[1]: *** [src/javascript/CMakeFiles/mraajs.dir/all] Error 2

It seems that swig does not support parameter -javascript & -node, how to resolve this problem?

Support installation from NPM for Nodejs

Currently installing mraa Nodejs requires installing from opkg, this is normal for c++ libraries but rarely in the Nodejs community. In the Nodejs community dependencies are handled through the npm package management system, which does support native modules.

I would like help with this anyway possible. I currently have a module mraa-js that a) deploys the built mraa.node from opkg b) has a set of mocks for development on non edison boards.

Options for native packaging native modules:

1. Add the .node file to the package, since the module is made to support only a number of systems this approach may be optimal.
2. Add a native build step and let node-gyp build mraa when npm install runs.
3. Others??

Any thoughts would be great.
Adam

uart not properly mapped for revg

Calls to mraa_uart_init() return NULL on GEN2. I believe it is because the uart array in the instance of mraa_board_t is not properly initialized in intel_galileo_rev_g.c->mraa_intel_galileo_gen2(). In fact it isn't initialized at all. For the GEN1 board, intel_galileo_rev_d.c->mraa_intel_galileo_rev_d() contains the following code at the very bottom of the routine:

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;

I couldn't find anywhere in intel_galileo_rev_g.c where that is done. Since the instance of mraa_board_t is simply malloc'ed you would have trash in the pin positions for both the rx and tx pins. Seems like a bad thing.

[gen2] Initializing Gpio instances appears broken

root@quark016c31:~# node -e 'console.log(require("mraa").getVersion());'
v0.5.4-31-gf7256f1
root@quark016c31:~# node
> var m = require("mraa");
undefined
> new m.Gpio(0);
{}
> new m.Gpio(1);
{}
> new m.Gpio(2);
Error: Illegal arguments for construction of _exports_Gpio

> new m.Gpio(3);
Error: Illegal arguments for construction of _exports_Gpio

> new m.Gpio(4);
{}
> new m.Gpio(5);
Error: Illegal arguments for construction of _exports_Gpio

> new m.Gpio(6);
Error: Illegal arguments for construction of _exports_Gpio

> new m.Gpio(7);
{}
> new m.Gpio(8);
{}
> new m.Gpio(9);
Error: Illegal arguments for construction of _exports_Gpio

> new m.Gpio(10);
Error: Illegal arguments for construction of _exports_Gpio

> new m.Gpio(11);
Segmentation fault

root@quark016c31:~# node
> var m = require("mraa");
undefined
> new m.Gpio(11)
Error: Illegal arguments for construction of _exports_Gpio

> new m.Gpio(12)
{}
> new m.Gpio(13)
{}
>

Not sure what caused this regression, but it was reported to me by Johnny-Five users who don't understand low level fail like this.

i2c bus frequency switching from userspace

[Edison] Writing spi in odd bytes causes Edison to go into limbo land

When using SPI in 16 bit mode, and you want to send say 3 bytes you would use
mraa_spi_write_buf(spi,3);

If you do this the Edison becomes non responsive. On the scope it just blasts a bunch of data out for a while then quits. The terminal even becomes non responsive. In playing with this I have tried sending 1,3,5,7,9 bytes and they all do the same. Only even numbers work.

mraa_get_platform_name() call

libmraa should just provide, eg mraa_get_platform_name() would need to pass a char* pointer in C API and return an std:string in object API. See discusion on #34.

Add ability to silence `fprintf` debugging messages

There needs to be a "silent" mode or some mechanism to shut off debugging messages that are produced by mraa.

[Galileo gen2] Analog pin defect?

With nothing attached to the analog pins:

Test:

var m = require("mraa");
for (var i = 0; i < 6; i++) {
  console.log(new m.Aio(i).read());
}

Result:

1016
224
1021
1022
993
882

Test:

import mraa

for x in range(0, 6):
  print mraa.Aio(x).read()

Result:

1020
218
1021
1022
993
883

Disregarding the line noise, A1 is obviously experiencing some issue and I'm not sure how to find it. This may not even be an mraa issue, but I don't know where else to report.

edit

If I put a jumper across 5V and A1, the value is a nice 1023.

[API] Buffered IIO reads for ADC

Instead of hardcoding an IIO file for the ADC we should really iterate on the IIO devices of type ADC and then use that. Secondly it should be possible to ask for a number of AIO reads instead of one read.

PWM is not working on Edison

I tested the PWM sample on XDK IoT Edition by Edison on Arduino Expansion Board but it seems that PWM is not working well.
It actually create pulses but the duty cycle couldn't be configured by MRAA.
The duty cycle looks always almost 0.

At first, I haven't changed the sample code at all but didn't work so please refer the sample.
Strangely, it seems that only period could be configured.

[API] Aio module could do with function that returns normalised 0.0f-1.0f float

mraa_uart_init still not working

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 - Not sure what code should should be properly setting the state of the linux pins associated with the Arduino pins 0 and 1

Mraa have an error on decision of current board type

I use Intel Edison Kit for Arduino.

# node -e 'console.log(require("mraa").getVersion());'
v0.5.4-31-gf7256f1

When I execute require("mraa").getVersion();, it outputs following logs in journal:

Dec 15 09:13:03 edison-miyamoto-a libmraa[1019]: libmraa initialised by user 0
Dec 15 09:13:03 edison-miyamoto-a libmraa[1019]: gpio: Failed to write to export
Dec 15 09:13:03 edison-miyamoto-a libmraa[1019]: edison: Failed to initialise Arduino board TriState,                assuming Intel Edison Miniboard
Dec 15 09:13:03 edison-miyamoto-a libmraa[1019]: libmraa initialised for platform 2

I use not breakout board (= Miniboard) but arduino board.
But mraa confuse that the current board is breakout board, doesn't it?

Instructions for installing on Gen 1 and Gen 2?

Are there any straight forward, step-by-step instructions for getting mraa onto either/both Gen 1 or Gen 2 boards?

mraa_init() should be more verbose

mraa_init() should at least print username instead of 'user 0', complain about inadecate permissions and print the platform name instead of the enum value.

[Edison] mraa_spi_lsbmode Does not have any affect

using mraa_spi_lsbmode(spi,0) or mraa_spi_lsbmode(spi,1) does not have any affect on how data is sent.

also, the function for it could be trimmed up a bit by getting rid of the first if statement. to this:

mraa_result_t
mraa_spi_lsbmode(mraa_spi_context dev, mraa_boolean_t lsb)
{
uint8_t lsb_mode = (uint8_t) lsb
...

[deb] mraa deb pkg

We should support the making of a deb pkg for submission into debian repos.

make error: unknown type name 'pthread_t'

I'm trying to build mraa, all build commands works correctly until make:

$ make
Scanning dependencies of target mraa
[  1%] Building C object src/CMakeFiles/mraa.dir/mraa.c.o
In file included from /Users/rwaldron/clonez/mraa/src/mraa.c:31:
In file included from /Users/rwaldron/clonez/mraa/include/mraa_internal.h:32:
/Users/rwaldron/clonez/mraa/include/mraa_internal_types.h:40:5: error: unknown type name
      'pthread_t'
    pthread_t thread_id; /**< the isr handler thread id */
    ^
/Users/rwaldron/clonez/mraa/src/mraa.c:117:12: warning: implicit declaration of function
      'sched_setscheduler' is invalid in C99 [-Wimplicit-function-declaration]
    return sched_setscheduler(0, SCHED_RR, &sched_s);
           ^
1 warning and 1 error generated.
make[2]: *** [src/CMakeFiles/mraa.dir/mraa.c.o] Error 1
make[1]: *** [src/CMakeFiles/mraa.dir/all] Error 2
make: *** [all] Error 2

Mac, OSX 10.9.4 with dev tools installed.

Add mraa_spi_transfer_buf

Most of this comes from a thread on the Intel forum: https://communities.intel.com/thread/56112

I have been playing around with Adafruit 2.8" tft display which uses SPI with an ILI9341 Controller chip. I have now my own versions of the Adafruit_ILI9341 library ported over to run on the Intel Edison. I have an Arduino version, and I have the version I am playing with now that runs under Linux and I am using MRAA to talk to hardware, which I have posted about. Code for my both are up on github, the current one is in my Raspberry Pi project (KurtE/Raspberry_Pi · GitHub) Bad name, but first linux box...

The current version up on github uses the standard mraa_spi functions. One thing I noticed was the mraa_spi_write_buf function always does a malloc for return data, which I have to free, so I wondered about a transfer function that you can pass in you own RX buffer. Also while I am not good yet at looking at device driver code, I got the impression that the rx buffer was optional to pass to it, so wondered what would happen if did not ask for the data to be returned. So I hacked up my own transfer function... I extracted some definitions from MRAA project

#ifdef MRAA_SPI_TRANSFER_BUF
// from internals of SPI
struct _spi {
    /*@{*/
    int devfd; /**< File descriptor to SPI Device */
    int mode; /**< Spi mode see spidev.h */
    int clock; /**< clock to run transactions at */
    mraa_boolean_t lsb; /**< least significant bit mode */
    unsigned int bpw; /**< Bits per word */
    /*@}*/
};
mraa_result_t mraa_spi_transfer_buf(mraa_spi_context dev, uint8_t* abOut, uint8_t* abIn, int length)
{
    struct spi_ioc_transfer msg;
    memset(&msg, 0, sizeof(msg));

    msg.tx_buf = (unsigned long) abOut;
    msg.rx_buf = (unsigned long) abIn;
    msg.speed_hz = dev->clock;
    msg.bits_per_word = dev->bpw;
    msg.delay_usecs = 0;
    msg.len = length;
    if (ioctl(dev->devfd, SPI_IOC_MESSAGE(1), &msg) < 0) {
        //syslog(LOG_ERR, "Failed to perform dev transfer");
        return MRAA_ERROR_INVALID_RESOURCE;
    }
    return MRAA_SUCCESS;
}
#endif

I then changed my ported version of the Adafruit graphic test program to see if it changed in the timings. Before my change my last run showed:

ILI9341 Test!
Display Power Mode: 0x9C
MADCTL Mode: 0x48
Pixel Format: 0x5
Image Format: 0x9C
Self Diagnostic: 0xC0
Benchmark                Time (microseconds)
Screen fill              2969897
Text                     2833053
Lines                    27616144
Horiz/Vert Lines         342621
Rectangles (outline)     488944
Rectangles (filled)      6204091
Circles (filled)         15837252
Circles (outline)        12089819
Triangles (outline)      8772333
Triangles (filled)       10038844
Rounded rects (outline)  3949121
Rounded rects (filled)   9064036
Done!

After I changed my code in the driver to use the function above the timings are:

root@Edison:~/Raspberry_Pi/testAdafruit_ILI9341C# ./graphictest
ILI9341 Test!
Display Power Mode: 0x9C
MADCTL Mode: 0x48
Pixel Format: 0x5
Image Format: 0x9C
Self Diagnostic: 0x0
Benchmark                Time (microseconds)
Screen fill              2909710
Text                     2780826
Lines                    27218499
Horiz/Vert Lines         338233
Rectangles (outline)     476022
Rectangles (filled)      6057534
Circles (filled)         15288228
Circles (outline)        11925822
Triangles (outline)      8634251
Triangles (filled)       9750937
Rounded rects (outline)  3882691
Rounded rects (filled)   8900734
Done!

Note: I tried passing in NULL for the txBuffer when I was doing reads and this appeared to crash the processor.

After I did this test I forked this library over to: https://github.com/KurtE/mraa
Where I have done a pull request for the multiple c++ files causes link errors and issues with UART.

After that pull request, I made the changes to add a transfer function, which I added to the C and C++ header files and source file. Also to verify that I did not screw up in the C++ header, I updated the c++ spi example program to in one case call the transfer. Note: I made a few other changes to it as well, like checking on write, that it did not return a NULL pointer and to free the buffer returned.

Can easily do another pull request

mraa rpi support

rpi support currently being dev'd in 'arch' branch

SPI MOSI initialization is messed up on Galileo Gen2

There are typos in intel_galileo_rev_g.c related to pins[11].spi causing SPI MOSI to be incorrect.

This is what it is:

b->pins[11].spi.mux_total = 3;
b->pins[11].spi.mux[0].pin = 72;
b->pins[11].spi.mux[0].value = 0;
b->pins[11].spi.mux[1].pin = 44;
b->pins[11].spi.mux[2].value = 1;
b->pins[11].pwm.mux[2].pin = 24;
b->pins[11].pwm.mux[2].value = 0;

I believe the correct configuration should be this:

b->pins[11].spi.pinmap = 1;
b->pins[11].spi.mux_total = 3;
b->pins[11].spi.mux[0].pin = 72;
b->pins[11].spi.mux[0].value = 0;
b->pins[11].spi.mux[1].pin = 44;
b->pins[11].spi.mux[1].value = 1;
b->pins[11].spi.mux[2].pin = 24;
b->pins[11].spi.mux[2].value = 0;

Support edison minibreakout board

Currently only the arduino breakout board is working with libmraa, this is a bug to track this issue.

mraa_spi_bit_per_word, Does not have any affect

Changing the bits parameter in mraa_spi_bit_per_word, does not change bytes written out.
They still are sent out as 8-bit. tried on Intel breakout board.
Code used to try it as follows.

int main (void)
{
mraa_spi_context spi;

spi = mraa_spi_init(0);
mraa_spi_mode(spi,MRAA_SPI_MODE0);
mraa_spi_bit_per_word(spi, 16);
mraa_spi_frequency(spi,100000);


unsigned char data[5];

data[0] = 0xa5;
data[1] = 0x5a;
data[2] = 0xa5;
data[3] = 0x5a;

mraa_spi_write_buf(spi, data, 4);    // does not matter if I change it from 4 to 2. 

}

mraa_gpio_dir performance when switching back and forth from input/output...

I have been playing around some with a Parallax ping sensor and you current performance makes it unusable on Edison Arduino board (will be doing testing with mini as well).
More details currently up on the Edison thread: https://communities.intel.com/thread/57568

A ping sensor works, by doing a quick pulse on a pin and then switch the pulse to input and wait for the device to give you a pulse back, where the pulse width gives you the distance. Note: there are other devices out there as well who do similar things including some servos.

I have been playing with the Arduino code base and have sped up the the switching from OUTPUT_FAST to INPUT_FAST by maybe a factor of 3...

I am thinking of making a new branch of my github fork to try out some changes, where you cache some data. Example everytime you call mraa_gpio_dir you are going through all of the work to set the PU device associate with the pin to input. Could cache the last state set and only call when needed.

will let you know how well this helps.

Error: Unknown SWIG preprocessor directive @SWIG3.0.3

In swig 3.0.3, it seems to be changed a preprocessor directive of Comments.

alva@ubilinux:/work/mraa/build$ make -j2
[ 1%] Swig source
[ 23%] Built target mraa
[ 25%] Swig source
/home/alva/work/mraa/src/javascript/../mraa.i:48: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/javascript/../mraa.i:52: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/javascript/../mraa.i:56: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/javascript/../mraa.i:60: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/javascript/../mraa.i:64: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/javascript/../mraa.i:68: Error: Unknown SWIG preprocessor directive:
make[2]: *** [src/javascript/mraajsJAVASCRIPT_wrap.cxx] Error 1
make[1]: *** [src/javascript/CMakeFiles/mraajs.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/home/alva/work/mraa/src/python/../mraa.i:48: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/python/../mraa.i:52: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/python/../mraa.i:56: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/python/../mraa.i:60: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/python/../mraa.i:64: Error: Unknown SWIG preprocessor directive:
/home/alva/work/mraa/src/python/../mraa.i:68: Error: Unknown SWIG preprocessor directive:
make[2]: *** [src/python/python-mraaPYTHON_wrap.cxx] Error 1
make[1]: *** [src/python/CMakeFiles/_python-mraa.dir/all] Error 2
make: *** [all] Error 2
alva@ubilinux:/work/mraa/build$ swig -version

SWIG Version 3.0.3

Compiled with g++ [i686-pc-linux-gnu]

Configured options: +pcre

Please see http://www.swig.org for reporting bugs and further information
alva@ubilinux:~/work/mraa/build$

[API] Javascript Syntax improvement

Instead of:
var myLed = new m.Gpio(36);

Could it be written as:
var myLed = new m.Gpio(m.EDISON.GP14);

Having to read a lookup table becomes troublesome for new users.

[SWIG] mraa_init() runs twice on SWIG'd builds

Whilst harmless this is a bit dumb. Unclear what is causing this - again. I guess the DEFINES don't work as they should which requires investigation. At least verified for nodejs build from jenkins using cpack.

python aio.py segmentation fault on the edison minibreakout board

When trying to execute the aio.py example on Edison I get the following:
v0.5.0-25-g5e20a1c
Segmentation fault

The minibreakout board doesn´t have the ADC converter but the segmentation fault doesn´t looks like a normal behaviour.

The same happened with i2c_HMC5883.py and rgblcd.py

Grove LCD display does not display text on Edison

The "Grove-LCD RGB Backlight v2.0" Node.js example code given at
https://software.intel.com/en-us/iot/sensor/grove-lcd-rgb-backlight
does not work on Edison (I have not tested on Galileo).

Specifically, the backlight color can be changed, but no text can be displayed on the LCD (these functions are apparently controlled by two different devices at different I2C addresses).

I tried with two separate displays and had the same problem, so I've ruled out the particular display I was using having a problem. Someone also suggested putting a small delay between the I2C call to set the color and the call to set the display. This also did not resolve the issue. In other words, the following code has the same problem:

// Load i2clcd module
var LCD = require('jsupm_i2clcd');
//Initialize Jhd1313m1 at 0x62 (RGB_ADDRESS) and 0x3E (LCD_ADDRESS)
var myLcd = new LCD.Jhd1313m1(0, 0x3E, 0x62);
myLcd.setColor(64,255,64);
setTimeout(function() {
console.log("Attempting to say hi");
myLcd.setCursor(0,0);
myLcd.write('Hello World'); // doesn't work for some reason
console.log("Done saying hi");
},1000);

I double-checked the I2C addresses and they seem to be correct, but that could be one possible error... if someone else can confirm that would be good.

Looking at the journal the following messages related to mraa appear ("george" is the name of my Edison):
Nov 05 10:30:21 george libmraa[279]: libmraa initialised for platform 2
Nov 05 10:30:21 george libmraa[279]: libmraa initialised for platform 2
Nov 05 10:30:21 george libmraa[279]: Invalid i2c bus, moving to default i2c bus
Nov 05 10:30:21 george libmraa[279]: Invalid i2c bus, moving to default i2c bus

[API] Add possibility to get raw GPIO number from mraa_gpio_context

Basic Blink Fails - Javascript / Edison / Arduino Board

Hi, I'm getting a failure when I do a basic sample program.
mraa is installed via the opkg instructions.

This code:
var m = require('mraa');
console.log(m.getVersion());
var led = new m.Gpio(8);

Gets me:
v0.5.1-18-ge5c3e49
Segmentation fault

Same happens in Python.

When I modify the pin:
var m = require('mraa');
console.log(m.getVersion());
var led = new m.Gpio(13);

I get this:
/home/reid/blink2.js:4
var led = new m.Gpio(13);
^
Error: Illegal arguments for construction of _exports_Gpio
at Object. (/home/reid/blink2.js:4:11)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3

Edison version is Bodega Bay.
Firmware version is edison-rel1-maint-weekly_build_16_2014-10-14_14-56-19

[Edison Arduino] Illegal arguments for construction of _exports_Pwm on IO 10/11 (PWM swizzler)

Environment:

root@blurr:~# cat /etc/version && node -e 'console.log(require("mraa").getVersion());' && node -v
edison-rel1-maint-weekly_build_16_2014-10-14_14-56-19
v0.5.4-2-gffdd828
v0.10.28

Error:

root@blurr:~# node
> var m = require("mraa")
undefined
> var p = new m.Pwm(11)
Error: Illegal arguments for construction of _exports_Pwm
    at repl:1:9
    at REPLServer.self.eval (repl.js:110:21)
    at repl.js:249:20
    at REPLServer.self.eval (repl.js:122:7)
    at Interface.<anonymous> (repl.js:239:12)
    at Interface.EventEmitter.emit (events.js:95:17)
    at Interface._onLine (readline.js:202:10)
    at Interface._line (readline.js:531:8)
    at Interface._ttyWrite (readline.js:760:14)
    at ReadStream.onkeypress (readline.js:99:10)

(blurr => edison)

edison platform config init lives in fantasy ideal world

plenty of uncleaned handles etc never been cleaned properly. Code needs a nice big cleanup.

Value range of I2C writing by script languages

It seems that the write function of I2C object accept a value only if the value is less than 128 due to the argument type of write function is not unsigned char but char.
For example, the following code gives an error.

var i2c = new mraa.I2c(0);
i2c.address(0x70);
i2c.write(0xFF);

Is this an expected behavior? Do I need to use twos complement or something?

On older (ww42 & less) edison (arduino) GPIO (13 & others) seems broken

See: https://communities.intel.com/thread/57877?sr=stream&ru=167828

It sounds to me like non mmape'd fallback is failing or that magic PCIe string is not working.

Node.js Gpio.dir() crash

in my hello world project (xdk onboard led blink template) in node.js the program exits without writing any log when trying to execute

myOnboardLed.dir(mraa.DIR_OUT);

mraa version : v0.5.0-17-g2b5e38b
device : Intel Edison

pinmapping for arduino boards needs to be clear