|
|
|
the downside of cheap
Tuesday, September 29 2015
It was another warm, humid day, though eventually it started to rain. Just before that got going, I cut up the last of the long pieces of oak piled up around the woodshed, and it all went into the fourth tranche (along with 123.6 pounds of oak I'd salvaged from the same place I'd gathered yesterday's wood). By tonight, rain was coming down in something of a constant hard shower, and this would go on all night. Meterologically, there was a freakish confluence of weather systems channeling enormous quantities of humid tropical air into the area.
On my clock project, today I managed to write the code necessary to alter the time using five of the buttons on the little button array I'd salvaged for it yesterday. The code I wrote to parse the information altered by those buttons and save it to the real time clock wasn't perhaps the most efficient it could have been, but it got the job done.
Being only able to display six or seven characters on the LED matrices limited the possibilities of what kind of user interface I could provide on the clock itself for changing its internal settings. But I definitely wanted to do more than just be able to set the time. I also wanted to be able to, for example, switch from military to non-military time. Perhaps down the road I might want to add one or more alarms. All of that should be configurable on the device itself. To support the configuration of multiple parameters using such a small screen, I decided to make it page between data that it displays whenever the cursor moves off screen to the left or right of whatever is currently being displayed. As a start, I added the configuration of Military time. Once I page left off the time configuration, I see something that looks like Mil:0. The cursor then blinks on the 0, and I can either increment it or decrement it to 1 (the only two values it can have). This changes whether or not the display shows military or conventional time.
I managed to get this working by midnight, but not before seeing some strange behavior. For some reason the cursor blinked really fast when hovering over the digits in the time editor but slowly when over the digit in the Military configuration. Looking through the code, I could find no source for this delay. Eventually I narrowed the place where the delay happened to a for loop that scanned through the character array holding the display information while updating it with values from the character array holding the information to be parsed when the data is eventually saved. The difference between these two arrays is typically only the substitution of the cursor character (one of several different-lengthed unscore characters), and that difference is only in effect half the time. Something about the memory holding this information was slow for some of the bytes in the display array. By slow, I mean that setting it required at least 100 times more time than the setting of other bytes. By the time I went to bed, I'd concluded that there must be a defect with some of the memory in the Atmega328 on the cheap no-name Arduino micro board knock-off I was using as a controller. I could configure an identical controller to prove that this is the case, but it would be on another identical board, which might well have an identical problem with its memory. Perhaps this explains how I can get such boards for $2.54 from China, shipping included. These boards mostly work flawlessly in Arduino applications, though it's possible they are powered by microcontrollers that have failed Atmel's stringent standards. If so, it's a simple matter (and a good, if frustrating exercise) to tweak the code to work around such minor flaws.
For linking purposes this article's URL is:
http://asecular.com/blog.php?150929 feedback
previous | next |
