Ever since the world decided to transition from mechanical ball mice to optical mice, we have been blessed with computer pointing devices that don’t need regular cleaning and have much better performance than their ancestors. They do this by using what is essentially a tiny digital camera to monitor changes in motion. As we’ve seen before, it is possible to convert this mechanism into an actual camera, but until now we haven’t seen something like this on a high-performance mouse designed for FPS gaming.
For this project [Ankit] is disassembling the Logitech G402, a popular gaming mouse with up to 4000 dpi. Normally this is processed internally in the mouse to translate movement into cursor motion, but this mouse conveniently has a familiar STM32 processor with an SPI interface already broken out on the PCB that could be quickly connected to in order to gather image data. [Ankit] created a custom USB vendor-specific endpoint and wrote a Linux kernel module to parse the data into a custom GUI program that can display the image captured by the mouse sensor on-screen.
It’s probably best to not attempt this project if you plan to re-use the mouse, as the custom firmware appears to render the mouse useless as an actual mouse. But as a proof-of-concept project this high-performance mouse does work fairly well as a camera, albeit with a very low resolution by modern digital camera standards. It is much improved on older mouse-camera builds we’ve seen, though, thanks to the high performance sensors in gaming mice.
As one of the most popular buses today for on- and inter-board communication within systems, there’s a good chance you’ll end up using it with an embedded system. I2C offers a variety of speeds while requiring only two wires (clock and data), which makes it significantly easier to handle than alternatives, such as SPI. Within the STM32 family of MCUs, you will find at least one I2C peripheral on each device.
As a shared, half-duplex medium, I2C uses a rather straightforward call-and-response design, where one device controls the clock, and other devices simply wait and listen until their fixed address is sent on the I2C bus. While configuring an STM32 I2C peripheral entails a few steps, it is quite painless to use afterwards, as we will see in this article. Continue reading “Bare-Metal STM32: Using The I2C Bus In Master-Transceiver Mode”→
If you thought that Tamagotchis were a late ’90s fad that has faded from most people’s memory by now, you’d be wrong: the franchise is still alive and well today, with new models being released regularly. But even the original model from 1996, known as Tamagotchi P1, is being kept alive by a small group of enthusiasts. When ROM dumps of the original hardware began floating around the internet a couple of years ago, even those without the real thing could run these virtual pets in an emulator.
The software platform is [JC]’s TamaLib which we featured last year; in effect it’s an open-source emulator that allows the Tamagotchi ROM to run on a variety of modern hardware platforms. It also contains several additional options like the ability to save and restore your progress or to select customized ROMs. The OpenTama hardware, meanwhile, is a proper 21st-century reimplementation of the original: a small, egg-sized PCB sporting an STM32 microcontroller driving an LCD or OLED display, powered by a 100 mAh battery that can be recharged through a USB-C port.
Ok, the title is a bit misleading. Like most things in life, it really isn’t infinite. But I’m going to show you how you can use a very interesting Linux feature to turn one serial port from a microcontroller into a bunch of virtual ports. In theory, you could create over 200 ports, but the reality is you will probably want to stick with fewer.
The feature in question is what’s known as pseudoterminal or sometimes a pty or pts. These special files were made to feed data to programs that expect to accept data from a terminal. The files provide two faces. To the client, it looks like any other terminal device. To the creator, though, it is just another file. What you write to that file goes to the fake terminal and you can read anything that is sent from the program connected to the terminal. You use these all the time, probably, without realizing it since running a shell under X Windows, for example, doesn’t attach to a real terminal, after all.
You could, of course, do the same trick with a composite USB device, assuming you have one. Also assuming you can find a working driver and get it working. However, many microcontrollers have a serial port — even one with a USB converter built-in — but fewer have full-blown USB hardware. Even the ones that do are often at odds with strange drivers on the PC side. Serial ports work and work well even on the simplest microcontrollers.
The plan is simple enough. A Linux program listens to a real serial port and watches for special character sequences in the data stream. Those sequences will allow you to switch data so that the data stream will go to a particular terminal. Data coming back from the terminals will go to the real serial port after sending a sequence that identifies its source.
We see tons of projects with the infamous “Blue Pill” STM32 boards. They are cheap and plentiful and have a lot of great features, or at least they were before the chip shortage. I recently picked up a “Black Pill”, which is very similar but has an even more powerful processor. For a few bucks, you get an ARM CPU that can run at 100 MHz (but with USB, probably 96 MHz). There’s 512 kB of flash and 128 kB of RAM. There’s a USB type C port, and even a button and an LED onboard. The thing fits on a breadboard and you can program it with a cheap STLink dongle which costs about $10.
Of course, you then have to consider the software. The STM32Cube stuff is a lot to set up and learn but it does let you do just about anything you can imagine. Then there is the STM32Duino plug-in that lets you use it as a beefy Arduino. That works and is easy enough to set up. However, there’s also Mbed. The only problem is that Mbed doesn’t work right out of the box. Turns out, though, it isn’t that hard to set up. I’ll show you how easy it is to get things going and, next time, I’ll show you a practical example of a USB peripheral that uses the mBed RTOS features.
Obviously, you are going to need a Black Pill. There are at least two choices but for as cheap as they are there is little reason not to get the STM32F411 version that has more memory. The DIP form factor will fit in whatever breadboard you happen to have and a USB C cable will power the board so unless you are driving a lot of external circuitry, you probably don’t need an external supply.
DYMO 550 series printer marketing blurb says “The DYMO® LabelWriter® 550 Turbo label printer comes with unique Automatic Label Recognition™”, which, once translated from marketing-ese, means “this printer has DRM in its goshdarn thermal stickers”. Yes, DRM in the stickers that you typically buy in generic rolls. [FREEPDK] didn’t like that, either, and documents a #FreeDMO device to rid us of yet another consumer freedom limitation, the true hacker way.
The generic BluePill board and two resistors are all you need, and a few extra cables make the install clean and reversible – you could definitely solder to the DYMO printer’s PCBs if you needed, too. Essentially, you intercept the RFID reader connections, where the BluePill acts as an I2C peripheral and a controller at the same time, forwarding the data from an RFID reader and modifying it – but it can also absolutely emulate a predetermined label and skip the reader altogether. If you can benefit from this project’s discoveries, you should also take a bit of your time and, with help of your Android NFC-enabled phone, share your cartridge data in a separate repository to make thwarting future DRM improvements easier for all of us. Continue reading “#FreeDMO Gets Rid Of DYMO Label Printer DRM”→
[Peng Zhihui] seems to have found some spare time and energy to crack out another sweet robot build, this time it’s a much smaller, and cuter emoji-bot (Original GitHub Link,) with the usual production-ready levels of attention to detail. With a lot of fine details in the 3D printed models, this is one for SLS printing in nylon, but that can be done for a reasonable outlay, in China at least. The electronics package consists of a few full custom, and tiny, PCBs designed with Altium Designer, with off-the-shelf modules for the circular LCD and camera. The main board hosts an STM32F405 and deals with the display and SD card, The reason for this choice of STM32 was due to the requirement for connecting to an external USB3300 high-speed USB PHY. There is a sensor PCB which handles the gesture sensor, a USB hub, MPU6050 9-axis sensor, and also the USB camera module. This board attaches to the USB-C connector in the base, via a FFC cable, allowing the robot to rotate on its base.
[Peng] clearly has exacting standards as to how things should work, and we guess wanted to have the arms back-driveable in a way that enabled the host computer to track and record the motor positions for replaying later on. The connection back to the controller is via I2C, allowing all five servos to hang on the same bus, saving previous resources. Smart! Getting a processor and motor driver in such a tiny space was a bit of challenge, but a walk in the park for [Peng] as is demonstrates in the video embedded below (We believe English subtitles are pending!) The arm mechanism is particularly interesting, and rather elegantly executed, and he does seem rather proud of this part of the design, and so he should! Like with [Peng’s] other projects, there is a lot to see, and plenty of scope for feature explosion. It was nice to see the ‘bot being used as an input device, not only with gesture sensing via the dedicated sensor, but also using the camera with OpenCV to track user posture and act accordingly. This thing could act as genuinely useful AI device, as was a being darn cute at the same time!