Errors

[GitJer]

Thanks for making this repository. I think the arduino compatibility could be more important for large scale adoption of the k210 boards of Sipeed than micropython is.

However, there are some issues.

After installing maixduino as described here, I get the following errors:

During starting the arduino IDE:

Index error: could not find referenced tool name=kflash version=0.4.1 packager=Maixduino

I noticed that in the json only the kflash version 1.0.0 is mentioned in the tool section, could that be an issue? On the other hand, both 0.4.1 and 1.0.0 are installed in the Maixduino/tools/kflash directory.

When compiling the mas_basic example I get the following error:

/home/j/.arduino15/packages/Maixduino/tools/riscv64-unknown-elf-gcc/8.2.0/bin/../libexec/gcc/riscv64-unknown-elf/8.2.0/cc1plus: error while loading shared libraries: libisl.so.19: cannot open shared object file: No such file or directory

Searching the internet shows that this is some gcc error, and thus probably caused by the compilers. Repairing this seems to be tricky, so I used my separately installed toolchain that I know is working. This was achieved by adding the following lines at the appropriate lines in board.txt:

go.menu.toolsloc.manual=Manual go.menu.toolsloc.manual.compiler.path=/home/j/bin/kendryte/kendryte-toolchain/bin/

I get a lot of compiler warnings, but it does produce a .bin file.

At first uploading did not work while no error message was produced. After switching the MAIX Go board off and on, and waiting a while, uploading did succeed. There is, however, no visible output. Not in the IDE (of course, but the other kflash versions I used automatically started a minicom) and not in the arduino serial monitor. Starting an external serial monitor (cutecom) does show a small portion of the output (about 5 lines), but then stops. Starting a minicom myself via a python3 script:

import serial.tools.miniterm serial.tools.miniterm.main(default_port='/dev/ttyACM0', default_baudrate=9600, default_dtr=False, default_rts=False)

does produce the correct output.

Hopefully some of these issues can be repaired, or maybe you can tell me what I should do differently.

[bitsk]

@GitJer Hello, thank you for your feedback on this project.

• We replaced the previous version of Windows with the python version of kflash in the latest version. In order to ensure that we received the update, we replaced the version number of the tool. The linux version has not changed substantially, so you can delete it now.
• The warning during compilation is generated during the compilation of kendryte-standalone-sdk. This problem will be solved with the upgrade of sdk in the future.
• Have you set the correct baud rate in the Arduino serial monitor? Can you provide some more details for our analysis?

[GitJer]

The baud rate is set correctly. Changing it does not make it work.

If I upload the sketch and then open the serial monitor it shows nothing. If I then close the serial monitor and open it again it shows about 10 to 20 lines of the output but does not continue. If I close and open it again, it shows newer output but again only some lines without continuing.

I added a Serial.flush() after the printing statements in loop(). This did not help.

It seems like the arduino serial monitor and cutecom are able to read a buffer with output, but not read directly from the device.

Then I tried to use minicom and I noticed something odd: At first minicom did not show any serial output. With minicom still running, I started the script in my original post. That script crashed with:

raise SerialException('read failed: {}'.format(e)) serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

but immediately the minicom terminal started showing the serial output, and kept on going! It seems like my script changed some settings that allowed minicom to read data from the device.

I tried the same with the other terminal programs: If I open the arduino serial monitor and then start the script, the script returns the error:

could not open port '/dev/ttyACM0': [Errno 16] could not open port /dev/ttyACM0: [Errno 16] Device or resource busy: '/dev/ttyACM0'

And nothing further happened.

If I open cutecom and then start the script, cutecom stops and closes the device and my script starts producing output.

Hopefully this gives you a hint of what might be wrong.

Thanks in advance!

[Neutree]

I tried on a new one ubuntu18, no error occurred!

If can not find lib.so like libisl.so.19, you can add the toolchain path to LD path in ~/.bashrc or !/.zshrc

toolchain_path=/home/j/.arduino15/packages/Maixduino/tools/riscv64-unknown-elf-gcc/8.2.0/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$toolchain_path

These way may resolve your serial problem

• And add user to dialout group:

sudo usermod -a -G dialout $(whoami)

then need to logout or reboot!

• try maix bit board or dock board

• try to burn open-ec firmware for Maix Go board

• do not use USB HUB, plug into USB on PC directly

• or try again on another PC

[GitJer]

I installed the latest Arduino IDE, added the toolchain path to .bashrc, and did the usermod command. It now compiled and uploaded without a problem (except for the compile warnings). Thanks!

Unfortunately, the serial is still not working. I did observe something strange. I did some further testing, now also using minicom. When I start minicom (with all correct settings) it does not show the serial output. If I leave minicom open, and in another terminal I issued the following statements, I get interesting results:

python3 -m serial.tools.miniterm --dtr 0 --rts 0 /dev/ttyACM0 9600

Python gives an error, and minicom starts showing output. But for

python3 -m serial.tools.miniterm --dtr 0 --rts 1 /dev/ttyACM0 9600

or

python3 -m serial.tools.miniterm --dtr 1 --rts 0 /dev/ttyACM0 9600

or

python3 -m serial.tools.miniterm --dtr 1 --rts 1 /dev/ttyACM0 9600

python does not stop but gives no output and minicom also does not start showing output.

So dtr and rts need to be 0. Serial.tools.miniterm probably first sets the dtr and rts and then finds out the serial port is already in use and stops with an error. Thanks to setting dtr and rts to 0, minicom can finally read the serial port. I am not sure what, but there seems to something wrong with my installation.

I haven't yet burned open-ec. Maybe I will give that a try.