PDA

View Full Version : CAN a variable exist without a PIN attached?



T Chap
05-27-2006, 04:17 AM
In the case of wanting to set a variable to a state for later use, is there a way to do it without wasting an
i/o?

STATEMONITOR1 VAR USING NO PINS but something else that remembers

example:

If "some condition that may involve i/o's " then
STATEMEMONITOR = 1


Where the state is only for the chips own purposes, not i/o? I have a case where I need to store a state for later use, but its use will never be i/o.

Tom Walker
05-27-2006, 04:31 AM
If I am understanding you correctly, then the answer is: variables don't have a "native" connection to pins. Variables CAN be associated with pins, but are not limited to being so.

Or am I missing your point?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

SSteve
05-27-2006, 04:36 AM
stateMonitor VAR BIT
sensor PIN 1

...
stateMonitor = sensor
...



Now stateMonitor has the value of pin 1 at the time that line of code was executed. If Pin 1 changes state, stateMonitor's value will not change.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

T Chap
05-27-2006, 08:05 AM
stateMonitor VAR BIT

Yes that is what I am after, a memory location to store a state just as you described. I assume you can assign other variables to a BIT for other storage bits as well? Is that is true, does the chip just look for a free bit of memrory and claim it for that vvariables use?

Thanks for the replies

Invariant1
05-27-2006, 10:20 AM
You can create as many variables as you want up until you fill up memory in your EEPROM. BIT vars take almost no room so use them liberaly. If you're looping and testing pin states with "IF" conditions, it's good programming to test a variable that is set equal to the pin state, instead of testing and branching based on the pin state itself. That way you have a distinct point in the flow of your code where states are defined (stateMonitor=sensor, sM2=snsor2,etc.) and all subsequent "IF" tests through the program loop will perform predictably. Otherwise, you never know where in the logic flow a pin state might flip and the conditional branching can do bizarre things. Being an all-digital simulation guy for years, I learned this the hard way the first time I had real hardwire-in-the-loop feeding inputs to my BSII.

Chris Savage
05-27-2006, 10:58 AM
Invariant1 said...(trimmed)
You can create as many variables as you want up until you fill up memory in your EEPROM. BIT vars take almost no
Just for clarification, variables use RAM not EEPROM.· DATA statements and WRITE commands use EEPROM, as well as your program.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com (mailto:csavage@parallax.com)

T Chap
05-27-2006, 01:08 PM
Ok that is great info thanks fellas. I didn't know that you could write to the eeprom other than from the tokenizer, that is interesting. So you could theoretically write a time stamp at some interval, say minute by minute, then if power off and back on, compare the old time stamp with a brand new one and generate a report of down time?

Completely off topic but after 3 days of learning from scratch about basic, it seems you can do about anything you want to do. I am curious if there is anyone experienced with assembly language systems that could comment on why you would want to write code with a chip that requires much more complited language. Everyone I have taked to says C or similar is much more harder to tackle, so why leave basic?

SSteve
05-27-2006, 01:33 PM
You can write to the EEPROM, but keep in mind that it's only good for 1,000,000 or so writes. If you wrote an EEPROM location every minute, it's good for a little under two years. You could also rotate addresses to increase the life. e.g. you could set aside 16 locations as a circular buffer for your timestamps. When the program started, it could look for the most recent timestamp to determine down time. It could then start writing new timestamps at the next location and wrap back around to the beginning of the buffer when it reaches the end. You've just extended your EEPROM life to over thirty years.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

Harbor
05-27-2006, 01:47 PM
originator99 said...
I am curious if there is anyone experienced with assembly language systems that could comment on why you would want to write code with a chip that requires much more complited language. Everyone I have taked to says C or similar is much more harder to tackle, so why leave basic?
This is the classic question of everyone as they learn their first programming language. Right now PBasic is teaching you things you can do in computers, but only some of those things.·PBasic is your window on the world of computing, but you can't 'see' the things that exist outside the world of PBasic. This feeling goes away after... well, never. The language you currently think in tends to limit the ways you see to solve problems with computers.

I program over a dozen assembly languages and a similar number of high level languages and I have to choose which language to think in before I get serious about designing a solution to a problem, because the language tends to constrain the way I think. PBasic is a blend of those two categories. Assembly languages let you deal with the raw instruction set of a processor. Programs that require that level of detail are difficult to move from one machine to another. A language like C lets you deal with the very basic attributes that almost all modern processors share, so it permits very detailed control of a processor, but the programs you write can be moved to other machines easily. At least to other machines of the broadest category. Well, fairly easily. C is so powerful that you have to·be skilled to avoid saying things that do not translate to other machines without error. On the other hand, some languages are so problem specific that you can't easily program anything outside a narrow range of problems, like LISP or Prolog, but they don't care at all which machine is executing the code.

'Pure' Basic, if you can ever find an example of that, is almost completely divorced from the underlying computer running the code. It was created to help teach people how to program without first having to teach them how computers work. (This objective was a little controversial to be honest, but that was the purpose of the original design.) It does teach certain principles about how programmers must think, but in pure Basic you can't 'see' the underlying hardware like registers and I/O ports.

Parallax Basic, like many variants of Basic, keeps the programming concepts very 'basic' but includes some pretty machine-specific features. The ones that were important to the designers at Parallax.

So it does seem like you can do anything you like, but only because you're working on a machine, the Basic Stamp, for which the PBasic language was designed. And right now you only like to do things the Basic Stamp was designed to handle.·If you tried to write a compiler or an operating system or an artificial intelligence list-oriented program in PBasic you would find it very difficult. A program of that sort is required to let the Basic Stamp execute the code you write in PBasic, but it runs as a support role that you never see, and that underlying program could not be written in PBasic itself.

I'm just speculating, but I imagine the various tokenizer and interpreter versions are written in C or in assembly code. The software that creates this forum may have been written the same way, but it also could have been done in one of the modern scripting languages that were designed to deal with internet applications.

Hope this helps, but don't be surprised if you keep getting surprised.<g> Computers are a large world with a lot of things going on and there's always something new to learn. That's why I'm on this forum after all these years mucking about with these things.

T Chap
05-27-2006, 04:07 PM
Thanks again for the detailed explanations. It sure is great to have these forums. Not unlike a lot of people, I want to know everything in 3 days. Actually, I am translating a logic IC based product to processor based, and am almist 50% done in 3 days time with no prior basic knowledge, it if rather an easy go once a few fundamentals come together.

I guess I should have added to my last post a more to the point thought, which is, if I can make this thing work flawlessly in PBasic, then, why move it to a more complicated language, excepting of course the issue of cost per processor. If it works it works right? So certainly there are many reasons to go to a more powerful system, depending on your app, but, Harbor would you ever create a product using a Stamp in PBasic for consumption by the public?

In my case I am a guy that is developing several products for which I am in 100% control of how it gets done, down to designing every detail. The cost of an OEM stamp is insignificant relative to the rest of the parts, so a $3 pic versus $20 OEM stamps is not a concern. Thats where I am really headed with trying to get an understanding of what is available, and how and why to choose what platform. I can already see that I will unlikely ever pursue C or similar, I don't have time to do it. But, I like the idea of being hands on with a stamp, taking it as far as possible, and then if needed, hand it off. Certainly it would have to cost less and be much more efficient to hand an engineer a working product with a stamp and my code for them to translate to a PIC, with C programming or whatever the case is. Is that practical?

Harbor
05-27-2006, 04:48 PM
originator99 said...
If it works it works right? So certainly there are many reasons to go to a more powerful system, depending on your app, but, Harbor would you ever create a product using a Stamp in PBasic for consumption by the public?

I wouldn't hesitate. It would take a fairly·large volume to justify the cost of conversion for the parts roll-up alone. The only other reason is increased bandwidth. That is, sometimes you may prototype something with a Basic Stamp but need to handle more total lines or a higher data rate in the intended final design. In those cases, conversion to a directly coded microprocessor, like the SX series, is appropriate after the design has been fully evaluated with a Basic Stamp.

But there is nothing about a Basic Stamp OEM implementation that is a drawback in itself. It it works, it works.