I’ve got most of the bugs ironed out in my display interface, but not all have been squashed in the driver portion. In other words, the method in which I can input text into the OsRAM is working nicely (I’m using a serial port console), but the nuts and bolts of how strings are sent to the display — arguably the most important part of this project — remains broken slightly.
The problem is that I was lazy. I should have paid more attention to the WR and CE lines for proper data latching into the display at the right times.
But this challenge has been fun. It’s always fun to work under a deadline to see what you can do. This forced me to learn more about Arduino. And despite my first impression, I’ve come to see that it’s pretty great. I especially love the C++ class support. For instance, its string and bitwise libraries are awesome. There are things that aren’t so great, like the editor. I had consistent undo (CTRL+Z) wonkiness that scared me (I was afraid of code-eating), so I switched quickly to Notepad++ with a good syntax language profile.
Things are progressing nicely. I have the display fully wired now to the Mega. It’s a spaghetti mess, but it’ll work. I have the serial port on the Arduino working nicely for debug. I also did a fair amount of thinking with regards to data and address packetizing. It quickly became apparent that doing a bunch of digitalWrite calls for all this pins (8 data, 5 address, per character of the display) would be a nightmare.
Here is the character map for the display.
So I came up with a character array method to do this. I tested tonight with the serial port debugger to verify correct character parsing.
*** The following is a “bitter old engineer” rant. You’ve been warned.
At this ripe old age, I have come to value most the quality of a toolchain. I’ll go a step further and say that the coherency and consistency of the umbrella that toolchain inhabits is a most prized quality. And what spurred this revelation? Why the obtuse declaration?
I have seen the other side, brothers and sisters. I have felt the greener grass on the knoll of Arduino, and I’m here to tell you something: it ain’t that green.
My (albeit, limited) experience to date in hacker-friendly Arduino land has been lackluster. It reminds me of another favorite rant of mine: Linux. There are some striking similarities between the two communities of DIY hobbyists and computer enthusiasts.
As soon as something “official” releases, there are half a dozen “forks” that have splintered off. This serves to dilute the overall user experience, causing bewilderment and disorganization.
As a result, newer users aren’t sure where to start to get things up and running.
Knowing where to turn for help is equally difficult. Because the dragon has a dozen heads, you might have to slay them all before you master the thing.
This was a replacement for (b), promising to be more better faster. At least this manufacturer’s drivers are self-hosted, i.e., they make their own suite of drivers. It’s not some arcane foreign package, managed by yet another third party, long defunct. And yet… damned if the thing won’t work. I get the dreaded Exclamation Point of Death.
This is a hopeless mess. Sparkfun’s driver link just goes nowhere. After a half an hour of reading and clicking, I stumble over to another vendor’s site and find some hearsay about yet another suite of drivers that allegedly work. Finally this installs, but there’s no COMM port listed in Device Manager. So, none of the software tools can recognized the thing.
I was foolhardy to think I could make my own programmer from scant directions on the interwebz. That was just a big fail.
My first Arduino dev board, the Uno, does not work. I plug it in, and most of the time no machine will recognize it. No “bonk”, no “ding”, nothing. I took this to my office and gave it to my technicians who are well accustomed to working with QC and microscopes and fancy solder reflow equipment. They found nothing distinctly wrong with it. And yet it clearly doesn’t work.
I found that if I bend the Uno board a bit (yes, bend), I can get Windows Device Manager to wiggle a bit. So there appears to be an inner layer fault, most likely a trace intermittence. Lovely. Another brick for my pile.
To program the AVR chip, I turned to these sprinkling of software tools that purport to do so:
The top three have been dudes for me so far. I’m yet to try the gold standard, AVR Studio. After all, this is published by the manufacturer of the MCU…
The only piece of hardware above that I got to work was the relay I/O board. And you know how I did it? With a Freescale HCS08 dev board. Not an AVR chip or an Arduino board. The S family of chips is simply lovely. It’s soothing. It’s a fresher breath of air, having inhaled the stale aroma from the Arduino “hackerspace”.
But to be fair, Freescale is my comfort zone. I cut my teeth on the Motorola HC11. So it stands to reason that I’d favor that flavor.
The uniformity of experience in going from a line of C code to a hex file burned onto silicon is now even more valuable to me. The Freescale “way of doing things” is a much more pleasant thing. One application (CodeWarrior) weighing in at a hefty half gig, published by a single vendor that also happens to design and fab the chip you’re using, is all you need. Start to finish. That’s power.
It’s in the implementation that I’m disappointed. Frankly, I’m surprised that the masses aren’t as frustrated as I am. I suspect that this is indicative of a greater public movement: that of DIY culture invading every corner of the marketplace. The software (or tool, or apparatus) doesn’t work as advertised? No sweat, just hack it!
And that ethos truly is something to celebrate. Kudos to the Everyman who fixes something rather than disposes of it, complains, and buys a new one.
But coming from the engineering and product development side of the aisle, I’m forced to side with the philosophies of coherent and esthetically pleasing user experience. This has value too, just as much (I would argue) as the value of DIY, crowd-sourced electronic hobbyism.