Float is used to make a diagnal line. If you dont use a float, the line won't be drawn on the correct path. Because the pixels coordinates are so small I could use a different technique while still staying with a single byte variable. I'll try it out and see how it works.
That is the algorithm the glcd library uses for its DrawLine() function, which is what I pulled into
the bitmap library. It saves 1600 bytes of code since it does not use floats.
I'm more of a "roll my own" type instead of just pulling code from others. My goal is to build something unique, not copy something existing. I know others have other goals. I appreciate everyone's suggestions, and the tip that using a float wastes a lot of code space was a very helpful. I've modified my code to not use the float and use my own line algorithm and saved 1,820 bytes. I may look at Bresenham's line algorithm to see if it yields any further speed or program size reduction.
I've also removed the "magic numbers", added a range checking option, and modified the code so it should work with 7 pixels high character displays (don't have one to test however). Version 1.2 should be released shortly.
From the suggestion of Francisco Malpartida and bperrybap (author of the Graphical LCD library) I removed the float variables in the line function which reduced the compile size by 1820 bytes. Also did some speed tweaks, added an option for range checking, and removed the "magic numbers". Finally, I believe it now will work with 7 pixels high character displays (change the BITMAP_CHAR_H define to 7). I don't have a display like this, so if someone can test and let me know that would be great.
Something seems to have gone wrong when creating the v1.2 zip image.
The directories and file names in the zip image have CPM/DOS backward slashes in
their names rather than have subdirectories and files within the sub directories.
bperrybap:
Something seems to have gone wrong when creating the v1.2 zip image.
The directories and file names in the zip image have CPM/DOS backward slashes in
their names rather than have subdirectories and files within the sub directories.
The previous 2 zip images were not like this.
--- bill
Strange, it works fine for me and all my ZIP apps show the files and directories in the same way. Even old DOS PKUNZIP and Unix unzip extracts the files without a problem for me. I created it on the same Windows 7 system as the previous releases. The only thing I did differently was after I created the ZIP file I deleted the .hg directory and .hgignore file created by the Hg app. What OS are you running?
Something is very odd.
It works ok with Win7 (which I would expect). It also works with XP file manager and on XP using 7zip.
It does not work with Ubuntu 10.10 using Nautilus which uses the Gnome archiver File Roller v2.32.0
It does not work with Mint 11 using Gnome Archinve File Roller v2.32.2
It does not work with 7z (from pk7zip-full version 9.04-dfsg.1.1 debian package) using the command line on Ubuntu.
Note: When I say "does not work" I mean that the files end up with backward slashes in them when viewing them
in a GUI and when extracted rather than shown/extracted in directories and subdirectories.
My guess is that it had something to do with deleting the files post ZIP file creation. I'll delete the files first, then create the ZIP. This time I'll also create the ZIP on my retro Windows 98 machine in my kitchen (had a 20 mile run today so I really don't feel like climbing the stairs to my office). It's available for download (v1.2a).
On a side note, I looked at your source for the line function and the Bresenham's line algorithm. It's surprisingly similar, except how I did the error correction with oversampling instead of using a float. I played with the Bresenham's line algorithm that doesn't swap variable values and it's very fast and saves code size as well. You may want to consider implementing it in your line code also as you're still using swaps. You should also see a significant speed increase and reduced code size. I need to test it out more, but I'll probably be adding it to v1.3.
Below is the code I'm experimenting with in my line code, it's probably easier to implement than the code on the Wiki site:
void LCDBitmap::line(byte x1, byte y1, byte x2, byte y2, boolean color, boolean update) {
#ifdef BITMAP_RANGE_CHK
LCDBitmap::valueCheck(x1, y1, x2, y2);
#endif
byte dx, dy, sx, sy;
int err, e2;
dx = abs(x2-x1);
dy = abs(y2-y1);
err = dx-dy;
if (x1 < x2) sx = 1; else sx = -1;
if (y1 < y2) sy = 1; else sy = -1;
while (1) {
#ifdef BITMAP_RANGE_CHK
LCDBitmap::rangeCheck(x1,y1,color);
#else
bitmap[x1][y1]=color;
#endif
if (x1 == x2 && y1 == y2) break;
e2 = 2*err;
if (e2 > -dy) {
err = err - dy;
x1 = x1 + sx;
}
if (e2 < dx) {
err = err + dx;
y1 = y1 + sy ;
}
}
if (update) LCDBitmap::update();
}
Also, for your variable swap you may want to use a^=b^=a^=b; Maybe slightly faster, and I'd guess it saves a little code size without the third variable needed.
Many performance tweaks and reduced compiled code size. Optimization were enough to deprecate the lineHor and lineVert commands. Both functions still work, there's just no longer any advantage in using them. Thanks to robtillaart for suggesting the Bresenham line algorithm. Modified range checking removing redundant checks. Added new function barGraph that easily creates a 1 to 20 bar graph.
Be sure to check out the new example code that better show the functions and speed of the library. I'll also update the video to show the new example code.
The examples will not work "as is" with releases prior to 1.0 because of the .ino extension.
If you renamed them to .pde then the examples could work "out of the box" with both
the the post and pre 1.0 releases.
The examples will not work "as is" with releases prior to 1.0 because of the .ino extension.
If you renamed them to .pde then the examples could work "out of the box" with both
the the post and pre 1.0 releases.
--- bill
Thanks! That's why the sketches weren't listed in 0023. I just did a cut and paste to test because for "whatever" reason it wouldn't load. Now the mystery has been answered. I'll make the changes for the next release.
I have installed arduino 1.0.1 and I just downloaded LCDBitmap library . I loaded the LCDBitmap_standard_4bit example and try to compile it.
This is the outcome:
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:89:17: error: LCD.h: not found
In file included from LCDBitmap_Standard_4bit.cpp:2:
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:110: error: expected `)' before ‘’ token
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:133: error: ISO C++ forbids declaration of ‘LCD’ with no type
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:133: error: expected ‘;’ before ‘’ token
LCDBitmap_Standard_4bit:4: error: no matching function for call to ‘LCDBitmap::LCDBitmap(LiquidCrystal*, int, int)’
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:108: note: candidates are: LCDBitmap::LCDBitmap()
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:108: note: LCDBitmap::LCDBitmap(const LCDBitmap&)
The first line shows a LCD.h not found statement... where LCD.h header is?. Am I missing something?.
Tim,
maybe to help newbies, you could add a compile time check/error to tell them how to resolve the issue.
For example, LCDBitmap.h includes <LiquidCrystal.h>
fm's LiquidCrystal.h includes "LCD.h" so the include of "LCD.h" is not needed in LCDBitmap.h
(This will eliminate the preprocessor error).
Then instead of the include for LCD.h
do a compile time check for a define that is only in fm's library.
Something like maybe:
#ifndef BACKLIGHT_ON
#error You need to install this version of the LiquidCrystal library: https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
#endif
(hint... hint...) maybe it would be useful to have a more unique define that could be checked
to compile time detect the existence/use of the replacement LiquidCrystal replacement library...
I have installed arduino 1.0.1 and I just downloaded LCDBitmap library . I loaded the LCDBitmap_standard_4bit example and try to compile it.
This is the outcome:
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:89:17: error: LCD.h: not found
In file included from LCDBitmap_Standard_4bit.cpp:2:
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:110: error: expected `)' before ‘’ token
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:133: error: ISO C++ forbids declaration of ‘LCD’ with no type
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:133: error: expected ‘;’ before ‘’ token
LCDBitmap_Standard_4bit:4: error: no matching function for call to ‘LCDBitmap::LCDBitmap(LiquidCrystal*, int, int)’
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:108: note: candidates are: LCDBitmap::LCDBitmap()
/home/ydirgan/SCRIPTS/Arduino/arduino-1.0.1/libraries/LCDBitmap/LCDBitmap.h:108: note: LCDBitmap::LCDBitmap(const LCDBitmap&)
The first line shows a LCD.h not found statement... where LCD.h header is?. Am I missing something?.
any advice will be appreciated.
Regards
YADL
I guess I missed this. I had believed LCDBitmap would work without the "New LiquidCrystal" library. But, that doesn't seem to be the case. Attached to this message are replacement library files. Save and replace these files with the existing files in your Arduino/libraries/LCDBitmap/ folder. I don't have a 4bit project in front of me to test, but the attached files do compile with a stock Arduino 1.0.1 with the LCDBitmap_Standard_4bit sketch.
bperrybap:
Tim,
maybe to help newbies, you could add a compile time check/error to tell them how to resolve the issue.
For example, LCDBitmap.h includes <LiquidCrystal.h>
fm's LiquidCrystal.h includes "LCD.h" so the include of "LCD.h" is not needed in LCDBitmap.h
(This will eliminate the preprocessor error).
Actually, when using a 4bit connection the LCDBitmap library was supposed to work without the need for the New LiquidCrystal library. I've changed the code so it should work with or without the New LiquidCrystal library and attached the revision to my previous reply.
Adding an error if trying to use other connection types without the New LiquidCrystal library is a good idea too, and I'll probably be implementing that as well.
Hi, thanks for this great library. I got it working successfully using an Arduino Leonardo, running IDE v1.0.1, with your modified version of the library attached on an above post. However, I've been playing around with the bars function and can't figure out: How could I use your library to display the value (graphical) of some analog inputs? Suppose I have 3 analog inputs. I read them, re-map or convert them, and display those values with a bar, with the highest possible value creating a full bar, and the lowest possible value giving an empty bar. Any help or suggestions would be great.