RWB, the *data has to be substituted for the pointer to your array containing the start screen data like this:
const uint8_t startscreen{1024] = { ... EXACTLY 1024 bytes of screen data here ...};
...
void setup() {
...
digole.uploadStartScreen(1024,startscreen);
delay(500); //before you do anything else with the screen, let it finish the operation
...
}
@peekay123 Ok I have tried to upload the start screen a million times now and get garbled results every time.
Here is the image code from the online Digole conversion software. All my other images show up just fine when created and called from the main loop. See if you can get this image uploaded to your screen successfully.
Here is the exact code I used to upload the image to Digole:
const uint8_t myBitmap3[] ={ Hex Image Data Goes Between Brackets};
void setup() {
digole.begin();
digole.uploadStartScreen(1024,myBitmap3);
delay(5000);
}
I think its important that when using the Digole Online Image Hex converting software to choose the bottom setting called Other 12864 LCD&Universal Adapter Welcome Screen to get the image to show up correctly.
Very soon, I will be doing a pull request to timbās digole library to add extra primitives - triangles, rounded boxes, arcs, pies and elipses, both in outlined and filled formats.
I have been working on exploiting the digole font memory to do sprite animations with a lot of success. It is somewhat tricky, however, since the fonts have to be defined with zero ādropā and equal āascentsā and ādescentsā which I have not yet figured out how to do in Fontforge (I had to edit the .bdf font file to do it). Once I figure out how to do this, I will document it all.
So on the sprite bit, my personal requirement is to do instrumentation sprites and icons. For example, sprites for various bar graphs, battery gauge, etc. I also designed some sprites to do a needle meter. For icons, these would be for displaying WiFi status, SD symbol and so on. I would like to know what you the members might be interested in seeing for both the sprites and icons! Please let me know
By the way, you donāt need to do a pull request! Youāve got full access to that repository. So you should be able to clone it directly without forking it. If you use the GitHub app for WIndows/Mac, it should show up under āGITHUB.COMā in the lefthand column of the main window. Click that, click the timothybrown/Spark-Core-Sundries repo and clone it. Then you can directly do a commit from the CLI or app!
I was about to ask you where you were at on this Digole stuff.
I think your Sprites that you have shown are pretty cool and will fit most peoples needs.
Iām really interested in learning how you are making them so I can do the same for my own needs. Looking forward to your tutorial.
Iām also interested in how to upload custom font libraries.
Once I learn how to do this and the next Sprint gets releases where I can turn the CC3000 ON/OFF and Power it down in code as needed then Iāll be well on my way to getting the Spark Core to do what Iām needing it to do.
timb, Iāll be honest, Github confuses the crap out of me! Using web-based acces to Github is partially logical though a lot of stuff is not intuitive. Using it, your repository lists as one of mine but the only clone option I see is to my desktop.
Using the Windows version is total crap. I canāt even see your stuff so I just removed it.[quote=ātimb, post:350, topic:2392ā]
Then you can directly do a commit from the CLI or app!
[/quote]
I am not sure what this means. I āthinkā it means I modify the files on āmyā repository and it will create a new commit. Am I understanding this correctly?
kennethlimcp, that little unit is actually an oled with an atmega328 processor which is basically an arduino UNO. If you want to play with oled without all the hassles, Digole has this new display that also has the onboard processor. They also have monochrome oled units. Of course, there is the larger 1.8" Digole oled unit which many members have used. You can also find oled displays at Adafruit. Digole and buydisplay.com also have ābareā oled displays that will require surface mounting for the connector and some extra components if you want to go that route.
Personally, I really like the Digole smart displays since they handle all the heavy lifting and we have a great library for them. It comes down to effort vs cost for the given purpose.
Has anyone had any success with the latest version of the library working with I2C? I get the following errors when I try to build the demo.
In file included from ../inc/spark_wiring.h:30:0,
from ../inc/application.h:31,
from DigoleSerialDisp.cpp:10:
../../core-common-lib/SPARK_Firmware_Driver/inc/config.h:12:2: warning: #warning "Defaulting to Release Build" [-Wcpp]
In file included from DigoleSerialDisp.cpp:11:0:
DigoleSerialDisp.h: In member function 'size_t DigoleSerialDisp::print(const char*)':
DigoleSerialDisp.h:225:5: warning: no return statement in function returning non-void [-Wreturn-type]
DigoleSerialDisp.cpp: In member function 'void DigoleSerialDisp::drawRoundRect(int, int, int, int)':
DigoleSerialDisp.cpp:267:9: warning: unused variable 'tmp' [-Wunused-variable]
DigoleSerialDisp.cpp: In member function 'void DigoleSerialDisp::fillRoundRect(int, int, int, int)':
DigoleSerialDisp.cpp:291:9: warning: unused variable 'tmp' [-Wunused-variable]
DigoleSerialDisp.cpp: In member function 'void DigoleSerialDisp::plot4EllipsePoints(int, int, int, int, int)':
DigoleSerialDisp.cpp:500:25: error: 'max_x' was not declared in this scope
DigoleSerialDisp.cpp:500:47: error: 'max_y' was not declared in this scope
DigoleSerialDisp.cpp:503:43: error: 'max_y' was not declared in this scope
DigoleSerialDisp.cpp:509:25: error: 'max_x' was not declared in this scope
DigoleSerialDisp.cpp:515:19: error: 'max_x' was not declared in this scope
DigoleSerialDisp.cpp:517:19: error: 'max_y' was not declared in this scope
make: *** [DigoleSerialDisp.o] Error 1
If I clean up the compile errors, it just never updates the screen. Any thoughts?
Update on making sprites: I have been trying a bunch of things to create a sprite āfontā for the Digole displays. This has been a big pain in my keester since there is no one program to do it all. The biggest issue is getting a u8glib-compatible font that has NO metrics (ascent, descent, etc.) so that each ācharacterā or sprite is exactly N by N in size and displays exactly where expected. If you donāt know what Iām talking about, check out the u8glib font information.
I first start with GraphicsGale Free Edition to create each of the sprites in the size I need like 32x32 or 16x16 in 1-bit color. The reason I use this program is it has a lot of drawing tools that other programs donāt. Once I have drawn my sequence of sprites or āframesā, I export āmultiple imagesā to .png files. As many sprites as needed can be created this way, resulting in a number of .png image files.
Then, I use Fontforge for windows and create a new file, then create a āBitmap Strikes Availableā with Pixel Sizes of the size I need (eg 32, 16). I then edit characters starting at the āspaceā character where I import the .png sprite images created in GraphicsGale into each subsequent character ācellsā. Care has to be taken to correctly align the bottom of the imported graphics with the bottom of the FontForge character cell by moving it down when imported. This is to have the bottom of the imported graphic at the lower ādescentā position so it displays correctly. Keep in mind that with 32x32 sprites, 32 sprites will take 4KB of digole font space.
Once all my FontForge characters are done, I do a āGenerate Fontsā which will create a .BDF font file that can be converted for use with the Digole display. During this step, all the āSFNTā options are turned off under the āOptionsā menu.
So now we have a .BDF font but FontForge has imbedded some ādescentā data we donāt want. So now we turn to Fony to fix this last part. I could skip the previous steps and only use Fony but it has poor editing tools. Now, I do an Import āBDF font fileā to load the sprite font. To correctly adjust the font size, I select āEdit/Propertiesā in the menu. There I change the āAscentā value to be the same as the āHeightā value and tick the āMonospacedā checkbox and hit OK. I answer YES to the convert dialog box and now the font is correctly setup. I then select āFile/Export/BDF fontā and save the file back to .BDF format.
Finally (!), the last step is to create a .c file with the array data I need to send to the Digole display. For this I use bdf2u8g.exe to create the .c file. The final step is to cut&paste the array data into a const char array which I then send to the digole using the uploadUserFont() command.
I will be posting a simple font uploading program in my github soon.
jkusnier, my bad! I swear I shouldnāt do commits without first topping up on my caffeine! I fixed the bugs and it now compiles just fine. I just did the commits so it should be available.