Developers love their macs, and if you look at the software that comes with it, it’s easy to see why. OS X is a very capable Unix-ey environment that usually comes on very capable hardware. There is one, huge, unbelievable shortcoming in OS X: the debugger sucks. GDB, the standard for every other platform, doesn’t come with OS X and Apple’s replacement, LLDB is very bad. After crashing Safari one too many times, [Brandon Edwards] and [Tyler Bohan] decided they needed their own debugger, so they built one, and presented their work at last weekend’s Shmoocon.
Building a proper tool starts with a survey of existing tools, and after determining that GDB was apparently uninstallable and LLDB sucked, their lit review took a turn for the more esoteric. Bit Slicer is what they landed on. It’s a ‘game trainer’ or something that allows people to modify memory. It sort of works like a debugger, but not really. VDB was another option, but again this was rough around the edges and didn’t really work.
The problems with the current OS X debuggers is that the tools used by debuggers don’t really exist. ptrace is neutered, and the system integrity protection in OS X El Capitan has introduced protected locations that can not be written to by root. Good luck modifying anything in /Applications if you have any recent Mac.
With the goal of an easy-to-use debugger that was readily scriptable, [Brandon] and [Tyler] decided to write their own debugger. They ended up writing the only debugger they’ve seen that is built around kqueue instead of ptrace. This allows the debugger to be non-invasive to the debugged process, inject code, and attach to multiple processes at once.
For anyone who has every stared blankly at the ‘where is GDB’ Stack Overflow answers, it’s a big deal. [Brandon] and [Tyler] have the beginnings of a very nice tool for a very nice machine.
A well organized approach to a project is a delight to see. [Pavel Gesyuk] takes just that approach with the experiments on his blog. Experiment 13 is a multi-part series using a Raspberry Pi as the heart of a weather station. [Pavel] is looking at wind speed and direction, and temperature measurement, plus solar power for the station. One of his videos, there are many, is after the break.
The anemometer and direction sensors are stock units wired to a Raspberry Pi A+ using an analog to digital daughter board. The data from the temperature sensor is acquired using I2C. During one part of the experiment he uses an EDIMAX WiFi adapter for collecting the data.
Python is [Pavel’s’ language of choice for development and freely shares his code for others to see. The code collects the data and displays it on a monitor connected to the Pi. The experiment also attempts to use solar power to charge batteries so the station is not dependent on mains power.
The mechanical assembly shows attention to detail commensurate with his project presentation and we respect how well organized the work is.
Continue reading “Raspberry Pi Wind Measurement”
The Arduino software environment, including the IDE, libraries, and general approach, are geared toward education. It’s meant as a way to introduce embedded development to newbies. This is a great concept but it falls short when more serious development or more advanced education is required. I keep wrestling with how to address this. One way is by using Eclipse with the Arduino Plug-in. That provides a professional development environment, at least.
The code base for the Arduino is another frustration. Bluntly, the use of
main() being hidden really bugs me. The mixture of C and C++ in libraries and examples is another irritation. There is enough C++ being used that it makes sense it should be the standard. Plus a good portion of the library code could be a lot better. At this point fixing this would be a monumental task requiring many dedicated developers to do the rewrite. But there are a some things that can be done so let’s see a couple possibilities and how they would be used.
Continue reading “Code Craft-Embedding C++: Hacking the Arduino Software Environment”
“What’s the weather like, honey?” “I don’t know. Let me check the mirror.” The mirror?
Both [Dylan Pierce] and [Dani Eichorn] have mirror projects that display the weather. They took two different approaches which makes for an interesting comparison. [Dylan] uses a Rapsberry Pi with an actual monitor behind the mirror. [Dani] puts an OLED behind the mirror driven by a ESP8266. It appears there is more than one way to hack a mirror, or anything, which is what makes hacking fun.
Raspberry Pi Booting
Framing Mirror and Monitor
[Dani] started with a picture frame, adding tinting film to the glass so it would reflect. A small section of tint was removed to allow the OLED to be seen. The ESP8266 software connects to the Weather Underground to get the latest information.
The Raspberry Pi version by [Dylan] puts a 27″ monitor behind the mirror. That is either terribly impressive or way over the top but seeing Linux boot behind the mirror makes it worth the effort. The Pi generates a web page which makes this adaptable as a general purpose kiosk.
A video of [Dani’s] mirror in operation, after the break.
Continue reading “Magic Mirror on the Wall, “Is Pi or ESP, Fairest of All?””
One barrier for those wanting to switch over from Eagle to KiCad has been the lack of a way to convert existing projects from one to the other. An Eagle to KiCad ULP exists, but it only converts the schematic, albeit with errors and hence not too helpful. And for quite some time, KiCad has been able to open Eagle .brd layout files. But without a netlist to read and check for errors, that’s not too useful either. [Lachlan] has written a comprehensive set of Eagle to KiCad ULP scripts to convert schematics, symbols and footprints. Board conversion is still done using KiCad’s built in converter, since it works quite well.
Overall, the process works pretty well, and we were able to successfully convert two projects from Eagle. The entire process took only about 10 to 15 minutes of clean up after running the scripts.
The five scripts and one include file run sequentially once the first one is run. [Lachlan]’s scripts will convert Eagle multi sheet .sch to KiCad multi sheets, place global and local net labels for multi sheets, convert multi part symbols, build KiCad footprint modules and symbol libraries from Eagle libraries, create a project directory to store all the converted files, and perform basic error checking. The Eagle 6.xx PCB files can be directly imported to KiCad. The scripts also convert Via’s to Pads, which helps with KiCad’s flood fill, when Via’s have no connections – this part requires some manual intervention and post processing. There are detailed instructions on [Lachlan]’s GitHub repository and he also walks through the process in the video.
Continue reading “Eagle to KiCad made easy”
We’ve seen ’em before: the charts and graphs in poorly photocopied ’80s datasheets, ancient research papers, or even our college prof’s chalkboard chicken scratch. Sadly, this marvelously plotted data is locked away in a poorly rendered png or textbook graphic. Fortunately, a team of programmers have come the rescue to give us the proper thieving tool to lift that data directly from the source itself, and that tool is Engauge.
Engauge is an open source software tool that enables to convert pictures of plots into the numerical representation of their data. While some of us might still be tracing graphs by hand, Engauge enables us to simply define reference points on the graph, and a clever image-processing algorithm extracts the curve for us automatically! Sure, there’s a little fine-tuning to determine what counts as data, but the net result is an all-in-one software tool that eats pictures and produces data–no intermediate steps required!
Engauge has been helping scientists and engineers preserve ancient data logs for years now, but it’s a tool that’s still fresh today when we’re recording from an analog o’scope or lifting those xs and ys off a textbook. In a world that’s increasingly digital, we’ve got the Engague developers to thank for arming us with the right tool for the job. All that said, If graph-thieving isn’t your thing, try spline-thieving to go from camera to CAD.
Engauge is a little lacking in the demo-video department, but we dug up a quickie on YouTube.
Thanks for the tip, [Jason]!
Continue reading “Engauge Makes Graph Thieving a Cinch”
[Anthony] at UCLA needed to verify the shape of a laser beam. Commercial units for this, as you would expect, are expensive. But a Raspberry Pi with a Pi Noir camera easily handles the task. Not only is the use of the Pi cool but so is the task – they are using lasers to cool molecules to study quantum effects. The Pi camera without the IR filter captures a wide bandwidth making it suitable for use with non-visible lasers. [Anthony] captures the beam along two axes and plots both curves on the LCD touchscreen. That data, based on the pictures, is also available on a host PC. All this in a super compact package with a 7″ touch screen display.
2D crystal of Yb ions.
One reason I find this fascinating is I did something similar 1977 at the University of Rochester Laboratory for Laser Energetics. My project was measuring the energy cross-section of a laser beam. The research goal of the Laboratory was the study of inertial confinement laser fusion. While [Anthony] uses an entire camera my project was limited to a 1 dimensional array of charge coupled devices (CCD). The output went to a Tektronix storage terminal and was printed on thermal paper for reference. He uses Python running on the target system. My work used a Z80 development system the size of a tower PC to write my program in assembly language which was then executed on a single board computer. We’ve come a long way. My code is long gone but you can get [Anthony’s] on GitHub.