Window Shopping

Roger Cheng

Window Shopping Google App Engine (And Some Competitors)

I think I have a working understanding of Angular Standalone components and plan to use them for my future Angular projects. But the sample application in “Getting Started with Angular Standalone Components” code lab had other details worth looking into. Two Google cloud services were included in the exercise: Diagflow Messenger and App Engine. I assume their inclusion were a bit of Google product cross-promotion, as neither were strictly required to build Angular applications using standalone components.

Diagflow Messenger makes it easy to incorporate a chatbot onto your page. I personally always ignore chatbots as much as I can, so I’m not likely to incorporate one to my own project. On the other hand, Google App Engine looks interesting.

The standalone component code lab project only used App Engine to host static files via express.static. In that respect, it could have just as easily been hosted via GitHub Pages, which is what I’ve been using because my projects so far have been strictly static affairs. But I have ambition for more dynamic projects in the future and for those ideas I’ll need a server. When I took the Ruby on Rails Tutorial (twice) aspiring web developers could host their projects on Heroku’s free tier. Unfortunately, Heroku has since eliminated their free tier. Web development learners like me will have to look elsewhere for a free option.

Heroku implemented their service on top of Amazon Web Services. Looking around AWS documentation, I didn’t find an equivalent service making it trivial to deploy backend projects like Ruby on Rails or Node.js. We could certainly roll our own on top AWS EC2 instances and there’s a tutorial to do so but it’s not free. While there’s an EC2 introductory offer for 750 free hours in the first 12 months, after that there’s nothing in Amazon’s always-free tier for this kind of usage.

Google App Engine is similar to Heroku in offering developer-friendly way to deploy backend projects, in this case Node.js. And even better, basic level services are free if I stay within relevant quotas. According to documentation, this service is built on containers rather than EC2 virtual machines like Heroku. I don’t know if there’s enough of a difference in developer experience for me to worry about. One footnote I noticed was the list of system packages available to my projects. I saw a few names that might be useful like FFmpeg, ImageMagick, and SQLite. (Aside: The documentation page also claims Chrome headless, but I don’t actually see it on the list.)

To round out the big three, I poked around Microsoft’s Azure documentation. I found Azure App Service and instructions for deploying a Node.js web app. Azure also offers a free tier and it sounds like the free tier is also subject to quotas. Unlike Google App Engine, everything on Azure comes to a halt if I hit free tier quotas. For experiments, I prefer Azure’s approach of halting. Exceeding free tier limits on Google App Engine starts charging money rather than taking my app offline. If I build something I want to actually use, I might prefer Google’s method. Sure, I might have to pay a few bucks, but at least I can still access my app.

These two free plans should be good enough for me to learn and evolve my skills, assuming they don’t disapper as Heroku free tier did. If I get far enough in my web application development adventures to be willing to pay for server capacity, I’m will also look into an independent offering like DreamHost’s DreamCompute or one of DigitalOcean’s products for Node.js hosting.

But that’s for later. Right now, I have more I could learn from Angular standalone components code lab sample application.

Roger Cheng

Window Shopping Polymer and Lit

While poking around with browser magnetometer API on Chrome for Android, one of my references was a “Sensor Info” app published by Intel. I was focused on the magnetometer API itself at first, but I mentally noted to come back later to look at the rest of the web app. Now I’m returning for another look, because “Sensor Info” has the visual style of Google’s Material Design and it was far smaller than an Angular project with Angular Material. I wanted to know how it was done.

The easier part of the answer is Material Web, a collection of web components released by Google for web developers to bring Material Design into their applications. “Sensor Info” imported just Button and Icon, unpacked size weighing in at several tens of kilobytes each. Reading the repository README is not terribly confidence inspiring… technically Material Web has yet to reach version 1.0 maturity even though Material Design has moved on to their third iteration. Not sure what’s going on there.

Beyond visual glitz, the “Sensor Info” application was built with both Polymer and Lit. (sensors-app.js declares a SensorsApp class which derives from LitElement, and import a lot of stuff from @polymer) This confused me because I had thought Lit was a successor to Polymer. As I understand it, the Polymer team plans no further work after version 3 and has taken the lessons learned to start from scratch with Lit. Here’s somebody’s compare-and-contrast writeup I got via Reddit. Now I see “Sensor Info” has references to both projects and, not knowing either Polymor or Lit, I don’t think I’ll have much luck deciphering where one ends and another begins. Not a good place for a beginner to start.

I know both are built on the evolving (stabilizing?) web components standard, and both promise to be far simpler and lightweight than frameworks like Angular or React. I like that premise, but such lightweight “non-opinionated” design also means a beginner is left without guidance. “Do whatever you want” is a great freedom but not helpful when a beginner has no idea what they want yet.

One example is the process of taking the set of web components in use and packaging them together for web app publishing. They expect the developer to use a tool like webpack, but there is no affinity to webpack. A developer can choose to use any other tool. Great, but I hadn’t figured out webpack myself nor any alternatives, so this particular freedom was not useful. I got briefly excited when I saw that there are “Starter Kits” already packaged with tooling that are not required (remember, non-opiniated!) but are convenient for starting out. Maybe there’s a sample webpack.config.js! Sadly, I looked over the TypeScript starter kit and found no mention of webpack or similar tool. Darn. I guess I’ll have to revisit this topic sometime after I learn webpack.

Roger Cheng

Potential Small PC Explorations

I had fun playing with the GMKtec NucBox3, an interesting and capable little PC more affordable than Intel’s NUC product line, naturally with some expected tradeoffs for its lower cost. I learned about these little PCs from a Newegg advertisement and, between the time I ordered one and its arrival, I had a failed USB external drive that I transplanted into a small form factor Dell PC. Computers in these two projects represent a spectrum that I should keep in mind for future project possibilities. Which one I buy would depend on a project’s requirements.

Intel NUC

A genuine Intel NUC would be more expensive than any of the other options below, but sometimes it’s worth spending that money. For example, if I’m building a solution that needs to be reliable, I will pay more for a brand name. Or if I want to design something that can be repeated by others, it’s easier for someone to buy an identical Intel NUC than to find, say, a GMKtec. For this reason: If my Sawppy rover ever changes over to an x86-64 PC ROS brain, the official recommended hardware will be an Intel NUC. (Supplemented with suggestions on what to look for in lower-cost alternatives like the NucBox3.)

Just Below $90

But when we’re feeling adventurous and not particularly motivated to pay for quality or consistency, we can go bargain hunting. Searching for various options, I observed a price floor somewhere in the $80-$90 range. I see an interesting hint of economic factors at play preventing things from much lower than $90, but I don’t know what they might be. (As a point of comparison, Raspberry Pi 4 8GB MSRP is $75.)

Lowest Bidder du Jour

Amazon categorized these products under: “Electronics” > “Computers & Accessories” > “Computers & Tablets” > “Desktops” > “Minis”. Sorting them by price today, I see several options right around $89, roughly 40% discount from the price of a NucBox3. To get to that price point we have to give up many things. For example, this item (*) made some notable tradeoffs:

  • Memory is half the size (4GB vs. 8GB), uses older technology (DDR3 vs. DDR4), and is soldered in never to be upgraded.
  • Storage is half the size (64GB vs 128GB), uses much slower technology (eMMC vs. SATA) and is also permanently soldered. However, it does have a 2.5″ SATA bay, which the NucBox3 does not.
  • CPU is three years older and from a different product generation (Celeron J3455 vs. J4125) and it doesn’t meet hardware requirements for Windows 11.

On the upside, it still meets all my hard requirements for robot brain: 64-bit CPU running x86-64/amd64 instruction set, gigabit Ethernet port, small, lightweight, and might run on battery power. Depending on future project requirements, I may choose these tradeoffs in favor of a <$90 bargain.

Buying Refurbished

Looking at inexpensive PCs on Amazon, I saw a lot of refurbished units. Clicking around a few listings, I learned Amazon had set up an entire department. “Amazon Renewed” is dedicated to refurbished products of all kinds, not just computers. I should definitely keep this in mind as an option. Given my personal experience, I’d restrict my search to refurbished Dell products from their corporate line. Which would still leave me with very many options. Check out these guys, each offered at a few bucks under $90:

  • Optiplex 3040 Micro Desktop (*) are bigger than an Intel NUC, but tiny compared to anything else. Skimming Dell’s manual, I see a 2.5″ SATA bay inside. I also see what looks like a M.2 slot on a picture of its mainboard, but M.2 isn’t called out in the manual as a storage option. I see a gigabit Ethernet port and it accepts power from a DC barrel jack, so there’s a possibility it can be persuaded to run on battery power.
  • Optiplex 790 USFF Desktop (*) are significantly larger. Packing an optical drive on top of a 2.5″ drive bay and AC power supply. No robot battery power for this machine, but dual 2.5″ drives are possible via an optical drive caddy. This could work for TrueNAS replication target if my storage drive is a high capacity 2.5″ laptop hard drive.
  • Optiplex 3020 SFF Slim Desktop (*) is a successor to the Optiplex 960 I repurposed to a TrueNAS replication target, with at least one 3.5″ drive bay and one optical drive bay. This would be my default choice if I need to build another replication target machine.

What if I want a parallel port for LinuxCNC? Sadly, that’s an uncommon enough request I can’t filter on Amazon. But when it comes to refurbished small Dell PCs, Amazon Renewed is not the only game in town. There are plenty of other vendors like PC Liquidations, who offers filtering by parallel port. Resulting in a list of refurbished Dell Optiplex with parallel port starting at, you guessed it, a few dollars under $90. All good options if I want to dedicate a cheap PC to a task, which usually also requires me to set up automatic software updates.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Window Shopping: GMKtec NucBox3 Mini PC

A Newegg advertisement sent me down a rabbit hole of tiny little desktop PCs with full x86-64 processors. I knew about Intel’s NUC, but I hadn’t realized there was an entire product ecosystem of such small form factor machines built by other manufacturers. The one that originally caught my attention was distributed by several different companies under different names, I haven’t figured out who made it. But that exploration took me to GMKtec which is either their manufacturer, or a distributor with a sizable collection of similar products built by different manufacturers. The product that originally caught my attention is listed as their “NucBox5” (company website listing and Amazon link *) but I actually found their “NucBox3” (company website listing and Amazon link *) to be a more interesting candidate for my Sawppy Rover’s ROS brain. Both products have a Gigabit Ethernet wired networking port that I demand for resistance against RF interference, but beyond that, their respective designs differ wildly:

First the bad news: the NucBox 3 has an older CPU, the Celeron J4125 instead of the Celeron N5105. But comparing them side-by-side, it looks like I’d be giving up less than 10% of peak CPU performance. There is a huge (~50%) drop in GPU performance, but that doesn’t matter to Sawppy because most of the time its brain wouldn’t even have a screen attached.

A longer list of good stuff balances out the slower CPU:

  • RAM on the NucBox 3 is a commodity DDR4 laptop memory module. That can be easily upgraded if needed, unlike the soldered-in memory on the NucBox 5.
  • They both use M.2 SSDs for storage, but the NucBox 3 accommodates popular 2280 form factor instead of a less common 2245 size used by NucBox 5.
  • The SSD advantage was possible because NucBox 3 has a different shape: is wider and deeper than a NucBox 5, but not as tall. Designed for installation on a VESA 100×100 mount, it will be easier to bolt onto a rover chassis.
  • Officially, NucBox 3 is a fan-less passively cooled machine whereas the NucBox 5 has a tiny little cooling fan inside. (Which I expect to be loud, as tiny cooling fans tend to be.) Given that these are both 10W chips, I doubt NucBox 3 has a more effective cooling solution, I think it is more likely that the design just lets the chip heat up and throttle itself to stay within thermal limits. This would restrict its performance in stock form, but it also means it’ll be easy for me to hack up a quiet cooling solution if necessary.
  • NucBox 5 accepts power via USB-C, which is getting easier and easier to work with. I foresaw no problems integrating it with battery power onboard a Sawppy rover. But the NucBox 3 has a generic 5.5mm barrel jack for DC input power, and I think that’ll be even easier.

A NucBox3 costs roughly 80% of a NucBox5 for >90% of the performance, plus all of the designed tradeoff listed above are (I feel) advantages in favor of the NucBox3. I’m sold! I placed an order (*) and look forward to playing with it once it arrives.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Window Shopping: Mystery Mini PC of Many Names

An interesting item came to my attention via Newegg marketing mailing list for discounts: an amazingly tiny Windows PC. My attention was captured by listing picture showing its collection of hardware ports. Knowing the size of an Ethernet port and HDMI port we can infer this is an itty-bitty thing. Newegg’s specific sale item was generically named “Mini PC” with an asking price of $200. I’m not entirely sure the thing is real: all the images look perfect enough I couldn’t tell if they’re 3D renderings or a highly retouched product photos.

I looked at the other listings by the same vendor “JOHNKANG” and saw several other generically named devices ranging from laptops to external monitors. There were no other similar products, so I think JOHNKANG is a distributor and not the manufacturer of this palm-sized wonder. If JOHNKANG is a US distributor for such merchandise, I guessed they probably have an Amazon listing as well. Sure enough, they have it listed on Amazon also at $200(*) at time of writing. Unlike the Newegg listing, the Amazon listing included this exploded-view diagram showing internals and capabilities.

That’s… pretty darned good for $200! With an Intel Celeron N5105 processor, I see a machine roughly equivalent to capabilities of a budget laptop but without the keyboard, screen, or battery. Storage size is serviceable at 256GB and can be swapped out with another M.2 SSD, though in a less common 2242 format which is shorter than the popular 2280. Its 8GB of RAM are soldered and not easily expandable, but 8GB is more than sufficient for this price point.

A few features distinguish this tiny PC from equivalent-priced laptops, starting with its dual HDMI port where laptops only have one. That might be important for certain uses, but I’m more interested in its wired Gigabit Ethernet port and that it runs on USB-C power input. This machine appears to check off all of my requirements for a candidate Sawppy Rover brain. It’s a pretty good candidate for running ROS slotting just below an Intel NUC in capability but compensates for that with a lower price and smaller physical size. Heck, at this size it is starting to compete with Raspberry Pi and might even fit in a Micro Sawppy.

I found no make or model number listed, which is consistent with a distributor that really doesn’t want us to comparison shop against anyone else who might be distributing the same product for less money. If I want hard details, I might have to buy one and look over the hardware for hints as to who built it. Still, searching for “Mini PC” and “MiniPC” with N5105 CPU found this eBay listing of a used unit with Rateyuso branding. Then I found this AliExpress listing with ZX01 as model name. That AliExpress listing is a mess, showing pictures of several other different mini PCs. Not confidence inspiring and definitely turned me off of buying from that vendor. However, the “ZX01” model name was useful because it led me to this page, which linked to a Kickstarter project that has apparently been taken down due to intellectual property dispute.

Performing an image search using the suspiciously perfect picture/render found the GMKtec Nucbox5(*) which appears to be the same product but with “GMKtec” stamped on top. Looking at the Amazon storefront for GMKtec (*) I see many other small form factor PCs without any family resemblance between their industrial designs. My hypothesis is that GMKtec is a distributor as well, but they have built up a collection of products from different manufacturers and that’s why they all look different. I thought this was encouraging. It implies experience and knowledge with the ecosystem of tiny PCs, offering a breadth of products each making a different tradeoff. I looked over their roster and found one more to my taste.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Window Shopping DFRobot AS7341 Board

I’m intrigued by the AMS AS7341 11-channel spectral color sensor, and I’ve reached the limits of what I can learn from its (somewhat disappointing) datasheet and application note documentation. It’s time to get some hands-on experience with the device, which hopefully would help me understand more of the documentation in a positive feedback cycle. Plus I just want to start playing with it.

I could buy the sensor chip itself from Digi-Key, which has published a product page highlighting AS7341. Cost is reasonable for single quantities ($11.42 at time of writing) but at 3.1mm x 2mm x 1mm it is far too small for me to handle directly. I need a breakout board. The most obvious choice is AMS’ own evaluation kit, but that is priced far too high ($189.38) for me to stomach. Thankfully there are other companies providing AS7341 breakout boards for electronics hobbyists like myself.

DFRobot is one of these companies, and it has not one but two AS7341 offerings that differ by physical interface. Product SEN0364 has connectivity via DFRobot’s “Gravity” connector. Its sibling product SEN0365 has generic 0.1″ pitch breadboard-compatible headers. They both have mounting holes and voltage level shifters/converters for both signal and power interface with 3.3V and 5V parts. (AS7341 itself is a 1.8V part.) The Gravity port only has I2C communication, but the 0.1″ header version also break out INT (optional signal for “reading complete”) and GPIO (optional signal for “start reading”). Both include a pair of white LEDs for illumination controlled by AS7341 LDR pin, but that also meant LDR was not brought out so we can’t use it to control external lights.

On the software front, DFRobot provides an Arduino library and several example projects. I thought their household lights comparison test was very interesting, using an AS7341 to show difference in emission spectra of various household lights. I understood the spectral plots, but they lost me when the math started going into CIE color spaces like the AMS calibration data sheet did. The biggest problem with this example project is that its online listing is incomplete: the Arduino sketch for interfacing with AS7341 is listed, but the Processing sketch was missing. It plots results on a desktop computer screen and screenshots were included in the project writeup. Without it we’d just have a bunch of numbers in a serial terminal. It shouldn’t be too hard to recreate using Processing’s Serial library if one felt motivated to do so. Still, its absence was annoying.

Interesting but incomplete example projects won’t change the fact DFRobot SEN0364 and SEN0365 seem like reasonable options for AS7341 breakout boards. Another option for AS7341 breakout board is Adafruit product #4698, which is what I eventually bought for myself.

Roger Cheng

Window Shopping RATTMMOTOR CNC Controller with Digital Dream

I determined that a Mach 3 CNC pendant wasn’t going to work in LinuxCNC with merely configuration file changes, so I started looking at other pendant options. I found this bare-bones option(*) that had only a few controls and no display screen, and almost every single function is broken out into its own physical wire. This fits very well with the LinuxCNC model built on the idea every I/O is a pin. Even when it’s not literally a pin on a parallel port, there’s a logical pin underneath for LinuxCNC configuration.

And while looking at these pendants designed for hard wiring, I found a controller that bundles such a pendant with a complete self-contained CNC controller unit. It is more capable than Grbl on an Arduino, but less than full LinuxCNC on a PC. It calls itself an offline motion controller system(*), running software from Digital Dream Automation. At a quoted maximum pulse rate of 500 kHz, it significantly outperforms Arduino Grbl which is reported to top out at around 30 kHz. This unit can also read G-Code from a USB flash drive, eliminating the need to have a separate computer running some sort of G-Code sender program to Grbl. A nice self-contained (I guess that’s what they meant by “offline”?) system.

Minor problem: G-code visualization options on such a little screen seems to be limited to 2D plots, giving up one of three axes. I’ve seen old CNC with the same limitation so it’s not a huge deal, but it is less than what we can do with modern PC-based systems.

Moderate problem: How would I generate G-code for these units? This particular unit’s owner’s manual explains firmware updates would be downloaded from ddcnc.com, and that’s how I found Digital Dream and presumably they are the author of software running on these units. Unfortunately, a quick search for Digital Dream on Fusion 360 post processor library came up empty. I don’t know how owners of DDCNC-based controllers like this one generates their G-code programs. The user manual has a list of supported commands, but I’m not familiar enough with the various styles to recognize if DDCNC uses the same set of code as something else.

Major problem: Buying such a product instead of setting up LinuxCNC comes with a drawback: I can’t dig into the code and learn how CNC controllers work under the hood. And that is the primary point of my CNC controller explorations. If someone asks me for a ready-made upgrade over Grbl on Arduino or ESP32, I’m happy to let them know these controllers exist. But for myself, I’ll resume my LinuxCNC explorations.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Window Shopping: Cutra Wondercutter Ultrasonic Knife

During an online video meetup with some makers, I learned that consumer-level ultrasonic knives exist. One member of the meetup was taking theirs apart for some reason I’ve now forgotten, I just remembered his quick demo of the handheld cutting blade cutting through a 3mm thick sheet of acrylic. It wasn’t exactly “hot knife through butter” (maybe cold knife through refrigerated butter) but certainly far superior to what I could do with my X-Acto #11 blade.

I had known of ultrasonic tools in the medical field, specifically dental tools. I also had some idea they existed in the realm of industrial manufacturing equipment. But something I could conceivably buy for my own workbench? That’s news to me. Unfortunately, the person on the video wasn’t able to give me much information to go on, so I started searching for “ultrasonic knife” from my usual list of tool vendors. Unsurprisingly, I got a hit at McMaster-Carr: Item #3415N11 Fast-Cutting Ultrasonic Precision Knife. Visually, this looks like the same device I saw being disassembled at the meetup. But McMaster-Carr didn’t give me very much information on this device, not even some things I consider basic like make and model for further evaluation.

A search for “Ultrasonic Knife” on Amazon would give me several multi-thousand-dollar industrial machines, and also this listing. (*) Titled “The Wondercutter S” it looks right, but this listing felt odd for several reasons. The brand is listed as “MICRO-MAKE” but there’s nothing else by that brand name. There is also a logo on the device absent from the McMaster-Carr listing. It is stylized so I couldn’t quite decipher it to letters, but it is definitely neither “Wondercutter” or “MICRO-MAKE”. This listing didn’t give me the confidence I needed to commit several hundred dollars, despite Amazon Prime guarantees.

Continuing online search, I also got a hit at Home Depot which was a mild surprise. I had not associated the big orange DIY home improvement store with high tech tools. From this listing I got a brand name “CUTRA” which explains the stylized logo I couldn’t read earlier.

Now that I have a brand name, I found its company site and their own product site. It appears to be a Korean company and I finally got the specifications I could sink my teeth into. There were also a lot of demonstrations videos on what this device could do, the one that got my attention was cleaning up supports for 3D printing. I’ve never enjoyed cleaning up supports, and I’ve had a few dangerous close calls with my trusty X-Acto blade doing so. A couple of hundred dollars is a significant investment, but if it saves me a single hospital visit that would make the item worthwhile.

From this site I also learned that Wondercutter was crowdfunded as an Indiegogo project back in 2017. Well, I definitely missed the early bird backer special of $258 USD! I just have to pay retail now. Elsewhere on the site I saw I could order direct from Korea, but they have signed an official distributor for United States: Micro-Mark. Now this is a name I know from my scale plastic model days! I used to be a very good Micro-Mark customer buying Tamiya paints (they’ve all since dried out) and small model-building hand tools (I still use some of them).

Well, at least this explains the mystery branding of “Micro-Make” on that Amazon listing, it was a typo of Micro-Mark. There is actually a Micro-Mark storefront on Amazon (*), but with only a subset of the full catalog. For example, they sell replacement Wondercutter blades (*) but they don’t sell the Wondercutter itself on Amazon. Why would they leave it open for an imposter vendor to take away potential Amazon sales? That’s a curious business decision. Micro-Mark claims to be the exclusive distributor for North America, and I can see they are listed as vendors on sites like Walmart. But I’m not sure what’s the point of going through Walmart (or Home Depot or Amazon) if Micro-Mark is actually the distributor. It seems to make more sense to order one direct from Micro-Mark’s own website.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Window Shopping LovyanGFX

One part of having an open-source project is that anyone can offer their contribution for others to use in the future. Most of them were help that I was grateful to accept, such as people filling gaps in my Sawppy documentation. But occasionally, a proposed contribution unexpectedly pops out of left field and I needed to do some homework before I could even understand what’s going on. This was the case for pull request #30 on my ESP_8_BIT_composite Arduino library for generating color composite video signals from an ESP32. The author “riraosan” says it merged LovyanGFX and my library, to which I thought “Uh… what’s that?”

A web search found https://github.com/lovyan03/LovyanGFX which is a graphics library for embedded controllers, including ESP32. But also many others that ESP_8_BIT_composite does not support. While the API mimics AdafruitGFX, this library adds features like sprite support and palette manipulation. It looks like a pretty nifty library! Based on the README of that repository, the author’s primary language is Japanese and they are a big fan of M5Stack modules. So in addition to the software technical merits, LovyanGFX has extra appeal to native Japanese speakers who are playing with M5Stack modules. Roughly two dozen display modules were listed, but I don’t think I have any of them on hand to play with LovyanGFX myself.

Given this information and riraosan’s Instagram post, I guess the goal was to add ESP_8_BIT composite video signal generation as another supported output display for LovyanGFX. So I started digging into how the library was architected to enable support for different displays. I found that each supported display unit has corresponding files in the src/lgfx/v1/panel subdirectory. Each of which has a class that derives from the Panel_Device base class, which implements the IPanel interface. So if we want to add a composite video output capability to this library, that’s the code I expected to see. With this newfound knowledge, I returned to my pull request to see how it was handled. I saw nothing of what I expected. No IPanel implementation, no Panel_Device derived class. That work is in the contributor’s fork of LovyanGFX. The pull request for me has merely the minimal changes needed to ESP_8_BIT_composite to be used in that fork.

Since those changes are for a specialized usage independent of the main intention of my library, I’m not inclined to incorporate such changes. I suggested to riraosan that they fork the code and create a new LovyanGFX-focused library (removing AdafruitGFX support components) and it appears that will be the direction going forward. Whatever else happens, I now know about LovyanGFX and that knowledge would not have happened without a helpful contributor. I am thankful for that!

Roger Cheng

Window Shopping Roku IDK (Independent Developer Kit)

I’ve been given a pair of Roku streaming devices that were retired from a friend’s household, as they knew I like to take things apart to look inside. Before I do that, though, I briefly investigated what might be fun to do with intact and functional Roku devices. I was quite pleasantly surprised to learn that Roku has recently (announcement dated October 26th, 2021) released an Independent Developer Kit (IDK) for hobbyists to play with Roku hardware. This is different from their official Software Development Kit (SDK), which is available to companies like Netflix to create their Roku apps (“channels”). Many other differences between the IDK and SDK are explained in their IDK FAQ.

The Roku SDK requires a business partnership with Roku, but the IDK is available to anyone who is willing to work at low level in C++ and has a Linux development machine available to the task. No direct support for Windows or MacOS, but as the resulting binary is uploaded through a web interface, theoretically a Linux virtual machine could be used to run these tools. The list of example apps hint at what is accessible through the IDK: the OpenGL ES API, interface to the Roku remote control, interface for audio playback, and interface for video playback. (Including Wildvine DRM-protected content.) And it sounds like an IDK app has pretty complete control of the machine, as only one IDK can be installed at any given time. If it takes over the Roku shell, that implies control over the entire system even greater than possible with SDK-developed Roku channels.

But I couldn’t test that hypothesis due to the final requirement: a Roku device with IDK support. A chart listing all Roku hardware has a row for “IDK Support” and the old devices I’ve been gifted are both shown as “No”. If I really want to play with the Roku IDK, I’d have to go out and buy my own Roku device with a “Yes” listed on that chart. At the moment I don’t see the advantage of buying Roku hardware for this purpose. On the surface Roku IDK appears less compelling than developer support available on Google Chromecast or Amazon Fire TV devices. Or for ultimate openness, we can go with a Raspberry Pi. Maybe I’ll find a reason for Roku projects in the future, in the meantime these two old devices without IDK support will be disassembled. Starting with the smaller streaming stick.

Roger Cheng

Window Shopping Home Assistant

I learned about Home Assistant in a roundabout way, but once I started looking at it, I saw an interesting new tool I want to add to my toolbox. It started off on my good side with description on the project’s home page: “Open source home automation that puts local control and privacy first.” I like everything about that sentence and the tone it sets for the project.

I was once very interested in the promises of having a “smart home” and I was one of the early adopters of a Nest thermostat. (Before they were acquired by Google.) However, several years of Nest thermostat ownership also soured me on the concept of home automation via cloud services. Every once in a while, a server I never knew existed goes down and I get an error message on my Nest. To Nest’s credit, when their backend goes offline the thermostat continues running the last program it remembers. So it would never be worse than a “dumb” thermostat. Unfortunately not all “smart home” devices has such a graceful failure mode. For example whenever AWS us-east-1 suffers an outage, I would read about people not being able to get into their house because their Alexa-enabled smart lock wouldn’t unlock. If my smart home fails, I want it to be my own fault.

With an aversion to this class of failure, I have not bought any more Nest devices and became cool to the whole smart home concept. But maybe that will change if I could have local control and execution, and that is something Home Assistant offers. This also means any data is stored on my home server instead on somebody else’s AWS/Azure/GCP instance. It is popular for people to run on a Raspberry Pi dedicated to the purpose, but I could also run it in a Docker container on my home server as I’ve been doing for many other software pieces in this project.

While I intend to start playing with Home Assistant with DIY nodes built from ESP8266/ESP32, it offers integration with many home automation systems beyond those running ESPHome. It can even integrate with Google Nest, Amazon Alexa, and the like. But there’s a catch: to integrate with cloud-based services I would then have to either (1) open my instance of Home Assistant to the internet, or (2) use Nabu Casa’s cloud-hosted Home Assistant service.

In the near term that would not be a problem because I’m going to leave my Nest as-is. Until I’m more comfortable with the system, I’m not going to let Home Assistant control anything with drastic failure modes like locking me out of my house. I’m going to start simple and keep stakes low.

Roger Cheng

Learned About Home Assistant From ESPHome Via WLED

I thought Adafruit’s IO platform was a great service for building network-connected devices. If my current project had been something I wanted to be internet-accessible with responses built on immediate data, then that would be a great choice. However, my current intent is for something locally at home and I wanted the option to query and analyze long term data, so I started looking at Home Assistant instead.

I found out about Home Assistant in a roundabout way. The path started with a tweet from GeekMomProjects:

A cursory look at WLED’s home page told me it is a project superficially similar to Ben Hencke’s Pixelblaze: an ESP8266/ESP32-based platform for building network-connected projects that light up individually addressable LED arrays. The main difference I saw was of network control. A Pixelblaze is well suited for standalone execution, and the network interface is primarily to expose its web-based UI for programming effects. There are ways to control a Pixelblaze over the network, but they are more advanced scenarios. In contrast, WLED’s own interface for standalone effects are dominated by less sophisticated lighting schemes. For anything more sophisticated, WLED has an API for control over the network from other devices.

The Pixelblaze sensor board is a good illustration of this difference: it is consistent with Pixelblaze design to run code that reacts to its environment with the aid of a sensor board. There’s no sensor board peripheral for a WLED: if I want to build a sensor-reactive LED project using WLED, I would build something else with a sensor, and send commands over the network to control WLED lights.

So what would these other network nodes look like? Following some links led me to the ESPHome project. This is a platform for building small network-connected devices using ESP8266/ESP32 as its network gateway, with a library full of templates we can pick up and use. It looks like WLED is an advanced and specialized relative of ESPHome nodes like their adaptation of the FastLED library. I didn’t dig deeper to find exactly how closely related they are. What’s more interesting to me right now is that a lot of other popular electronics devices are available in the ESPHome template library, including the INA219 power monitor I’ve got on my workbench. All ready to go, no coding on my part required.

Using an inexpensive ESP as a small sensor input or output node, and offload processing logic somewhere else? This can work really well for my project depending on that “somewhere else.” If we’re talking about some cloud service, then we’re no better off than Adafruit IO. So I was happy to learn ESPHome is tailored to work with Home Assistant, an automation platform I could run locally.

Roger Cheng

Window Shopping: Adafruit.IO

I have an ESP8266 I wanted to use to with an INA219 chip as the voltage and current monitor for my toy solar panel array. The logged data can be visualized for curiosity, or maybe analyzed and that information fed into something in the future. I started with Arduino IDE, then moved to ESP-IDF on an ESP32, and most recently I played with MicroPython. This was a fun trip exploring the foundational elements, but looking towards the future I see a lot of software work to build this into a system and my interest started to fade.

What if somebody else has already built the infrastructure for something like this? Well, since I was on Adafruit’s INA219 page I saw that they had built one called Adafruit IO. Right up on the landing page it says: “We do the hard work so you can focus on the fun stuff.” Hey, I like the sound of that!

And in typical Adafruit fashion, they have great support for the product interoperating with a wide range of hardware. Including the ESP8266 and INA219! (Though via the Arduino platform and not their CircuitPython platform as they’ve dropped support for ESP8266 CircuitPython.) Data is logged, stored, easy dashboards for visualization, and that data feeds into programmable triggers to take action in response to date. Everything I foresaw having to build but is already here and ready to go. And the price is reasonable: free to start with limited functionality, and $10/mo to upgrade for full functionality.

This looks amazing but I decided against it, because I wanted something purely for consumption at home. I wouldn’t call myself averse to internet applications. After all, I’ve put all my code on GitHub and my project notebook is publicly readable. (You’re reading it right now.) Running some things on the internet makes sense when the intent is for access from anywhere, but for my home projects I don’t want that data to leave the house.

Also, Adafruit IO only retains data for a limited time period. From what I can see this was 30 days during the beta and the duration is something they reserve the right to change. I can’t seem to find their current data retention policy but it really doesn’t matter. Their target usage scenario is for “right now” interaction and projects like long-term historical tracking and analysis is out of scope. I want the option to store that data for longer, and to do it at home, so I passed on Adafruit IO and started looking for another solution.

Roger Cheng

Investigating TI TPS61187 WLED Driver

I took apart a LG LCD panel LP133WF2(SP)(A1) hoping to salvage something useful. After I failed to salvage the polarizer film, my hope lies with the backlight module. Its diffuser had a multi-layer construction I didn’t understand but found fascinating and wanted to see it light up firsthand. And if I am to do that, I need to figure out how to send power to the backlight LEDs. When I split the panel into the display and backlight modules, I saw the backlight was connected by a ribbon cable with seven conductors. Six of them look identical, and the seventh was wider than the rest, making it a good candidate for either a common anode or a cathode. Which is it, though? For that I looked for hints on the display panel’s integrated driver board.

There were three significant-looking ICs on board. The largest is closest to the connector to the rest of the laptop and the top two lines written on it were “LG Display ANX2804”. I found no information on this chip online. In the middle of the circuit board is another IC, this one labeled “SM4037 DA1422 AMER038”. I found no information on this particular designation, either. (There exists a SM4037 from Fairview Microwave, but it is a connector and not a microchip.) That leaves the chip closest to the backlight connector as the best candidate for a LED driver, and luckily its markings of TPS 61187 match that of a Texas Instruments WLED driver. I think this is it.

Reading its publicly available datasheet reinforced it is the right result, as its “typical application” diagram shows the chip driving six parallel strings of LEDs. The schematic indicates the six strings are connected to a common anode with their own individual cathodes wired to one of six current sinks on the chip. This information is enough for me to wire up this array to my bench power supply to find the right voltage for this string and create my own LED driver circuit. But since I have the datasheet already on hand and a “I know it used to work” backlight control board, I kept reading to see if I could perhaps reuse the board as well.

It looks pretty promising. There are no handshake or control protocol involved, all the potential configurations for this chip are done via resistance values to certain pins which would be already present in this case. I think for a bare minimum setup I only need to provide a power source and a PWM signal to control brightness. I could also connect the enable pin but I think I could get away with using a pull-up resistor. And under this minimalist plan I would be ignoring the fault signals. Plus one very important lesson about its power supply I had to learn first.

Roger Cheng

Window Shopping: LVGL

I have the color composite video generation code of ESP_8_BIT repackaged into an Arduino display library, but right now the only interface is a pointer to raw frame buffer memory and that’s not going to cut it on developer-friendliness grounds. At the minimum I want to match the existing Arduino TVout library precedent, and I think Adafruit’s GFX Library is my best call, but I wanted to look around at a few other options before I commit.

I took a quick look at FabGL and decided it would not serve for my purpose, because it seemed to lack the provision for using an external output device like my code. The next candidate is LVGL, the self-proclaimed Light and Versatile Graphics Library. It is designed to run on embedded platforms therefore I was confident I could port it to the ESP32. And that was even before I found out there was an existing ESP32 port of LVGL so that’s pretty concrete proof right there.

Researching how I might adapt that to ESP_8_BIT code, I poked around the LVGL documentation and I was pleased it was organized well enough for me to quickly find what I was looking for: Display Interface section in the LVGL Porting Guide. We are already well ahead of where I was with FabGL. The documentation suggested allocating at least one working buffer for LVGL with a size at least 1/10th that of the frame buffer. The porting developer is then expected to register a flush callback to copy data from that LVGL working buffer to the actual frame buffer. I understand LVGL adopted this pattern because it needs RAM on board the microcontroller core to do its work. And since the frame buffer is usually attached to the display device, off the microcontroller memory bus, this pattern makes sense. I had hoped LVGL would be willing to work directly with the ESP_8_BIT buffer, but it doesn’t seem to be quite that friendly. Still, I can see a path to putting LVGL on top of my ESP_8_BIT code.

As a side bonus, I found an utility that could be useful even if I don’t use LVGL. The web site offers an online image converter to translate images to various formats. One format is byte arrays in multiple pixel formats, downloadable as C source code file. One of the pixel formats is the same 8-bit RGB332 color format used by ESP_8_BIT. I could use that utility to convert images and cut out the RGB332 section for pasting into my own source code. This converter is more elegant than that crude JavaScript script I wrote for my earlier cat picture test.

LVGL offers a lot of functionality to craft user interfaces for embedded devices, with a sizable library of control elements beyond the usual set of buttons and lists. If sophisticated UI were my target, LVGL would be an excellent choice. But I don’t really expect people to be building serious UI for display on an old TV via composite video, I expect people using my library to create projects that exploit the novelty of a CRT in this flat panel age. Simple drawing primitives like draw line and fill rectangle is available as part of LVGL, but they are not the focus. In fact the Drawing section of the documentation opens by telling people they don’t need to draw anything. I think the target audience of LVGL is not a good match for my intended audience.

Having taken these quick looks, I believe I will come back to FabGL if I wanted to build an ESP32 device that outputs to VGA. If I wanted to build an embedded brain for a device with a modern-looking user interface, LVGL will be something I re-evaluate seriously. However, when my goal is to put together something that will be quick and easy to play with throwing something colorful on screen over composite video, neither are a compelling choice over Adafruit GFX Library.

Roger Cheng

Window Shopping: FabGL

I have a minimally functional ESP32 Arduino display library that lets sketches use the color composite video signal generator of ESP_8_BIT to send their own graphics to an old-school tube TV. However, all I have as an interface is a pointer into the frame buffer. This is fine when we just need a frame buffer to hand to something like a video game console emulator, but that’s a bit too raw to use directly.

I need to put a more developer-friendly graphics library on top of this frame buffer, and I have a few precedents in mind. It needs to be at least as functional as the existing TVout Arduino library, which only handles monochrome but does offer a minimally functional graphics API. My prime candidate for my purpose is the Adafruit GFX Library. That is the target which contenders must exceed.

I’m willing to have an open mind about this, so I decided to start with the most basic query of “ESP32 graphics library” which pointed me to FabGL. That homepage loaded up with a list of auto-playing videos that blasted a cacophony of overlapping sound as they all started playing simultaneously. This made a terrible first impression for no technical fault of the API itself.

After I muted the tab and started reading, I saw the feature set wasn’t bad. Built specifically for the ESP32, FabGL offers some basic user interface controls, a set of drawing primitives, even a side menu of audio and input device support. On the display side (the reason I’m here) it supports multiple common display driver ICs that usually come attached to a small LCD or OLED screen. In the analog world (also the reason I’m here) it supports color VGA output though not at super high color depths.

But when I started looking for ways to adapt it to some other display mechanism, like mine, I came up empty handed. If there is provision to expose FabGL functionality on a novel new display like ESP_8_BIT color composite video generator, I couldn’t find it in the documentation. So I’ll cross FabGL off my list for that reason (not just because of those auto-playing videos) and look at something else that has well-documented ways to work on an external frame buffer.

Roger Cheng

Miha Kocar’s ESP8266 Remote Control

Getting basic voltage monitoring up and running on my Sawppy Rover ESP32 controller was a good milestone for me to take a break from rover work. My code is publicly available up on GitHub and it is even moderately well organized and commented if anybody else wants to take it for a spin. Either for their own Sawppy rover, or for another vehicle. But if someone just wants basic remote control, they don’t have to deal with my code. There’s a simpler and cheaper option: Miha Kocar’s browser-based WiFi remote control built from an ESP8266.

I learned of this project via Hackaday and I consulted it briefly before starting my own Sawppy rover control project. I thought it was admirably minimalist. The entire baseline 2-channel implementation fits in a single file. The browser HTML, CSS, and JavaScript are all encapsulated into a single C string inside that file. Compared to my sprawling project, that is amazingly compact!

One of the ways this could be so simple were the input controls: this project used the existing HTML <input type="range"> control for controlling each axis, which meant it inherited all the code dealing with pointer events. Creative CSS styling made it look very different from a boring HTML form input. The downside is that each of these controls can only manage a single axis, there’s no good way to do a two-axis control pad as I wanted. Having two separate single-axis controls meant two-finger operation, my two-axis control pad allows single-finger operation. This feature was important enough for me to take on the extra complexity, something I occasionally regretted but I think it’s worth the extra work.

Kocar’s project uses websocket for client-server communication, and the code looked super simple and easy. Seeing it removed a lot intimidation for me when I started using websocket for myself. Like my code, it has a “failsafe” mode for when communication is lost, but I didn’t see any code enforcing a single driver.

The biggest reason I didn’t use this project as a direct precedent was that ESP8266 didn’t have a hardware PWM peripheral. These servo control PWM signals are all generated in software. This is fine for one or two channels like we see here, but Micro Sawppy required upwards of 16 PWM channels and that’s too much to expect from an ESP8266, which didn’t have enough IO pins anyway. I needed the PWM hardware — and GPIO pins— of an ESP32.

The next reason was that I much preferred FreeRTOS and how it allowed me to organize individual functionality into tasks. Instead of managing it all myself in a single Arduino loop(), I have the FreeRTOS task scheduler handle things. Information flow between components are managed with FreeRTOS queues. From a personal preference point, I liked having this level or organization.

But I admit all the overhead I added to handle a six-wheel-drive, four-wheel-steering micro Mars rover would be sheer overkill for many other projects. Sometimes a project just need a simple straightforward two-channel remote control, and Miha Kocar’s project is a better tool for that job.

And as a change of pace from my little micro Mars rover, I started looking at a tool for an entirely different job: putting a color picture on an old analog television.

Roger Cheng

Window Shopping DRV8833 DC Motor Control IC

It was a pure accident that I stumbled across the DRV8833 DC motor control IC. After a quick comparison against my original candidate TB6612 I think some DRV8833 modules might actually the better choice for my micro Sawppy rover project. Its required control signals are an ideal fit for the MCPWM peripheral on the ESP32 I planned as my rover brain. Though note not all models of the ESP32 line has MCPWM peripherals, for example it appears to be absent from the ESP32-S2.

The DRV8833 is less capable than the TB6612 in some ways. For example, the maximum voltage is listed as 10.8V which is lower than the 15V listed for TB6612, and far short of the 45V listed for a L298. But TT gearmotors are typically listed with a maximum voltage of 6V, so I should be fine. I was surprised that the amperage rating isn’t much lower, with 1.5A typical and 2A peak that should suffice for TT gearmotors. And if I need additional current carrying capacity, the DRV8833 is explicitly stated to be capable of both output stages working in parallel to double the maximum current. The L298 datasheet also explicitly listed parallel operation as an option, but the TB6612 did not.

Like the L298, the DRV8833 has provisions for current-sensing resistors between AISEN and BISEN pins to ground. But unlike the L298, the DRV8833 will actually read their voltage to limit maximum current output. The current-sensing resistors are a whole world into themselves. They work best when placed close to the IC because that minimizes variation introduced by PCB traces. But if they are close, they will be in close proximity to heat generated by the IC, which will change their resistance. Quite a few variables need to be juggled for it to work right, so I’ll probably choose to opt out of current limiting and connect those pins to ground. Fortunately the chip’s own overcurrent protection circuit works independently and will activate with or without external current-sensing resistors.

All four control pins, two for each stage, have internal pull-down resistors. Thus this chip is always in a defined state and we don’t have to worry about any particular startup sequence. Whether power arrives first or control signals arrive first, the chip will work in a known way. There are two more input pins, one to control sleep and another to signify fault. The fault signal is open-drain which would make it compatible with a lot of different circuits, but I might not have ESP32 input pins to spare for detecting fault conditions. I won’t worry about low-power sleep (at least not yet) for micro Sawppy, and in that case the recommended procedure is to pull it up with a 25-75kOhm resistor.

In addition to that optional resistor, there are three required capacitors, but no external diodes are required. Looks like the diodes to handle back-EMF from inductive loads are built in which is great news. It makes for a pretty short list of external support components, but I still don’t plan to use the chip directly. The first reason is that I have many options for breakout boards. From high quality Adafruit #3297 to the lowest bidder of the day on Amazon.(*) For low quantities it’s worth a few extra bucks to pay for an already-assembled breakout board.

The second reason is that I can’t meet proper installation requirements for the more capable DRV8833 variants. As is typical, the DRV8833 is available in several chip package formats. I was surprised to see that one of them had a much lower rating for typical amperage, a third of the others. However, peak rating stayed the same, so I suspected it’s not a limitation of the chip itself. Further reading (section 10.3.1) confirmed that maximum current of a DRV8833 is a direct function of heat dissipation and the lower-rated chip package lacked a heat conduction pad present in the others. (TI calls it PowerPAD.) Thus soldering a DRV8833 correctly requires reflow soldering. I would have to pay someone else to handle it, or buy my own reflow setup, but that’s a concern for the future. Right now I can start with some cheap breakout boards.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

TB6612 Vs. DRV8833 DC Motor Driver ICs for ESP32 Micro Sawppy

While researching TB6612 DC motor driver IC breakout boards on Amazon, my results list actually had more breakout boards built around the DRV8833 (and claiming TB6612 compatibility) than actual TB6612 boards. So I tried performing an Amazon query for DRV8833(*) and saw I had far more options in that category. This may change in the future as worldwide silicon supply & demand varies, but that’s the situation as I type this. I didn’t explicitly set out to find yet another candidate to replace my L298 motor driver, but since I stumbled across it, I decided to spend a bit of time to take a closer look at the DRV8833 by Texas Instruments.

First things first: the claim of TB6612 control logic compatibility is wrong. Well, technically they are compatible for applications that are only interested in powering their motors only in full forward or full reverse, but that is not realistic. Such applications would not bother with a motor control IC and would directly use some MOSFETs or even relays instead. For real motor control applications, I’ve seen two different methods to interface with the classic L298 motor control IC. TB6612 is logic compatible with one method, DRV8833 is compatible with the other method, and they are not compatible with each other.

TB6612 requires three pins: two digital pins to control behavior (forward, backward, brake, or coast) and a PWM pin to control magnitude of that behavior. DRV8833 only accepts two pins to control behavior and modulation is done by rapidly pulsing one of those pins to switch between states. Partial throttle forward, for example, is done by rapidly switching between forward and coast states. DRV8833 does not have a dedicated PWM pin like the TB6612, and the closest counterpart to a L298’s ENABLE pin is the nSLEEP pin on a DRV8833 but that pin is unsuitable for modulating velocity. The first problem is that there’s only a single nSLEEP pin for both motors, and secondly waking up from sleep requires ~1ms making smooth motion difficult if not impossible.

In general, using two pins instead of three is an advantage when we are constrained by the number of pins available, and the ESP32 certainly has that problem. However, the tradeoff is that DRV8833 requires two pins capable of generating PWM signals per motor, whereas TB6612 only requires one. This would be a concern for microcontrollers with limited PWM peripherals, but the ESP32 literally has more PWM peripheral outputs than it has usable pins.

Looking specifically at my micro Sawppy rover application, the picture of pin allocation is not quite that straightforward as (2 pins * 6 wheels = 12 pins) versus (3 pins * 6 wheels = 18 pins). In typical operation, all the wheels on one side of the rover will be traveling in the same direction, so it is possible to share the direction control pins across three wheels on the same side of the rover, cutting it down to 10 pins instead of 18. Plus if I make the rover front-back symmetric I have an additional option to share the PWM control signal across front and rear wheels, which cuts pin count down to 8. But while DRV8833 can’t share pins across wheels on the same side, it can also benefit from front-back symmetry cutting its requirements down to 8 pins as well. A tie!

Clearly there are many tradeoffs I can make with motor driver arrangement and control, depending on how many PWM peripherals are on a particular microcontroller and how many pins it has to spare. For my first iteration I like the idea of having independent control over each wheel, even though right now I’m not sure how it would be useful. Once I get that working (or learn why I can’t) I’ll look into trading off independent control for reduced pin count. So the current plan of record is to use two PWM pins for each of six wheels, driving DRV8833 DC motor control ICs.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Window Shopping TB6612 DC Motor Driver IC

The cardboard backing for my latest experiment was never going to be the final arrangement, and neither are the L298 motor driver mounted using twist ties. I started experimenting with them because they were the classic, a known quantity, and widely available. But I would have expected technology to move on, and I found confirmation in this Hackaday article talking about the TB6612 motor driver IC as a replacement for those venerable L298.

I pulled up the data sheet published by manufacturer Toshiba because I wanted to learn where its specifications differed from the L298. As the article stated, this chip is not a direct drop-in replacement. In some respects this is good, for example the diodes to absorb back-EMF from inductive loads. The L298 required external support diodes, but the TB6612 has them built in, reducing parts count in our projects. In other respects the differences were limiting, such as a voltage range that only went up to 13.5V maximum which is far lower than the L298’s 45V. But since I’m looking to drive TT gearmotors which have a recommended voltage range of 3-6V, this limitation is not a problem here. And the smaller size of TB6612 would be quite welcome in a micro rover.

Examining the control signals, I see TB6612 allows us to specify motor direction using IN1 and IN2 pins. To control velocity, we send PWM signal to a pin explicitly named PWM. For applications that control a L298 using its IN1 and IN2 pins to control direction and control velocity by PWM controlling the enable (EN) pin, the TB6612 would be a direct logical replacement. However, my L298 breakout board tied EN to high by default implying speed control by PWM pulsing IN1 and IN2. I guess this is also valid for L298 but such a control scheme would not be compatible with TB6612.

Looking around, I can see the TB6612 used in a few other maker-friendly products including Adafruit product #1438 which is an Arduino motor shield built around this motor control chip. SparkFun #14451 offers it in a more compact breakout board instead of the Arduino shield form factor, Adafruit #2448 is another similar option. I haven’t built up my own equipment and skill to work with surface mount components directly, so I will need such breakout boards or pay someone else to assemble a board with it.

Examining my options on Amazon (*) I was surprised at how slim my selections were. Perhaps this is a temporary thing due to the current worldwide semiconductor shortage? Whatever the reason, the majority of my search results today were actually breakout boards for a different chip, the DRV8833, while claiming TB6612 compatibility. Since I’m in the research stage, I might as well take a look at that chip, too.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.