Password input panel - a phi-menu example

I made a little password input panel out of Arduino and Phi-1 shield.

Nothing fancy:
You can update your password, number or trials allowed.
You can also test your password, try it up to "_trials" times and you either get in or get booted.

Video:

This is a precursor to my release of phi-menu, an open-source versatile core for arduino to ask user inputs and build menus very quickly. Any suggestions and comments?

Code snippet:
You can see how easy it is to construct nice programs with the phi-menu. All I needed was to spell out the logic and let phi-menu handle the keypad and lcd and updates.

boolean test_password(char* pw, int trials)
{
  char msg[7]="000000";
  while(1)
  {
    lcd.clear();
    lcd.print("Enter password:");
    input_panel2(msg, 6, 4, 1, '0', '9'); // Asks user input to be stored in string pw, up to 6 characters, displayed at col=4 row=1. Valid inputs are between 0 and 9.
    msg[6]=0; // Terminate the input with \0
    if(strcmp(pw,msg)==0)
    {
      lcd.clear();
      lcd.print("Authorized!");
      wait_on_escape(2000);
      return true;
    }
    else
    {
      lcd.clear();
      lcd.print("Error!");
      lcd.setCursor(0,1);
      lcd.print("Trials left:");
      trials--;
      lcd.print(trials);
      wait_on_escape(2000);
      if (trials==0)
      {
        lcd.clear();
        lcd.print("Unauthorized!");
        wait_on_escape(2000);
        return false;
      }
    }
  }
}

Complete code and more details are on my blog:

Update:

Now i will follow your project more than before... nice!...

If you use Phi-1 witch led and buzzer could make the correct or incorrect sequence of sound and blinking :grin:

It's all up to you Nikka93. Download either the full or the nutshell (simplified) codes. Just call the test_password() function with your secret password and number of trials you give to user and if the function returns true, celebrate, bells whistles flashing leds! Or else, if it returns false, :stuck_out_tongue_closed_eyes: ]:slight_smile: :fearful: Drive a relay for some shenanigans.

Nice one. As you know I'm waiting for your phi-2-Shield to be ready to ship to Belgium. I'll keep a close I on your posts :wink:

PS: do you know where the smurfs are from?

Alright. I'll post on the forum when Phi-2 shield comes out. It really makes no difference on the display part but has improvement on other aspects over Phi-1 shield.

I'm not sure where smurfs come from. I found this picture online :blush:
Any answers from you?
I watched the blue smurfs TV series as a kid. There is one particular smurf that likes to invent and build things (mostly mechanical) so I thought I would use a smurf as avatar. But if you search smurf pics online, you see the smurfs and many strange images. I'm not with those strange smurfs :grin:

Well I know where they're from. Belgium: wikipedia:

The Smurfs (French: Les Schtroumpfs) is a comic and television franchise centered on a group of small blue fictional creatures called Smurfs, created by and first introduced as a series of comic strips by the Belgian cartoonist Peyo (pen name of Pierre Culliford) on October 23, 1958.

Watching the forum for your post on the phi-2-shield :wink:

Hi,
I started to read the documentation on phi-menu, and already learned a lot o things, thank you vey much liudr !

It's funny to that in some places I used the same logic do atain the same goal, without, I promise you, knowing anything about phi-menu. Like using the cursor to show the user the digit wer're editing and changing the increment accordingly. Creating the SAME (judging from screenshot) arrow up charter ! Using 0-padded input field to keep a consistent user interface. I guess some solution are universal.

There are also some part where our approach is different :

  • I needed a main loop() that could be interrupted as quickly as possible without using interrupt, so there is no delay() in my main loop and the sketch never waits for a timeout. But it costs me some global variables of course.
  • I never clears my LCD and only overwrite the lines if needed, avoiding the "display flicker" caused by the "no delay" policy
  • I constantly update a 1 char "heartbeat" which defeats a bit the purpose of my second solution but was VERY handy when debugging code

Here you can see a -too small- video of the early stage of this shield (I've got a dedicated keyboard now)

Again, thank you so much for helping me on my memory usage problem. Free time was hard to find this week, but I promise to make good use of your hints next week.

Hey pixelk,

Your work is very fine stuff! I guess with the dimension of 16 by 2, lots ideas converge to very similar forms. I'm not surprised we came to the same conclusion.

So you're working on a camera-related project? Could you PM me some details? May I suggest a Phi-1 shield to replace many of the wires you have (at least 20 of them on LCD and buttons)? That's the shield I used to demonstrate the password input pad. I DO have a text input panel function that might be the only step ahead of you on the menu codes :wink: :sweat_smile: Work hard now Liudr!

More update on the phi-menu.
Auto button automatically cycling menu and values and null buttons for maximal flexibility

Applying JO3RI's idea of automatically cycling menu and another idea I had, I created two more types of buttons:
Besides real buttons, physical buttons and button-like inputs such as photogates and Hall switches, there is another type of buttons, virtual buttons.
1 - null buttons
Null buttons are used where you want to disable say the left button. You can declare it as null in the button initializing. The use of this is to avoid having to remove or revise phi-menu functions in the event that several buttons are not needed and their pins are used for other purposes. Say you don't need left or right buttons and use their arduino pins for LEDs, then without the null buttons, you will remove the object instantiation lines, remove sensing these buttons inside the phi-menu system. It's a mess. Then you realize that you need them back so you go and add them back everywhere you removed them. Now with null buttons, you just assign btn_null as their pins and that button is treated as null button and sensing it always gives buttons_up status.

2 - auto buttons
This button is automatically pressed after every period of time, say 1.25 seconds. The button is not associated with any physical arduino pin so you can free up a pin. The use of auto button can be that you are in a crunch for more pins and have to sacrifice buttons to save pins. What can you do with less buttons? Let them be pressed automatically. Say, in the following video, I only needed ONE button to operate the whole password input panel that I used to use all 6 buttons to operate!!!

Well it's a waste of time if you want to input something very long but for prescribed things like day of the week or else, you can certainly waste some time to save arduino pins. You still need to sense the buttons to make the auto buttons work.

Video: ONE button operates the entire password input panel:

Ok I cross posted this too, but from now on I'll post here about the Menu: :roll_eyes:

Nice one. You know, I keep asking about that rotating arrow thing to be used in the menu, but then I released, you don't use that kind of menu.

I'm always think of a menu where you see more then 1 choice at a time. Something like this, where the arrow would change places when cycling the menu.

GAME . HSCORE
. CREDITS . HOWTO

. GAME . HSCORE

CREDITS . HOWTO

. GAME > HSCORE
. CREDITS . HOWTO

. GAME . HSCORE
. CREDITS > HOWTO

Now the reason why I would use this kind of menu is, that you know how many items you can choose of. I know it's limited this way to 4 items. BUT ...

I have seen some other approach on Alarm systems

Explanation of m => here you have the explanation of you menu item (scrolling)
.1.2.3>4.5.6.7.8 => here the arrow shows which menu item is shown above.

This way you have a better way of knowing how many menu items there are and when you'll get at number (let's say) 5

Great suggestion! All that can be done on one particular layer in the phi-menu, the menu render program. If I write a different render program (which I had for a four-input system), I will see different style. I'll ponder on it. Maybe get the four menu first and then the alarm system thing (I've never seen it personally so thanks for mentioning).

No video yet? ]:smiley: yeah, I know, it's sunday.

JO3RI:
No video yet? ]:smiley: yeah, I know, it's sunday.

Will upload tonight. I was busy getting the phi-menu ready for first release. It features 3 menu styles and a lot more.

Most recent update on the password input panel / phi-menu.

Formal release of phi-menu is within a week!

Very slick. I must say, seeing you use the menu, I like the index menu the most, because you really know where you are in the menu.

What I'm actually interested in, is the memory usage and how big your sketch is (uploaded bytes). You could put this code in your sketch, so you can check on your serial monitor (or you change it to show on your LCD), to show memory usage. (SRAM)

int availableMemory()
{
  int size = 2048; //set your aruino SDRAM (mine is 2048)
  byte *buf;
  while ((buf = (byte *) malloc(--size)) == NULL);
  free(buf);
  return size;
}

void loop () {
serial.print(availableMemory());
serial.print(" / mem used = ");
serial.print(2048-availableMemory()); //set your aruino SDRAM (mine is 2048)
}

or maybe you better have a look at:

http://www.arduino.cc/playground/Code/AvailableMemory

Great suggestion! I'll try it sometime maybe tonight. Have in mind that the Serial and LCD libs both eat up some memory. So the memory footprint of my library is not just itself. I'd say to run my library, you need maybe 100 bytes memory at most. The part that needs most SRAM are those that generate strings to print on LCD, with arrays at least 17 bytes each so if they nest a couple times, 50~bytes are gone. Then static variable definitions are maybe 20 bytes with 30 bytes of local variables that get released after execution. Other expenses are buttons class that should be there even without an interactive layer, maybe 54 bytes storage for 6 buttons and one int in one buttons class member function.

amazing work liudr... i still wait to use this function on phi1 shield :grin:

JO3RI,

The code you provided is not working as pointed out in the tutorial. Using the second code in the tutorial, and the bare bone phi-menu (not the one for demonstration with clock and else), I found out the bare menu itself has 1671B free when on the top menu. Using interactive functions will reduce that by around 30B, due to the text render buffer.

All this includes memory used by lcd and serial library, which should not be counted against the phi-menu but I can't find out how much they cost.

Just lcd and serial libraries:
Compile size:4058
Memory free:1826

Bare phi-menu with all interactive functions and one menu style plus limited rendering functions resident in FLASH:
Compile size:7040
Memory free:1689

6 buttons instances have 15*6=90B for storage + pointer
2 pointers for mem_check, 4B total, right?
Nested calling for two layers of functions + variables will be around 44B

all above add to 1689 is 1826.

So phi-menu uses around 50B of memory + 90B for 6 buttons + any additional rendering or user input related consumption.
If you want to go into my codes and chop out a few buttons that you don't use and squeeze a few bytes here and there, you spend around 90B+ SRAM if you use phi-menu.

I think this software is as good as you can get, for free :slight_smile: