search

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.
http://mraa.io
MIT License
1.37k stars 613 forks source link

How do I update mraa on Eclipse MARS.1 #725

Closed allene222 closed 7 years ago

allene222 commented 7 years ago

After updating the Yocto image on my Intel Edison my stable program would not run because of an mraa error

/home/root/nmea: error while loading shared libraries: libmraa.so.0: cannot open shared object file: No such file or directory

If I do the following it will run but the i2c part of the program just produces errors.

cd /usr/lib ln -s libmraa.so.1 libmraa.so.0

It will run with that addition but it will not work. All the i2c commands produce errors. Here are the return values.

mraa_init(), SUCCESS. MRAA return value is 0 rx_tx_buf0 ,Return Value is 45 rx_tx_buf1 ,Return Value is 8 rx_tx_write ,Return Value is 99 mraa_i2c_read, Return Value is -1

My program runs fine and has for more than 2 years including all the i2c commands but it will not work with the latest changes to mraa.

I am running an Eclipse MARS environment.

What do I need to do to get my code working again? I need the latest Yocto for some added features that are not in my 2015 version.

arfoll commented 7 years ago

So the reason for mraa v1 is an API change so there may be a need to recompile your program (reguardless of the name of the .so).

But it is odd, since not much has changed down in i2c where we could expect things to all fail. Can you share the output of syslog/journal? docs/debuging has some info for getting this if you're not sure.

allene222 commented 7 years ago

I should note that the MRAA GPIO works fine. It is just the i2c that gives errors.

Just to be clear on what is going on this is what I just did. 1) Ran my heel (i2c) code on my 2/11/2015 BlueZ4 image. It worked without problems. 2) Installed the new Intel 20160606 image, 3) Ran the heel code with this result: /tmp/heel: error while loading shared libraries: libmraa.so.0: cannot open shared object file: No such file or directory logout 4) Issued these commands cd /usr/lib ln -s libmraa.so.1 libmraa.so.0 5) Ran the heel code. The code has error checking and prints out the error codes.

mraa_init(), MRAA return value is 0 rx_tx_buf0 ,Return Value is 45 rx_tx_buf1 ,Return Value is 8 rx_tx_write ,Return Value is 99 mraa_i2c_read, Return Value is -1

I am using Eclipse MARS.1 Release (4.5.1)

Like so many things when trying to debug this, I looked at the debug docs and ran the code and issued the suggested command.

root@Papoose4:~# journalctl -f No journal files were found.

I also tried this root@Papoose4:~# journalctl -t libmraa journalctl: invalid option -- 't'

I ran the version code and got this Version: v1.0.0

I assume that is my problem but I don't know what to do to upgrade.

EDIT: 3.10.98-poky-edison+ #1 SMP PREEMPT Mon Jun 6 14:32:08 PDT 2016 i686 GNU/Linux

alext-mkrs commented 7 years ago

It's strange that your board reports no journal files, are you sure the upgrade went ok?

In any case, the only proper solution here is to recompile your program with new mraa version, as going from 0.x to 1.x may break things (thus the major version bump up). Even though I2C interface may not have changed that much, still the binary compiled against 0.x is not guaranteed to work with 1.x and what you see is pretty much the "why" of it.

alext-mkrs commented 7 years ago

Oh, and Eclipse version is irrelevant here, it's just mraa version your program is compiled against that matters.

allene222 commented 7 years ago

I guess you could say that is my question. I have a Windows 7 machine running Eclipse MARS.1. I am thinking I need to update the version of mraa that I am using with Eclipse so I started this thread. I am asking how to do that. This has been most frustrating.

Google "update libmraa edison" and the first hit takes me to an Intel site but it is talking about version 0.x so I don't think that is helpful.

Google "update mraa edison" first hit takes me to another intel page, https://software.intel.com/en-us/node/623543 and all the instructions are using linux so that doesn't look like what I want

Google "update mraa edison eclipse" and first hit is old, second hit takes me here https://software.intel.com/en-us/xdk/docs/libmraa-libmraa-updates which is for a different version of Eclipse and is talking about updating the library on the board which I don't think is my problem.

I posted on the Edison forum and they suggested I post here for help.

Perhaps if I had this problem in 2014 when I installed my Edison development and installed Intel's version of Eclipse I would know instantly how to do this. But too much time has passed so I need some instructions. I am at least 10 hours into trying to figure this out and I would be most grateful for whatever help you can give me. I guess I am looking for some step by step instructions for Windows 7 and Eclipse MARS.1

allene222 commented 7 years ago

It has also been suggested I just update to Intel Studio. I tried.

Operating system "Windows 7 Professional" is not supported.

allene222 commented 7 years ago

Another thought. I really have no issue with the performance of my old mraa. I need the new Edison Yocto version for other issues but is there a way to change the version on the Edison board back to an older version that would be compatible with my code and at the same time with the new version of Yocto?

alext-mkrs commented 7 years ago

I see now, thanks for clarifying what the exact problem is. The downgrade shhould be possible, but you'll most probably need to manually download the specific package version from the repo server first and then install it on the board using "opkg filename" way.

However better thing IMHO would be to update your host side, so that you could enjoy the latest and greatest mraa. This however would need some experimenting as I personally haven't used such setup. Back at the beginning there was I think full Yocto SDK and toolchain distributed as a part of this Eclipse-based setup (IoT DevKit as they call it), but I'm not sure it's the same these days and how it's supposed to be updated following the mraa/upm update on the board.

@arfoll, @propanu, do you by chance know something about this use case? Is it supported at all?

If no one knows I'll just install it on my machine and see if I can come up with something.

allene222 commented 7 years ago

Ah, that makes since. I have a link to a site where you could take the mraa files and just put them in a certain directory and that was the update. But the link just returns a 404 not found error.

I really appreciate the help here as I am counting my time trying to figure this out in man-days, not hours.

Allen

allene222 commented 7 years ago

OK, I got some help in doing the downgrade and Google helped me find a version old enough. After doing that, my code runs although I think a better solution is to upgrade the Eclipse side.

I downloaded mraa_0.7.4_i586.ipk from https://iotdk.intel.com/repos/2.0/intelgalactic/ and put it on the Edison, then issued these commands: opkg remove mraa --force-removal-of-dependent-packages opkg install mraa_0.7.4_i586.ipk

Hopefully this will not cause unintended side effects. More testing today to find out...

alext-mkrs commented 7 years ago

Yep, that would roughly be the way, shouldn't vause any major problems. If you use UPM library in your code, you'd need to downgrade that as well.

As for the Eclipse "way" - I'll hopefully have time in the evening today to take a look and if not then on the upcoming weekend.

allene222 commented 7 years ago

Looking a bit more closely to version numbers.
My old image, BlueZ4, has version 0.5.2 My Eclipse environment has libmraa.so.0.4.5 so I am thinking that means I am compiling with 0.4.5 The oldest version I can find to downgrade the Edison is 0.7.4.

It is working as far as I have seen so far from my testing. I use i2c, GPIO, and the UART.

I was a very early adopter of Edison, starting late 2014. I had to do a lot or workarounds to get things working. The BlueZ4 image was the only way I could get support for FTDI USB boards which is now built into the kernel.

Propanu commented 7 years ago

Hi @allene222, here's a possible solution to update both your board and the IDE and get everything in sync.

Install the latest image on the Edison from here and:

You should now have the same libraries in both your development environment and on the board.

allene222 commented 7 years ago

NOTE: I deleted some posts of my first attempt.

Being a glutton for punishment, I tried again. But this time I did several cleans when I got the error messages and after a few the program would compile and run. But it did not work. Instead of returning the value from the i2c register, it returns -1. In other words, it does not read the i2c. It is running mraa v1.6.1. My older compiled version will not run because it can't find libmraa.so.0, which is correct. When I backdate the mraa, the old compiled version runs but now Eclipse complains that it cannot find libmraa.so.1 which is also correct.

So I think I was successful in getting Eclipse to compile with 1.6.1 but not in getting my program to get data under that version.

There were 3 errors in the copy of the files about file names being too long. Also, this time 2 files that FileZella could not copy but they appeared to be links and not actual files.

Back to trying to restore Eclipse to where it was.

alext-mkrs commented 7 years ago

Thanks @propanu, exactly what I was hoping for :-)

@allene222, I'd rather suggest you to go on with the updated version and fix what's broken. Please just attach your program/relevant piece of code and describe the issue you observe. Probably it would make sense to do it in a separate "issue" than this one, to keep it focused on update itself.

But first - which exact files failed to copy during update? That may be the reason for updated program to fail.

allene222 commented 7 years ago

I have confirmed that I am a glutton for punishment. Let me outline what I did.

1) I did the update and upgrade on the Edison 2) I used FileZella and this time it copied directly into the target directories eliminating the copy errors I had but leaving the FileZella transfer errors (9). (http://allen-edwards.com/Image1.png). One of them was this. The other truncated ones were similar. /usr/lib/node_modules/iotkit-agent/node_modules/winston/node_modules/request/node_modules/form-data/node_modules/combined-stream/node_modules/delayed-stream/test/integration/test-delayed-stream-pause.js

3) I ran my heel.c program from Eclipse and it did not read from the i2c device. 4) I copied the heel.c program to the Edison and compiled it there with gcc and got the same result, errors in reading. So same result as with Eclipse. Here is the output of my program first few lines

hello mraa Version: v1.7.0 SUCCESS. MRAA return value is 0 rx_tx_buf0 ,Return Value is 45 rx_tx_buf1 ,Return Value is 8 rx_tx_write ,Return Value is 99 Return Value is -1 x=0.0 y=0.0 z=0.0

5) I downgraded the mraa on the Edison and recompiled the program. It ran fine. Here are the first few lines to compare.

hello mraa Version: v0.7.4 SUCCESS. MRAA return value is 12 rx_tx_buf0 ,Return Value is 45 rx_tx_buf1 ,Return Value is 8 Return Value is 6 x=0.0 y=0.0 z=0.9

I will post my code in the next message. If you want me to start a new thread regarding the code, I can do that.

allene222 commented 7 years ago

Here is my code.

// heel text code
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <mraa.h>
#include <math.h>
#include <mraa/gpio.h>

#include <unistd.h>              //Used for UART
#include <fcntl.h>               //Used for UART
#include <termios.h>             //Used for UART
int tty_fd;

int down  =  0;

// address of chip
#define ADXL345_I2C_ADDR 0x53
#define ADXL345_CONF_REG 0x2D
mraa_i2c_context i2c;

// these should go in correction array
double heel_correction_m = 1 ;
double heel_correction_b = 0;

double filter2pole(int index, double input){
    static double filter1[3] = {0,0,0};
    static double filter2[3] = {0,0,0};
    double tc = .4;
    double feedback = -.3;
    double gain = 1 / (1 + feedback);
    double sumOut = input + feedback * gain * filter2[index];
    double difference = sumOut - filter1[index];
    if (abs(difference) > 5){
        filter1[index] = input / gain;
        filter2[index] = input / gain;
    }
    else {
        filter1[index] += tc * (difference);
        difference = filter1[index] - filter2[index];
        filter2[index] += tc * (difference);
    }
    return gain * filter2[index];
}

void init_heel(){

    int rtv;
    rtv = mraa_init();
    if (rtv != MRAA_SUCCESS && rtv != MRAA_ERROR_PLATFORM_ALREADY_INITIALISED)
      {
        printf( "ERROR MRAA Init Failed,Return Value is %d\n",rtv);
      }
    else printf("SUCCESS.  MRAA return value is %d\n",rtv);
    uint8_t rx_tx_buf2[2] = {0,0};

    i2c = mraa_i2c_init(0);

    rtv = mraa_i2c_address(i2c, ADXL345_I2C_ADDR);
    if (rtv != MRAA_SUCCESS ) printf( "MRAA address ,Return Value is %d\n",rtv);
    rtv = rx_tx_buf2[0] = 0x2D;
    if (rtv != MRAA_SUCCESS ) printf( "rx_tx_buf0 ,Return Value is %d\n",rtv);
    rtv = rx_tx_buf2[1] = 0x08;
    if (rtv != MRAA_SUCCESS ) printf( "rx_tx_buf1 ,Return Value is %d\n",rtv);
    rtv = mraa_i2c_write(i2c, rx_tx_buf2, 2);
    if (rtv != MRAA_SUCCESS ) printf( "rx_tx_write ,Return Value is %d\n",rtv);

    /********************
    set higher order bits to 0 for normal
    BW and measureemnt rates
    Rate    BW      Code
    25      12.5    1000
    12.5    6.25    0111
    6.25    3.13    0110
    3.13    1.56    0101
    1.56    0.78    0100 <----
    0.78    0.39    0011
    0.39    0.20    0010
    0.20    0.10    0001
    0.10    0.05    0000
    **********************/

    mraa_i2c_address(i2c, ADXL345_I2C_ADDR);
    rx_tx_buf2[0] = 0x2C; // this is 0x2C the bw port
    rx_tx_buf2[1] = 0x04; // bandwidth per table above
    mraa_i2c_write(i2c, rx_tx_buf2, 2);

    // fifo length
    mraa_i2c_address(i2c, ADXL345_I2C_ADDR);
    rx_tx_buf2[0] = 0x38; // this is 0x2C the bw port
    rx_tx_buf2[1] = 0x00; // 8 sets fifo to stream, A is 10 samples
    mraa_i2c_write(i2c, rx_tx_buf2, 2);
}

double absl(double x){
    return x < 0 ? -x : x;
}

void heel(double *heel_angle)

    {
    uint8_t buf[6] = {0,0,0,0,0,0};
    int j = 0;
    int rtv;
    for ( j = 0; j < 1; j++) buf[j] = 0;
    static double heel = 0;
    //static double gravity = 1;
    //read the registers

    mraa_i2c_address(i2c, ADXL345_I2C_ADDR);
    mraa_i2c_write_byte(i2c, 0x32);
    mraa_i2c_address(i2c, ADXL345_I2C_ADDR);
    rtv =  mraa_i2c_read(i2c, buf, 6);
    if (rtv != MRAA_SUCCESS ) printf( "Return Value is %d\n",rtv);
    usleep(10);
    //printf("Raw Data: %02X%02X  %02X%02X  %02X%02X\n",buf[1],buf[0],buf[3], buf[2], buf[5], buf[4]);

    // combine registers
    int16_t x = (((int)buf[1]) << 8) | buf[0];
    int16_t y = (((int)buf[3]) << 8) | buf[2];
    int16_t z = (((int)buf[5]) << 8) | buf[4];

    double xx = (double)x / 256;
    double yy = (double)y / 256;
    double zz = (double)z / 256;
    printf ("x=%.1f y=%.1f z=%.1f\n",xx,yy,zz);

    double angle2 = 0;
    int alt = 1;

    double sq_term_x = sqrt(zz*zz + yy*yy);
    double anglex = 180 * atan2(xx,sq_term_x) / M_PI;
    printf ("\nX term %.1f\n",anglex);

    double sq_term_y = sqrt(xx*xx + zz*zz);
    double angley = 180 * atan2(yy,sq_term_y) / M_PI;
    printf ("Y term %.1f\n",angley);

    double sq_term_z = sqrt(xx*xx + yy*yy);
    double anglez = 180 * atan2(zz,sq_term_z) / M_PI;
    printf ("Z term %.1f\n\n",anglez);

    printf("Down is %d\n",down);
    if (down == 0){
        printf ("x=%.1f y=%.1f z=%.1f\n",xx,yy,zz);
        if ((absl(xx) > absl(yy)) && (absl(xx) > absl(zz))){
            if (alt == 0) down = 2;
            else down = 3;
        }
        else if ((absl(yy) > absl(zz)) && (absl(yy) > absl(xx)) ){
            if(alt == 0) down = 3;
            else down = 1;
        }
        else if ( (absl(zz) > absl(xx)) && (absl(zz) > absl(yy))){
            if(alt == 0) down = 1;
            else down = 2;
        }
        else {
            printf("ER Something is wrong in heel\n");
        }
    }

    if (down == 1) angle2 = anglex;
    else if (down == 2) angle2 = angley;
    else if (down == 3) angle2 = anglez;
    else angle2 = 0; // error condition

    printf("**********angle2 is %.1f ********\n", angle2);

    double gravity = sqrt(xx*xx + yy*yy + zz*zz);
    printf("gravity is %.2f\n",gravity);

    if (gravity < 1.1 && gravity > .9) {
        heel = filter2pole(0, angle2);
        //printf("valid\n");
    }
    else printf("invalid gravity.  Should be between .9 and 1.1\n");
    printf("raw heel:%0.1f\n",angle2);
    printf("filtered heel:%0.1f\n",heel);
    *heel_angle = (heel);
}

void btoh(unsigned char c, char *str){
    unsigned char x;
    x = c >> 4;
    str[0] = x + (x > 9? 'A'-10: '0');
    x = c & 0x0f;
    str[1] = x + ( x > 9? 'A' - 10 : '0');
    str[2] = '\0';
}

int main(int argc, char **argv)
{

    fprintf(stdout, "hello mraa\n Version: %s\n ", mraa_get_version());
    struct termios tio;
    tty_fd = open("/dev/ttyMFD1", O_RDWR | O_NONBLOCK);
    tcgetattr(tty_fd, &tio);
    cfsetspeed(&tio, B9600);
    cfmakeraw(&tio);
    tcsetattr(tty_fd, TCSANOW, &tio);
    char string[3];
    init_heel();
    double heel_angle = 0;

    usleep(1000000);// takes time for buss to come  up.

    for (;;){

        heel(&heel_angle);
        printf("heel angle = %.0f\n", heel_angle);
        heel_angle = abs(heel_angle);

        sprintf(string,"%.0f",heel_angle);
        if(strcmp(string, "-0") == 0) strcpy(string,"0");

        usleep(1000000);
    }
    mraa_i2c_stop(i2c);
    close(tty_fd);
    return 0;
}
alext-mkrs commented 7 years ago

Ok, so what I see here is that apparently the first mraa_i2c_write() in init_heel() is failing with some error. The function itself hasn't actually changed much since 0.7.4 and the difference couldn't be causing such error. That leads me to thinking it might be something on the OS level, so we really need to get to your syslog logs. Please try rebooting your board and running that journalctl -xn 40 --no-pager command one more time after running your program (compiled with the newest mraa). If that returns nothing again, try dmesg |tail -100 command instead.

As for the Eclipse side - those files, which failed to copy, are I think irrelevant, so for now we can conclude your host (Eclipse) part is updated. To exclude any possible interference though, please compile your code directly on Edison (just like you did in your last comments) and we'll test the whole path (from Eclipse to Edison) after we resolve that I2C problem.

BTW, I've edited your comment with the program source to use Markdown formatting for C, otherwise it's quite hard to read.

alext-mkrs commented 7 years ago

And one more thing - the above comment is based on the visual review. I've now tried to compile your program and it actually doesn't compile with current master due to deprecated (in 1.0.0+ mraa) identifier:

root@edison1:~/mraa-725# gcc -o test test.c -lmraa
test.c: In function 'init_heel':
test.c:53:39: error: 'MRAA_ERROR_PLATFORM_ALREADY_INITIALISED' undeclared (first use in this function)
     if (rtv != MRAA_SUCCESS && rtv != MRAA_ERROR_PLATFORM_ALREADY_INITIALISED)
                                       ^
test.c:53:39: note: each undeclared identifier is reported only once for each function it appears in

Please also post a full command line you use to compile your program with new mraa.

allene222 commented 7 years ago

I changed i2c = mraa_i2c_init(0); to i2c = mraa_i2c_init(6); That worked. It also works from Eclipse. My hardware is the same so not sure what is up with that.

Now I am faced with a dilemma. Should I use mraa1 or mraa0? If I use mraa1 I am up to date but I am forcing all my users to upgrade the OS in order to take any updates of my code. If I use mraa0, I can still have new users use the new OS and all its features, and the code will run in either platform.

You say that the mraa i2c has not changed much. What advantage do I get with mraa1?

The rest of this email I wrote before trying the above so it applies to the case where init(0) was still there.

Sorry about the compile error. I edited that identifier out for the new OS. But you may notice that with 0.7.4, that is the return code I get. With the new version, I get MRAA_SUCCESS.

The first block is the old mraa. Then I recompiled and ran. The first block of the journal output is just the part after running heel.c. Finally, the entire journal output.

Allen

./heel hello mraa Version: v0.7.4 SUCCESS. MRAA return value is 12 rx_tx_buf0 ,Return Value is 45 rx_tx_buf1 ,Return Value is 8 Return Value is 6 x=-0.0 y=0.1 z=0.9

X term -1.0 Y term 3.8 Z term 86.1

gcc heel.c -lm -lmraa root@Papoose4:~# ./a.out hello mraa Version: v1.7.0 SUCCESS. MRAA return value is 0 rx_tx_buf0 ,Return Value is 45 rx_tx_buf1 ,Return Value is 8 rx_tx_write ,Return Value is 99 Return Value is -1 x=0.0 y=0.0 z=0.0

X term 0.0 Y term 0.0 Z term 0.0

May 13 14:49:16 Papoose4 systemd-timesyncd[173]: interval/delta/delay/jitter/drift 64s/+0.016s/0.186s/0.006s/+0ppm May 13 14:49:40 Papoose4 libmraa[369]: libmraa version v1.7.0 initialised by user 'root' with EUID 0 May 13 14:49:40 Papoose4 libmraa[369]: gpio214: init: Failed to write to 'export': No such device May 13 14:49:40 Papoose4 libmraa[369]: edison: Arduino board not detected, assuming Intel Edison Miniboard May 13 14:49:40 Papoose4 libmraa[369]: libmraa initialised for platform 'Intel Edison' of type 2 May 13 14:49:40 Papoose4 libmraa[369]: i2c_init: Selected bus 0 May 13 14:49:40 Papoose4 libmraa[369]: Invalid i2c bus 0, moving to default i2c bus 1 May 13 14:49:40 Papoose4 libmraa[369]: i2c1: write: Access error: Remote I/O error May 13 14:49:40 Papoose4 libmraa[369]: i2c1: write: Access error: Remote I/O error May 13 14:49:40 Papoose4 libmraa[369]: i2c1: write: Access error: Remote I/O error May 13 14:49:41 Papoose4 libmraa[369]: i2c1: write_byte: Access error: Remote I/O error May 13 14:49:42 Papoose4 libmraa[369]: i2c1: write_byte: Access error: Remote I/O error

Entire output

journalctl -xn 40 --no-pager -- Logs begin at Sat 2000-01-01 00:00:12 UTC, end at Sat 2017-05-13 14:49:42 UTC. -- May 13 14:38:02 Papoose4 wpa_cli[275]: /etc/udhcpc.d/50default: Adding DNS 208.201.224.11 May 13 14:38:02 Papoose4 wpa_cli[275]: /etc/udhcpc.d/50default: Adding DNS 208.201.224.33 May 13 14:38:02 Papoose4 xdk-daemon[301]: Loading /opt/xdk-daemon/config.json last modified: Mon May 16 2016 18:28:30 GMT+0000 (UTC) May 13 14:38:03 Papoose4 xdk-daemon[301]: starting on baseport = 58888 May 13 14:38:03 Papoose4 mDNSResponder[288]: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 09C41DF4 Papoose4.local. (Addr) that's already in the list May 13 14:38:03 Papoose4 mDNSResponder[288]: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 09C42178 134.1.168.192.in-addr.arpa. (PTR) that's already in the list May 13 14:38:03 Papoose4 mDNSResponder[288]: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 09C46EE4 Papoose4.local. (Addr) that's already in the list May 13 14:38:03 Papoose4 mDNSResponder[288]: mDNS_Register_internal: ERROR!! Tried to register AuthRecord 09C47268 15.2.168.192.in-addr.arpa. (PTR) that's already in the list May 13 14:38:03 Papoose4 xdk-daemon[301]: MDNS Broadcast Sent:58888 May 13 14:38:03 Papoose4 xdk-daemon[301]: V8PORT REC May 13 14:38:04 Papoose4 xdk-daemon[301]: child exited May 13 14:38:04 Papoose4 xdk-daemon[301]: Child process closed May 13 14:38:05 Papoose4 kernel: snd_intel_sst: Stop for str 14 pipe 0xe May 13 14:38:05 Papoose4 kernel: snd_intel_sst: Free for str 14 pipe 0xe May 13 14:38:05 Papoose4 kernel: snd_intel_sst: Stop for str 1 pipe 0x90 May 13 14:38:05 Papoose4 kernel: snd_intel_sst: Free for str 1 pipe 0x90 May 13 14:38:05 Papoose4 kernel: snd_intel_sst: runtime_idle called May 13 14:38:07 Papoose4 kernel: snd_intel_sst: runtime_suspend called May 13 14:38:07 Papoose4 login[277]: pam_lastlog(login:session): file /var/log/lastlog created May 13 14:38:07 Papoose4 login[277]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) May 13 14:38:07 Papoose4 systemd[1]: Starting Session c2 of user root. May 13 14:38:07 Papoose4 systemd-logind[217]: New session c2 of user root. May 13 14:38:07 Papoose4 systemd[1]: Started Session c2 of user root. May 13 14:38:07 Papoose4 login[367]: ROOT LOGIN on '/dev/ttyMFD2' May 13 14:38:32 Papoose4 systemd-timesyncd[173]: Using NTP server 216.239.35.8:123 (time3.google.com). May 13 14:48:43 Papoose4 systemd[311]: Time has been changed May 13 14:48:43 Papoose4 systemd-timesyncd[173]: interval/delta/delay/jitter/drift 32s/+611.403s/0.191s/0.000s/+0ppm May 13 14:48:43 Papoose4 systemd[1]: Time has been changed May 13 14:49:16 Papoose4 systemd-timesyncd[173]: interval/delta/delay/jitter/drift 64s/+0.016s/0.186s/0.006s/+0ppm May 13 14:49:40 Papoose4 libmraa[369]: libmraa version v1.7.0 initialised by user 'root' with EUID 0 May 13 14:49:40 Papoose4 libmraa[369]: gpio214: init: Failed to write to 'export': No such device May 13 14:49:40 Papoose4 libmraa[369]: edison: Arduino board not detected, assuming Intel Edison Miniboard May 13 14:49:40 Papoose4 libmraa[369]: libmraa initialised for platform 'Intel Edison' of type 2 May 13 14:49:40 Papoose4 libmraa[369]: i2c_init: Selected bus 0 May 13 14:49:40 Papoose4 libmraa[369]: Invalid i2c bus 0, moving to default i2c bus 1 May 13 14:49:40 Papoose4 libmraa[369]: i2c1: write: Access error: Remote I/O error May 13 14:49:40 Papoose4 libmraa[369]: i2c1: write: Access error: Remote I/O error May 13 14:49:40 Papoose4 libmraa[369]: i2c1: write: Access error: Remote I/O error May 13 14:49:41 Papoose4 libmraa[369]: i2c1: write_byte: Access error: Remote I/O error May 13 14:49:42 Papoose4 libmraa[369]: i2c1: write_byte: Access error: Remote I/O error root@Papoose4:~#

allene222 commented 7 years ago

I went back to mraa0 and ran the program and looked at the output. I think this will explain what is going on.

Here are just a few lines of the log

May 13 15:05:03 Papoose4 libmraa[404]: edison: Arduino board not detected, assuming Intel Edison Miniboard May 13 15:05:03 Papoose4 libmraa[404]: libmraa initialised for platform 'Intel Edison' of type 2 May 13 15:05:03 Papoose4 libmraa[404]: i2c_init: Selected bus 6

allene222 commented 7 years ago

Note that this document, https://iotdk.intel.com/docs/master/mraa/i2c_8h.html#ac562c1d61ce8c4831d61affac9fad716

Has this sample code: mraa_i2c_context i2c; i2c = mraa_i2c_init(0);

Also, googling "mraa_i2c_init(0)" and Edison gives over 100 hits. Same with "mraa_i2c_init(6)" gives 6

This tutorial also has init(0) https://lasr.cs.ucla.edu/classes/edison_tutorials/gpio.pdf

alext-mkrs commented 7 years ago

Ah, ok, now the reason is clear. So you have a miniboard and used to use the init(0) stance, which is ok and used frequently. But there's actually no bus number 0 on Edison, there are only 1 and 6 and while miniboard has both available, the Arduino board exposes only 6. To make it easier for users, there's a logic in mraa, which switches to the actually existing bus, marked as default in the code, in case user does init() with non-existing bus number.

And between 0.7.4 and 1.0.0, commit 03d741ff3e31dbe65e7fe3dc8815566b50d43eb1 back in 2016 has changed the default from 6 to 1 for the miniboard - causing the effect you've observed. You apparently had your sensor connected to bus 6 all the time, but init(0) selected bus 6 before 03d741ff3e31dbe65e7fe3dc8815566b50d43eb1 and bus 1 - after it. So the solution is simple and you've already found it - use the explicit bus number.

As for the old vs. new library version considerations - that's really your call, given all the circumstances. For one, older OS images are not supported by Intel (and they have some bugs, e.g. SPI has improved noticeably over time), so your users will probably migrate to the latest one anyway at some point. As for mraa itself - for your specific use case of working with an I2C sensor, I don't think things changed much in this area, however there were various fixes and changes increasing stability of the library in general, which may or may not be relevant to your use case. And then again - if you face issues down the road, or want to enhance your program, it would be hard for us to help you on old (and 0.7.4 is just ancient) versions, so you have to weigh the importance of that for you, and I'd really suggest you to use the new one.

Hope this helps.

So back to the original matter - now that the i2C communication is fixed, let's check out the whole path, from Eclipse down to the board. You've got both sides updated, please give it a try and feel free to let me know if there's anything else not working - we'll sort it out.

allene222 commented 7 years ago

As I said on my post above, it works through Eclipse so all is good. I will take your advice and use the latest mraa, 1.7.0.

Thinking of the future, I am a bit worried about a repeat of this. The image 20160606 is loaded with mraa 1.0.0. To get the latest I did a opkg upgrade. That got me to mraa1.7.0 which is what is in my Eclipse. Do I need to do that or can I take the standard image 20160606 and just update the mraa to 1.7.0? This is an embedded processor and I want to maintain some configuration control. I don't want a lot of different versions out there. I am OK with this upgrade because I need the new OS to do my UDP displays but I don't want every new user to have a new configuration.

The issue is that I have an image 20160606. I have mraa1.7.0. But I don't know what is in the opkg upgrade and doing that a year from now might produce a different configuration.

I hope this makes since?

alext-mkrs commented 7 years ago

So Eclipse part is not strictly necessary even if you update the board's mraa to something newer than what the image has by default. It is necessary if you want to program the board from Eclipse, if you are ok with compiling yor program directly on the board, that's not necessary. Or, if you think about your users, which get your program in sources - they don't need the whole Eclipse piece to compile it, just provide them with mraa version requirement, instructions on compiling it on a board and they should be good.

If I got your question correctly :-)

allene222 commented 7 years ago

I don't give out source. I distribute the executable. So there needs to be some control between the version of the OS they have and my source.

I can specify the OS version as 20160606 and I can specify that they use mraa1.7.0 as those are available. But I don't have control of what opkg upgrade installs.

I just need configuration control and I am wondering how to do that. I guess I could just start over with 20160606 and not do the opkg upgrade and upgrade mraa to 1.7.0 manually. But perhaps the OS needs to be upgraded to allow 1.7.0 to work. I don't know.

If there was a way for me to capture an image off my system that would work as well but I don't know how to do that.

alext-mkrs commented 7 years ago

I see. In this case I would suggest you to settle on a policy of supporting a current OS image + specific version of mraa on top. You can go with older images of course, but imho it's not worth it, due to bugfixes.

That way you can specify the OS image version as a prerequisite (e.g. "Edison software release 3.5", which is how they officially call that 201606<...> one) and then make people install specific mraa version by running "opkg install ", instead of a blanket "opkg upgrade".

alext-mkrs commented 7 years ago

So, @allene222, do you need any further help with this one?

allene222 commented 7 years ago

I am good. I have a copy of Edison-20160606 and mraa 1.7.0 and scrips and instructions for my users to install that combination. I have tested it and my code, compiled with the new Eclipse setup you helped me with works. My Eclipse version had the upgrade so there may be some small differences but everything is working so I am good. Thank you for your help. It was invaluable.

alext-mkrs commented 7 years ago

Great, glad to read that :-) So I'm closing this one and you are more than welcome to open new records should you need any further help.