need to check: btw which version of mraa do you have?
(e.g. "opkg info 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
Maintainer: Intel IoT-Devkit
Description: mraa built using CMake
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.
1 of 1 people found this helpful
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.
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.
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/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.uart.mux_total = 0; b->pins.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.uart.mux.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