Skip to main content

New functions for LCD and time !

It's been a while since I rewrote them, but I always forgot to post.

This article will be text-only. Sorry, but it will be about code, so I don't have a lot to show, except that "it works" just as shown in the previous vidéo. Go take a look at the previous article !

So, I had that problematic misconception of my previous screen functions. Remember, the whole problem was :
  • I wrote them as part of the LiquidCrystal_I2C library, which means I had to share my modified library, which is highly unpractical and dirty,
  • I wrote them with delays everywhere, which stopped the whole microcontroller, and this is a huge pain in the ass because nothing looks okay.
So the goal was to rewrite them as RTOS tasks, so they can be lauched "in parallel", or at least, they allow the microcontroller to do another task while in a waiting state.

The thing is, on my little 20x4 screen, space is limited. The main feature I wanted was a scrolling feature, like you would find in any serious radio device, with the following features :

  • The scroll should go forward with X chars (X being tweakable),
  • The scroll should wait for N milliseconds between each step, with 2*N waiting at the beginning of the scrolling and at the end (to let you read calmly !)
  • The display for the song title and artist (I don't split them) should be reset at every song change. That means, every time the KaRadio sends a song title, a flag is triggered, and the scrolling is interrupted, the screen cleared, and the new song begins to scroll from the beginning.
Well, what can I say ? I implemented all of that. 
I also implemented another trick : I noticed that the screen may be accessed by two functions running in parallel. That's a common case of single resource where a mutual exclusion must be implemented. I managed to get rid of that by introducting a mutex with the boolean "isLCDused". So far, I haven't seen any wrong behaviour.

To gather all the informations I need, I created a small structur, with a "Song" instance.

struct InfoScroll {
  char line; // line number, 0-3
  char *s_connect;
  char fw;
  int waiting;
};


InfoScroll Song = {0, "INIT...", 2, 900};
 


My RTOS function looks like this :


static void printScrollRTOSTask(void *pvParameters) {
  while (1)  {
    vTaskDelay(10);
    bool finished = false;
    int i = 0;
    int len = strlen(Song.s_connect);
    String p_connect = String(Song.s_connect);

    while (!finished)
    {
      // Get the song title, start at position 'i', truncate it if needed
      String p_message = p_connect.substring(i, (i + LCD_WIDTH < len ? i + LCD_WIDTH : len));
     
      // To avoid trailing at the right of the screen, fill with blanks
      for (int k = len - i; k < LCD_WIDTH; k++)
        p_message += " ";

      while (isLCDused); // wait for the LCD to be available.

      // Write that stuff
      isLCDused = true;
      lcd.setCursor(0, Song.line);
      lcd.print(p_message);
      isLCDused = false;
     
      // Wait a bit if it's the first line...
      if (i == 0)
        vTaskDelay(2 * Song.waiting);

      // Wait a bit and flag 'finished' if it's the last time
      if (i + LCD_WIDTH >= len)
      {
        finished = true;
        vTaskDelay(2 * Song.waiting);
      }
      // Go forward in the display !
      i += Song.fw;
      vTaskDelay(Song.waiting);

      // If we have to update the title, just flag 'finished' so that the new title is taken into account at the beginning.
      if (flag_screen[NEWTITLE] == 1)
      {
        finished = true;
        flag_screen[NEWTITLE]--; // remember, we have to update 2 different locations. First is, when we CLEAN UP the whole line, Second is here.
      }
    }
  }
}


Some additionnal quirks should be noticed.
flag_screen[NEWTITLE]--;
flag_screen[] is an array of chars that are used as flags to know which part of the screen must be updated. In some rare cases, I need to update multiple parts of the screen with only one flag. In order to do them in the right order, I decided to use chars instead of simple booleans, and use flag_screen[] as a countdown latch. 
I'm rather satisfied with how I strip down the title. It's far better than previously where I played along with pointers and sometimes it messes up everything.

The whole screen refresh is done in another RTOS task, actually "mainTask". I won't write it here, it's not that interesting. I will post my code some day on some GitHub, promise. Leave a comment if you want it now !
One interesting point is that, "mainTask" doesn't have priority on taking over the LCD. The whole function is in a "if(!isLCDused)", and if it's not, the whole function will just be skipped. It's run at 5Hz, so by far sufficiently fast to actually refresh the screen in case of trouble, even for time display.

Let's talk about time ! As you may have seen in previous videos, I implemented a local time counter. At first, it was messed up because of the delays in the scrolling. Now, it works fine ! Here's my code :


static void localTimeTask(void *pvParameters) {
  while (1) {
    seconds++;
    vTaskDelay(1000);
    flag_screen[NEWTIME]++;
    if (seconds >= 60)  {
      seconds = 0;
      minutes++;
      if (minutes >= 60)  {
        minutes = 0;
        hours++;
        if (hours >= 24) {
          hours = 0;
        }
      } //endif (minutes)
    } // endif(seconds)
  } //endwhile
}


Well, it may work nice, but I will try to rewrite it using the RTClock library for STM32, because it should me much more optimized and it has built-in structures to use seconds, minutes, hours, and days. Why do days matter ? Well, maybe in a future version, I would like my alarm clock to fire only on certain days, only on weekdays for example...

 Finally, I made a function to monitor a button state with polling, and to take action on press, but I think it deserves a dedicated article. It's better to keep things a bit organized.

By the way, my TM1637 - controlled 7-segment clock arrived today ! Can't wait to try it out ! I think I'll probably make some kind of test program to learn how to display things on the TM1637, and how to use the EEPROM to store reboot-resistant variables (for alarm clock time !).

Exciting times ahead ! See you next time !
 

 

Comments

Popular posts from this blog

Flashing an STM32 "Blue Pill"

Flashing this STM32 "Blue Pill" board took me 5 hours. I finally recieved my microcontrollers. I have at disposal : A brand new WeMos D1 Mini (it's a smallish NodeMCU) An Arduino Pro Mini (it acts just like a Leonardo, but it lacks some interesting pins sadly :(  ) An STM32F103C8T6, I'll call this the Blue Pill for short. The Arduino Pro Mini has an Arduino bootloader out-of-the-box, so  I could play with it directly. It's nice ! Still, it lacks the double Serial of the original Leonardo, and most importantly, there's no A4 and A5 pins, so libraries for I2C won't work without modification. But the Blue Pill needs more work. Basically, I followed the instructions on this site : http://wiki.stm32duino.com/index.php?title=Installation Since it's quite complicated, consider the following as a tutorial to set up your Blue Pill. I tried different things, the following has worked for me. Before doing anything software-related, while reading the B

Anti-optimization, hardware crumbling apart, GitHub

Today, short post about deceiving software. Remember when last time, I said I had to do optmizations on my code ? Well I tried. And it went worse than I expected ! First, I tried to gather similar codes in some tasks, but it came out they were too heavy for FreeRTOS to handle them correctly, resulting in heap panic... So trying to enhance my code, I worsen it ! So I hard to roll it back. Then, I tried to implement real mutexes for some resources that are shared among the tasks, in particular the screen (and maybe the UART one day, but I can manage to use it only in one task, if I split it in several functions). When I though I understood it and implemented it correctly, it turned out to make the STM32 crash at bootup, and being non recognizable by my PC anymore ! So again, I had to rollback to the previous version. I'm still trying to figure out how to re-design my code, while keeping it runnable on that picky Blue Pill. You can FINALLY find my code on Github ! I suggest

Buttons and alarm

Now I have my buttons. And it didn't go smooth sailing. Before all, let's try to review what I want and how to do that : I want buttons to control the KaRadio. 6 buttons are enough. We will detail them a bit afterwards. I want my buttons to also set an alarm clock. This should stay visible, and should use the already implemented buttons to be modified and set. I want that any push in a button results in changes that are visible on the LCD screen. If the volume changes, I want to see it. If the station changes, well that's already implemented. First, I went to read the documentation on how to operate the GPIO. I knew I needed only to read digital states of the GPIO. At first, I found this document straight from Maple docs : http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-docs/0.0.12/libmaple/api/gpio.html It's quite dense, but there is some information. GPIOs must be initialized with gpio_init(), then you need to set their state to output or in