Is developing on an Arduino too slow? Are Phidgets too expensive? When might you use one or the other? Hackaday regular [Ken] breaks down what he learned from three experimental time trials.
The main development differences between Arduino and Phidgets are a mix of flavor preferences and some hard facts. The Arduino is open source, Phidgets are proprietary. Arduino requires a mix of hard- and software where Phidgets only needs (and only allows) a connection to a full computer but enables high level languages – it is expected to get the job done sooner and easier. And finally, Arduinos are cheap, Phidgets are 3-5x the cost.
The three time trials were common tasks: 1. Blink an LED. 2. Use a pot to turn a servo. 3. Build a pedometer. For [Ken], the Phidgets won in each of the three experiments, but not significantly: 37%, 45%, and 25% respectively. The difference is only minutes. Even considering time value, for most hackers it is not worth the cost.
In context, the advantages of a mildly more rapid development on the simplest projects are wasted away by needing to rebuild a permanent solution. Chained to a PC, Phidgets are only useful for temporary or fixed projects. For many of our readers that puts them dead in the water. Arduinos may technically be dev kits but are cheap enough to be disposed of in the project as the permanent solution – probably the norm for most of us.
[Ken] points out that for the software crowd that abhor electronics, Phidgets plays to their preferences. Phidgets clips together their pricey peripherals and the rest is all done in code using familiar modern languages and libraries. We wonder just how large this group could still be; Phidgets might have been an interesting kit years ago when the gulf between disciplines was broader but the trend these days is towards everyone knowing a little about everything. Hackaday readers probably represent that trend more than most, but let us know if that seems off.
[Ken]’s article has much more and much better detailed explanations of the experiments and the tradeoffs between the platforms.
If you enjoy watching parallel engineering, see the time-lapse video below for a split screen of the time trials.
Continue reading “Arduino vs. Phidgets – Dev Time Trials”
[Ádám] participates in a competition called KöMaL. It’s a 9-times-a-month journal for junior high and high school students featuring math and physics problems. [Paul Erdős], one of the most published mathematicians of all time, was a huge participant and by far the most notable student to crack open a copy of KöMaL in its hundred-year history. [Ádám] was trying his hand at a problem in Excel, but the official rules prohibit the use of Excel macros. In a daze, he came up with one of the most clever uses of Excel: building an assembly interpreter with the most popular spreadsheet program.
This is a virtual Harvard architecture machine without writable RAM; the stack is only lots and lots of IFs. The instructions – mostly load, MOV, JNZ, INC, and CMP solves this problem, examining two inputs to see if they multiples of each other. If you’re wondering, an example cell from [Ádám]’s Excel sheet looks like this:
[Ádám] has provided his Excel solution to the problem, available on the hackaday.io. It’s in Hungarian which really shouldn’t matter since it’s basically Excel and a pseudo-x86 instruction set. but the column labels will require a bit of Google Translate.
The history of software is littered with developers that built a great product, gave people a reasonable option to license the software, and ended up making a pittance. There’s a reason you don’t see shareware these days – nobody pays. It looks like [Gates] had a point with his Open Letter to Hobbyists.
Such is the case with Atanua. [Jari] built a nice little graphical logic simulator that has tens of thousands of downloads, and is being used in dozens of universities. [Jari] has sold only about 60 licenses for Atanua, netting him only a few thousand Euro. You can’t develop software with a pittance, so now [Jari] is giving Atanua away. This neat little logic simulator has reached the end of its life, the license is free, and [Jari] is out of the business.
This isn’t an ideal situation, but [Jari] is strongly considering open-sourcing Atanua. The code is a little bit of a mess at the moment, and cleaning it up will require a bit of work. [Jari] is leaving the option to buy a license for Atanua open, and anyone who wants to see this bit of software open sourced could buy a license or hundred.
While this isn’t great news for [Jari], if you’re looking for a neat tool to learn digital logic, you now have a very nice free option. Atanua simulates individual logic gates, 74-series chips, and even an 8051 microcontroller in real-time (up to about 1 kHz), with enough buttons, LEDs, and displays to do some very cool stuff. It’s more than enough to learn digital logic on, and good enough for a test bed for some odd and bizarre projects you might have floating around your head.
When implementing USB on a microcontroller, most people are going to reach for V-USB if they’re using an AVR, one of Microchip’s USB libraries if a PIC is involved, or any number of the USB libraries for various ARM processors. [Kevin] had a different idea. As a challenge to himself, he wrote a USB device driver for the Teensy 3.1 microcontroller board, getting as close to the bare metal as he could get.
Writing a USB device driver first required a literature review. There are a few peculiarities in the Freescale K20 family of microcontrollers – the one found in the Teensy 3.1 – that dictate the need for a specific memory layout, using several clocks, and handling all the USB descriptors. [Kevin] started with the clocks, every last one of which must be enabled. The clock is generated by the Multipurpose Clock Generator from a 16MHz crystal, PLL’ed to the frequencies the USB module needs, and sent out over the System Integration Module.
Following the flowcharts and sequences found in the Freescale reference guide told [Kevin] exactly what needed to be done with the startup sequence, and offered a few suggestions on what needed to be done to set up all the interrupts. [Kevin] spent an incredible amount of time documenting, programming, and smashing his head against the keyboard for this tutorial, but he does give everyone a great opportunity to learn from his struggles.
While [Kevin] has a mostly complete USB device driver, his work is far from done. That’s alright, because this project wasn’t meant to be a full-featured driver; it’s still missing real error handling, strings in the configuration, and a real VID/PID. That’s alright, it’s still a great exercise in building something from scratch, especially something that very few people have built successfully.
Oh, blatant Hackaday Store plug for the Teensy 3.1.
When the 4D Systems display first arrived in the mail, I assumed it would be like any other touch display – get the library and start coding/debugging and maybe get stuff painted on the screen before dinner. So I installed the IDE and driver, got everything talking and then…it happened. There, on my computer screen, were the words that simply could not exist – “doesn’t require any coding at all”.
I took a step back, blinked and adjusted my glasses. The words were still there. I tapped the side of the monitor to make sure the words hadn’t somehow jumbled themselves together into such an impossible statement. But the words remained… doesn’t.require.any.coding.at.all.
Continue reading “Making Embedded GUI’s Without Code”
[Jordan] has been playing around with WS2812b RGB LED strips with TI’s Tiva and Stellaris Launchpads. He’s been using the SPI lines to drive data to the LED strip, but this method means the processor is spending a lot of time grabbing data from a memory location and shuffling it out the SPI output register. It’s a great opportunity to learn about the μDMA available on these chips, and to write a library that uses DMA to control larger numbers of LEDs than a SPI peripheral could handle with a naive bit of code.
DMA is a powerful tool – instead of wasting processor cycles on moving bits back and forth between memory and a peripheral, the DMA controller does the same thing all by its lonesome, freeing up the CPU to do real work. TI’s Tiva C series and Stellaris LaunchPads have a μDMA controller with 32 channels, each of which has four unique hardware peripherals it can interact with or used for DMA transfer.
[Jordan] wrote a simple library that can be used to control a chain of WS2812b LEDs using the SPI peripheral. It’s much faster than transferring bits to the SPI peripheral with the CPU, and updating the frames for the LED strip are easier; new frames of a LED animation can be called from the main loop, or the DMA can just start again, without wasting precious CPU cycles updating some LEDs.
Quick, how do you wire up an SPI bus between a microcontroller and a peripheral? SCK goes to SCK, MISO goes to MISO, and MOSI goes to MOSI, right? Yeah. You’ll need to throw in a chip select pin, but that’s pretty much it. Just wires, and it’ll most likely work. Now add a second device. The naïve solution found in thousands of Arduino tutorials do the same thing; just wires, and it’ll probably work. It’s not that simple, and Mr. Teensy himself, [Paul Stoffregen] is here to show you why.
When using multiple SPI devices, a pullup resistor on the chip select lines are a really great idea. Without a pullup, devices will work great when used alone, but will inexplicably fail when used together. It’s not magic; both devices are listening to the bus when only one should be. Putting a pullup on the CS lines keeps everything at the right logic level until a device is actually needed.
How about the MISO line? Most peripherals will disconnect their pins when the chip select signal is active, but there are exceptions. Good luck finding them. There is an easy way to check, though: just connect two resistors so the MISO line floats to a non-logic level when the CS pin is high, and check with a voltmeter. If MISO is driven high or low, you should put a small tri-state buffer in there.
That just covers hardware, and there are a few things you can do in software to reduce the number of conflicts when using more than one SPI device. One of these methods is transactions, or defining the clock rate, setting MSB or LSB first, and the polarity of the clock. Newer versions of the Arduino SPI library support transactions and the setup is very easy. In fact, transaction support in the Arduino library is something [Paul] worked on himself, and gets around the problem of having SPI-related code happening in both the main loop of a program and whenever an interrupt hits. Awesome work, and a boon to the Arduino makers around the world.