Arduino Create

[mwallnoefer]

I have tried to integrate my Edison into the new Arduino Create IDE (https://create.arduino.cc). The Intel agent gets installed correctly, sketches compile and get uploaded (:+1:).

First of all, what does not work (but it is optional) is the NetworkManager plugin. But that's also understandable, since we use connmanctl instead of nmcli (I guess?).

PACKAGE "NETWORKMANAGER" IS MISSING
Some informations are not available because the package called "NetworkManager" is not installed in your device.
Do you want to install it now? 

Basically whenever this web dialog pops up and you click on 'yes', nothing happens - but okay, it's not fundamental.

Regarding the sketch, once uploaded it cannot be executed. A quick check with readelf -a reveals that it is a x86_64 executable though, but then I am lost... It might need some dependencies like mraa etc. So I upload it here for further inspection.
sketch_oct25a.gz

[htot]

Your right, on the edison we are using connman. Imho it works very well, wifi 2.4G and 5G, ethernet over usb, over bluetooth, access point.

Afaiu the Arduino Create IDE should use the edison sdk (make sdk). Then the dependencies should be taken care of.

[mwallnoefer]

Afaiu the Arduino Create IDE should use the edison sdk (make sdk). Then the dependencies should be taken care of.

That won't be possible, it is Amazon EC²-based and managed by the Arduino project. But wait...there is also the agent which gets installed locally, maybe that one can be patched somehow.

[mwallnoefer]

Solved, curious on what it was about? The path of ld-linux-x86-64.so.2, Intel expects it to be under /lib64 not /lib.
So this one did the trick for me:

mkdir /lib64
ln -s /lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2

I think it would be good to fix this to retain compatibility to the other Intel boards...

[mwallnoefer]

Please find attached the trace of a simple sketch which uses the serial port.
ASCIITable.log
BlinkWithoutDelay.log

Things which I notice:

• Arduino Create expects the first serial under /dev/ttyS0, we however have it on /dev/ttyS1
• The old gpio mappers get used: for instance /sys/class/gpio/gpio214/

[htot]

If you are using mraa that makes sense, it has platform code (1 file) that needs to be rewritten to use libgpio.

[mwallnoefer]

Okay, so Arduino Create doesn't seem to use the latest version/respectively correct module, given the serial port name (should be /dev/ttyS1). I need to check this...

But how should we address the loader path issue (previous comment)? Can we move ld-linux.so on x64 into /lib64 for Intel-compatibility or if not possible, add some symbolic link?

[htot]

I don't know. Our lib path if different from Ubuntu's because we are not building with multilib. We could try to mimic Ubuntu, but the correct way would be to use the Edison sdk to compile to natively run on Edison. That would include using the right version of mraa.

I had been looking at arduino-builder (1.8.10). It seems we should be able to fix that up to use the right sdk but as is it has the path to the sdk hard coded which includes the version. A symlink here and there might fix that.

I think this would be the way to go, but I never used arduino-builder so I don't know exactly how it's supposed to work. See also #78

[xlla]

we can install latest sdk into hard coded version folder easier.
the main difficulty is that arduino edison lib intend to change each pin's function on demand, but we can't switch Soc pin mode via libgpiod now, even we take efforts to migrate arduino edison lib from sysfs to ligpiod, it's useless.

everytime we want to connect some gadget on edison board to do a test, we have to build image and flash it, then we lost all settings and have to reconnect wifi, setup timezone, setup apt source ,etc...

[mwallnoefer]

@xlla: ah, got it.

[htot]

we can install latest sdk into hard coded version folder easier.
the main difficulty is that arduino edison lib intend to change each pin's function on demand, but we can't switch Soc pin mode via libgpiod now, even we take efforts to migrate arduino edison lib from sysfs to ligpiod, it's useless.

Do you really need to change the function on demand all the time? I know it needs to be done some times (like the led on the edison-arduino is used on a line that is also needed for spi).

I think like @andy-shev says, once you have hardware attached, to need to configure the pinmux at boot in most cases.

everytime we want to connect some gadget on edison board to do a test, we have to build image and flash it, then we lost all settings and have to reconnect wifi, setup timezone, setup apt source ,etc...

No.

Load the asl manually when you need it. It is not necessary to install the deb or to use the systemd service. You can also generate aml outside yocto, it's simple and quick. And you can unload the aml again when you don't need it any more, reboot probably not even needed.

[andy-shev]

Of course we can add a hack, as temporary solution, to mimic old stock image to mux the pins, but I prefer not to waste resources on it and rather try to get ACPI <--> pin control layer done. The problem there is that I have other priorities and not enough time for everything... Some help would be really appreciated!

[xlla]

Load the asl manually when you need it. It is not necessary to install the deb or to use the systemd service. You can also generate aml outside yocto, it's simple and quick. And you can unload the aml again when you don't need it any more, reboot probably not even needed.

If that does work, even reboot would be a good solution! because change hardware connection will power off first in the safe operation.

[htot]

Of course that works :-) iasl compiler is in Ubuntu package acpica-tools

See compiling
See loading.

Unloading example is here:

[xlla]

Of course we can add a hack, as temporary solution, to mimic old stock image to mux the pins, but I prefer not to waste resources on it and rather try to get ACPI <--> pin control layer done. The problem there is that I have other priorities and not enough time for everything... Some help would be really appreciated!

mux pins via acpi-table is fine, I am not sure switch soc pin function in acpi by pinFunction will work, because in spi/i2c definition does not refer to pinFunction, however the corresponding soc pins were switch correctly and those interface work fine.

I am try to start learn kernel module development, but make image seems harm harddisk a little, my host system was crash and can't boot, I am try to migrate whole system to externel enclosure and fix it. :(

[andy-shev]

Of course we can add a hack, as temporary solution, to mimic old stock image to mux the pins, but I prefer not to waste resources on it and rather try to get ACPI <--> pin control layer done. The problem there is that I have other priorities and not enough time for everything... Some help would be really appreciated!

mux pins via acpi-table is fine, I am not sure switch soc pin function in acpi by pinFunction will work, because in spi/i2c definition does not refer to pinFunction, however the corresponding soc pins were switch correctly and those interface work fine.

It won't without above mentioned layer. For time being we rely on firmware configuration.

[htot]

Okay, so Arduino Create doesn't seem to use the latest version/respectively correct module, given the serial port name (should be /dev/ttyS1). I need to check this...

But how should we address the loader path issue (previous comment)? Can we move ld-linux.so on x64 into /lib64 for Intel-compatibility or if not possible, add some symbolic link?

IIUC /lib64 is used on platforms with multiarch. Probably Yocto will use that as well when multiarch is enabled. When you are developing using host toolchain I found that LDFLAGS="-Wl,-O1 -Wl,-z,relro,-z,now -Wl,--dynamic-linker=/lib/ld-linux-x86-64.so.2" resolves the issue.

I just documented using Qt Creator for remote development here: https://htot.github.io/meta-intel-edison/3.1-Remote-develop.html

[htot]

@mwallnoefer @xlla I'm thinking to just remove the arduino toolchain and sketch support as it works only partly or not at all. And nobody cares enough to fix this.

The preferred (modern) way to develop for current Edison platform would be to have devices defined by acpi tables and drivers built into the kernel. Then use libiio, libgpiod and libserial to access them.

What would you vote? Clean up and close this issue? Or wait until someone resolves it?

[mwallnoefer]

Okay, agreed, it does not make much sense any more.