Sample Code request for simple, simple, simple project

gsanders

I have an extremely simple project but I've not coded in PBASIC before. I have
all of the logic diagrammed out and am about to very inefficiently take a
crack at the code, since I am learning while doing. And, of course, I'm in
a big hurry.

The hardware:
-- 2p24 Basic Stamp
-- professional development board
-- one 2x16 serial backlit lcd from parallax (item 27977)
-- 3 momentary buttons
-- 3 on/off slider switches
-- all this is to be in a low-voltage, battery-operated case

I am comfortable with doing the flow control, but would like some sample
code for interfacing with the lcd, buttons, and switches.

Anybody have something I can cut and paste?

Gary

Mike2545

First Of all I'd Like to say Hi and welcome to the forum.

Secondly, what do you want the buttons to do and what do you want displayed on the LCD?

Thirdly, I don't need to know if your teacher wants it in a low voltage, battery-operated case.

Mike2545

gsanders

Hi back to you.

The buttons just change the message in the display to a completely new message in most cases. I see the messages as 4 types, perhaps:
1. static
2. has a variable value that needs to display within the message,
3. displays a message with a countdown ("blah in 9", then "blah in 8", ...)
4. has a portion of a static message that appears to flash maybe every 1/2 second

All of the messages have been made to fit in 2x16 without any horizontal or vertical scrolling effect.

There is a reqmt for a timeout function such that if a person doesn't hit a button for a configurable period of time the display changes to another message.

As to the exact text of the display, I can type that in the code once I know how to paint it on the display.

Mike2545

Well Greg-O,

It sounds simple, it also sounds like a homework assignment, and nobody is going to do that for you.

You will need to read up on the following to help you in your quest:

SEROUT

BUTTON

Once you have learned that; then you can learn about VAR and Pause

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike2545

This message sent to you on 100% recycled electrons.

Post Edited (Mike2545) : 2/11/2009 1:53:08 AM GMT

gsanders

I'm not a student. It's not homework. It's a consumer product. I'm trying to get it prototyped asap so I can get a few units passed around for people to react to. I've been iterating the concept for about 3 mo and I just got the the functional design problems solved.

Gary

Franklin

When you get some code together come back and maybe we can help. There is code for the LCD on the site page where they sell the product and there is documentation and tutorials in the resourses area of the Parallax site. Good Luck.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Mike2545

In that case, I apologize all around. A lot of times we get students looking to get other people to do their homework.

I would start with the examples that Parallax has for the LCD display and add button commands to the code to run sub routines. If you get into it and have trouble by all means post here to find help. But to write your first post and ask for others to write code for your consumer product is a bit much, don't you think?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike2545

This message sent to you on 100% recycled electrons.

SRLM

gsanders said...
all this is to be in a low-voltage, battery-operated case

I'm curious: what does a battery operated case look like? [noparse]:)[/noparse] Anyway, you won't be able to get any lower than 5 volts (the BS2 level), otherwise you'll have lots of problems (like keeping the BS2 in a constant state of reset). Since you've got the DevBoard, you should be able to whip this project out quite quickly. My last project took me a night to write all the main code and prototype on the board, and several days to solder together boards and test them. Still not done yet...

Anyway, look in the Stamps in class books for how to code up for a switch/button. For the LCD, keep in mind that you may have to change the SEROUT constant to fit the different version of the stamp. Look in the BS Syntax and Reference manual for a table of these.

gsanders

Mike2545 said...
..and ask for others to write code...

Oh heck no.... I didn't mean anything more than if you know of some existing code that shows how it's done. Most of the examples, reference works, and tutorials often seem to show snippets or something incomplete that is hard to copy and just hack at. Just figured lcd and button handling routines are usually pretty standard-looking so wanted an example or two.

I'm getting some good direction from everyone so far.

metron9

Is the function of this device just to write to the display or is there other output that needs to be done to control, light LED's, beep beepers etc...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!

gsanders

The only things other than previously mentioned are
-- a single color led
-- a beeper
-- a physical actuator that switches from one position to an opposite one on a pulse. I suppose this will need a capacitor to bump up the current, but I'm not yet concerned with analog support circuitry.

The main deal is the lcd messages augmented with beeps and the led.

Chris Savage

It is often hard to describe how to do something this complex without actually doing the work. There are sample codes for the LCD, reading buttons and switches, etc. But sometimes merging the code can be an issue for someone new. At some future point I hope to address this with a well thought out video, but in the mean time, think of things this way. In every sample code for a peripheral device the following are the most common things that may be required in the code for the device to operate:

Constants
Variables
Initialization
Main Program Loop (Function/Sub Calls)
Subroutines

Constants are fixed values assigned to labels that make it easy for us to use them in the code. For example your LCD will work at a certain Baud Rate so you may assign a constant called LcdBaud to the fixed baudrate value, so anyplace you need that you can substitute LcdBaud in that place. Constants also include I/O pin definitions. You may want to create a label called LcdOut for the I/O pin you’re using so you don’t have to remember the number, just the label.

Variables are needed to pass dynamic values between parts of your code and the peripheral device. Often in embedded design it is good planning to reuse limited resources like variables where possible.

Initialization usually happens one time at the beginning of a program and is used to set up I/O pin states and directions, as well as to send certain commands to certain peripherals to set them for use in the program. For example, your LCD may need its I/O pin set HIGH and to an output and you may need to load customer characters or set the cursor mode.

The Main Program Loop is where everything happens. You may have seen simple programs that count and display values and then end. But in real-world applications the program never ends. It always sits in a loop either waiting or executing instructions. Good programs have a single main loop from which everything else happens. Sure there are subroutine calls, but the main program loop is the typical place these originate from and return to.

Finally, subroutines are called by the main program loop to do repetitive tasks, such as displaying a value on the LCD. You could do this from your main program, but then the code would keep growing with each new SEROUT command. By using a subroutine we have one section of code that does this job and we simply call it after setting up parameters and/or variables used by it.

Now, here’s where this information becomes useful in combining different example codes into one program…if each program has any of the above elements EXCEPT the main program loop calls, you can pretty much copy them into your new program. For example, you can copy the constants from an LCD example and a GPS example into one new program, same with the variables, initialization and subroutines. At this point it is a wise idea to examine each subroutine and the variables used to see if you can consolidate, reuse or share certain variables. This can be difficult for beginners, but keep one thing in mind…the BASIC Stamp can only do one thing at a time, so often a variable used in one part can be reused in another part without issue. Let’s take the LCD example where an index variable was declared to count a certain number of characters read from the EEPROM and sent to the LCD. Later we can use this index variable for other counting tasks.

Once you’ve gone through the variables and each subroutine to make sure there are no conflicts and you have optimized variable usage then you can create your main program loop. Often this will reside inside a DO…LOOP and you can flowchart out the calls to the various subroutines and define your comparisons within it. Everything running in the loop will always happen in order as defined by you.

So perhaps you want to display GPS data. So you call the subroutine which gets the GPS data and displays it on the LCD. But what if the GPS doesn’t have a lock? You could query the GPS for valid signal and then if it is valid, then query for the data and display it. Hopefully breaking down the merging of example programs will be made easier by looking at things in the context presented here. It has worked for me for over 27 years.

I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering

metron9

To add to what Chris said. Using psudo code is also a good way to go before you do any of the bare metal coding. Laying out all the variables you need in the program and then isolating each function or task and working on only one task at a time. The biggest concepts in dealing with input and output is the scale of time the microprocessor is going relative to your concept of time. When I can do 10 million things in the time it takes you to read this sentence it gives you a whole different approach to thinking in the Micro-controller arena. Typically I process the actual code algorithms in my head as I watch TV or just sit and ponder. When the code in my head becomes clear I then take it to the computer and isolate each concept and test just the very core function. If I try and put all the concepts in my head at one time they don't fit and it becomes a mess like my office.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!

MrBi11

Another advantage in laying out code it the format Chris stated, is that you can slowly create yourself a 'library' of functions.

Soon your development time is reduced considerably because you just pick items from you library and use them as building blocks.

The only coding ends up being tying them together with you 'Main' routine and maybe some tweaking for special features.

i.e. modifying your standard 4x4 keypad matrix routine to accept 2 keys at once for a hidden feature.
[noparse][[/noparse]I just used that on a machine .. you needed to press "#" & "*" at the same time to get into the 'set-up' mode.]

doing this with the examples isn't as effective as rolling your own, you'll find re writing the examples into your own format will make it easier
to re-use at a later time, everyone has there own 'flavor' of doing a task, all may get them completed, but you'll be able to reuse your own with less work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Smile ... It increases your face value!

Post Edited (MrBi11) : 2/11/2009 7:44:34 PM GMT

Chris Savage

Gentlemen,

Both of you have very good and valid points. The last one is especially along my train of thought…Libraries. The Propeller deals in this manner of code, but way back since my first assembly programs on the 6502 and Z80 I learned quickly to develop subroutines for a task that were very flexible and could be used in any program. I then can copy/paste this into new code. I almost always use the same variable names ahead of times, knowing that these library routines will mesh with others I have created for DS1302, DS1620, MAX7219, etc. I used to use pseudo-code more, but each time I try nowadays I feel I end up just using the commands, so I tend to refer more to a flowchart. There was an interim where I did just the opposite though. Everyone finds their niche eventually…different ways of doing things may work differently for different people.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering