Member Since: April 4, 2010

Country: United States

  • I've also added new-line processing, so it is a closer implementation of a glass-TTY. I found that writing strings to the screen was annoying without the backpack handling line endings.
    The algorithm should do something "reasonable" for PC and Linux/Unix line endings. I don't know the MAC convention.
    Email me at carl dot mikkelsen at gmail dot com for a source distribution.

  • The code is too large to post in forums -- I tried.
    Does SparkFun have an FTP site? Or is there a CVS/SVN server? I have code to contribute, but no means to contribute it.
    Does this go back through Google Code?
    Do I need to create a SourceForge project for it?
    Should I put it on my own web site?
    All of these seem a little haphazard. Surely there must be a way to get code back to SparkFun (where I got the original code)?
    What are the procedures and rules for working with SparkFun to improve your products?
    -- Carl

  • I fixed the last bug that currently annoys me, and have a new main.c to distribute. For my purposes, it not only works better, but it turns out that I no longer ever get an X-OFF character. Still, it's good to have it built in so noone, including me, needs to worry about overrunning the Serial Graphic LCD Backpack input buffer.
    I can't simply include the file here, as it is too big. How does one release code into the Arduino/AVR development society?
    The display is ever-so-much more responsive now, and I'm getting no extraneous pixels or screen clearing events. It's been rock solid for hours.
    I don't have a good test suite, so although i've tried to limit the scope of my changes to those things which I am testing, I welcome more testing or code review by anyone interested.
    -- Carl

  • I have rewritten some of the serial communication code for the Graphic LCD Backpack to:
    1) implement a true, IRQ safe, circular buffer
    2) observe proper buffer discipline
    3) remove the "command near the end of buffer" cases
    4) increase the buffer to 512 bytes
    5) send X-OFF (S> when the buffer is 3/4 full
    6) send X-ON (Q> when the buffer is back to 1/2 full
    This now has resolved some of the bugs I saw, and I can drive it much faster since the Arduino driving it need not guess how fast it can send.
    There are still a few random pixels appearing on the bottom line -- probably a problem in the line-drawing code, as that is what I am heavily using.
    My question is, how do I release this code back to SparkFun (or anyone else?).
    Anyone wanting the code can email me at carlmikkelsengmailcom.
    I have a dual-Arduino test bench right now :) A Duemilanove as the ISP, and a MEGA as the test engine. Once I wired it up properly, it works quite well. Cudos to the Arduino development team.
    -- Carl

No public wish lists :(