There’s some debate on which program gets the infamous title of “First Computer Virus”. There were a few for MS-DOS machines in the 80s and even one that spread through ARPANET in the 70s. Even John von Neumann theorized that programs might one day self-replicate. To compile all of these early examples of malware, and possibly settle this question once and for all, [Mikko Hypponen] has started collecting many of the early malware programs into a Museum of Malware.
While unlucky (or careless) users today are confronted with entire hard drive encryption viruses (or worse), a lot of the early viruses were relatively harmless. Examples include Brain which spread via floppy disk, the experimental ARPANET virus, or Elk Cloner which, despite many geniuses falsely claiming that Apples are immune to viruses, infected Mac computers of the 80s. [Mikko] has collected many more from this era that can be downloaded or demonstrated in a browser.
Retrocomputing is an active community, with users keeping gear of this era up and running despite it being 30+ years old. This software, while malicious at the time, is a great look into what the personal computing world was like in its infancy. And don’t forget, if you have a beige computer from a bygone era, you can always load up our Retro Page.
Thanks to [chad] for the tip!
KiCAD remains a popular tool for designing PCBs and other circuits, and with good reason: it’s versatile and it’s got pretty much everything needed to build any type of circuit board you’d want. It also comes with a pretty steep learning curve, though, and [Jeff] was especially frustrated with the bill of materials (BOM) features in KiCAD. After applying some Python and Kivy, [Jeff] now has a BOM manager that makes up for some of KiCAD’s shortcomings.
Currently, the tool handles schematic import, like-component consolidation, and a user-managed parts database that can be used to store and retrieve commonly used parts for the future. All of the changes can be saved back to the original schematic. [Jeff] hopes that his tool will save some time for anyone who makes more than one PCB a year and has to deal with the lack of BOM features native to KiCAD.
[Jeff] still has some features he’d like to add such as unit tests, a user guide, and a cleaner user interface. What other features are you anxious to see added to KiCAD?
This script is a great tool for anyone who has had similar frustrations. KiCAD is popular to modify and expand, too: there have been tools for mechanical CAD export, a parts-generator and cost-tracker, and an Eagle to KiCAD converter if you’re thinking of making the switch.
When boards were larger and components mostly through hole, designers could put a lot of information on the silk legend – reference designator, values, additional text and so on. But with surface mount components becoming smaller and board real estate at a premium, modern boards do not have a lot of information marked on the silk layer. If you are building and distributing a short run of kits, perhaps for a round of beta testing, then [Adam Greig]’s StickerBOM python script for KiCad can be really handy. StickerBOM is a KiCad BOM exporter designed for people stuffing boards by hand. It generates a PDF for printable sticky labels, where each label reflects one BOM line from a supplier. You then stick these labels on the bags from your supplier, and they show you where the parts go.
The labels get printed with the reference designator, quantity, component value, package, vendor and part number. It also adds a drawing of the PCB with the relevant parts highlighted for easy location identification. To use it, schematic symbols must have the supplier field and part number added. The script can be run from the command line, or from the BOM manager in eeschema. The script is set up for Avery L7164 labels, but this setting can be changed. It’s still work in progress so there’s a couple of bugs to be aware of. It cannot process the bottom layer of the board, and the result is only as good as the data you provide. And if you have a large board with components spread all over, the resultant graphic printed on the label may not be ideal.
We are hoping this, and other scripts such as the Part generator and Cost spreadsheets or the script for mechanical CAD export, get added to future releases of KiCad. The KiCad version 5 Developer’s road map document already has some really nice feature additions in the works.
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?””