Posts with «arduino hacks» label

Many Uses For A Single Button

When building projects with a simple goal in mind, it’s not unheard of for us to add more and more switches, buttons, and complexity as the project goes through its initial prototyping stages. Feature creep like this tends to result in a tangled mess rather than a usable project. With enough focus, though, it’s possible to recognize when it’s happening and keep to the original plans. On the other hand, this single-button project with more than one use seems to be the opposite of feature creep. (YouTube, embedded below.)

[Danko]’s project has one goal: be as useful as possible while only using a single button and a tiny screen. Right now the small handheld device can be used as a stopwatch, a counter, and can even play a rudimentary version of flappy bird. It uses an Arduino Pro Mini, a 64×48 OLED screen running on I2C, and has a miniscule 100 mAh 3.7V battery to power everything. The video is worth watching if you’ve never worked with this small of a screen before, too.

Getting three functions out of a device with only one button is a pretty impressive feat, and if you can think of any other ways of getting more usefulness out of something like this be sure to leave it in the comments below. [Danko] is no stranger to simple projects with tiny screens, either. We recently featured his homebrew Arduino calculator that uses an even smaller screen.

The Arduino Hits The Rails

Certain hobbies come in clusters. It isn’t uncommon to see, for example, ham radio operators that are private pilots. Programmers who are musicians. Electronics people who build model trains. This last seems like a great fit since you can do lots of interesting things with simple electronics and small-scale trains. [Jimmy] at the aptly-named DIY and Digital Railroad channel has several videos on integrating railroad setups with Arduino. These range from building a DCC system for about $45 (see below) to a crossing signal.

There are actually quite a few basic Arduino videos on the channel, although most of them are aimed at beginners. However, the DCC — Digital Command and Control — might be new to you if you are a train neophyte. DCC is a standard defined by the National Model Railroad Association.

Model trains pick up electrical power from the rails. DCC allows digital messages to also ride the rail. The signal shifts from positive to negative to indicate marks and spaces. By diode switching the electrical signal, the train or other equipment can get a constant supply of current. However, equipment monitoring the line ahead of the diodes can read the data and interpret it as commands.

To accommodate old equipment, you can stretch the high or low values to make the average voltage either positive (forward) or negative (reverse). This can heat up DC motors, though, so it may shorten the life of the legacy equipment.

The build uses an available Arduino library, so if you want to get into the protocol you’ll have to work through that code. We had to wonder if there were other places where passing power and data on the same lines might be useful. There are other ways to do that, of course, but this would be a reasonable place to start if you needed that capability.

If you want to use an mBed system instead of an Arduino, there’s a great tutorial for that. Either way, it is just the thing for your next coffee table.

Treasure Trove of Projects Provides Endless Examples

Sometimes, traveling the internet feels a little like exploring an endless cave system looking for treasure. Lots of dark passageways without light or life, some occasional glimmers as you find a stray gold doubloon or emerald scattered in a corner. If we take the metaphor too far, then finding [Paul]’s “Little Arduino Projects” repository is like turning an unremarkable corner only to discover a dragon’s hoard.

LEAP (as [Paul] also refers to the collection) is a numbered collection of what looks like more or less every electronics project he has completed over the last few years. At the time of writing there are 434 projects in the GitHub repository and tagged and indexed in a handy blog-style interface. Some are familiar, like a modification to a Boldport project. Others are one-off tests of a specific concept like driving a seven segment display (there are actually 16 similar projects if you search the index for “7-Segment”). On the other end are project builds with more detailed logs and documentation, like the LED signboard for monitoring the status of 24 in-progress projects, mounted in a guitar fret board.

LEAP reminds us of the good old days on the internet, before it felt like 50% trolling and 50% tracking cookies. Spend a few minutes checking out [Paul]’s project archive and see if you find anything interesting! We’ve just scratched the surface. And of course, send a tip if you discover something that needs a write-up!

Debugging Arduino is Painful: This Can Help

If you are used to coding with almost any modern tool except the Arduino IDE, you are probably accustomed to having on-chip debugging. Sometimes having that visibility inside the code makes all the difference for squashing bugs. But for the Arduino, most of us resort to just printing print statements in our code to observe behavior. When the code works, we take the print statements out. [JoaoLopesF] wanted something better. So he created an Arduino library and a desktop application that lets you have a little better window into your program’s execution.

To be honest, it isn’t really a debugger in the way you normally think of it. But it does offer several nice features. The most rudimentary is to provide levels of messaging so you can filter out messages you don’t care about. This is sort of like a server’s log severity system. Some messages are warnings and some are informational, and some are verbose. You can select what messages to see.

In addition, the library timestamps the messages so you can tell how much time elapsed between messages and what function you were in during the message. It can also examine and set global variables that you preconfigure and set watches on variables. It is also possible to call functions from the serial monitor.

There’s a companion Java program (see video below) although you can use most of the features directly from the normal serial monitor, it just isn’t as pretty. The Java program can also read an Arduino program file and convert all the print calls in it to use the library, if you like.

As you might expect, this requires some cooperation from your program. You have to set up the library and the serial port. You also have to arrange for the main function to run frequently (for example, in the main loop). By default, the debugging is mostly suppressed (although you can change that). You have to issue a serial port command to turn on higher level logging and debug functions.

If you start with the examples that come with the library (use the simple one for an AVR-based Arduino and the advanced one for any others), you’ll see a few #defines you can use to control the library:

  • DEBUG_DISABLED – Set to true and the library compiles out with no overhead
  • DEBUG_DISABLE_DEBUGGER – Turn off everything but message logging
  • DEBUG_INITIAL_LEVEL – Starting level of debug messages
  • DEBUG_USE_FLASH_F – Store debug messages in flash memory

There’s really two versions of the code: one for 8-bit AVR processors and another for other Arduino types. We found problems building both of them. The files src/utility/Fields.cpp, src/utility/Vector.h, and
src/utility/Util.cpp refer to arduino.h. That works on computers that have case-insensitive file systems. In each case, for Linux, it needs to be Arduino.h. In addition, SerialDebug.cpp is lacking a stdarg.h include. We’ve reported both of these issues to the developer so they may be fixed by now.

You can explore the video and the documentation to see how it all works. Is it a full-blown debugger? No. You can’t stop execution (odd, because you certainly could technically), set breakpoints, or single step. But it still useful to have access to at least some of your program’s internal state.

Of course, Arduino has promised full debugging soon. We’ve even seen one Arduino debugging another via debugWIRE.

Hack a Day 08 Nov 06:00

Gyro Controlled RGB Blinky Ball Will Light up Your Life

[James Bruton], from the XRobots YouTube channel is known for his multipart robot and cosplay builds. Occasionally, though, he creates a one-off build. Recently, he created a video showing how to build a LED ball that changes color depending on its movement.

The project is built around a series of 3D printed “arms” around a hollow core, each loaded with a strip of APA102 RGB LEDs. An Arduino Mega reads orientation data from an MPU6050 and changes the color of the LEDs based on that input. Two buttons attached to the Mega modify the way that the LEDs change color. The Mega, MPU6050, battery and power circuitry are mounted in the middle of the ball. The DotStar strips are stuck to the outside of the curved arms and the wiring goes from one end of the DotStar strip, up through the middle column of the ball to the top of the next arm. This means more complicated wiring but allows for easier programming of the LEDs.

Unlike [James’] other projects, this one is a quickie, but it works as a great introduction to programming DotStar LEDs with an Arduino, as well as using an accelerometer and gyro chip. The code and the CAD is up on Github if you want to create your own. [James] has had a few of his projects on the site before; check out his Open Dog project, but there’s also another blinky ball project as well.

Hack a Day 03 Nov 03:00

This Cup Holder Crystal Ball Tells Your MPG Future

Hybrid vehicles, which combine an eco-friendly electric motor with a gasoline engine for extended range, are becoming more and more common. They’re a transitional technology that delivers most of the advantages of pure electric vehicles, but without the “scary” elements of electric vehicle ownership which are still foreign to consumers such as installing a charger in their home. But one element which hybrids are still lacking is a good method for informing the driver whether they’re running on petroleum or lithium; a way to check at a glance how “green” their driving really is.

[Ben Kolin] and his daughter [Alyssa] have come up with a clever hack that allows retrofitting existing hybrid vehicles with an extremely easy to understand indicator of real-time vehicle efficiency. No confusing graphics or arcade-style bleeps and bloops, just a color-changing orb which lives in the cup holder. An evolved version which takes the form of a smaller “dome light” that sits on the top of the dashboard could be a compelling aftermarket accessory for the hybrid market.

The device, which they are calling the ecOrb, relies on an interesting quirk of hybrid vehicles. The OBD II interface, which is used for diagnostics on modern vehicles, apparently only shows the RPM for the gasoline engine in a hybrid. So if the car is in motion but the OBD port is reporting 0 RPM, the vehicle must be running under electric power.

With a Bluetooth OBD adapter plugged into the car, all [Ben] and [Alyssa] needed was an Arduino Nano clone with a HC-05 module to read the current propulsion mode in real-time. With some fairly simple conditional logic they’re able to control the color of an RGB LED based on what the vehicle is doing: green for driving on electric power, purple for gas power, and red for when the gas engine is at idle (the worst case scenario for a hybrid).

Check out our previous coverage of OBD hacking on the Cadillac ELR hybrid if you’re looking to learn more about what’s possible with this rapidly developing class of vehicle

Hands on with the Arduino FPGA

All of the tools you need to work with the FPGA Arduino — the Vidor — are now in the wild!

We reported earlier that a series of French blog posts finally showed how all the pieces fit together to program the FPGA on the Arduino MKR4000 Vidor board. Of course, I wasn’t content to just read the Google translation, I had to break out the board and try myself.

I created a very simple starter template, a tool in C to do the bitstream conversion, required, and bundled it all together in one place. Here’s how you can use my starter kit to do your own FPGA designs using the Vidor. I’m going to assume you know about FPGA basics and Verilog. If you don’t, why not check out the FPGA boot camps first?

The first thing you’ll want to do is grab my GitHub repo. You’ll also need the Arduino IDE (a recent copy) and Intel’s Quartus software. Inside, you’ll find three directories, two of which contain slightly modified copies of original Arduino files. But before you start digging in, let’s get the high-level overview of the process.

Basic Concepts

The FPGA onboard the Vidor is an Intel/Altera device so to configure it, we’ll use Quartus. Usually, Quartus handles everything including programming the device, but we can’t use it for that with the Vidor. Instead, we will have to tell the CPU how we want the FPGA configured and it will do it for us as part of our Arduino program (I really hate saying sketch).

Quartus (see below) will take our Verilog files and create a ttf file that represents the configuration bitstream. This is just an ASCII text file full of decimal numbers. Unfortunately, the way the Vidor is set up, it needs the numbers bit reversed at the byte level. That is, 01 in the ttf file needs to be 80 hex sent to the FPGA.

Arduino supplies a Java class file to do the task, but I got frustrated because the class file needed Java 11 and I didn’t want to put it on every machine I use, so I just rewrote it in C. It is easy enough to port the algorithm, though. In the shell subdirectory, I have another example implementation using awk.

Once you have this stream of numbers, you can include it in an Arduino sketch with some boilerplate to enable the FPGA and load it. The standard program includes the file app.h which is just the output of the conversion program. There’s no C code in it, just comma-separated numbers that the main code will stick in an array at compile-time. Beyond that, it is a normal Arduino program and you can do what you like. Upload it and you’ll get the CPU and FPGA programmed all in one go.

There is one caveat. The FPGA code has a top-level block with lots of I/O pins defined and the corresponding constraints. You should be very careful not to change these or alter the pin constraints. If you drive a pin that’s already an output, for example, you could do real harm to the board. Because all the pins are shared, you have the same problem with the Arduino pins, too. If you are driving an output pin with the FPGA, you shouldn’t try to drive it with the CPU also. However, as you will see, it is perfectly fine to have the FPGA reading a pin from the CPU or vice versa. That’s good because it gives us a way to send data back and forth between them.

On to Code

I wanted something simple, and I didn’t want to accidentally modify the Arduino boilerplate Verilog. You could instantiate a Verilog module, but this would require passing all the I/O pins into the module or modifying the original code every time, both of which I wanted to avoid.

My answer was to use the Verilog `include directive inside the boilerplate. That way your code has access to everything the main module has, but you don’t have to change the main module. The only downside is that Quartus has a smart compile feature that can’t figure out when only an include file changes. So it wasn’t recompiling when I made changes. I turned that feature off in the Quartus options, so if you pick up my example project, you won’t have any problems.

Here’s my example user.v:

reg [27:0] hadcounter;
assign bMKR_D[6]=bMKR_D[5]?hadcounter[27]:hadcounter[21];

always @(posedge wOSC_CLK)
begin
   if (!rRESETCNT[5])
   begin
      hadcounter<=28'hfffffff;
   end
   else
   begin
      if (hadcounter==28'h0) hadcounter<=28'hffffffff; else hadcounter<=hadcounter-28'h1;
   end
end

In the real file, I left a lot of comments in that explains what all the main module has that you can use. But the above is the working part. I define a 28 bit counter. The bMKR_D array is the digital ports for the Arduino and I’m using pin 6 and 5 as an output and an input, respectively.

The assign statement says, in English, If D5 is high, connect the 27th bit of the counter to the LED. If it is low, connect the 21st bit. The rest of the code just makes the counter countdown. I reload the counter even though it would naturally roll over in case you want to fine tune it to a different frequency.

As the counter runs, bit 27 will toggle relatively slowly, but bit 21 will be a good bit faster — that’s just how a counter is. So by changing D5 you can make the LED blink slow or fast.

As Verilog goes, this isn’t very complicated or even useful, but it is simple and shows that we can share data with the CPU in both directions. If you open the example project in Quartus, all you really need to do is make any changes to user.v you like, add any other files you want to use and double-click the Compile Design task (see left). If you get a successful compile, you’ll find the ttf file in the output_files directory. That’s the file you need to process with either the Java program, the C program, or the awk script. Either way, collect the output as app.h and put it in the same directory as your Arduino code.

CPU Side

On the sketch side, you need to leave the template code alone since it turns on the FPGA clock, among other things. You’ll notice it also includes app.h and uses a file called jtag.c to communicate with the FPGA. I didn’t segregate the Arduino code into its own include because you probably have to change the setup function, and make changes in global space, but that could be arranged (perhaps make setup call cpu_setup and loop call cpu_loop or something).

If you want to remove the demo parts of the blink-sketch file, you can get rid of:

  • The definitions and calls related to FPGAVal, SPEED, and FPGALED
  • The Serial calls and definitions
  • Everything in the loop function

I left the unmodified code in the EmptySketch directory. Note in the demo code, though that SPEED is an output. This is set to D5, which is an input to the FPGA. By the same token, FPGALED corresponds to D6 and allows the CPU to read the state of the LED output.

You will need an LED and dropping resistor on pin 6 unless you want to watch with a scope or a meter. I always keep some LEDs with built-in 5V dropping resistors handy, and even at 3.3V it was plenty bright. With one of those, you can just stick the wires right into the header socket on the board. Don’t try that with a regular LED, though!

Once you run the sketch, you can open the serial monitor or any terminal at 9600 baud. There will be a message saying you can press any key to change the blink rate. Of course, since the serial monitor doesn’t allow you to press keys exactly, you’ll have to enter something and hit enter (set “No line ending” at the bottom of the monitor screen), but on a real terminal, any character press should do it.

The main code is pretty simple:

void loop() {
static int oldstate=-1;
static int linect=0;
int state;
if (Serial.read()!=-1)
  {
  FPGAVal=FPGAVal==HIGH?LOW:HIGH;
  digitalWrite(SPEED,FPGAVal);
  }
state=digitalRead(FPGALED);
if (state!=oldstate)
  {
  Serial.print(state);
  if (++linect==16)
    {
    Serial.println();
    linect=0;
    }
  oldstate=state;
  }
}

In the loop, if serial data appears, we just toggle the output going to the FPGA. We also sample the LED output on every pass. If it has changed from the last time, we write the new state to the terminal and then update the state so we don’t flood the screen with repeated characters. A lot of the code is just tracking when we’ve written enough to start a new line.

Vidor’s Hello World

I wanted to get everything you needed in one place and an example that would be easy to follow yet show the critical working parts. It would be easy enough to use the shared I/O pins to do SPI, for example, and then you could trade data with the FPGA quite easily. Don’t forget there’s Arduino IP (intellectual property; sort of library subroutines for FPGAs) in the IP directory, too, if you want to use it.

Now you just need a project idea that makes sense for an FPGA. Our personal favorite would be a logic analyzer. The CPU can talk to the PC, set up triggers and then let the FPGA do the dirty work of finding the trigger and storing data as fast as possible. If you want something less ambitious, it is very simple to create totally autonomous PWM outputs on an FPGA. We could see this being handy for robotics or machine control where you want a very rapid sequence of outputs without CPU intervention or overhead.

Of course, not every project has to make sense. If you are just wanting to learn about FPGAs there are plenty of projects you could do with a CPU but are easy enough to build in an FPGA (the classic traffic light comes to mind). Of course, with the Vidor you have an opportunity to use a blend of FPGA code and CPU code, which is kind of the point.

Want to Learn Ethernet? Write Your Own Darn AVR Bootloader!

There’s a school of thought that says that to fully understand something, you need to build it yourself. OK, we’re not sure it’s really a school of thought, but that describes a heck of a lot of projects around these parts.

[Tim] aka [mitxela] wrote kiloboot partly because he wanted an Ethernet-capable Trivial File Transfer Protocol (TFTP) bootloader for an ATMega-powered project, and partly because he wanted to understand the Internet. See, if you’re writing a bootloader, you’ve got a limited amount of space and no device drivers or libraries of any kind to fall back on, so you’re going to learn your topic of choice the hard way.

[Tim]’s writeup of the odyssey of cramming so much into 1,000 bytes of code is fantastic. While explaining the Internet takes significantly more space than the Ethernet-capable bootloader itself, we’d wager that you’ll enjoy the compressed overview of UDP, IP, TFTP, and AVR bootloader wizardry as much as we did. And yes, at the end of the day, you’ve also got an Internet-flashable Arduino, which is just what the doctor ordered if you’re building a simple wired IoT device and you get tired of running down to the basement to upload new firmware.

Oh, and in case you hadn’t noticed, cramming an Ethernet bootloader into 1 kB is amazing.

Speaking of bootloaders, if you’re building an I2C slave device out of an ATtiny85¸ you’ll want to check out this bootloader that runs on the tiny chip.

Burn Some Time with this Arduino Reddit Browser

If you’re like us, you probably spend more time browsing Reddit than you’d like to admit to your friends/family/boss/therapist. A seemingly endless supply of knowledge, wisdom, and memes; getting stuck on Reddit is not unlike looking something up on Wikipedia and somehow managing to spend the next couple hours just clicking through to new pages. But we’re willing to bet that none of us love browsing Reddit quite as much as [Saad] does.

He writes in to tell us about the handheld device he constructed which lets him view random posts from the popular /r/showerthoughts sub. Each press of the big red button delivers another slice of indispensable Internet wisdom, making it a perfect desk toy to fiddle with when you need a little extra push to get you through the day. Like one of those “Word a Day” calendars, but one that you’ll actually read.

For those curious as to how [Saad] is scraping Reddit with an Arduino, the short answer is that he isn’t. Posts are pulled from Reddit using an online tool created for the project by his wife (/r/relationshipgoals/), and dumped into a text file that can be placed on the device’s SD card. With 1500 of the all-time highest rated posts from /r/showerthoughts onboard, he should be good on content for awhile.

[Saad] has done an excellent job documenting the hardware side of this build, providing plenty of pictures as well as a list of the parts he used and a few tips to help make assembly easier. Overall it’s not that complex a project, but his documentation is a big help for those who might not live and breathe this kind of thing.

For the high-level summary: it uses an Arduino Pro Mini, a ILI9341 screen, and a 3.3 V regulator to step down 5 V USB instead of using batteries. A bit of perfboard, a 3D printed case, and a suitably irresistible big red button pulls the whole thing together.

We’ve seen a similar concept done in a picture frame a couple of years back, but if that’s not interactive enough you could always build yourself a Reddit “controller”.

A Robotic Arm For Those Who Like Their Kinematics Both Ways

A robotic arm is an excellent idea if you’re looking to get started with electromechanical projects. There’s linkages to design, and motors to drive, but there’s also the matter of control. This is referred to as “kinematics”, and can be considered in both the forward and inverse sense. [aerdronix] built a robotic arm build that works in both ways.

The brains of the build is an Arduino Yun, which receives commands over the USB interface. Control is realised through the Blynk app, which allows IoT projects to easily build apps for smartphones that can be published to the usual platforms.

The arm’s position is controlled in two fashions. When configured to use inverse kinematics, the user commands an end effector position, and the arm figures out the necessary position of the linkages to make it happen. However, the arm can also be used in a forward kinematics mode, where the individual joint positions are commanded, which then determine the end effector’s final position.

Overall, it’s a well-documented build that lays out everything from the basic mechanical design to the software and source code required to control the system. It’s an excellent learning resource for the newcomer, and such an arm could readily be used in more complex projects.

We see plenty of robotic arms around these parts, like this fantastic build based on an IKEA lamp. If you’ve got one, be sure to hit up the tip line. Video after the break.

Hack a Day 19 Oct 12:00