Jump to content

goeck

Members
  • Posts

    21
  • Joined

  • Last visited

  1. 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.
  2. 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
  3. 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
  4. goeck

    SSD1306 driver

    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/ .
  5. goeck

    SSD1306 driver

    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
  6. goeck

    SSD1306 driver

    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
  7. goeck

    SSD1306 driver

    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
  8. goeck

    SSD1306 driver

    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
  9. goeck

    SSD1306 driver

    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
  10. goeck

    SSD1306 driver

    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
  11. 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).
  12. goeck

    SSD1306 driver

    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
  13. goeck

    SSD1306 driver

    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
  14. goeck

    SSD1306 driver

    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
  15. goeck

    SSD1306 driver

    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
×
×
  • Create New...