Big font

This is another inspiration I drew from the Arduino forum and sparkfun’s contest on instructables.com a while ago:
I’ve seen several examples of using “Big numbers” to display time on a 16X2 character display.
I’ve seen JO3RI doing animations on a 16X2 character display.
So I asked myself, why can’t someone come up with a way to double up the size of the 16X2 character display, not just ten numbers, but all alphabets, then it’d be useful as a larger display! Time, Speed, Direction, etc.
I’ve brewed this for a while (between last night and this morning), tada!

You can see that I intentionally scaled my images down so small that it would hurt to read the standard size fonts (click to zoom) but the large font is just fine. I made an estimate with it. I can read the clock from about 4 meters (13ft) away just fine, while the standard text is visible less than half that distance away.

 

The entire thing is for now resident in SRAM (please don’t blame me. I’ve been on this since lunch. I need a break, critic and encouragement before I squeeze memory)

Everything has been integrated smoothly in my phi-menu system now.

If you just want these large fonts, take the following code, but if you want all the interactive features, you need the phi-menu.

Nutshell version code

Full version code (up soon)

Phi-menu is about to be released!

The following is a teaser of the functions of phi-menu. The “official” release is set to be next Wednesday, together with the Phi-2 shield, which supersedes the Phi-1 shield that has been successful.

An initial analysis on the memory yields the following result: about 90 bytes of SRAM is used if you’re using Phi-menu so you’re pretty safe from running out of memory. Read some of my coding tricks to reduce your memory usage if you have already used up a lot of memory.

Here is how you can figure out memory usage:use the second code. The first one doesn’t work.

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

Password panel

Password panel for Arduino Phi-1 shield

introduction:

I have been thinking about this for a while: an arduino password input panel. You will be prompted to enter a password, you have three trials. If you pass, something happens, if you fail, something else happens. You decide!

After I recently pre-released the phi-menu, a versatile arduino shell for interacting with users and building menus, I realized I could make the password panel very easily with ph1-menu.

The project simply calls input_panel2() to get a string from the user, 6 digits long, ‘0’ to ‘9’ (you can change this yourself). Then it compares the user input with the stored password. If it is correct, it returns true and prints some good texts. If it is incorrect, the user is given more trials until the trials run out and some not so good texts are shown.

A second part of the project is a function that updates the password to different numbers and updates number of trials a user can have. This part, ideally only gets called after authentication, will be a part that you can offer to authenticated users. I’m just having it here as a demonstration of how easy it is to make something out of phi-menu.

Here is a video:

Here is the code:

Full version with Phi-menu

Nutshell version (password is, well, read my code!)

About phi-menu

Please refer to the phi-menu page for all the details

Arduino character art on LCD

The posts on arduino forum by JO3RI inspired me to make the following:

I used an arduino, Phi-1 shield, and phi-menu to create some animation art. His arts were very awesome but mine is lame. Anyway, here it is:

Here is how I constructed my codes with my latest Arduino Phi-menu software. The code download is in the end:

We need three menu items:
1. Display the animated arts
2. Set parameters, such as speed of the animation, forward or backward, and which animation to play
3. Display credits.

First, take a quick look at the FUNCTIONS.pde

Then add your menu texts in the menu_item00 and menu_item01 strings (in red) and add more menu items as you need (in green) . Make sure you enumerate all these strings in the later array (in green).

Now define some variables that you will be using in your program here after the comment line (in green).

Scroll down in FUNCTIONS.pde and find the switch command. Make sure you add additional menu items in the function (in green).

We code the parameters function first. We have three parameters, delays, art_number, and _forward. In parameters function (menu_function_0), we need to ask user to adjust each parameter at a time. You first prompt the user with a string such as “Delays” (in red) so the user knows what he is adjusting. Then you assign the value of the parameter, such as “delays”, to a temporary variable para_val (in purple). This way if the user changes the value and decides to escape, the original value of delays is not disturbed. Then invoke the hmi function. It handles everything, displays the current value of the parameter, sets the up and down keys to change the value, with lower and upper limits, and step size per key press. Once the user is happy with the value, it returns. Details of how to use the hmi function is in the documentation.
The last line in the block updates the parameter only if the user presses confirm. If the user actually escapes, the parameter is not changed.

In the body of the FUNCTIONS.pde, you will define menu_function_1. such as the following image:

In the body of the FUNCTIONS.pde, you will define menu_function_2. such as the following image:

Source code:

Character art with Phi-menu for Phi-1 shield

Optimizing your program

The following is just a reply I made on arduino forum. May be useful to share.

This is related to another post a while ago:

http://liudresllc.com/2011/02/04/how-to-optimize-your-arduino-memory-usage/

In case you run into memory issues,

On the efficiency in function calling:
1) Stack space is filled with return address and parameters you pass to your function
2) Your function may need to establish new variables costing more memory
3) You can rewrite the layers of functions, combining some layers if the lower layer doesn’t ever get called by more than one caller.
4) Using global variables reduces parameters passing to your functions, but also reduces readability re-usability of your code. Say you have one global msg[] for printing messages for serial or lcd and any function uses that array.

Other issues:
1) do you have too many strings? (move them to FLASH with PROGMEM)
2) have you defined too many variables that don’t ever change? (replace with #define)
3) are you using float where a short will suffice? (reduce footprint of each variable)
4) are you using too many overloaded versions of one library function? Say you use lcd.print(int) and lcd.print(string) and lcd.print(float). Try use only lcd.print(string) and use sprintf for formatting since it’s the best way ever.

Cross talk

Cross talk is a common feature that probably originated from phone lines carrying noise from an active conversation across its wires. If you have a piece of electrical wire close to another one, then the change of the current on one wire will induce change of current of the other, simply by the law of induction in physics. If you have strange noise in your project such as ultrasonic ranger, motors, etc., you may want to see if your power lines are cross talking with your control or sensor signal lines.

The ultrasonic transducer for example is a big power sucker. It’s turned on only momentarily and then turned off quickly, and then repeat for 7 to 8 times to generate the necessary sonic pulse for distance detection. The change in current within a unit amount of time, or di/dt, is big on the power lines and that could couple to their neighbors via induction with dB/dt (magnetic field changes with time), AKA cross talk. To eliminate this noise, you may add a capacitor between power and ground near the transducer to reduce the need to change current on the wire that passes the current. Charges on the capacitor simply flow to the device as needed to reduce the need to pull additional currents along the power line. This capacitor is called a decoupling capacitor. Or you can also shield your control or signal line and connect it to the ground. For a mobile device, a decoupling capacitor is most convenient.

When I was a grad student, I observed this strange but straightforward physics law of induction first hand. I was trying to control a power supply with a PID temperature controller. The power supply was connected to resistive heaters so was a thermistor. They went down the same cable, which was not properly shielded. The thermistor was used as feedback for tjhe PID temperature controller. I got the strange jump of power every now and then and the temperature was not stable. Then I realized the problem and used the shield inside the cable to shield the signal from the power lines. It worked nicely afterward. It turned out, the thermistor reading was strongly affected by the power supply suddenly turning on or off and that affected the temperature reading and knocked the PID off balance. My experience, either use a decoupling capacitor or use shield around your sensors. The shield needs to be grounded.

%d