Track My Order
Frequently Asked Questions
International Shipping Info
Mon-Fri, 9am to 12pm and
1pm to 5pm U.S. Mountain Time:
Chat With Us
April 4, 2010
about 10 years ago
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.
about 10 years ago
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?
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.
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.
No public wish lists :(