Posts with «arduino hacks» label

Vintage Vending Machine Makes The Perfect Gift

Nothing says ‘I Love You’ like an old vending machine, and if it is a restored and working vintage Vendo V-80 cola dispenser then you have yourself a winner. [Jan Cumps] from Belgium was assigned the repair of the device in question by a friend. He started off with just a working refrigerator and no electronics. In a series of repairs, he began with replacing the mechanical coin detector’s switches with optical and magnetic sensors to detect the movement of the coin. These sensors are in turn connected to an Arduino which drives the dispensing motor. The motor itself had to be rewound as part of the repair. Since the project is on a deadline, the whole thing is finished using protoboards and through-hole parts. The final system works by dispensing one frosty bottle every time a coin is inserted.

In contrast to most vending machine repairs, this project was a simple one. Instead of using an off-the-shelf coin detector, a simple LED and photodiode pair brought the hack to life. This could easily be adapted to any machine and even be used to create a DIY vending machine on the cheap. 

In his blog, [Jan Cumps] demonstrates each working step in a video and share the Arduino code and schematic as well as other interesting details. You can see the final working version in the video below.

It has been a long time since a Vending Machine Prototyping project was commissioned and we would love to see what this project inspires.


Filed under: Arduino Hacks

Sous Vide Arduino isn’t Lost in Translation

If your idea of a six-course meal is a small order of chicken nuggets, you might have missed the rise of sous vide among cooks. The idea is you seal food in a plastic pouch and then cook it in a water bath that is held at a precise temperature. That temperature is much lower than you usually use, so the cook times are long, but the result is food that is evenly cooked and does not lose much moisture during the cooking process. Of course, controlling a temperature is a perfect job for a microcontroller and [Kasperkors] has made his own setup using an Arduino for control. The post is in Danish, but Google translate is frighteningly good.

The attractive setup uses an Arduino Mega, a display, a waterproof temperature probe, and some odds and ends. The translation does fall down a little on the parts list, but if you substitute “ground” for “earth” and “soil” you should be safe. For the true epicurean, form is as important as function, and [Kasperkors’] acrylic box with LEDs within is certainly eye-catching. You can see a video of the device, below.

The switches, LEDs, and relays are all pretty standard fare. The real heart of the project is the temperature control. Many controllers use a PID (proportional/integral/derivative) to hold the temperature, but this project takes a more pragmatic approach. Depending on how far from the set point the temperature is, the controller simply drives the heating element differently and measures more or less frequently to adjust. For example, if the temperature is more than two degrees low, the heating element is left on constantly. As it gets closer, though, the heating element runs for 10 seconds, there’s a 5 second wait, and then the algorithm reads the temperature again.

There’s a lot of debate about how precise the temperature has to be. Apparently, for things like fish, a wide range of temperatures isn’t a problem. Eggs, however, need tighter control because their proteins can denature (whatever that means).

There’s also a safety relay that shuts the whole affair down if the temperature goes very high or low so a bad temperature sensor won’t boil everything away. We might have considered doing that with a bimetallic coil so that even an Arduino failure would not stop it from working.

We’ve seen other attractive sous vide setups. Not to mention the more utilitarian builds made with a crock pot. No matter what it looks like, these projects are probably not going to help your waistline.


Filed under: Arduino Hacks

Pi Time – A Fabric RGB Arduino Clock

Pi Time is a psychedelic clock made out of fabric and Neopixels, controlled by an Arduino UNO. The clock started out as a quilted Pi symbol. [Chris and Jessica] wanted to make something more around the Pi and added some RGB lights. At the same time, they wanted to make something useful, that’s when they decided to make a clock using Neopixels.

Neopixels, or WS2812Bs, are addressable RGB LEDs , which can be controlled individually by a microcontroller, in this case, an Arduino. The fabric was quilted with a spiral of numbers (3.1415926535…) and the actual reading of the time is not how you are used to. To read the clock you have to recall the visible color spectrum or the rainbow colors, from red to violet. The rainbow starts at the beginning of the symbol Pi in the center, so the hours will be either red, yellow, or orange, depending on how many digits are needed to tell the time. For example, when it is 5:09, the 5 is red, and the 9 is yellow. When it’s 5:10, the 5 is orange, the first minute (1) is teal, and the second (0) is violet. The pi symbol flashes every other second.

There are simpler and more complicated ways to perform the simple task of figuring out what time it is…

We are not sure if the digits are lighted up according to their first appearance in the Pi sequence or are just random as the video only shows the trippy LEDs, but the effect is pretty nice:

 


Filed under: Arduino Hacks, led hacks
Hack a Day 17 Apr 03:00

Hacker U.

If you go to the University of South Florida, you can take the “Makecourse.” The 15-week program promises to teach CAD software, 3D printing, Arduino-based control systems, and C++. Don’t go to the University of South Florida? No worries. Professor [Rudy Schlaf] and [Eric Tridas] have made the entire course available online. You can see several videos below, but there are many more. The student project videos are great, too, like [Catlin Ryan’s] phase of the moon project (see below) or [Dustin Germain’s] rover (seen above).

In addition to a lesson plan and projects, there’s a complete set of videos (you can see a few below). If you are a regular Hackaday reader, you probably won’t care much about the basic Arduino stuff and the basic electronics–although a good review never hurts anyone. However, the more advanced topics about interrupts, SDCards, pin change interrupts might be just the thing. If you ever wanted to learn Autodesk Inventor, there are videos for that, too.

If you don’t need any of the instruction offered, this would still make a great program to offer at a local hacker space or anywhere else where you want to teach build to build. You can see from the variety of student projects that it is well-balanced and lets students focus on areas where they are most interested.

So much educational material is online now that it is hard to find time to see even a fraction of it. We love EdX, for example, but who has the time to take even a fraction of the classes offered? We always love seeing student projects–they give us ideas. [Bruce Land’s] classes, in particular, are always inspirational.


Filed under: 3d Printer hacks, Arduino Hacks

Everyone Loves Faster ESP8266 TFT Libs

Reader [Jasper] writes in with glowing praise for the TFT_eSPI library for the ESP8266 and the various cheap 480×320 TFT displays (ILI9341, ILI9163, ST7735, S6D02A1, etc.) that support SPI mode. It’s a drop-in replacement for the Adafruit GFX and driver libraries, so you don’t need to rework your code to take advantage of it. If you’re looking to drive an LCD screen with an ESP8266 and Arduino, check this out for sure.

As a testbed, [Jasper] ported his Tick Tock Timer project over to the new library. He got a sevenfold increase in draw speed, going from 500 ms to 76 ms. That’s the difference between a refresh that’s visibly slow, and one that looks like it happens instantly. Sweet.

Improving software infrastructure isn’t one of the sexiest or most visible hacks, but it can touch the lives of many hackers. How many projects have we featured with an ESP8266 and a screen? Thanks, [Bodmer] for the good work, and [Jasper] for bringing it to our attention.


Filed under: Arduino Hacks, Microcontrollers

PlatformIO and Visual Studio Take over the World

In a recent post, I talked about using the “Blue Pill” STM32 module with the Arduino IDE. I’m not a big fan of the Arduino IDE, but I will admit it is simple to use which makes it good for simple things.

I’m not a big fan of integrated development environments (IDE), in general. I’ve used plenty of them, especially when they are tightly tied to the tool I’m trying to use at the time. But when I’m not doing anything special, I tend to just write my code in emacs. Thinking about it, I suppose I really don’t mind an IDE if it has tools that actually help me. But if it is just a text editor and launches a few commands, I can do that from emacs or another editor of my choice. The chances that your favorite IDE is going to have as much editing capability and customization as emacs are close to zero. Even if you don’t like emacs, why learn another editor if there isn’t a clear benefit in doing so?

There are ways, of course, to use other tools with the Arduino and other frameworks and I decided to start looking at them. After all, how hard can it be to build Arduino code? If you want to jump straight to the punch line, you can check out the video, below.

Turns Out…

It turns out, the Arduino IDE does a lot more than providing a bare-bones editor and launching a few command line tools. It also manages a very convoluted build process. The build process joins a lot of your files together, adds headers based on what it thinks you are doing, and generally compiles one big file, unless you’ve expressly included .cpp or .c files in your build.

That means just copying your normal Arduino code (I hate to say sketch) doesn’t give you anything you can build with a normal compiler. While there are plenty of makefile-based solutions, there’s also a tool called PlatformIO that purports to be a general-purpose solution for building on lots of embedded platforms, including Arduino.

About PlatformIO

Although PlatformIO claims to be an IDE, it really is a plugin for the open source Atom editor. However, it also has plugins for a lot of other IDEs. Interestingly enough, it even supports emacs. I know not everyone appreciates emacs, so I decided to investigate some of the other options. I’m not talking about VIM, either.

I wound up experimenting with two IDEs: Atom and Microsoft Visual Studio Code. Since PlatformIO has their 2.0 version in preview, I decided to try it. You might be surprised that I’m using Microsoft’s Code tool. Surprisingly, it runs on Linux and supports many things through plugins, including an Arduino module and, of course, PlatformIO. It is even available as source under an MIT license. The two editors actually look a lot alike, as you can see.

PlatformIO supports a staggering number of boards ranging from Arduino to ESP82666 to mBed boards to Raspberry Pi. It also supports different frameworks and IDEs. If you are like me and just like to be at the command line, you can use PlatformIO Core which is command line-driven.

In fact, that’s one of the things you first notice about PlatformIO is that it can’t decide if it is a GUI tool or a command line tool. I suspect some of that is in the IDE choice, too. For example, with Code, you have to run the projection initialization tool in a shell prompt. Granted, you can open a shell inside Code, but it is still a command line. Even on the PlatformIO IDE (actually, Atom), changing the Blue Pill framework from Arduino to mBed requires opening an INI file and changing it. Setting the upload path for an FRDM-KL46 required the same sort of change.

Is it Easy?

Don’t get me wrong. I personally don’t mind editing a file or issuing a command from a prompt. However, it seems like this kind of tool will mostly appeal to someone who does. I like that the command line tools exist. But it does make it seem odd when some changes are done in a GUI and some are done from the command line.

That’s fixable, of course. However, I do have another complaint that I feel bad for voicing because I don’t have a better solution. PlatformIO does too much. In theory, that’s the strength of it. I can write my code and not care how the mBed libraries or written or the Arduino tools munge my source code. I don’t even have to set up a tool chain because PlatformIO downloads everything I need the first time I use it.

When that works it is really great. The problem is when it doesn’t. For example, on the older version of PlatformIO, I had trouble getting the mBed libraries to build for a different target. I dug around and found the issue but it wasn’t easy. Had I built the toolchain and been in control of the process, I would have known better how to troubleshoot.

In the end, too, you will have to troubleshoot. PlatformIO aims at moving targets. Every time the Arduino IDE or the mBed frameworks or anything else changes, there is a good chance it will break something. When it does, you are going to have to work to fix it until the developers fix it for you. If you can do that, it is a cost in time. But I suspect the people who will be most interested in PlatformIO will be least able to fix it when it breaks.

Bottom Line

If you want to experiment with a different way of building programs — and more importantly, a single way to create and build — you should give PlatformIO a spin. When it works, it works well. Here are a few links to get you started:

Bottom line, when it works, it works great. When it doesn’t it is painful. Should you use it? It is handy, there’s no doubt about that. The integration with Code is pretty minimal. The Atom integration — while not perfect — is much more seamless. However, if you learn to use the command line tools, it almost doesn’t matter. Use whatever editor you like, and I do like that. If you do use it, just hope it doesn’t break and maybe have a backup plan if it does.


Filed under: Arduino Hacks, ARM, Hackaday Columns, reviews, Skills

Hackaday Prize Entry: [Nardax] Shoots Fireballs

If you’re looking for a high entertainment value per byte of code, [Nardax] has you covered with his wearable spellcasting controller. With not much effort, he has built a very fun looking device, proving what we’ve always known: a little interaction can go a long way.

[Nardax] originally intended his glorified elbow-mount potentiometer to be a fireworks controller. Ironically, he’s now using it to throw virtual fireballs instead. Depending on the angle at which he holds his elbow before releasing it, he can cast different spells in the game World of Warcraft. We’re not at all sure that it helps his gameplay, but we’re absolutely sure that it’s more fun that simply mashing different keys.

There’s a lot of room for expansion here, but the question is how far you push it. Sometimes the simplest ideas are the best. It looks like [Nardax] is enjoying his product-testing research, though, so we’ll keep our eyes out for the next iterations of this project.

We’ve seen a number of high-tech competitors to the good old power glove, and although some are a lot more sophisticated than a potentiometer strapped to the elbow, this project made us smile. Sometimes, it’s not just how much tech you’ve got, but how you use it. After all, a DDS pad is just a collection of switches under a rug.


Filed under: Arduino Hacks, The Hackaday Prize

The $2 32-Bit Arduino (with Debugging)

I have a bit of a love/hate relationship with the Arduino. But if I had two serious gripes about the original offering it was the 8-bit CPU and the lack of proper debugging support. Now there’s plenty of 32-bit support in the Arduino IDE, so that takes care of the first big issue. Taking care of having a real debugger, though, is a bit trickier. I recently set out to use one of the cheap “blue pill” STM32 ARM boards. These are available for just a few bucks from the usual Chinese sources. I picked mine up for about $6 because I wanted it in a week instead of a month. That’s still pretty inexpensive. The chip has a lot of great debugging features. Can we unlock them? You can, if you have the right approach.

The Part

For a few bucks, you can’t complain about the hardware. The STM32F103C8T6 onboard is a Cortex-M3 processor that runs at 72 MHz. There’s 64K of flash and 20K of RAM. There’s a mini-USB that can act as a programming port (but not at first). There’s also many 5 V-tolerant pins, even though this a 3.3 V part.

You can find a lot more information on this wiki. The board is a clone–more or less–of a Maple Mini. In fact, that’s one way you can use these. You can use the serial or ST-Link port to program the Maple bootloader (all open source) and use it like a Maple. That is, you can program it via the USB cable.

From my point of view, though, I don’t want to try to debugging over the serial port and if I have the ST-Link port already set up, I don’t care about a bootloader. You can get hardware that acts as a USB to ST-Link device inexpensively, but I happen to have an STM32VLDISCOVER board hanging around. Most of the STM32 demo boards have an ST-Link programmer onboard that is made to use without the original target hardware. On some of the older boards, you had to cut traces, but most of the new ones just have two jumpers you remove when you want to use the programmer to drive another device.

The “blue pill” designation is just a common nickname referring to the Matrix, not the pharmaceuticals you see on TV ads. The board has four pins at one edge to accommodate the ST-Link interface. The pin ordering didn’t match up with the four pins on the STM32VLDISCOVER, so you can’t just use a straight four-pin cable. You also need to bring power over to the board since it will have to power the programmer, too. I took the power from the STM32VLDISCOVER board (which is getting its power from USB) and jumpered it to my breadboard since that was handy.

The Plan

Programming the board is easy — I knew the community had done a lot of work to create a support package for it. You do need a recent version of the Arduino IDE (not the one that shows up in the default Ubuntu repositories). I downloaded version 1.8.1 from the Arduino website, just to be sure. That was the first step of my general plan of attack:

  1. Load the latest Arduino IDE
  2. Set the compile messages to verbose
  3. Use the Board Manager to install the STM32 F1 packages
  4. Get more tools
  5. Capture the build directory
  6. Run the right version of GDB

The recent versions of the Arduino IDE let you select platforms by using the Board Manager (available from the Tools | Board menu). However, if you look, you won’t see this board on the list. You’ll need to tell the IDE where to get the third-party support package. To do that, you can go to the Preferences menu item (on the File menu for Windows and Linux; I understand it is on the Arduino menu on the Mac). You need this same preferences dialog for step two, also.

Step 2 isn’t strictly necessary, but it will make step 5 easier. Just check “Show verbose output during compilation.” What you really need to know is the temporary directory the IDE uses for your build and this is the easiest way to do that, as you’ll see.

Further down the preferences screen is an entry for “Additional Boards Manager URLs.” If there’s already something there you should click the little button to edit the list. If it is empty, you can add this URL:

https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json

Now you can go back to the Tools | Board menu, pick Board Manager, and search for STM. You’ll probably see a few packages (I had three) but the one for the F1 will specifically mention the blue pill. Click the button to install and wait for it to do its thing.

Once installed, you’ll have some new entries on your board menu. When you have the blue pill selected, you’ll be able to pick a few options for uploading including the one we want: ST-Link.

Coding

The package has all the stuff you need to build and download programs using a variety of methods, including ST-Link. However, it doesn’t have the particular tool you need to do debugging.

It is simple enough to build the tools. The GitHub repo has the code and some simple build instructions. You do need libusb and CMake, but the page explains all that and once you have all the pieces, the build goes fast. For many OS choices, there are pre-built binaries you can use, too.

You’ll also need to know the USB ID of your ST-Link board and add it to the udev rules for Linux. If you don’t do this, you’ll need to be root to program the device and that’s not a good idea. However, depending on which ST-Link interface you use, it may already be there from other software or from the Arduino install. I’d try a test first and if it only works as root, you’ll need to update udev.

If you did your own build, I suggest running the tool stlink-gui to perform the test. You can also run st-info --descr

If you run stlink-gui, press the connect button with the ST-Link and blue pill powered up and connected. You should get the information about the device. If not, try as root. If that works, you need to update udev. I created a file, /etc/udev/rules.d/45-stlink.rules.

ACTION=="add" SUBSYSTEM=="usb", ATTR(idVendor)=="0483", 
     ATTR(idproduct)=="3744", MODE="0666", GROUP="usbusers"

You’ll need to modify that for the USB ID of your particular interface (mine was 0483:3744; the lsusb command can help). The mode allows all users to read and write the device. I made the group owner usbusers, but since everyone can access the device that probably isn’t strictly necessary.

Once you can do all that, try running the blink sketch from the IDE examples. Be sure to pick “Upload Method: STLink” from the Tools menu of the Arduino IDE. If it doesn’t work, you may need to use the tools you just built instead of the ones that come with the Arduino IDE. Mine worked but the debugging required the custom build (because the Arduino package didn’t ship with that particular tool built).

Finding the Tools and Build Directory

The Arduino IDE is pretty friendly, so it doesn’t try to install things like boards for all users, since that would require root. The board package you loaded winds up in your home directory under ~/.arduino15/packages/STM32/tools. There’s an STM32Tools directory and a few more levels down you’ll find copies of the ST-Link tools. If they don’t work, you can manually run the tools you built in the previous step to do your uploads. When we debug, we are going to do that anyway.

What’s really important though is back under the STM32/tools directory is another directory with the compiler that the IDE uses to compile your code. There’s also a matching version of GDB — the GNU Debugger — there that you will have to use.

If you loaded an example, make sure you save it to your own directory (I hate saying sketchbook). If you don’t, the IDE will make a private copy of any changes you make and things will get confusing.

Do a build (the checkmark icon) and — assuming you checked the box in step 2 — you’ll get a lot of output from the build tools. You might verify that the compiler in use is the one we mentioned above. You’ll also see that your program gets added to other things and put in a directory named something like /tmp/arduino_build_XXXXXX where the XXXXXX is a number. Your source code will be in this directory named something like sketch/Blink.ino. In the top-level directory will be the executable Blink.ino.elf. This is what you need to debug.

If you are comfortable editing your Arduino settings file (just be sure the IDE isn’t running first) you can also force a build directory using the build.path key. The IDE does have an “export binary” command (on the Sketch menu) that compiles to your sketch folder. However, this .bin file doesn’t have enough information for the debugger.

Debugging at Last

Finally, you can debug. Use the arm-none-eabi-gdb executable from the same directory as the GCC used to compile your program. This is important. If the versions don’t match you’ll get strange errors even though many things will seem to work. Provide the name of the elf file as an argument to GDB.

If you like, you can use the -tui flag to GDB to get a sort of text-based GUI. Either way, you have one more step to go. The st-util tool you built earlier can listen to the ST-Link interface and provides a socket that GDB can use to do debugging.

Start it like this:

st-util -p 1234

That will make it listen on port 1234. If you already use that port for something else, pick another one. Just remember that on Linux only root can listen on ports below 1024, so pick a bigger number.

Once that is running, you fire up GDB with your elf file name and issue the command:

target extended-remote :1234

Or, I’ve recently started using:

target remote :1234

You can run the two parts on different computers, so use a hostname if necessary (that is, devbox21:1234). Most times, the programs are on the same box and you can use localhost or omit it like I did. The difference between remote and extended-remote is that the server does not shut itself down at the end of an extended-remote session. It often works, but I have seen cases where I had to restart the server anyway, so lately I’ve been using plain-old remote to force me to restart it with each session.

A “load” command to GDB will now flash your program to the board. A typical session after a load might be:

break main
continue
list
n
n
n

The “n” command steps to the next instruction.You can find a lot more about using GDB in an earlier post. You also might find it easier to watch the walkthrough in this video:

A few caveats. First, optimization can cause your lines to execute out of order, or even go backwards. It can also cause variables to not be visible where they have been optimized out. The other thing to watch out for is that, in some cases, the debugger internally single steps. This can cause very slow execution of delay routines, for instance. You might reduce or remove delays while debugging or be careful where you try to single step instead of placing breakpoints.

Final Thoughts

It would be neat if the Arduino IDE let you debug inside of it. However, there are ways to do that using Eclipse (and GDB) or Visual Studio (if you use Windows). If you are like me and OK with the command line, you might think about using one of the Makefiles for Arduino instead of the IDE. If you aren’t OK with the command line, there are GUI shells for GDB that you could try. If you’d rather hack the ST-Link firmware, we’ve seen that done, too. If you miss doing printf’s, you might want to try a Black Magic probe, which ought to work about the same as the ST-Link interface, but also provides a serial port for printf and other mischief.

By the way, Arduino isn’t the only choice for this board. It is possible to use mBed and other development tools with them. But that’s a topic for a future post.


Filed under: Arduino Hacks, ARM
Hack a Day 30 Mar 18:01

Acoustic Coupler Pole-Vaults Over China’s Firewall

[agp.cooper]’s son recently went to China, and the biggest complaint was the Great Firewall of China. A VPN is a viable option to get around the Great Firewall of China, but [agp] had a better idea: an acoustic coupler for his son’s iPhone.

Hackaday readers of a recent vintage might remember an old US Robotics modem that plugged into your computer and phone line, allowing you to access MySpace or Geocities. Yes, if someone picked up the phone, your connection would drop. Those of us with just a little more experience under our belts will remember the acoustic coupler modem — a cradle that held a phone handset that connected your computer (indirectly) to the phone line.

With a little bit of CNC work, [agp] quickly routed out a block of plywood that cradled his son’s iPhone. Add in a speaker and a microphone, and that’s an acoustic coupler. There’s not much to it, really. The real challenge is building a modem.

In the late 90s, there were dedicated chipsets for modems, and before that, there was a 74xx-series chip that was a 300-baud modem. [agp] isn’t using anything like that. He’s building a modem with an Arduino. This is a Bell 103A-compatible modem, allowing an iPhone to talk to a remote computer at 300 bits per second. This is a difficult challenge; we’re not able to get 33kbps over a smartphone voice connection simply because of the codecs used. However, with a little bit of work, [agp] managed to build a real modem with an Arduino.


Filed under: Arduino Hacks

Panel Mount Display Solves The Problem Of Drilling Square Holes

[Absolutelyautomation] has a problem with seven-segment displays. Fitting these displays in an enclosure is a pain because you can’t drill perfectly square holes, and you will invariably mess up a few enclosures with overzealous file work. There is a solution to this problem – panel mount meters.

The bezels on these panel mount meters hide the imperfections in the enclosure, and usually don’t require screws. They are, however, dedicated displays, usually for temperature, RPM, or some other measurement.

[Absolutelyautomation] took one of these dedicated panel mount displays and turned it into an all-purpose device. Basically, it’s a panel mount Arduino with three seven-segment displays.

This project is built on perfboard cut down to fit inside the enclosure of a very cheap panel meter found at the usual suppliers. Tucked away underneath this perfboard is an ATmega, a few resistors, and the support parts to make everything go. This panel mount meter can either be a serial slave or as a standalone controller, programmable with the Arduino IDE. It’s cheap, too. You can check out [Absolutelyautomaion]’s video below.


Filed under: Arduino Hacks