The mBot is a great little programmable robot, and my 9 year-old nephew is really getting into it. His computer can only use Mac OS 10.7.5 Lion, and the mBlock software almost works. Here’s how I got it running perfectly.


  1. Install sketchy driver ver.1.2 for CH340G from a Russian website. (direct link)
  2. Open
  3. Find line tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} -p{build.mcu} -c{upload.protocol} -P{serial.port} -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"
  4. Wrap the -P in double quotes: tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} -p{build.mcu} -c{upload.protocol} "-P{serial.port}" -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"
  5. Comment on my GitHub PR which fixes this issue.


I was lucky to pick up an mBot from my local Radio Shack at a discount before it closed. My nephew has been getting more interested in computers, robots, and programming, and I figured it would be a great gift. It uses an app called mBlock, which is based on Scratch 2.0. It has a host of interesting components: ultrasonic, line follower, IR receiver (with remote), IR transmitter, light, buttons, beeper, bluetooth, and USB/serial. It has expandable ports with RJ25 connectors. Each port provides power, i2c, and two GPIO or analog pins. This makes custom add-ons relatively easy; certainly much easier than Dash & Dot from Wonder Workshop!

Old computer problems

The website for mBlock simply says “latest OSX recommended.” The only computer my nephew has unfettered access to runs MacOS 10.7 Lion, which was released in 2011. I was happy to find that mBlock launched fine and appeared to work. I only ran into problems once I wanted it to connect to the mBot over USB.

Programming the mBot requires you install an ‘Arduino Driver’. Unfortunately even after installing the driver, the mBot is not recognized. The mBot and some other budget Arduino-ish devices use very cheap CH340/CH341 USB->Serial converters instead of the higher-quality FTDI chips. It turns out the driver included with only works on MacOS X 10.9 and above.

Rather than trying to get MacPostFactor running on his computer (a MacBook 4,1), I was determined to find a driver for this chip that would work on older hardware. USB->Serial converters have been around for ages, there has to be a compatible driver out there, right?

Fortunately there is; however, it does feel sketchy. There is a Russian hobbyist electronics website that has a page devoted to the CH340G, and includes an older version of the same driver, 1.2. This one installs fine on MacOS 10.7. Disclaimer: I’m not responsible for this driver messing up your computer. I wish that was enough to get everything working, but unfortunately it isn’t so simple.

New serial problems

As you see above, the driver doesn’t work for the most frustrating reasons. The .kext creates serial devices at paths like /dev/tty.wch ch341 USB=>RS232 1d10, and the mBlock toolchain doesn’t escape the special characters. This results in avrdude ignoring the entire device path after the first space. It tries to upload to an arduino at /dev/tty.wch and fails, with a file not found error.

Failed ideas

First, I made a symbolic link at /dev/tty.mbot that points to /dev/tty.wch ch341 USB=>RS232 1d10. The command doesn’t survive restarts, so I created a LaunchDaemon and shell script. They have to run at startup as root, which is annoying, and means you have to secure them properly. Also, sometimes the mBot gets created with a slightly different name (ends with 1a20 instead of 1d10), which breaks everything until you reinsert the cable and pray it works. I don’t want a 9 year-old to deal with that.

Second, I assumed this must be a problem with mBlock’s code. I went through the (laborious, 2) process of getting mBlock 3.4.5 to compile on my Mac. I changed the relevant code to wrap the device’s name in double quotes. I recompiled and updated the .app package, but it still failed. avrdude seemed to be interpreting the double quotes as parts of the path. By the way, if you want to compile mBlock 3.x for Mac and you stumble on this post, you have to use AIR SDK + Compilers 19.0. You’re welcome.

Finally, I tested this behavior on the latest vanilla Arduino app and my personal computer, and found that this is a bug in Arduino. It turns out this has even been discussed before. The post there helped me find the right Arduino txt file to fix the problem.

Super serial solutions includes a full copy of, version 1.6.5-r5. You can modify the file at to wrap the upload.pattern’s -P{serial.port} option in double quotes: "-P{serial.port}". This causes the path to be passed successfully down the entire toolchain.


I can relax knowing that when I’m back in New York, my nephew and his father can use his fancy new robot reliably and with ease. Now he can focus on making amazing programs, educational failures, and mischief.

I’d like Arduino to make this change in their code. I’ve submitted a pull request, but given the previous comments, it won’t get approved without enough support.


Who’s Varun?

I most recently was the founder of an HR tech startup, Disqovery. I have worn many hats, and I like making things. I also like talking business. You can reach me at, @smartperson, Github, and LinkedIn.