I get some good feedback.
I've been learning "C" for microcontrollers.
My second project (work) needed a better display, so I got a small Cellphone display from Gravitech. I started with some example code they provided, but it was pretty limited, and rather slow due to some issues with how they were actually getting the data out to the display.
I re-wrote the parts that I didn't like, and added a bunch more, and sent them my code. They replied today:
"we finally have chance to look at your project. It is a WOW! Thank you for your distribution. We'll post your code on the product page in a couple of days. Do you mind if we put your name there ... like "Thanks David VanHorn for the code"?"
Cool eh?
Here's the display.
http://store.gravitech.us/13secogrlcd.html
I cleaned up how the text is displayed, and sped up the actual data transmission as I mentioned before. I also implemented Bresenhams line algorithm, http://en.wikipedia.org/wiki/Bresenham's_line_algorithm, with speedup for the special cases where the line is in one axis or the other, and the midpoint circle algorithm http://en.wikipedia.org/wiki/Midpoint_circle_algorithm.
I added bargraph, oscilliscope, and waterfall display capabilities that I'm using in my work project, to show me internal variables that I couldn't otherwise see.
I added an approach for further speedups that I've used before in ASM, marking the data that actually needs to be updated. Normally you'd have to run through the entire display for an update, but with this method, only things that actually changed get repainted. For example, in my bargraph code, I paint from where it was before to where it is now. Not the whole thing.. If it went up, then I paint in the foreground color, and if it went down, I paint in the background color. This can be a huge timesaver since a typical screen full of bargraphs would otherwise require 50+ to 90% of the pixels to be repainted. My approach seems to settle in at about 10-20%
I'd estimate that on the same clock, my I/O routines are roughly twice as fast as the original implementations, and there's a whole lot more functionality now.
I also commented everything much better than it was before. The original was pretty sparse.
Finally, I added a method to display pictures that have been converted from BMP.
My second project (work) needed a better display, so I got a small Cellphone display from Gravitech. I started with some example code they provided, but it was pretty limited, and rather slow due to some issues with how they were actually getting the data out to the display.
I re-wrote the parts that I didn't like, and added a bunch more, and sent them my code. They replied today:
"we finally have chance to look at your project. It is a WOW! Thank you for your distribution. We'll post your code on the product page in a couple of days. Do you mind if we put your name there ... like "Thanks David VanHorn for the code"?"
Cool eh?
Here's the display.
http://store.gravitech.us/13secogrlcd.html
I cleaned up how the text is displayed, and sped up the actual data transmission as I mentioned before. I also implemented Bresenhams line algorithm, http://en.wikipedia.org/wiki/Bresenham's_line_algorithm, with speedup for the special cases where the line is in one axis or the other, and the midpoint circle algorithm http://en.wikipedia.org/wiki/Midpoint_circle_algorithm.
I added bargraph, oscilliscope, and waterfall display capabilities that I'm using in my work project, to show me internal variables that I couldn't otherwise see.
I added an approach for further speedups that I've used before in ASM, marking the data that actually needs to be updated. Normally you'd have to run through the entire display for an update, but with this method, only things that actually changed get repainted. For example, in my bargraph code, I paint from where it was before to where it is now. Not the whole thing.. If it went up, then I paint in the foreground color, and if it went down, I paint in the background color. This can be a huge timesaver since a typical screen full of bargraphs would otherwise require 50+ to 90% of the pixels to be repainted. My approach seems to settle in at about 10-20%
I'd estimate that on the same clock, my I/O routines are roughly twice as fast as the original implementations, and there's a whole lot more functionality now.
I also commented everything much better than it was before. The original was pretty sparse.
Finally, I added a method to display pictures that have been converted from BMP.