CAN a variable exist without a PIN attached?
T Chap
Posts: 4,223
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.
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.
Comments
Or am I missing your point?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
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?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
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.
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?
But there is nothing about a Basic Stamp OEM implementation that is a drawback in itself. It it works, it works.