I ordered up some new Digole displays to play with.
Got a 2.7 and 1.8" Black and White Graphic LCD + the 1.8" Color OLED display you guys have been playing around with here. We will be able to make sure the library is working with all these displays.
RWB, I like the 2.7" but it is not an easy one to panel mount. The 1.8" b&w looks better since the board has mounting holes. Let me know what you think. Personally, Iāve added their controller board to their 3" LCD module and it works really well.
Yea I think the 1.8 inch will have a sharper image due to smaller pixels and mounting holes will be beneficial also.
Once they arrived Iāll come back to try to get things working again 
Yesterday I tested 1.8āā COLOR OLED with the latest library. It looks nice! I had to add:
#include "application.h" // add to DigoleSerialDisp.h due to latest changes in Spark firmware
But I was unable to draw bitmap (converted via Digole web page). 256 color in that resolution wonāt fit into Spark memory. I added drawing b/w image in setup() function and Spark did blink with cyan/white (donāt remember). Had to do a factory reset in order to upload another sketch. But writing some text does work.
I use hardware SPI and bought this color display, because I want to transfer image snapshots from desktop over UDP. Is that 10ms and DIV16 parameter required? Would it be possible to stream 256 color bitmaps over UDP to OLED?
I can control Syma S107 RC helicopter (using IR LED + transistor) in realtime with Spark Core. TCP/IP (even with NoDelay) is not for realtime communication. UDP solved my problems. I have a Windows C# app using DirectInput, which recognizes all game devices including Saitek Cyborg X joystick. I have successfully mapped joystick axes to RC helicopter and Spark Core is doing UDP packet receiving + IR remote control in realtime with no probs :-).
cyberluke, I am not sure why the full screen 256-color image would not fit in the spark memory. I just reloaded a demo sketch I have with such an image and it works fine. What does not fit is a 262K bitmap. Work on getting data in the external flash will fix that. You also mention:
Is that 10ms and DIV16 parameter required?
timb and I are working on that code together. The 10ms delay is based on tests we did and allows the Digole cache to clear before the drawBitmap256 command. You can remove it and try it out if you wish. The DIV16 for the SPI can be changed to DIV32 or DIV64 if you wish. We found the DIV16 to be the fastest we could get without hickups.
I believe you could "stream" your image to the Spark/Digole over UDP if you send "slices" of the picture and use drawBitmap256() to display each slice consecutively. This is because an entire image would take 20K of RAM! The only catch with UDP is stateless with no out-of-order packets. So your image may not get there correctly all the time.
Yeah 
for UDP joystick data, each packet has its own timestamp and packets with older timestamp are ignored.
Cool, I will experiment.
I used their web tool: http://www.digole.com/tools/PicturetoC_Hex_converter.php (both DEC and HEX) and declared it as
uint8_t myBitmap[] = {255,255,255,...}
Then tried to compile it in Spark IDE and got compile error, that it canāt fit into the memory.
I want to build my wireless display with remote desktop capability. I thought about streaming 160x128 box from desktop as UDP byte array, where latency is preserved and wrong packets are ignored as they will be made obsolete by another incoming packet.
Sending individual slices: I would add Y position information into each UDP packet slice and it would drawBitmap256() at this position. But that sounds like latency will be a problem and it wonāt useable if I cannot send 160x128 in one byte array.
I am prostitute robot from the future! http://www.weeatfilms.com/wp-content/uploads/2012/06/manny.jpg ā¦Does in this Universe exist one solution that would make this possible on Spark Core? I donāt care how hard solution it is, I will just do it. Would external SD card, external memory, CC3000 EEPROM solve it? Or the only solution would be to have a bigger RAM on Spark Core (will have to learn soldering on it o_0) ?
Haha! Easy to fix... to avoid RAM, you need to put your bitmap in flash with the "const" type like this:
const uint8_t myBitmap = {255,255,255,...}
Try that and see what happens. As for a full image RAM buffer, the Spark core does not have the resources for that. You could use external FRAM or SRAM connected by SPI (up to 40MHz SPI). You would have to create a library for interfacing and you could store your image(s) there and customize the drawBitmap() code to fetch the image from there. There may already be arduino products you could adapt.
Yes, asimilate existing duino code, thats what I do mostly . But I have connected the display to spi already,so working with two devices over spi might need some changes to digole lib as well. Will have to investigate dedicated video ram for this. ToDo for Spark 1.1: bigger ram!!! I have old DDR 433,maybe I could PWM it with 500 hz 
DDR? No really! For SPI, the CC3000 uses SPI as well. It preserves the SPI ācontextā when it runs so user apps are not affected. However, it would be good to have an SPI ābrokerā so there are no conflicts. I think the Spark team is working on that. I will discuss an MRAM/FRAM/SRAM module with timb to see what he thinks.
Ok, Im willing to help with it as well 
Here is my motivation: Complete how to build guide for realtime Windows external monitor with LCD and Arduino (+source): http://q61.org/en/chibimo/ ā¦no additional SRAM. There is also uncompleted guide for color LCD: http://q61.org/marymo/ (in Japanese only). I couldnāt find this link before. If it works on any Arduino or AVR, it should work on Spark Core with ARM Cortex CPU, right?
ARM Cortex M0 48Mhz was used in color OLED project back in 2011: http://translate.google.cz/translate?sl=auto&tl=en&js=n&prev=_t&hl=cs&ie=UTF-8&u=http%3A%2F%2Fq61.org%2Fmarymo%2F
Yeah man, that's a completely different ballgame than what you're proposing here! In the first project, he's using a 128x64 black and white LCD. 128x64 = 8KB for a full screen uncompressed image. Looking at a snippet of his code, he's using a VNC like compression algorithm and only updating small blocks of the screen at a time.
The last link you posted was dedicated hardware and from what I can tell programmed at a lower level (i.e., not using the Wiring framework).
Then you're not doing something right. 160*128 = 20KB, which should well fit in the Core's memory unless your program is massive.
If you want to stream image data over UDP, the best way to do it is going to be in blocks. Each block could be 40x32 (404 = 160; 324 = 128), so you draw all four blocks to the screen one by one and then use an algorithm to only update the blocks that have pixel changes in them. This would work better (and faster) if you broke the screen up into 8 or 16 sections, but you could start with 4.
That said, these Digole screens are really not designed to do live video. They're running a 64MHz PIC chip that takes easy to use commands over a serial link and draws the data pixel by pixel over an 8-bit interface to the display.
If you really want to do video you need to get an OLED or TFT display with a native 8-bit interface and hook it up to D0-D7 on the Core. That will be extremely fast and be your best bet for live video streaming.
I've got a 4.3" and 2.4" TFT here (the former donated by a generous member) that I'm working on porting over to the Core (by means of U8glib). Once @peekay123 and I get that going you could give it a try.
Ok thanks a lot! Iāll try streaming by small blocks (configurable size) and updating only some pixels. Digole manual (http://www.digole.com/images/file/Tech_Data/Digole_Serial_Display_Adapter-Manual.pdf) lists directCommand(0xaf) and directData(0x88). So I thought that this display could have the best of both worldsā¦direct access + nice chip with GUI library and animations. Iām planning to buy some LCD touch screen as well. Will look for 8-bit native interface if SPI is a no go. Will post some Spark + .NET source next week (or so).
Found FRAM in PDIP-8 for $22 = nice for quick prototyping on breadboard: http://cz.mouser.com/ProductDetail/Cypress-Semiconductor/FM25V20-PG/?qs=sGAEpiMZZMtsPi73Z94q0OKOSVYv1Kg26S1EAOjMJe0%3D
Hey guys, I was watching Adafruits Show & Tell today and a guy was on there working with the Sharp Memory Display and Adafruits GFX library. He found a way to use custom fonts from your computer and use them with the GFX library.
I have a strong desire to use my own fonts with these LCD screens so please watch the video and let me know if this is new to you and if it some thing we can use to make custom fonts work with the Digole displays and Sharp Memory LCD displays when its up and working.
Go to the 19:30 min mark in the video.
RWB, Iām going to look at the Dot Factory stuff but from the sounds of it, it requires a lot of data massaging to get it working. The Adafruit GFX library is coded to a 5x7 fixed-sized font so anything else will require changes to the library. Essentially, the library is one font setup. One of the reasons timb and I are working on porting u8glib is that it comes with a large font selection.
Sounds great. Glad you guys are on it
I just looked up the u8glib and it looks nice. For others who have no idea what that is look here: Google Code Archive - Long-term storage for Google Code Project Hosting.
Any idea on how long you think till you guys have this up and running?
RWB, the u8glib created two version, one for arduino and another for ARM. The ARM version is more suitable for the Spark but is lacking soft SPI, I2C and parallel display support (!). I am working on either porting the arduino version to Spark or adding the missing functions to the ARM version. Heehah! Canāt really tell you at this point how long it will take.
Sounds good! Iāll be ready to try it out once you have it all cooked up 
From Digole website: ā7 preloaded fonts, fontās data structure full compatible with U8Glibā. I canāt see a problem why you couldnāt convert your font to U8Glib format and upload to Digole screen 
