The Hackaday Prize isn’t exclusively about building things that will help the planet; you can also build things that will enable others to build things to save the planet. [Eric] isn’t saving the world with his commonCode library, but it will make it vastly easier for other people to build the next great Thing.
The idea behind commonCode is the same as shared libraries you’ll find in any desktop application of reasonable size; it provides a common library for AVR microcontrollers to build just about anything. Bit manipulation, an interface for timers, math functions, graphics, I/O, and peripheral drivers are all available in the commonCode library. This makes it easy for the developmentally challenged among us to create whatever project they want.
The commonCode library wasn’t created just for The Hackaday Prize. [Eric] has been tinkering around with AVRs since well before the Arduino existed, and he has dozens of projects in permanent installations. It’s a great way to give back to the community, and the perfect way to allow people to develop their own things to solve whatever problem they have in mind.
Awesome! Thanks for the write-up, Brian!
When you put it that way, I should rush to get this thing ready so someone can win the prize using it… Alright, maybe next year.
Pardon my ignorance, but could someone point out the advantages of using this versus basing a project on Arduino?
Arduinos are more expensive than microcontrollers. Also sometimes one needs to make smaller device or needs more I/O pins, different peripherals, etc. Using Arduino (or RPi) to blink a LED when one can use either Attiny, PIC10F, plain NE555 or two transistors is like hunting mosquitoes with shotgun.
Moryc – What are you writing about? You blink an LED with a 328 in order to learn how to use the tools and to verify your hardware and software are working correctly.
Please don’t comment until you have a better understanding of hardware and programming.
I just meant a situation, where simple tasks are done by complex devices, because designer/programmer doesn’t know better. Like making a LED blinker with Arduino. I’ve seen a simple clock made on Parallax Propeller. In other words a simple task programmed on device that can do so much more. And if my memory serves me right, that was a contest entry. That was my point.
And I know a thing or two about hardware and software design, thank you very much.
Actually, I understood that as an explanation to the original commenter about why one might choose a smaller uC over an arduino… as in “one wouldn’t use an arduino to build a television remote that’s going to be mass-produced.”
Having never used the arduino toolchain, I can’t make that comparison for you. The best I can say is to click the link and read the project description. If you come to some conclusions, please share!
…
Some thoughts regarding why I never “switched over” and have put so much effort into this system for my own needs:
As I understand arduinos, they are based on only a handful of AVR devices. My ‘commonCode’ attempts to work with all AVR devices. Further, it is becoming increasingly device/platform-independent. I even use it for OpenGL desktop applications.
I don’t really like working with IDEs
I wanted this system and code to be compatible with common/reliable/enduring cross-platform standards and a minimum of necessary tools, while hopefully still being compatible with most general-purpose IDEs
I tend to reinvent the wheel
This system keeps the commonCode in a central location and automatically handles multiple versions/dependencies/bug-fix-trickle-down
This system attempts to aim at various issues I’ve noticed in seemingly de-facto embedded/kernel design techniques such as the need to download/extract all kernel source (including drivers for entirely different platforms!)…
The learning experience! The vast vast majority of the code is my own work; I know it inside and out. I develop and test in a methodical manner, so I can quickly locate bugs or fine-tune to new/specific needs… something that’s quite a bit more difficult for me when using someone else’s code “pile”
I comment heavily, including things like ascii-art timing diagrams in the code
Configurable/Size Optimizations… lots
…
Plausibly these commonThings could be ported to arduino or other environments without too much difficulty, maybe even the commonCode system itself. That might be a good pursuit at some point.
…
But as far as a beginner is concerned, a well-established development system/community like arduino would probably be a better starting point. (For now?) Excepting maybe the most massochistic of beginners ;)
That’s a very ambitious project. I think that resource allocation and constraints are a big deal on platforms which are more complicated than these oldish AVRs.
Infineon went a quite interesting (and free open source) way by using the The ECLiPSe Constraint Programming System (http://eclipselp.org) to solve the various dependency problems between io-pins, timers, etc. for their ARM Cortex development environment.
As I begin developing for more sophisticated devices, this could be handy. (looks to be a dead-link, though? I’ll try google-fu at some point). Thanks
Far from the best code I’ve seen. Rambling comments, dead code, …
https://github.com/ericwazhung/meh-polled_uar/blob/master/_commonCode_localized/polled_uar/0.51-gitHubbing/polled_uar.c
Wow, dude… if your blog didn’t look potentially-useful, I’d assume this message was nothing more than the spoutings of a “scour-bot” with a high troll-setting. But I’ll chalk that up to my sense of being-stepped-upon and instead give you thanks for so succinctly summarizing two of the project log-entries as well as the “Current Status” located in the project-details.
….
Indeed: to anyone actually thinking about *using* [pieces of] this project in its *current state*: Don’t, unless you’re a developer willing to help work out bugs!
I’ll also take this opportunity to point out, again, that commonCode, like many of the prize-entries, is VERY PRE-RELEASE, and further, that the push for making it public is really about the centralization/versioning/distribution-system rather than the code itself…
…
TL;DR: yep. I don’t claim otherwise. Please read the project description!
I wouldn’t worry to much, comments like his would only come from someone that has never been involved with a large project. I doubt he has ever worked on anything with more than a few files.
Large rambling blocks of comments are common and dead code is a place holder for working code to come.
Thanks, Neuntoter. That last sentence is up there amongst quotes from some of the best philosophers!
…
Among other things, dead-code is also a good reminder of how things were, so that they won’t be repeated…
…
In fact, it’s always been a nebulous-idea floating in my mind: something like a multi-dimensional text-editor which intentionally keeps things like dead-code, ancient comments, comments on why it didn’t work, and every revision therein (the third dimension being something like, but not limited to, time?), nevermind expandable commentaries, for purposes exactly like this.
…
Hunter Thompson allegedly wrote his novels on a single continuous roll of paper… Yet watch “Where the Buffalo Roam” and you’ll know he’d pick it up and set it down for hours/days at a time… sometimes even stuck in the middle of a paragraph. That typewritten-roll isn’t “stream of conscience” it’s more like… carefully-selected bottles of conscience funneled one-by-one through a straw. And, is there really such thing as a “stream of conscience” anyhow?
We have computers now which can add topology and depth to that roll of paper (rather, straw)… could turn that artificially-linearized expression of the human-experience into the friggin’ fractal that more closely approximates it; yet, it seems, even this far in the game the best we’ve come up with is hyperlinks and ‘diff’?!
Wow! Amongst the HaD-blog-follower-crowd, I can’t believe no one took the opportunity to point out the absurdity of this write-up! There’s no Edit button, so:
Of course, Hunter Thompson isn’t the dude; obviously I meant Jack Kerouac… And, of course, “Where the Buffalo Roam” doesn’t apply to him; so let’s rephrase that sentence from “Yet, watch … and you’ll know he’d…” to something more like: “I’d find it incredibly hard to believe he (or any writer) wouldn’t pick it up and set it down for hours/days at a time…”
Having work-in-progress code is normal, but keep it separate from the working code. I have lots of code that didn’t work out, so it never went beyond my local version control system.
Good comments help people use the code, and are rather short. The best code often doesn’t need comments. it’s OK to document your rhought process in writing/designing, but put that in your blog, not the code comments.
Thank you, Ralph. You have proven yourself exactly the audience I never intended this for :)
Shall we waste time and emotions on trying to educate entirely different perspectives on why ours is “the perspective” or shall we just chalk it up to differing goals? Oooooh, but how I SO want to educate you.
That’s not to say my code meets even my own standards… it could certainly stand to be improved, and some of your suggestions are spot-on in many of those cases. But my code will likely never go without my thought-process, thank you. Code without comments, even really good code, to me, might as well be written in machine-language. I dunno about you, but I think in English long before translating that to code. And the reverse is much easier if that English sits alongside the code.
Thanks for the thought-points, it’s really helping me refine my thoughts on how to word my project-description…
Ohhh! You’re THIS dude:
http://hackaday.com/2015/06/05/embed-with-elliot-multiplexing-spi-uses-few-pins/
…whose design prompted this little gem: “A design such as this submitted by an employee would result in a serious career track slowdown.”
…
Somehow I feel “pot meet kettle” would be appropriate for this comment-thread, as well, but I’m not sure how it fits, exactly. ;)
Props on that limit-pushing design, BTW.