Day 30+: a postlude

(Copyright Vectorbelly Webcomics)

While the rest of the world is preparing for super sportsing, I’m taking the opportunity to tinker. This post is a continuation of the GaSiProMo challenge I took part in a while ago.

Today’s update brings in the next stage of that project with my OsRAM LED display: better packaging.

The goal here is to reduce the amount of “rat’s nest” wiring from the prototype to a more manageable amount of cabling for better display of the pretty blinky lights.

So I harvested an old Shuttle micro PC for its hard drive cables, which are nicely bundled.  The first step was to make a breadboard carrier for the OsRAM.

breadboard layout
breadboard layout

I chose sockets for wire-wrapping.  I’m a big fan of wire wrap.  It’s old school, but very rapid for prototyping.

wire wrap pins
wire wrap pins
finished wire wrap
finished wire wrap

Next up was to make a mapping of the pins from my Arduino to a breadboard.  This took a while to derive the most optimal routing of wires.

Pin mapping for translation cable
Pin mapping for translation cable

No to my surprise, the HDD housing has one pin blocked.  So I had to Dremel this out.

recovered pin
recovered pin

 

I have a serial port terminal working so that I can type in any message from the PC and have it show up on the OsRAM:

20160207_131515

terminal port

terminal port

Hello, world!

Hello, world!

 

Day 30: final day

This post is part of the GaSiProMo challenge.   You can read more about this here.

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.

OsRAM write timing
OsRAM write timing

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.

Oh well, what can I say?   I got distracted by another project.  So I can show you what I have so far:

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.

Until next year.

 

Day 15: display testing

This post is part of the GaSiProMo challenge.   You can read more about this here.

So I have my display working sort of.  It’s definitely showing good old ASCII characters.  Here’s a quick video of it in action:

You can see my code at GitHub.

I’m quickly realizing that I will need a more sophisticated text parser to make this thing usable.  ‘Cuz sending a character at a time for bit-fiddling pretty much sucks.

Day 6: early firmware testing

This post is part of the GaSiProMo challenge.   You can read more about this here.

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.

ipd2131 ASCII chart
encoded character map

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.

So far so good.

The state of the Arduino ecosystem

*** 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.

The Arduino Uno, marvel of electronics enthusiasts.
The Arduino Uno, marvel of electronics enthusiasts.
  1. 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.
  2. As a result, newer users aren’t sure where to start to get things up and running.
  3. 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.

I have on my work bench a handful of Arduino-esque stuff, virtually all of it non-operational hardware (so far):
a) A Pololu AVR programmer
b) A Sparkfun Pocket AVR Programmer
c) A homemade ISP programmer
d) An Arduino UNO
e) A relay development board with ATtiny2313 MCU

a)

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.

b)

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.

c)

I was foolhardy to think I could make my own programmer from scant directions on the interwebz.  That was just a big fail.

d)

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.

e)

To program the AVR chip, I turned to these sprinkling of software tools that purport to do so:

  • WinAVR
  • AVRDude
  • AVRDude-GUI
  • AVR Studio

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.


I should note right here and now that I’m actually the biggest supporter of the Open Hardware Movement and the philosophies that Arduino espouses.  There have been countless amazing creations achieved with this platform.

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.