Hi everyone,
Is there a Ringo emulator similar to the MAKERbuino one I can use to program and test apps before I receive my unit?
1 Like
Hey,
Unfortunately not, but weâre looking into making this in the future and even implementing it in CircuitBlocks. Although, itâs not as easy as it sounds 
2 Likes
If your Chromebook supports Linux apps (Crostini) you can probably install the 64 bit package (.deb) and compile the firmware or apps, but you will probably need to sync those files out to the host ChromeOS and flash them with another tool like Chromeduino or AVRChick or similar.
Crouton is another option but it requires your Chromebook to be in Developer Mode which isnât always possible if your Chromebook is managed by an organization or school.
Hi Dragon!
Did you do something like that in the past? Is Chrome OS really the operating system of choice for projects like that? It seems that there are a lot of things that might not work properly there.
Cheers,
Robert
Yeah, I tend to use my Chromebook for almost everything that I would have used a Linux machine for a few years ago.
Google supports Android Studio run inside the Linux apps environment for developing Android applications and they are adding support for more USB devices to be able to communicate in and out of the Linux VM all the time.
I just found out this morning that I can access the GPG on my Yubikey on ChromeOS r81 which was really the last thing holding me back from switching over 100% of my development to my Chromebooks.
Iâll be testing this USB pass-through with various other microcontroller devices soon and Iâll put my MAKERphone at the top of the list.
Great to hear that, itâs been a rough ride for Chrome OS since theyâre the newest around so it takes a bit of time to build the community and the whole system properly.
Glad to see things evolve so quickly! 
Weâll follow the progress of the Chrome OS and definitely plan to release any new software (and CB at some time) to this new OS as well.
Keep us updated on how the experiment is going!
Cheers,
Robert
Here are a couple screenshots showing the commands I used in the Crosh shell to attach the USB device into the default Termina VM and then showing on the right side the beginning and completion of a firmware update.
What these donât show is the pain I ran into with some assumptions that were made in how the Arduino IDE got installed and how it has several paths that it might check nor how I had to monkey around with the cache in order to get it to download the 1.0.6 version of the Ringo files to get them to show as options and install Python 2.7 and python-serial (2.7 went end of life in January 2020) in order to allow the esptool to flash though it should work just fine with Python 3.x.
I donât think any of the above issues were strictly limited to installing inside Crostini on a Chromebook, I think Debian and possibly Ubuntu would have the same issues.
Wow, it seems like you really went through hell to get there.
I have to say bravo for your perseverance and effort to pull this through - hard work always pays off in the end!
Do you maybe have a little tutorial made so other Chrome OS users can also use this method?
Kudos,
Robert
So while I was able to install CircuitBlocks I havenât had much luck using it to push code to the MAKERphone, but I just went through the steps to install it again on another Chromebook (which is not in Developer Mode so closer to what most students and non-power users will use) and I took some notes.
First off the installation of CircuitBlocks from the .deb package can be started from the Files app and doesnât take long, but then when you first launch from the shortcut it tries to download the world (or at least the Arduino IDE and maybe some other things which take quite a long time with a spinner but no progress bar or status messages).
The first big issue I ran into was the files in ~/.arduino/arduino-1.X.XX/java/bin/ werenât executable so launching Arduino IDE from the launcher just hung, but I had to try running arduino from the Terminal to be reminded about the java issue that Iâd fixed previously. To fix it again I ran the command below which has a * in the middle so that it works for any version of arduino under ~/.arduino which in my case happened to be arduino-1.8.12.
chmod +x ~/.arduino/*/java/bin/*
After I got the IDE to open before I could do anything with the Ringo I had to set the Crostini USB Allow Unsupported flag to Enabled in chrome://flags and restart the Chromebook. When I plugged in the phone after the restart it prompted me whether I wanted to connect the device to Linux which I allowed.
Then I tried to âBurn Bootloaderâ from the Arduino IDE but I couldnât actually run it because it didnât have a port selected, and this was due to /dev/ttyUSB0 being owned by root:root (user/group) and even though the user inside Crostini is a member of dialout (historically used for serial devices/modems which is why so many IoT devices use converters that are recognized as ttyUSBx), I had to sudo chown root:dialout /dev/ttyUSB0 in order to actually see and select the port in the IDE.
Then running âBurn Bootloaderâ failed because there was no python available. Initially I installed python-pip since that pulls in Python 2 and typically you need pip to get any additional Python packages. Then it complained about needing PySerial so I fixed that with pip install pyserial but then I realized since PySerial was the main thing it actually needed I could just install python-serial or python3-serial and skip doing installs through multiple package managers (apt and pip). I verified that once I had a python in the PATH I was able to reflash no problem (though for Python3 I had to symlink it to /usr/bin/python since Arduino is hardcoded to look for just python and not python3).
I made sure Python3 worked because it is strongly preferred for any new code or installations since Python2 is no longer supported by the Python Software Foundation (and Python 3.x has been around forever). The steps below should get things in order from the Python side of things.
sudo apt update && \
sudo apt install python3-serial
if [ -f /usr/bin/python3 ] && [ ! -f /usr/bin/python ]; then
sudo ln --symbolic /usr/bin/python3 /usr/bin/python;
fi
Flash log (mostly the same for Python2.7 or 3.7)
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____.....___
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, BLK3 partially reserved, Coding Scheme None
MAC: aa:bb:cc:dd:ee:ff
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 18244.9 kbit/s)...
Hash of data verified.
Compressed 15328 bytes to 9994...
Writing at 0x00001000... (100 %)
Wrote 15328 bytes (9994 compressed) at 0x00001000 in 0.1 seconds (effective 907.9 kbit/s)...
Hash of data verified.
Compressed 1540816 bytes to 830185...
Writing at 0x00010000... (1 %)
Writing at 0x00014000... (3 %)
Writing at 0x00018000... (5 %)
Writing at 0x0001c000... (7 %)
Writing at 0x00020000... (9 %)
Writing at 0x00024000... (11 %)
Writing at 0x00028000... (13 %)
Writing at 0x0002c000... (15 %)
Writing at 0x00030000... (17 %)
Writing at 0x00034000... (19 %)
Writing at 0x00038000... (21 %)
Writing at 0x0003c000... (23 %)
Writing at 0x00040000... (25 %)
Writing at 0x00044000... (27 %)
Writing at 0x00048000... (29 %)
Writing at 0x0004c000... (31 %)
Writing at 0x00050000... (33 %)
Writing at 0x00054000... (35 %)
Writing at 0x00058000... (37 %)
Writing at 0x0005c000... (39 %)
Writing at 0x00060000... (41 %)
Writing at 0x00064000... (43 %)
Writing at 0x00068000... (45 %)
Writing at 0x0006c000... (47 %)
Writing at 0x00070000... (49 %)
Writing at 0x00074000... (50 %)
Writing at 0x00078000... (52 %)
Writing at 0x0007c000... (54 %)
Writing at 0x00080000... (56 %)
Writing at 0x00084000... (58 %)
Writing at 0x00088000... (60 %)
Writing at 0x0008c000... (62 %)
Writing at 0x00090000... (64 %)
Writing at 0x00094000... (66 %)
Writing at 0x00098000... (68 %)
Writing at 0x0009c000... (70 %)
Writing at 0x000a0000... (72 %)
Writing at 0x000a4000... (74 %)
Writing at 0x000a8000... (76 %)
Writing at 0x000ac000... (78 %)
Writing at 0x000b0000... (80 %)
Writing at 0x000b4000... (82 %)
Writing at 0x000b8000... (84 %)
Writing at 0x000bc000... (86 %)
Writing at 0x000c0000... (88 %)
Writing at 0x000c4000... (90 %)
Writing at 0x000c8000... (92 %)
Writing at 0x000cc000... (94 %)
Writing at 0x000d0000... (96 %)
Writing at 0x000d4000... (98 %)
Writing at 0x000d8000... (100 %)
Wrote 1540816 bytes (830185 compressed) at 0x00010000 in 13.7 seconds (effective 902.2 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 143...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (143 compressed) at 0x00008000 in 0.0 seconds (effective 3423.8 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...Bravo sir!
Very impressive and you really went a long way to get this working.
Can we use your instructions and images to create a little âadvanced tutorialâ that we would publish in the âCreationsâ section on our website? Of course, you would get full credit as the author and we would link it here to the forum.
Cheers,
Robert
Sure! I also noticed it appears you are using fpm to build the Debian package, maybe adding python-serial as an explicit dependency would help as that would pull in Python and pyserial.
Okay,
Weâll look into that! Thanks
Robert