...but even if I (you) can figure this out, I think there's still a problem with the actual serialport.c/.h code. At some point, it seems to either stop responding to bytes coming in (or sending out) or simply stops interacting with java. The way the code is written now (Cedric's code) it simply opens a file handle (in .c) then passes that for app-handling in Android. Maybe if the whole reading/writing/buffering is done in .c and only the read/written bytes are passed to java (e.g. as a circular buffer or something, alloc once only), instead of as a file handle?
New image: https://drive.google.com/open?id=0B400VKg9Vc0rTEo5X2hlTkItU1U This includes the new kernel/bootimage, which improves the ttyMCC quality. It also bundles a new application based on Serial Test, Minicom, which allows you to send/receive bytes on the ttyMCC. Source code is on GitHub.
That's great! Downloading it now for testing. I was also [finally!] able to get a very slimmed down piece of C code (also based on Cedric's code) to run directly on the Neo to test for ttyMCC communication (with buffering directly at the linux level, skipping the jni layer). [I'll post the code later, as an fyi for others.] It showed that the problem (with the older version) was definitely an indefinite block on the read statement. Will report back when I have results using the new image. ps: it might be a little while because today is VOTING DAY in the USA!!! (can't wait for that to be over!)
Very quickly: so far so good. Thanks Francesco, nice work! Only had a chance to check reading M4 (no time to test writing, yet) but looking very solid so far. Reading without fail, no hangs. Lots more info to share but first, gotta go VOTE!!! (will follow up with info+code later today)
[Quote = "Francesco, mensaje: 22172, miembro de: 37414"] Sigue este: http://www.udoo.org/docs-neo/Arduino_M4_Processor/Programming_Arduino_M4_from_External_PC.html Instalar el IDE en su ordenador, añadir el gestor de tabla de JSON e instalar el paquete NEO. Parchear el NEO BSP para permitir la programación a través de la red en lugar de USB ( "Subir un esbozo sobre la Red") en lugar de 192.168.7.2 con la dirección IP de administración. Simplemente haga clic en "esbozo de carga" en su IDE. Cuando todo será estable, serán publicados documentos apropiados. ¡Lo prometo! [USER = 35731] @frudman [/ USUARIO]:? ¿Funcionó [/ quote] Does not work, the Arduino IDE marks me that the skecth is raised but the board does not load it. I'm using a MAC.
Does /data/m4last.fw exists ? Please run "logcat | grep M4" on the serial port or the terminal app in Android and post the log.
When Running logcat | grep M4 on the Android terminal does not send anything. /data/m4last.fw does not exist unless you are not looking in the right place.
Please send me the full sketch source code and also the /data/m4last.fw sketch. I'm sending you my email address privately.
OK, after a few days of testing, I'd like to say that our code is working flawlessly with Francesco's updates. To keep it simple for everyone, I've encapsulated the relevant sections of code (and instructions) in this Bitbucket snippet. Some notes: the code is written for C# (using Xamarin/Mono) and works directly into Linux (no need for Java/Jni layer) but is simple enough it should be very obvious how to convert it over to Java (including the C++ part in order to use the JNI layer). We have no need of that so I'm leaving it as an exercise for others (sorry). The shared library instructions can work for any direct-to-linux code running on Android-based platforms (e.g. Neo) Francesco's (and Cedric's) initial code used the jni layer to open/close the file descriptors, then used the Java layer to do the actual read/write. That did not work for me so I decided to place the read/write methods directly in the library (only an additional 10 lines or so) and all our problems disappeared. I'll never know if it was data-marshaling issues or simply old bugs (since removed in Francesco's updated image) but the code snippet above avoids all of this by not trying to marshall read/write through jni layer. We haven't tested for performance (yet) but continuous runs over multiple days have yet to fail The buffer is allocated only once, at the managed-code level. The code snippet does not memory-pin it so it could be moved for very long executions but that's an unrelated issue (easily solvable by pinning the buffer before passing its pointer). I hope this information helps someone. Bottom line, we now have a solid read/write to/from Arduino/M4 via ttyMCC. Once again, Big Thanks to Francesco! Freddy
Hello, I managed to add the library to my android Studio project, so that it can work after adding it to the project, it should change the name of the package that comes in the libre, both in .c and .h for that of its application. I was testing the run but apparently the board does not support much the multitasking of the app and code in arduino. Thanks.
Do you know if there is a way to restart/reset the arduino side programmaticaly on Android ? Sometimes the sketch just stop and the only way is to reboot
If you decide to restart a sketch (the M4) while the kernel is running then there is no guarantee the kernel/peripherals will remain stable. If you review the kernel source tree that support the M4 and MQX code you will understand why.
Jas-mx, you keep mentioning this issue and talking in riddles regarding the solution. Fact is that this is the only method to upload sketches/bins to the m4 for inexperienced embedded programmers (like me). If you know the solution for your problem (with what symptoms?) please share it with us all. We all know the m4 part is not perfect but I don't know what issues are symptoms of the upload issue and what not.
Currently the solution, although not popular would be to reboot the board each time a sketch is uploaded. This was the previous method of loading sketches. The new udooneo-m4uploader is trying to upload m4 code after the kernel is running, which currently isn't how the kernel is expecting the M4 to be launched. Its something for the udoo team to address however I'm not sure if they even understand the problem based on the way udooneo-m4uploader code has been changed.
As long as I have a Neo (more than a year) it is possible to upload an Arduino sketch on a running Neo without reboot. What has changed then?
Unfortunately my answer is start reviewing the source code changes, the devils in the detail. I suspect walter you will probably respond 'its out of my depth' but without understanding the imx6sx architecture, boot sequence for uboot + kernel and m4 coexistence your not going to understand whats possible or whats right or wrong.
