ArduinoMania

Cats are no respecters of personal property, as [Joe Mattioni] learned when one of his cats, [Layla] needed a special prescription diet. Kitty didn’t care for it, and since the other cat, [Foxy]’s bowl was right there– well, you see where this is going. To keep [Layla] out of [Foxy]’s food and on the vet-approved diet, [Joe] built an automatic feeding system with feline facial recognition. As you do.

The hardware consists of a heavily modified feed bowl with a motorized lid that was originally operated by motion-detection, an old Android phone running a customized TensorFlow Lite model, and hardware to bridge them together. Bowl hardware has yet to be documented on [Joe]’s project page, aside from the hint that an Arduino (what else?) was involved, but the write up on feline facial recognition is fascinating.

See, when [Joe] started the project, there were no cat-identifying models available– but there were lots of human facial recognition models. Since humans and cats both have faces, [Joe] decided to use the MobileFaceNet model as a starting point, and just add extra training data in the form of 5000 furry feline faces. That ran into the hurdle that you can’t train a TFLite model, which MobileFaceNet is, so [Joe] reconstructed it as a Keras model using Google CoLab. Only then could the training occur, after which the modified model was translated back to TFLite for deployment on the Android phone as part of a bowl-controller app he wrote.

No one, [Joe] included, would say that this is the easiest, fastest, or possibly even most reliable solution– a cat smart enough not to show their face might sneak in after the authorized feline has their fill, taking advantage of a safety that won’t close a bowl on a kitty’s head, for example–but that’s what undeniably makes this a hack. It sounds like [Joe] had a great learning adventure putting this together, and the fact that it kept kitty on the proper diet is really just bonus.

Want to go on a learning adventure of your own? Click this finely-crafted link for all the details about this ongoing contest.

We wrote up a video about speeding up Arduino code, specifically by avoiding DigitalWrite. Now, the fact that DigitalWrite is slow as dirt is long known. Indeed, a quick search pulls up a Hackaday article from 2010 demonstrating that it’s fifty times slower than toggling the pin directly using the native pin registers, but this is still one of those facts that gets periodically rediscovered from generation to generation. How can this be new again?

First off, sometimes you just don’t need the speed. When you’re just blinking LEDs on a human timescale, the general-purpose Arduino functions are good enough. I’ve written loads of useful firmware that fits this description. When the timing requirements aren’t tight, slow as dirt can be fast enough.

But eventually you’ll want to build a project where the old slow-speed pin toggling just won’t cut it. Maybe it’s a large LED matrix, or maybe it’s a motor-control application where the loop time really matters. Or maybe it’s driving something like audio or video that just needs more bits per second. One way out is clever coding, maybe falling back to assembly language primitives, but I would claim that the right way is almost always to use the hardware peripherals that the chipmakers gave you.

For instance, in the end of the video linked above, the hacker wants to drive a large shift register string that’s lighting up an LED matrix. That’s exactly what SPI is for, and coming to this realization makes the project work with timing to spare, and in just a few lines of code. That is the way.

Which brings me to the double-edged sword that the Arduino’s abstraction creates. By abstracting away the chips’ hardware peripherals, it makes code more portable and certainly more accessible to beginners, who don’t want to learn about SPI and I2C and I2S and DMA just yet. But by hiding the inner workings of the chips in “user friendly” libraries, it blinds new users to the useful applications of these same hardware peripherals that clever chip-design engineers have poured their sweat and brains into making do just exactly what we need.

This isn’t really meant to be a rant against Arduino, though. Everyone has to start somewhere, and the abstractions are great for getting your feet wet. And because everything’s open source anyway, nothing stops you from digging deeper into the datasheet. You just have to know that you need to. And that’s why we write up videos like this every five years or so, to show the next crop of new hackers that there’s a lot to gain underneath the abstractions.

• Read more about Nuvoton Launches 4th Generation Gerda HMI Display ICs for Automotive Safety and UX
• Log in or register to post comments

• Read more about OpenAI and Jony Ive Partner on Screenless AI Companion to Replace Traditional Interfaces
• Log in or register to post comments

• Read more about India Poised for Growth in Semiconductor Research as Manufacturing Lags Says MediaTek
• Log in or register to post comments

• Read more about TSMC Declines India’s Factory Proposal as Nation Launches 3nm Chip Design Centers
• Log in or register to post comments

• Read more about TSMC Declines India’s Factory Proposal as Nation Launches 3nm Chip Design Centers
• Log in or register to post comments

• Read more about ROHM Expands NIR LED Lineup with Miniature Models for VR, Industrial, and Medical Use
• Log in or register to post comments

• Read more about DigiKey Introduces Digital Technology Portals to Drive Education and Innovation in APAC Region
• Log in or register to post comments

Although plenty of us have our preferred language for coding, whether it’s C for its hardware access, Python for its usability, or Fortran for its mathematic prowess, not every language is specifically built for problem solving of a particular nature. Some are built as thought experiments or challenges, like Whitespace or Chicken but aren’t used for serious programming. There are a few languages that fit in the gray area between these regions, and one example of this is the language MOUSE which can now be run on an Arduino.

Although MOUSE was originally meant to be a minimalist language for computers of the late 70s and early 80s with limited memory (even for the era), its syntax looks more like a more modern esoteric language, and indeed it arguably would take a Python developer a bit of time to get used to it in a similar way. It’s stack-based, for a start, and also uses Reverse Polish notation for performing operations. The major difference though is that programs process single letters at a time, with each letter corresponding to a specific instruction. There have been some changes in the computing world since the 80s, though, so [Ivan]’s version of MOUSE includes a few changes that make it slightly different than the original language, but in the end he fits an interpreter, a line editor, graphics primitives, and peripheral drivers into just 2KB of SRAM and 32KB Flash so it can run on an ATmega328P.

There are some other features here as well, including support for PS/2 devices, video output, and the ability to save programs to the internal EEPROM. It’s an impressive setup for a language that doesn’t get much attention at all, but certainly one that threads the needle between usefulness and interesting in its own right. Of course if a language where “Hello world” is human-readable is not esoteric enough, there are others that may offer more of a challenge.