coding

18 Articles

A Lightweight AVR IDE

February 17, 2019 by 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 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” →

Don’t Be A Code Tyrant, Be A Mentor

May 16, 2017 by 168 Comments

Hardware hacking is a way of life here at Hackaday. We celebrate projects every day with hot glue, duct tape, upcycled parts, and everything in between. It’s open season to hack hardware. Out in the world, for some reason software doesn’t receive the same laissez-faire treatment. “Too many lines in that file” “bad habits” “bad variable names” the comments often rain down. Even the unsafest silliest of projects isn’t safe. Building a robot to shine lasers into a person’s eyes? Better make sure you have less than 500 lines of code per file!

Why is this? What makes readers and commenters hold software to a higher standard than the hardware it happens to be running on? The reasons are many and varied, and it’s a trend I’d like to see stopped.

Software engineering is a relatively young and fast evolving science. Every few months there is a new hot language on the block, with forums, user groups, and articles galore. Even the way software engineers work is constantly changing. Waterfall to agile, V-Model, Spiral model. Even software design methodologies change — from pseudo code to UML to test driven development, the list goes on and on.

Terms like “clean code” get thrown around. It’s not good enough to have software that works. Software must be well commented, maintainable, elegant, and of course, follow the best coding practices. Most of these are good ideas… in the work environment. Work is what a lot of this boils down to. Software engineers have to stay up to date with new trends to be employable.

There is a certain amount of “born again” mentality among professional software developers. Coders generally hate having change forced upon them. But when they find a tool or system they like, they embrace it both professionally, and in their personal projects. Then they’re out spreading the word of this new method or tool; on Reddit, in forums, to anyone who will listen. The classic example of this is, of course, editors like the vi vs emacs debate.

Continue reading “Don’t Be A Code Tyrant, Be A Mentor” →

The Python Programming Language For Physical Hacking

September 5, 2012 by 12 Comments

We see projects here all the time that blend computing with the real world. Some people are naturally stronger on the mechanical end of things, whereas some are better with electronics or coding. All three specialities can be needed depending on your project. If your weakness lies in making a computer do your bidding, I might suggest that the Python language is a good one to learn.

I’ve been going through Learn Python the Hard Way, which is offered for free online, or you can pay for it if you so choose. I’ve published my thoughts on lessons 1-10 and 11-20 so far. As a mechanical engineer with limited (but not totally nonexistent) programming skills, it’s been an excellent experience so far.

If you’re wondering if Python is a good language to learn if you’d like to participate in [HAD] style projects, why not check out the following projects featured here:

Or just do a search of [HAD], and you’ll find many other projects for inspiration. If you’ve got a Python project to share, be sure to tell us about it in the comments!