Sample Code request for simple, simple, simple project
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
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
![smile.gif](http://forums.parallax.com/images/smilies/smile.gif)
Comments
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
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.
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
Gary
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
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.
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.
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!
-- 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.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!
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
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