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)  {
    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);
      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;

      // 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[] 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) {
    if (seconds >= 60)  {
      seconds = 0;
      if (minutes >= 60)  {
        minutes = 0;
        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 !



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 :
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 Blue Pill page …

KaRadio DVT-01

I packed everything in my little case.

It's really a mess in there, with cables flying around and every card floating, not fixed on the inside. But it looks quite cool ! I removed the old radio antenna to use its hole to pass my USB cable.

Here's how it looks !

As you can see, I let the rotary knob (it's a simple angular potentiometer, in fact) from the amplifier out. It holds with a little nut that was provided with it. The buttons you can see are all fakes, they belonged to the old radio and I forgot to remove them (in fact they're simply glued to the back). 
Maybe I'll find some tools to make a nice-looking front panel when my stuff arrives. I'll ask people around me to lend me their tools...  In the end, the radio would have a 20x4 LCD screen to display artist + title and useful infos (like the IP or the volume when you change it from the website, maybe). I think I'll need two more buttons to change the station. I won't bother myself to add a volume…

Adding some speakers, part 2

I added the audio transistors.

Before diving into this modification, I wanted to see how deteriorated the sound is when you try to link everything on the same power supply WITHOUT transistors. So I made this little video. You can hear the difference !

First, I noticed that my three little wires (on the output of the VS1053) were badly soldered and caused a short-circuit somewhere. So I removed them, and replaced them with a naked Jack plug. (I took it from a selfie stick. True story. These selfie sticks have an audio Jack plug to be able to take a shot from a button near the hand, that acts just like a button from headphones with mic. End of the story, back to business :p )

I wired the output of the VS1053 to the input of the transformers, and I wired the output of the transformers to the input of the PAM8403 (the amplifier). Since on the input and on the output, they have common ground between the two channels, I kept the common ground. You can see a rough scheme below (the "Aud…