goeck

Well, Joel, thanks for the guideline. Maybe I was mistaken. I must have said, I have incomming data that has to displayed to the user, not real MCU related debugging data. I want to display all the communication of an UART attached system that I am communicating with. So when the project is finished I whish to have all those data on the display, it's not necessary for the function of the system though. But anyways, how could a threaded GUI be done with uGFX? Best would be to implement the thread and attach it to gwinPrintf() I just thought, so the printf computation implicitely runs in that thread and when it's done it lays itself asleep again or terminates. This at least is what I was used to doing Qt GUIs.

Hey Svenska, thanks for the reply. You really got my point, I have realtime and non realtime, and I see no well paved way how this can be solved in uGFX. I agree with you; maybe you know the famous Einstein quote "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." This is actually the way I like to go, so I thought of robust mechanisms which led me to the posted idea. Rather than keeping lists and counters I'd like to have a dedicated display drawing thread that takes care of non realtime GUI stuff and hides whenever performance and no latency is demanded. Right now, what I do is saving timestamps and doing no GUI output when events happen, e.g. start_of_measurement notification. This is not ideal since I want to put out lots of debug data. Regards Stefan

Hey everyone, I have a SSD1306 driven OLED display hooked up to my ChibOS-runngin STM32F0-Discovery over SPI for performance reasons (could have hooked it up over I2C as well). No I found that when using gwinPrintf() it takes several 10s ms to compute the output data and only 1.3ms to push the display RAM to the display. Since I do some performance measurements in a row with my running application I can not display the result of each trial since it would influence the next measurement. I thought about the following possible solution to this issue: - set up a thread, only responsible for display output at a very low priority - put it asleep at startup - pass the whole gwinPrintf() somehow to this thread, computation of printf() has to be done in this thread, not the invoking one - when system gets lazy again, display output could be done Well, one could actually pass one msg_t to this thread and would maintain a list of predefines messages whichs index could be stuffed in that msg_t and the display thread goes through that list and prints whatever there is bundled to according to the list. I actually want to have something close to the earlier mentioned idea. What do you think? Regards from Germany

OK, here we go. I did change to SPI and made the SPI board working. It's blazing fast, but some scrolling artefacts are not affected by this improvements. I was hoping to get rid of those two flicks every time a line gets scrolled by doing faster communication. Anyway, I hereby have the spi board file and the tweaked "main" file gdisp_lld_SSD1360.c Maybe it's not yet to late to incorporate this in v2.0. Cheers Stefan Can't upload files?! I have therefor set up an repository on Github, which is my fav. GIT hoster. Please have a look at https://github.com/goeck/SSD1306/ .

OH, now I know what happened. I had a SSD1306_board.h file left in the drivers source folder, where in the GDISPStreaming branch all those board files have been moved, as you just said. I guess I still had it in the editor and accidently saved in nack to the location where it originally was loaded from. There was some older code in it. Now, in the boards/addons/gdisp folder the code is the latest, the version that I just tested as good. So, after trying to compile the latest version in GDISPStreaming I get a compiler error in gdisp_lld_SSD1306.c, the board file is not found. fatal error: board_SSD1306.h: No such file or directory Also, I am a little stuck. How can I implement vertical scrolling again. Adding a gdisp_lld_vertical_scroll() doesn't change anything. Please, I need a quick advice on this topic. EDIT: OK, I just had to add GDISP_HARDWARE_SCROLL TRUE to gdisp_lld_config.h to let uGFX run into that function. No I am getting that guy... EDIT 2: Almost there, the only issue that I'm having is: it looks like scrolling only happens if the page is fully written, not after each line has been written, so that I could scroll one line up. That's how my scrolling routine is written ( i use g->p.y1 to grab y height which is to be scroll up). EDIT3: OK, done. That was because I didn't call the flushing routine but just set the need_flush flag. So scrolling was done but the display would just have been updated after "a while"... No that's through. Here's my working implementation (part of gdisp_lld_SSD1306.c) of scrolling for the v2.0 GDISPStreaming branch (Can't push a pull request since I don't have a bitbucket account) #if GDISP_NEED_SCROLL /** * @brief Scroll vertically a section of the screen. * @note Optional. * @note If x,y + cx,cy is off the screen, the result is undefined. * @note If lines is >= cy, it is equivalent to a area fill with bgcolor. * * @param[in] x, y The start of the area to be scrolled * @param[in] cx, cy The size of the area to be scrolled * @param[in] lines The number of lines to scroll (Can be positive or negative) * @param[in] bgcolor The color to fill the newly exposed area. * * @notapi */ LLDSPEC void gdisp_lld_vertical_scroll(GDisplay *g) { #ifdef GFX_USE_OS_CHIBIOS int32_t thdPriority = (int32_t)chThdGetPriority(); chThdSetPriority(HIGHPRIO); #endif /* See datasheet table T10-1 for this*/ uint8_t fHeight = g->p.y1; write_cmd2(g, SSD1306_SETDISPLAYOFFSET, fHeight-2); write_cmd2(g, SSD1306_SETMULTIPLEX, (GDISP_SCREEN_HEIGHT - fHeight+1)); /* Scrolling animation.*/ for(int i=0; i write_cmd(g, SSD1306_SETSTARTLINE | i); gfxSleepMilliseconds(20); } /* Shift buffer up a font line.*/ for (int i = 0; i < SSD1306_PAGE_WIDTH*(GDISP_SCREEN_HEIGHT/8-1); i++) { if(i % SSD1306_PAGE_WIDTH){ RAM(g)[i] = RAM(g)[i+SSD1306_PAGE_WIDTH*(fHeight/8)] >> fHeight % 8; RAM(g)[i] |= RAM(g)[i+SSD1306_PAGE_WIDTH*(fHeight/8 + 1)] << (8 - fHeight%8); } } /* Clear second last page.*/ for(uint8_t i=0; i<2; i++) memset( RAM(g) + (GDISP_SCREEN_HEIGHT/8 -1)*SSD1306_PAGE_WIDTH - GDISP_SCREEN_WIDTH, 0, GDISP_SCREEN_WIDTH); #ifdef GFX_USE_OS_CHIBIOS chThdSetPriority(thdPriority); #endif /* Update display.*/ gdisp_lld_flush(g); } #endif // GDISP_NEED_SCROLL

Hey everyone, No after some days of bedtime due to a heavy cold, I was able to fix my hardware issue and test the memory-fixed SSD1306 driver, which worked like a charm (except scrolling was done in software). Now I updated my local repository clone and found the old code within the driver. Could you, inmarket, please update the branch with the memory size oriented improvements you made? Then I was able to retest this and implement the scrolling again. Cheers Stefan

Hey, I have not had the chance to test the fix. I have some weird hardware flaws since today in my testing system. I can't get it to work until Monday unfortunately. Actually you're just right. It's mess with the temp. buffer, but sending (at least over I2C) in more packets takes more time to transmit the whole frame buffer. That's why I tried to send in as few packages as possible which has shown to be two transmissions each containing half of the frame buffer. I like thy slick way you took a chance on that problem though *thumbs up* When I have the chance to view this with my saleae logic I'll post some performance infos about that topic. Maybe it's the best tradeoff between performance and memory optimization anyways. I'll keep you posted. Cheers

Hey, I just took some time to test the new adapted driver and found some issues. It's not working properly because the write_data() implementation has a bug. The display wants to receive one data stream without interruption (i2c Stop condition followed by a new i2c start condition) beginning with DATA indicating start byte and the next consequently following bytes shall be the frame buffer content in x-many pieces. So it has to look like this, this actually works fine. static inline void write_data(GDisplay *g, uint8_t* data, uint16_t length) { // uint8_t command[1]; (void) g; // // command[0] = 0x40; // Co = 0, D/C = 1 // // i2cStart(&I2CD1, &i2cconfig); // i2cMasterTransmitTimeout(&I2CD1, SSD1306_I2C_ADDRESS, command, 1, NULL, 0, MS2ST(10)); // i2cMasterTransmitTimeout(&I2CD1, SSD1306_I2C_ADDRESS, data, length, NULL, 0 , MS2ST(10)); // i2cStop(&I2CD1); uint8_t command[length+1], txLength = length+1; command[0] = 0x40; // Co = 0, D/C = 1 memmove(&command[1], data, length); i2cStart(&I2CD1, &i2cconfig); i2cMasterTransmitTimeout(&I2CD1, SSD1306_I2C_ADDRESS, command, txLength, NULL, 0, MS2ST(10)); i2cStop(&I2CD1); } The point is, how to make this more memory optimized, so to append the 0x40 at the beginning. This would mess up the data array if we don't do a temp. copy to work on. All that is needed here, is a way to control the sending of an i2c start/stop condition with hte higl level i2c driver. By now, that's the best and most simple way to do it. Another thing is. I tried to implement native scrolling on top, I activated GDISP_NEED_SCROLL but the scrolling routine doesn't get called. Keep it up. cheers Stefan

Hey everyone, I have tuned the driver a little more. This is the small changelog: + added a thread priority lift for the time data gets stuffed into the display, thus updating display goes faster and looks smoother * now spi and i2c init are done after the pads functions are set Hope this makes it into trunk. Cheers goeck SSD1306.rar

OK, here we go. After fiddeling with the code for a while I created those two board files for SPI and I2C communication with the display and washed out some bugs. Please have a look at it. SSD1306.zip

Hey, thanks for the input. This kind of hints solve the missing links in my brain... 8-) I implemented gdisp_lld_fill_area() as just a function body and set GDISP_CONSOLE_USE_CLEAR_LINES back to TRUE and as you stated it's actually the same experience. Firstly I will improve the scrolling algorithm again and afterwards imlement a filling strategy. --- EDIT: ------ Just got it working. Thanks again for that hint! After Implementing fill area, pretty straight forward though, and killing a bug in the buffer shifting loop everything now works again. I uploaded it under v0.4 in the drivers thread (link mentioned earlier here).

Awesome. Honestky, Tectu, If you have those days left in schedule for uGFX I will do that when beeing back from vacation. I guess you have some stuff left to do... Give me a shout. Cheers

Oh, sorry...I am in some kind of vacation state since Friday actually. I could for sure do that split, but not earlier than in two weeks when beeing back in office. I didn't know about the physical layer extraction into board files, that's why I did it with the PHY_LAYER_xxx define. So that's not needed anymore, How exactly am I gonna do it now? Two board files one assuming SPI is used and one assuming I2C is used, right? Thanks for the hints! Cheers Stefan

I guess adding SPI support shouldn't be that much of an issue. I will do some untested coding, since I don't actually want to rewire my board. But maybe I even do this, because update rates can be much higher using SPI (at least tons of youtube videos point that way). _____________________________________ EDIT 1: I just hacked a little and we some support for SPI now, please give it a try. I didn't test it, as I would have to reassemble the wiring then. Cheers SSD1306.zip

Hey, thanks for the feedback. Though I was kind of wondering, what semed to have been happening after I started developing the driver. I just took the templates from that time and worked upon them..anyway, I guess I now have changed almost everything accordingly but left the most stuff undone in gdisp_lld_control for now. Cheers Stefan SSD1306.zip

Oh...shoot...Shure, have a look over here.

Hey everyone I am happy to release my first version of a SSD1306 display driver with nice smooth scrolling. I packed everything together and uploaded it with this post. It was developed using the 1,3" OLED board by adafruit hooked up over I2C. Notes: - Driver works only with SSD1306 hooked up over I2C (at least SPI lld needs to be added) - Driver is written for 128x64 pixel displays (128x32 are only partly suppoerted and need small further work) - after using GFX subsystem gdisp_lld_diaply() hast to be called "by hand" to push over framebuffer to display - for nice scrolling GWIN_CONSOLE_USE_CLEAR_LINES has to be set to FALSE in file console.c Please someone give it a try. Cheers Stefan SSD1306.zip

Oh, sorry about that... But by the way, everytime I update the code from the repo, I manually have to set GWIN_CONSOLE_USE_CLEAR_LINES to FALSE, otherwise I get the bug back. I guess that's not the intended way of doing it. I have to look at the actual root of this bug again... Anyway, now I am happy with nice smooth scrolling and thus I want to release the first version of this driver. I packed everything together and uploaded it with this post. Notes: - Driver works only with SSD1306 hooked up over I2C (at least SPI lld needs to be added) - Driver is written for 128x64 pixel displays (128x32 are only partly suppoerted and need small further work) - after using GFX subsystem gdisp_lld_diaply() hast to be called "by hand" to push over framebuffer to display - for nice scrolling GWIN_CONSOLE_USE_CLEAR_LINES has to be set to FALSE in file console.c Please someone have a look at it. Cheers Stefan SSD1306.zip

OK, now I got it... console.c states at the beginning #define GWIN_CONSOLE_USE_CLEAR_LINES TRUE which I actually activated (set to true) and has been the problem. In console.c in gwinPutChar() after computing whether to scroll or not this code comes in focus #if GWIN_CONSOLE_USE_CLEAR_LINES /* clear to the end of the line */ if (gcw->cx == 0) gdispFillArea(gh->x, gh->y + gcw->cy, gh->width, gcw->fy, gh->bgcolor); #endif I think this takes me to this portion of emulation.c void gdisp_lld_fill_area(coord_t x, coord_t y, coord_t cx, coord_t cy, color_t color) { #if GDISP_HARDWARE_SCROLL gdisp_lld_vertical_scroll(x, y, cx, cy, cy, color); #elif GDISP_HARDWARE_LINES coord_t x1, y1; x1 = x + cx - 1; y1 = y + cy; for(; y < y1; y++) gdisp_lld_draw_line(x, y, x1, y, color); #else coord_t x0, x1, y1; x0 = x; x1 = x + cx; y1 = y + cy; for(; y < y1; y++) for(x = x0; x < x1; x++) gdisp_lld_draw_pixel(x, y, color); #endif } and since I have hardware scroll enabled this comes out like a double scroll. Now I set GWIN_CONSOLE_USE_CLEAR_LINES to false and everything is just as expected: only one line scrolled only when the screen is already full :-) Thanks for the time and support anyways, tectu. Keep up the good work! Cheers

Hey Tectu, thanks for trying... ;-) ... this is propably the most occuring issue that I personally have: "say it right, dude... :evil: " (speaking to myself) The scrolling behaviour is some sort of broken. OK, the point is I have written some sort of scrolling algorithm, that - when used as a simple function, called "by hand" - shits everything 11 pixels upwards which is just a line using UI2 font [i have to get the line height and spacing later on to automate this]. Now I put this stuff in the function sceleton called gdisp_lld_vertical_scroll(...). This gets called by gwinPutChar() under certain circumstances. What I get afterwards is scrolling everytime I put some text on the display; no matter if its the very first line or the tenth. I have 5 visible lines on the display using the mentioned font. After posting this issue, I even commented out the call of gdisp_lld_vertical_scroll() in gwinPutChar() and still, everything gets scrolled. The behaviour that I want to achieve is scrolling a line up only if the added line to the console was not visible. This should be done bye the if (gcw->cy + gcw->fy > gh->height) statement in gwinPutChar(). I'll investigate further tomorrow. My guess is that I have left some code unattended somewhere and now it's playing tricks... Couldn't find it till now. Good night Cheers

Hey everyone, first post in the new forum..whohoo :-)Anyways, I have a concern here with my SSD1306 driver which I am about to release to the public, but prior I really want nice console up-scrolling. Now I implemented some stuff, but I see the lines get scrolled all the way from the first line beeing written leading to spare lines between the normal written lines. The scrolling gets called from console.c everytime gwinPutChar() gets called. Looking at the code tells me, that scrolling should only be called, when y_cursor and lineheight > gdisp_height (64 in this case). As far as I figured out all the defines and measures are there. void gwinPutChar(GHandle gh, char c) { ... if (gcw->cy + gcw->fy > gh->height) { #if GDISP_NEED_SCROLL /* scroll the console */ gdispVerticalScroll(gh->x, gh->y, gh->width, gh->height, gcw->fy, gh->bgcolor); /* reset the cursor to the start of the last line */ gcw->cx = 0; gcw->cy = (((coord_t)(gh->height/gcw->fy))-1)*gcw->fy; #else /* clear the console */ gdispFillArea(gh->x, gh->y, gh->width, gh->height, gh->bgcolor); /* reset the cursor to the top of the window */ gcw->cx = 0; gcw->cy = 0; #endif } ... } Does anyone has a hint for me? Thanks in advance. Cheers Stefan