Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: Strategies for attempting separate simultaneous updates on SSD1306 from Teensy

  1. #1

    Strategies for attempting separate simultaneous updates on SSD1306 from Teensy

    Hi all,

    i am working on a project which uses a SSD1306 display connected to a Teensy 3.2. At first i was updating the display whenever something happened which should cause the display to be updated. That didn't work and i've now gone to a different approach which is to just update the display on a regular basis (20 times per second or 20Hz) no matter whether the display needs updated or not.

    I'm wondering if anyone has any strategies for updating a display which will allow me to go back to my first approach of updating the display when something changes in my code which should cause an update to take place.

    The reason i had problems with my first approach is that i have 4 clocks running and they can all be at different speeds and timings between pulses. This means that each clock "could" update the display independently but that causes issues where one clock is updating the display but other clocks want to update the display. I was getting some glitches in the display which is why i went to the second method of a 20Hz refresh rate instead. Without getting into the code for my first version specifically (i don't have any of it left since i reworked the code for my second approach), does anyone have a method where i could update the display for each clock independently as in my first approach but would mean that only one clock could update the display at a time and the other clocks would wait till the display was free to update it themselves. I also had problems when the screen was being updated because of user input at the same time that a clock would want to update the display. Glitches were worse in those situations.

    I tried to simply have a variable which would keep track of whether the display was being updated or not (1 = being updated and 0 = display is free to be updated) and if it was then no other updates could happen until the variable went from 1 back to 0 but that didn't work.

    I know i haven't posted any code here for my first approach (it's all been re-written since then) but it's overall strategies i am looking for here, not specifically code.



  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Might help if we had a better idea of what is going on and what you would actually like:

    That is you say you have 4 clocks running that can update the display? Do they want to update the whole display, or do they have some area of the screen that each one wishes to

    If each one wishes to update portions of the display, like the whole display, that others may also want to update. What arbitrates what goes onto the display?

    In some cases, like each one wishes to update a field in the display. I would tend to maybe have each timer/task save out new values to some known locations and/or call something in the arbitration/display code, that says something like update field X to value Y and then when appropriate that code would know something is dirty and update the display.

    But if in some cases where one of the tasks has a logically higher priority to be displayed, like the fire alarm has been triggered, then maybe there is some call again that says this task currently owns the display. When it is done, it can call something again to say I am done...

    But again just throwing darts

  3. #3
    Hi KurtE,

    Thanks for the reply.

    The display can be showing several things as it has 3 pages. One page is just settings for the project so can be ignored. The other two screens show details about the clocks themselves.

    The whole point of the project is to provide clock signals to external devices for modular music production. On the main display it shows the position of each clock in its loop. As a clock moves to the next step the pointer on the display will move forward one step. This happens for all 4 clocks independently.

    Click image for larger version. 

Name:	Main Screen.png 
Views:	5 
Size:	13.2 KB 
ID:	28434

    The Focus screen shows all of the details for that specific clock. It has a part at the top which also shows the position of the clock in its loop which should be updating regularly, just like the Main screen, but the rest will only update when the Teensy receives a user input through the use of buttons and an encoder.

    Click image for larger version. 

Name:	Focus Screen.png 
Views:	12 
Size:	14.6 KB 
ID:	28435

    So, on both screens there is some portion which has to be updated regularly, several times a second, but there are other parts which don't update regularly or only when a user input has occurred.

    I experimented in the past with updating parts of a display and that went fine. My issue is still with more than one process trying to update all or part of the screen at the same time. Also making sure that if an update can't occur because the screen is already being updated, it can take place right afterwards.

    Any help will no doubt be useful.



  4. #4

    I would suggest you use an internal framebuffer. Since your screen is monochrome with size 128x64, a memory buffer will only take 128*64 / 8 = 1kb of RAM (at 1 bit per pixel). You may use the GFXCanvas1 class for example to draw on the framebuffer. Then any process can write on the memory buffer at any time to update part of its content without any risk of conflict. Separately, you can set up a timer that will blit the buffer onto the screen a regular intervals. You may even update the timer to tick asap after each modification of the frame buffer to make the UI more responsive. Since there will be only one timer doing the job of updating the screen, there is again no risk of conflict. This approach should work but there are probably simpler solutions...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts