LTE project button code

lteprojecta

Here’s the deal, I have a very small screen, with six available buttons. I need to make sure that if you press the button, it does the right thing for the screen it is currently on. How do I map the six buttons to the specific screen I’m on, with only 32 kb of programming space?

Well, brilliant or butchered, here’s what I did….

First, I decided on the flow of screens. Example, from the main screen (screen number 1), you can go to the texting screen (sn 6) or GPS screen (sn 3) or the “other programs” screen (sn 12). From the GPS screen, you can go to the location screen (sn 2), or the compass screen (sn 4). And from the texting screen, you can go to the read messages screen (sn 9), or the send messages screen (sn 7), the delete all messages screen (sn 8), and so on and so forth. All told, there is around 15 screens currently.

But how to map pushing the same four buttons for each screen number? There are probably better ways to do this, but I came up with a mathematical formula and a switch to handle this for me.

sn Button 1 Button 2 Button 3 Button 4 Button 5 Button 6
1 2 3 4 5
2 6 8 10 12
3 12 15 18 21
4 20 24 28 32
5 30 35 40 45
6 42 48 54 60
7 56 63 70 77
8 72 80 88 96
9 90 99 108 117
10 110 120 130 140
11 132 143 154 165
12 156 168 180 192
13 182 195 208 221
14 210 224 238 252
15 240 255 270 285
16 272 288 304 320
17 306 323 340 357
18 342 360 378 396
19 380 399 418 437

What the above table does, is utilize the following formula: “Screen number plus Button number is multiplied by Screen number.” With this formula, I then used the variable screen number, which I need for what screen text to display anyways, and made a switch that checks the math to see what button I am pushing. What is interesting about this is that you technically could do any operation from any screen, but the screen number will make the math work only for the operations you should do on that screen.

As you can see, screen number 2 and screen number 3 both share the number 12. In my small table, it is the only occurrence of the same number twice. Fortunately, it is okay, because I made screen 2 the location screen, which you get to from screen 3. So pushing that first button on screen 3 takes you mathematically to screen 2, and on screen 2, pressing the last button takes you mathematically to screen 2, which is where location information is displayed. So it is a little sloppy, but works out in the end.

Buttons 5 and 6 don’t work that way, though. They are special buttons that always return the same two numbers. The first one is the “home” button, which from any screen takes you back to the main menu. The second is the “select” button, which will be unique in use and will have to have a special case by case use. It’s actually not used on any screens thus far, so it is held in reservation for now. I was thinking of making it a modem power on/off switch, but we will see.

As always, you can check out the commit on my GitLab.

Linux – keep it simple.

Drawing variable circles with an Arduino Uno and a Nokia 5110 LCD

I’m still trying to catch up on some of my new toys that I bought/got around Christmas time. I know, I’m four months behind! One of those gadgets was a Nokia 5110 LCD screen, and this thing is fun! It looks like something they used to use in old Nokia cell phones, and it works great for a monochrome, low resolution display.

I’m driving it with an Arduino Uno board. At first, to make sure I understood how to use it, I watched InterlinkKnight’s Youtube tutorial, which you also should check out. It was very clear, highly informative, and really well put together.

After watching the tutorial, and loading the library and his sketches, I then set out to make my own. I noticed a couple of things that were noteworthy for the new user, so I thought I’d share them here.

First, you need the library. You can get it here: https://github.com/olikraus/U8glib_Arduino

Just unzip the library, and put it in your Arduino library folder (unzipped, of course). For me, on my Ubuntu Linux machine, that was in /home/alaskalinuxuser/Arduino/libraries/, where I just dropped off the unzipped folder from U8. If you don’t put this in your Arduino libraries, it can’t find the referenced include file, and this wont work.

Then I made my own sketch:

/*
This is an example on how to use the display known as Nokia 5110 SPI with PCD8544 driver using the U8GLIB library.

Nokia 5110 SPI display pins for Arduino Uno/Nano:
* RST = 8
* CE = 10
* DC = 9
* DIN = 11
* CLK = 13
* VCC = 5V
* BL = 3.3V
* GND = GROUND

We use this library: https://github.com/olikraus/U8glib_Arduino

User Reference Manual: https://github.com/olikraus/u8glib/wiki/userreference

List of fonts: https://github.com/olikraus/u8glib/wiki/fontsize

Sketch Originally made by: InterlinkKnight
This sketch was featured on his video tutorial for this display: https://www.youtube.com/watch?v=1ZvY_lb6BoU
Last modification: 11/22/2017

Sketch modified by alaskalinuxuser
Last modification: 04/02/2019
*/

#include “U8glib.h” // Include U8glib library
// Create display and set pins:
U8GLIB_PCD8544 u8g(13, 11, 10, 9, 8); // (CLK=13, DIN=11, CE=10, DC=9, RST=8)

int Variable1; // Create a variable to have something dynamic to show on the display
int fadeAmount = 1; // how many points to change by

void setup(void) // Start of setup
{

// Select a font:
u8g.setFont(u8g_font_profont12);

// Change display orientation:
//u8g.setRot90();
u8g.setRot180();
//u8g.setRot270();

} // End of setup

void loop(void) // Start of loop
{
// wait for 25 milliseconds to see the dimming effect
delay(25);

// change the brightness for next time through the loop:
Variable1 = Variable1 + fadeAmount;

// reverse the direction of the fading at the ends of the fade:
if (Variable1 <= 0 || Variable1 >= 45) {
fadeAmount = -fadeAmount;
}

u8g.firstPage(); // Beginning of the picture loop
do // Include all you want to show on the display:
{
u8g.drawCircle(41, 21, Variable1, U8G_DRAW_ALL); // Draw a circle (x,y,radius,option)

u8g.drawRFrame(59, 10, 25, 13, 3); // Draw a rounded square (x,y,width,height,radius)

// Variable with left text alignment:
u8g.setPrintPos(63, 20); // (x,y)
u8g.print(Variable1); // Value to print
} while(u8g.nextPage()); // End of the picture loop

} // End of loop

The key part of what I was playing with, was using a variable to set the circle size. Every run of the loop, after a slight delay, the circle is increased or decreased in size to make it grow or shrink on the screen. This makes a very nice “pulse” effect. Most of the code here was originally in InterlinkKnight’s sketch, I just modified it for my use, and added a variable changer.

Another thing I noticed was the back lighting. On my Nokia 5110, it is labeled as “BL” which means you apply voltage to it to illuminate the back lighting of the screen. In his tutorial, he rightly mentioned that you could use 5 volts here, which works great, but I found it to be obnoxiously bright. Instead, I used the 3.3 volt output from the Uno, and that was much better on the eyes. The screen will work without the back lighting, but then you need ample light to view it.

I’m seeing some fun potential with this screen!

Linux – keep it simple.

Critical Velocity – an open source libGDX game that was crashing on small screens is now fixed!

Critical Velocity is a fun little open source arcade style scrolling game that I made after finishing my Android developer class. It was my first released game using the libGDX engine, an open source graphics engine that is great for making games. Due to my inexperience, however, I didn’t take into account that all screens are not created equal. Some screens are bigger than others, and some have lower resolution than the phone I built the game on.

This caused a problem. After releasing the game, I quickly was alerted to the issue through the GitHub issue tracker, where several players let me know that it was crashing on startup with their phones. It took a little bit of time to figure out, but I came to realize that the app was crashing on phones that were smaller than 800×480 screen resolution.

At first I thought there were all sorts of problems with graphic asset sizes, and memory issues. I tried numerous things to fix it, but nothing worked. Finally, I gave up. But, a few days ago, I decided to take another look. By God’s grace, this time I got it figured out! Before, I was working off of the information provided by people with smaller resolution screens, but I decided that I should load up the game in an emulator with a 320×240 resolution screen, and watch the logs. That’s when I found the problem.

The issue didn’t have anything to do with libGDX, the graphic assets, or the amount of memory the game takes (about 15 MB). As it turns out, the math just didn’t add up. Literally!

In the game, the upper and lower walls are separated by a gap. The size of the screen and the size of the gap is used to determine where the next set of walls opening can be (up or down) from the previous wall. The idea was that as you went faster, an opening at the top of the screen followed by an opening at the bottom of the screen is technically impossible to reach, so this math would keep it “near” the other opening within reason, but still allow it to be randomly placed, up or down from the previous one.

The math looked like this:

Place of the next wall opening = randomly based off of (1/2 of the screen height – the size of the gap) from the center of the screen.

This worked great on my test phone that had a screen resolution of 1920×1080. With the standard gap that I set of 450, the math looked like this:

Place of the next wall opening = randomly based off of (960 – 450 = 510) from the center of the screen.

But it didn’t work for a screen as small as 320×240 because:

Place of the next wall opening = randomly based off of (160 – 450 = -290) from the center of the screen.

For a random number, you can have a negative outcome, but you cannot put in a negative input. The random number is based on starting at 0, and create UP TO X random numbers. So if X is negative, then the random number generator doesn’t know what to do!

So I had to invent a way to fix this problem. Fortunately, that was easy. I used an if/then statement to ask what the screen size was, and then changed the gap size to be less than 1/2 of the screen size. I also had to edit a few parameters, such as thrust, speed, and distance also based on screen size. You can check out my code and commits here and here, if you’d like.

Long story short: Don’t make assumptions, check the logs and they WILL lead right to the problem! If I had run the emulator myself before, not having a small screen phone anymore, I hopefully would have seen this right away. Here are some screen shots of the game on different phones. Unfortunately, I still have a lot to learn to make sure that the game LOOKS the same on different sized screens, but at least now it doesn’t crash!

Linux – keep it simple.

Sometimes the screen is just too small….

Recently I updated my Ships, Captain, and Crew game, because of a comment from a friend. They wanted to know where to find the instructions on how to play the game.

Of course, I told them the instructions are on the “about” page. They looked and couldn’t find them. After looking at their phone, I realized that the screen, though large, was a lower resolution, and the information I wanted displayed was off of the bottom of the screen.

App making is a lot more tedious than I thought.

When you are unsure if information will be off of the screen, there are several options to choose from, like making everything smaller, or using constraint layouts, or even scroll views. I just wanted to leave a note for the wise to check that their information is properly being displayed on different devices. Just because it looked good on the Android emulator doesn’t mean that it actually displays on every one’s real screen.

Linux – keep it simple.