Portrait Of A Digital Weapon

Over the years, artists have been creating art depicting weapons of mass destruction, war and human conflict. But the weapons of war, and the theatres of operation are changing in the 21st century. The outcome of many future conflicts will surely depend on digital warriors, huddled over their computer screens, punching on their keyboards and maneuvering joysticks, or using devious methods to infect computers to disable or destroy infrastructure. How does an artist give physical form to an unseen, virtual digital weapon? That is the question which inspired [Mac Pierce] to create his latest Portrait of a Digital Weapon.

[Mac]’s art piece is a physical depiction of a virtual digital weapon, a nation-state cyber attack. When activated, this piece displays the full code of the Stuxnet virus, a worm that partially disabled Iran’s nuclear fuel production facility at Natanz around 2008. Continue reading “Portrait Of A Digital Weapon”

Direct Memory Access: Data Transfer Without Micro-Management

In the most simple computer system architecture, all control lies with the CPU (Central Processing Unit). This means not only the execution of commands that affect the CPU’s internal register or cache state, but also the transferring of any bytes from memory to to devices, such as storage and interfaces like serial, USB or Ethernet ports. This approach is called ‘Programmed Input/Output’, or PIO, and was used extensively into the early 1990s for for example PATA storage devices, including ATA-1, ATA-2 and CompactFlash.

Obviously, if the CPU has to handle each memory transfer, this begins to impact system performance significantly. For each memory transfer request, the CPU has to interrupt other work it was doing, set up the transfer and execute it, and restore its previous state before it can continue. As storage and external interfaces began to get faster and faster, this became less acceptable. Instead of PIO taking up a few percent of the CPU’s cycles, a big transfer could take up most cycles, making the system grind to a halt until the transfer completed.

DMA (Direct Memory Access) frees the CPU from these menial tasks. With DMA, peripheral devices do not have to ask the CPU to fetch some data for them, but can do it themselves. Unfortunately, this means multiple systems vying for the same memory pool’s content, which can cause problems. So let’s look at how DMA works, with an eye to figuring out how it can work for us.
Continue reading “Direct Memory Access: Data Transfer Without Micro-Management”

Your Plants Can Take Care Of Themselves Now

One of [Sasa]’s life goals is to be able to sit back in his home and watch as robots perform all of his work for him. In order to work towards this goal, he has decided to start with some home automation which will take care of all of his house plants for him. This project is built from the ground up, too, and is the first part of a series of videos which will outline the construction of a complete, open-source plant care machine.

The first video starts with the sensors for the plants. [Sasa] decided to go with a completely custom module based on the STM32 microcontroller since commercial offerings had poor communications designs and other flaws. The small board is designed to be placed in the soil, and has sensors for soil moisture as well as other sensors for amount of light available and the ambient temperature. The improvements over the commercial modules include communication over I2C, allowing a large number of modules to communicate over a minimum of wires and be arranged in any way needed.

For this build everything is open-source and available on [Sasa]’s GitHub page, including PCB layouts and code for the microcontrollers. We’re looking forward to the rest of the videos where he plans to lay out the central unit for handling all of these sensors, and a custom dashboard for controlling them as well. Perhaps there will also be an option for adding a way to physically listen to the plants communicate their needs as well.

Continue reading “Your Plants Can Take Care Of Themselves Now”

The Right Tools For The Job

We’re knee-deep in new microcontrollers over here, from the new Raspberry Pi Pico to an engineering sample from Espressif that’s right now on our desk. (Spoiler alert, review coming out Monday.) And microcontroller peripherals are a little bit like Pokemon — you’ve just got to catch them all. If a microcontroller doesn’t have 23 UARTS, WiFi, Bluetooth, IR/DA, and a 16-channel 48 MHz ADC, it’s hardly worth considering. More is always better, right?

No, it’s not. Chip design is always a compromise, and who says you’re limited to one microcontroller per project anyway? [Francesco] built a gas-meter reader that reminded to think outside of the single-microcontroller design paradigm. It uses an ATtiny13 for its low power sleep mode, ease of wakeup, and decent ADCs. Pairing this with an ESP8266 that’s turned off except when the ATtiny wants to send data to the network results in a lower power budget than would be achievable with the ESP alone, but still gets his data up into his home-grown cloud.

Of course, there’s more complexity here than a single-micro solution, but the I2C lines between the two chips actually form a natural division of work — each unit can be tested separately. And it’s using each chip for what it’s best at: simple, low-power tasks for the Tiny and wrangling WiFi on the ESP.

Once you’ve moved past the “more is better” mindset, you’ll start to make a mental map of which chips are best for what. The obvious next step is combination designs like this one.

New Parts, New Hacks

The biggest news this week is that Raspberry Pi is no longer synonymous with single-board Linux computers: they’re dipping their toes into the microcontroller business with their first chip: the RP2040, and the supporting breakout board, the Pico. It’s an affordable, capable microcontroller being made by a firm that’s never made microcontrollers before, so that’s newsy.

The Hackaday comments lit on fire about this chip, with some fraction of the commenters lamenting the lack of wireless radios onboard. It’s a glass-half-full thing, I guess, but the RP2040 isn’t an ESP32, folks. It’s something else. And it’s got a hardware trick up its sleeve that really tickles my fancy — the programmable input/output (PIO) units.

The other half of the commenters were, like me, salivating about getting to try out some of the new features. The PIO, of course, was high on that list, but this chip also caters to folks who are doing high-speed DSP, with fast multiplication routines burnt into ROM and a nice accumulator. (You know you’re a microcontroller nerd when you’re reading through a 663-page datasheet and thinking about all the funny ways you can use and/or abuse the hardware peripherals.)

All chip designs are compromises. Nothing can do everything. The new peripherals, novel combinations of old elements, and just pleasant design decisions, open up new opportunities if you’re willing to seek them out. When the ESP32 was new, I was looking at their oddball parallel-I2S hardware and thinking what kind of crazy hacks that would enable, and clever hackers have proven me right. I’d put my money on the PIO being similar.

New chips open up new possibilities for hacks. What are you going to do with them?

Everything You Wanted To Know About Padauk MCUs And More

At this point you’d need to have lived underneath a rock somewhere on the dark side of the Moon to not have heard about these amazing, 3-cent microcontrollers. A number of places have pitched in on them, but comprehensive reviews, let alone a full-blown review of the entire ecosystem surrounding these Padauk MCUs have been scarce. Fortunately, [Jay Carlson] has put in a lot of effort to collect everything you could possibly want to know about anything Padauk.

The most important take-away is that these MCUs do not have any kind of communication peripherals. UARTs, I2C, and SPI all have to be done in software. They’re not very great at low-power or battery-powered applications due to high power usage. Essentially you’ll be using GPIO pins a lot. On the other hand, its multi-CPU context, FPPA feature is rather interesting, with the article covering it in detail.

As for the development tools, [Jay] came away very impressed with the In-Circuit Emulation (ICE) instead of running code on an MCU, as this can reduce development times significantly. This makes even the OTP (one-time programmable) property of most Padauk MCUs less significant than one might at first assume.

Then there’s the actual programming of the MCUs. The Micro C compiler Padauk provides essentially implements a sub-set of the C language, with some macros to replace things like for loops. Initially this may seem like a weird limitation, until you realize that these MCUs have 64 to 256 bytes of SRAM. That’s bytes, without any prefixes.

Finally, [Jay] shows off a couple of test projects, including a NeoPixel SPI adapter and bike light, which are all available on Github. The WS2812b project is something we have seen before, for example this project from [Anders Nielsen] (featured in the article image), which provides another take on this range of MCUs.

Did reading [Jay]’s article change your mind on these Padauk parts? Have you used these MCUs and ICE parts before? Feel free to leave your thoughts in the comments.

Simulated Newton’s Cradle Makes A Flashy Desk Toy

Newton’s Cradle was once upon a time, a popular desk toy in offices around the world. For [TecnoProfesor], however, it wasn’t quite flashy enough. Instead, they built a simulated version with flashing LEDs. As you do.

Rather than relying on the basic principles of the cradle to make it work, this relies on two servo motors to move the balls on the ends, with the ones in the middle remaining stationary. Each ball is fitted with an RGB LED, which flashes with the simulated “motion” of the cradle. By using ping pong balls, the light from the LEDs is nicely diffused. The frame is built from wooden dowels, metal rods, and acrylic.

It’s a project that is sure to confuse at first glance, but it’s a great way to learn basic microcontroller skills like interfacing with LEDs and servomotors. We’d love to see a version that works like a real Newton’s Cradle, flashing the LEDs as they are hit by their neighbours. We’ve even seen them automated, for the truly lazy among us.  Alternatively, one could go completely ridiculous and have such a device tweet on every hit, though you might run afoul of the API’s spam restrictions. If you give it a go, drop us a line.