Ok, I understood the limitations. But why they are present here, and aren't present elsewhere?
Ok, I understood the limitations. But why they are present here, and aren't present elsewhere?
And is there a way to overcome them?
Hi,
Where are they not present? Can you show me an example in Sinclair BASIC that does what you want?Ok, I understood the limitations. But why they are present here, and aren't present elsewhere?
Yes and no.And is there a way to overcome them?
There is, to my knowledge, no way to have a pin or port or any other register for that matter aliased into an array in a way that makes the pin/port automagically change when you write to the array. You need to write code that iterates thru the array and writes each port/pin individually and then call that routine each time you change the array. There might be a way (by specifying the absolute adress) to create a BIT array "overlaying" the port register adress space but then all the pins will be consecutive within the array, ie if Array[0] is PortB.0 then Array[1] will be PortB.1 and so on.
If you could explain a little bit what the purpose of this operation is perhaps someone will provide a workable solution.
/Henrik.
Clearly I have erred, first in drawing assumptions and, second by posting untested code based on those assumptions. I dislike being wrong, but I dislike being ignorant even more. Ha! Is this not true for others as well?
So perhaps, it is germane to the discussion, will someone help me to understand my error? In the PBP manual, the statement SYMBOL is used to assign a second name to an existing variable - the process is described as aliasing; I presumed this meant then that both variable names would create pointers to the same RAM address - and be resolved during the assembly process. This misunderstanding was reinforced in the book PIC Basic Projects: 30 Projects Using PicBasic and PicBasic Pro by Dogan Ibrahim where he asserts on page 84:
"In order to make programs more readable, we can assign meaningful names to variables..." He uses the example: SYMBOL Count = B0. The author goes on to note: "This statement does not occupy any location in microcontroller RAM memory".
I accept Henrik's explanation; yet, I struggle to understand the purpose of SYMBOL and how it is used if not in this way.
As an aside, I also note that Curiousone did not make the SYMBOL assignments I suggested in the code he posted.
SYMBOL AC[5] = PORTC.5
This statement is invalid, according to PBPpro.
Hi,
SYMBOL is a left over from the BASIC Stamp and is not recommended.
In the BASIC Stamp there are a fixed number of pre-declared variables for you to use. B0 is one of those (a byte variable) and W0 is another (a word variable).
The statement SYMBOL Count = B0 simply creates an alias or a meaningful name to an already declared variable (the exact same thing as Count VAR B0 would) It's correct that it doesn't occupy any (new or more) space in RAM since it refers to an already declared variable (B0). What's important to remember here is that Count and B0 would be the exact same location RAM, translated to an absolute memory adress at compile time. (Well, yes the Basic Stamp is interpreted but anyway...)
(By the way, Count is a reserved word in PBP (and in the BasicStamp programming language) and has been for as long as I can remember so that book doesn't seem very well written but that's a side note).
Now, you can very well create an alias to a port, like myPort VAR PortB or to a pin, like myLED VAR PortB.0 - this works and there are no issues. The problem comes when you try to "alias" two different locations in memory to each other. I mean, I think it's pretty obvious that something like this wouldn't work right:Again, AC VAR BIT[8] creates an array of 8 bits in memory (RAM). You can then, if you want, create meaningful names for the individual bits in that array by aliasing: AC_0 VAR AC[0] (which is not a very meaningful name but you get the idea.) In this case AC_0 refers to the exact same bit in memory as AC[0] does.Code:PortB.0 VAR PortC.0 PortB.0 = 1 ' Set both PortB.0 and PortC.0....Nope, won't work.
What you can not do is say AC[0] VAR PortB.0 or anything like that because (just as with PortB.0 VAR PortC.0 above) both the AC and PortB are already existing - at different memory locations in the PIC. They are two different entites, at two different adresses.
/Henrik.
If you think about it really is quite logical.
OK.
Speaking simply, PORTB.1 is an alias, which refers to particular register or whatsoever, say at address F9 HEX.
So can I make such hex adresses into array, so when I write 1 to array member, which corresponds to F9 HEX, the associated hardware port becomes high?
Hi,
Yes, PortB is simply an identifier which translates into an absolute adress, on the 16F877 PortB is at adress 0106h for example.Speaking simply, PORTB.1 is an alias, which refers to particular register or whatsoever, say at address F9 HEX.
I've beem tryimg to explain why but I don't seem to get the point across so I'm going to revert to the simple answer of NO, you can't.So can I make such hex adresses into array, so when I write 1 to array member, which corresponds to F9 HEX, the associated hardware port becomes high?
Again, please show me an example in Sinclair BASIC which does what you want.
/Henrik.
Bookmarks