Code For Hackers

September 19, 2020 by Elliot Williams 57 Comments

Mike and I were talking about two very similar clock projects we’d both built recently: they both use ESP8266 modules to get the time over WiFi and NTP, and they both failed. Mike’s failed because he was visiting relatives in a different timezone with different WiFi credentials, and mine failed because daylight savings time caught me off-guard. In both cases, we hard-coded stuff that could obviously change, but we drew vastly different conclusions.

Mike thought he’d solve his WiFi problem with a fallback to a captive portal, and maybe would have to figure out some web interface for configuring the timezone. A very clean, professional solution. Me? I’ve got good comments in the code, can find the UTC offset (or the WiFi creds) in a few minutes, and flash the new version up simply by fetching a USB cable, for something that happens twice a year. It’s hardly worth the trouble to cobble together a web interface.

We’ve accidentally embodied a quandary that spans both the hardware and software worlds: should flexibility be exposed to the end-user or to the hacker who can peer under the hood or open up the source code? (And what if the end-user is the hacker?) What are the tradeoffs, in project complexity and in ease of use?

And in this, Mike is on the side of right and good, and I’m the heretic. I don’t always write my code to be extensible or re-usable. I sometimes write it to be quickly re-edited and patched whenever I need to. Is it full of magic numbers? Sure! But I know just where they are and how to change them. Heck, most are even well documented in their own header file. You could probably figure it out just about as fast. Would my father-in-law be able to tweak the timezone? Nope! But this ain’t his project anyway.

Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more. Don’t be afraid to edit code. Tweak, compile, and re-flash when the situation changes. After all, that’s how you got the code there in the first place.

And although I’m on the wrong end of history, in this case I was right. You see, before daylight savings time could come around again, and I could have made use of that captive portal that I didn’t bother coding up anyway, my son entered first grade. Everything needs to be changed, from the hardware to the software. Will I code up the next version with flexible time regimes? As flexible as I need it to be, but not more.

Classic 8-Bit Computing The Atari Way

April 29, 2020 by Bryan Cockfield 9 Comments

In the classic gaming world, even before the NES arrived on the scene, there was no name more ubiquitous than Atari. Their famous 2600 console sold almost as many units as the Nintendo 64, but was released nearly 20 years prior. In many ways, despite making mistakes that led to the video game crash of the early 80s, Atari was the first to make a path in the video game industry. If you want to explore what the era of 8-bit computing was like in the Atari age, a new resource is compiling all kinds of Atari-based projects.

This site has everything, from assembling Atari 8-bit computers based on the 6502 chip, to programming them in BASIC and assembly, to running official and homebrew games on the hardware itself. This was put together by [Jason H. Moore] who grew up around Atari systems and later, their home computers. He even puts his biomedical experience to use here by designing a game for the 2600 called Gene Medic which can be found at the site as well.

If you grew up in the 70s and 80s and are looking for a bit of Atari nostalgia this site is the place to go. It’s even worth a visit from younger folks as well since the 8-bit world is a lot easier to get immersed in and learn the fundamentals of computer science. Of course, if you want to take it the other direction, it’s possible to modify the old Atari to add a few modern conveniences.

Photo via Evan-Amos

The Ifs Make Learning To Code Child’s Play

November 11, 2019 by Dan Maloney 12 Comments

Anyone who has done the slightest bit of programming knows about the “Hello, World!” program. It’s the archetypal program that one enters to get a feel for a new language or a new architecture; if you can get a machine to print “Hello, World!” back to you, the rest is just details. But what about teaching kids to program? How does one get toddlers thinking in logical, procedural ways? More particularly, what’s a “Hello, World!” program look like for the pre-literate set?

Those are the sort of questions that led to The Ifs by [Makeroni Labs]. The Ifs are educational toys for teaching kids as young as three the basics of coding. Each If is a colorful plastic cube with a cartoon face and a “personality” that reflects what the block does – some blocks have actuators, some have sensors. The blocks are programmed by placing magnetic tabs on the top representing conditions and actions. A kid might choose to program a block to detect when it’s being shaken, or when the lights come on, and then respond by playing a sound or vibrating. The blocks can communicate with each other too, so that when the condition for one block is satisfied, something happens on another block.

The Ifs look like a lot of fun, and they’re a great jumpstart on the logical thinking skills needed for coders and non-coders alike. We’re not alone in thinking this is a pretty keen project – the judges for this year’s Hackaday Prize selected The Ifs as one of the twenty finalists. Will it win? We’ll find out next week at the 2019 Hackaday Superconference. If you won’t be in Pasadena with us, make sure you tune in to the livestream to watch the announcement.

Four Years Of Learning ESP8266 Development Went Into This Guide

July 30, 2019 by Bryan Cockfield 20 Comments

The ESP8266 is a great processor for a lot of projects needing a small microcontroller and Wi-Fi, all for a reasonable price and in some pretty small form factors. [Simon] used one to build a garage door opener. This project isn’t really about his garage door opener based on a cheap WiFi-enabled chip, though. It’s about the four year process he went through to learn how to develop on these chips, and luckily he wrote a guide that anyone can use so that we don’t make the same mistakes he did.

The guide starts by suggesting which specific products are the easiest to use, and then moves on to some “best practices” for using these devices (with which we can’t argue much), before going through some example code. The most valuable parts of this guide especially for anyone starting out with these chips are the section which details how to get the web server up and running, and the best practices for developing HTML code for the tiny device (hint: develop somewhere else).

[Simon] also makes extensive use of the Chrome developers tools when building the HTML for the ESP. This is a handy trick even outside of ESP8266 development which might be useful for other tasks as well. Even though most of the guide won’t be new to anyone with experience with these boards, there are a few gems within it like this one that might help in other unrelated projects. It’s a good read and goes into a lot of detail about more than just the ESP chips. If you just want to open your garage door, though, you have lots of options.

Expert Says Don’t Teach Kids To Code

March 14, 2019 by Al Williams 220 Comments

I was a little surprised to see a news report about Andreas Schleicher, the director of education and skills at OECD — the Organization for Economic Cooperation and Development. Speaking at the World Innovation Summit for Education in Paris, Schleicher thinks that teaching kids to code is a waste of time. In particular, he seems to think that by the time a child today grows up, coding will be obsolete.

I can’t help but think that he might be a little confused. Coding isn’t going away anytime soon. It could, of course, become an even deeper specialty, and thus less generally applicable. But the comments he’s made seem to imply that soon we will just tell smart computers what we want and they will just do that. Somewhat like computers work on Star Trek.

What is more likely is that most people will be able to find specific applications that can do what they want without traditional coding. But someone still has to write something for the foreseeable future. What’s more, if you’ve ever tried to tease requirements out of an end user, you know that you can’t just blurt out anything you want to a computer and expect it to make sense. It isn’t the computer’s fault. People — especially untrained people — don’t always make sense or communicate unambiguously.

Continue reading “Expert Says Don’t Teach Kids To Code” →

A Lightweight AVR IDE

February 17, 2019 by Lewin Day 11 Comments

It’s entirely possible to do your coding in vim or emacs, hammering out hotkeys to drive the interface and bring your code to life. While working in such a way has its charms, it can be confronting to new coders, and that’s before even considering trying to understand command line compiler settings. The greenhorn coder may find themselves more at home in the warm embrace of an IDE, and [morrows_end] has now built one for those working with AVR assembly code.

The IDE goes by the name of Simple AVR IDE, or savr_ide for short. Programmed in C++ with the FLTK widget library, [morrows_end] has tested it on Windows XP, but notes that it should successfully compile for Linux, Unix, and even MacOS too.

All the basic features are there – there’s syntax highlighting, as well as integration with the AVRA assembler and AVRDUDE for programming chips. It’s a tool that could make taking the leap into assembly code just that little bit easier. For another taste of bare metal coding, check out [Ben Jojo]’s discussion of x86 bootloaders.

Rubber Duck Debugging The Digital Way

June 10, 2018 by Dan Maloney 16 Comments

Anyone who slings code for a living knows the feeling all too well: your code is running fine and dandy one minute, and the next minute is throwing exceptions. You’d swear on a stack of O’Reilly books that you didn’t change anything, but your program stubbornly refuses to agree. Stumped, you turn to the only one who understands you and pour your heart out to a little yellow rubber duck.

When it comes to debugging tools, this digital replacement for the duck on your desk might be even more helpful. Rubber duck decoding, where actually explaining aloud to an inanimate object how you think the code should run, really works. It’s basically a way to get you to see the mistake you made by explaining it to yourself; the duck or whatever – personally, I use a stuffed pig– is just along for the ride. [platisd] took the idea a step further and made his debugging buddy, which he dubs the “Dialectic Ball,” in the form of a Magic 8-Ball fortune teller. A 3D-printed shell has an ATtiny84, an accelerometer, and an LCD screen. To use it, you state your problem, shake it, and read the random suggestion that pops up. The list has some obvious suggestions, like adding diagnostic print statements or refactoring. Some tips are more personal, like talking to your local guru or getting a cup of coffee to get things going again. The list can be customized for your way of thinking. If nothing else, it’ll be a conversation piece on your desk.

If you’re more interested in prognostication than debugging, we have no shortage of Magic 8-Ball builds to choose from. Here’s one in a heart, one that fits in a business card, and even one that drops F-bombs.

Continue reading “Rubber Duck Debugging The Digital Way” →