Does anyone have any clever idea or routines that ensure all variables are set to zero as and when the program starts?
I try to remember to keep all variable declarations together at the top of my code, then call a 'StartUp' routine into which I copy and paste a list of my variable declarations, then convert them from:
I just wondered if there were any more elegant ways of achieving a similar result that might eliminate silly errors where I've later added a further variable, have forgotten to add it to my 'initialise' list and then used it in maths - causing an overflow - as it has not had the value anticipated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do not poke the variables address. If I could remove poke and peek I would.
As you are using #option explicit - you know the vars so set to 0 if this is concerning you. Another, methoid would be to take the ASM pull out all the variables, including the system and librtary variables = 0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"As you are using #option explicit - you know the vars so set to 0 if this is concerning you. Another, methoid would be to take the ASM pull out all the variables, including the system and librtary variables = 0."
Would you be able to expand on this a little please?
in my .asm file, I have some variables:
FILE_NUMBEREQU39NOW_PLAYINGEQU40PLAYTESTEQU41
How would I then use this information to set their values to 0?
I'll be honest, I was hoping someone might say "Why not use the overloaded declaration for variables?"
"If I could remove poke and peek I would."..... and goto? NOoooo!
ps does anyone use peek/poke in gcb? picaxe it was normal because you soon ran out of variable space, joy.
Last edit: stan cartwright 2017-12-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I must admit I try to avoid GoTo where possible. I'm not a fan of Peek or Poke either.
In PicAxe Basic I've often used Poke to build up a 'buffer' for my LCD displays, building the display components up, Pixel by Pixel, only updating individual Pixels as required, then putting 'Peek' into a loop that outputs the entire display sequentially if a full refresh is required, or just individual Pixels if only single Pixels have changed. I found this to be quicker than any other method of updating the LCD with the limited processor speed available to PicAxe. It also allows some simple routines to be made that can be called with values for the start Pixel and number of Pixels to update set so that the required Pixels can be updated in memory with similar routines for writing as many Pixels as required when updating the display. Probably wouldn't be simpler for other people, but it suited me at the time...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Peek n poke is very familiar to me from the 80's but this is 2017. Best never mentioned but the original post asked. Funny, I thought ram reverted to 0's when powered off.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Loads of fun mkstevo. I got a ssd1306 working and a graphic game working in picaxe but I nearly ran out off vars. That's why I appreciate the gcb glcd includes....and it's 100x faster.
I haven't used peek/poke in gcb and don't intend to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Stan,
I just came across your recent comments on clearing variables at startup. Seeing that GCB accepts
assembler; I use the following;-
;----------------Clear RAM 20h-7Fh in bank-0-------------------------
mov FSR,#20h ;Start location
STARTX ;
clr INDF ;Clear RAM pointed to !
inc FSR ;next location
sb FSR.7 ;End of RAM ?
jmp STARTX ;No,so return
;----------------All RAM now cleared !-------------------------------
clr PORTC ;Port-C output pins=0
; setb LCD_PWR ;POWER SOURCE OF LCD MODULE
; call DELAY2 ;
;===============================================
It's written in the old CVASM (8051 type) but the idea is there .
regards, Geoff
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The method you are using is probably the best way if there are not a huge number of variables. However it is possible to clear ram memory using indirect addressing as aluded to in Geoffrey's post above. For example on an 18F27K40 this will clear the Ram in Bank 1
SUB ClearBank1
DIM FSR0 as WORD alias FSR0H,FSR0L
LFSR FSR0, 0x100
CLEARNEXT:
CLRF POSTINC0 ; Clear INDF register then inc pointer
BTFSS FSR0H, 1 ; All done with Bank1?
BRA CLEARNEXT ; NO, clear next
End SUB
This was take directly from the 18F27K40 datasheet page 118 (Example 10-5) with some slight changes to work with GCB.
You should be able to use this method with a PIC16F chip as well, Just refer to the datasheet under "indirect addressing" ..
I do not recommend this for the inexperienced or the faint of heart And by all means ..test, test. test before including in any final code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Shouldn’t it also be possible to do it with GCB using Poke?
From: William Roth
Sent: Thursday, December 28, 2017 9:29 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Elegantly setting the initial values of variables?
@mkstevo
The method you are using is probably the best way if there are not a huge number of variables. However it is possible to clear ram memory using indirect addressing as aluded to in Geoffrey's post above. For example on an 18F27K40 this will clear the Ram in Bank 1
SUB ClearBank1
DIM FSR0 as WORD alias FSR0H,FSR0L
LFSR FSR0, 0x100
CLEARNEXT:
CLRF POSTINC0 ; Clear INDF register then inc pointer
BTFSS FSR0H, 1 ; All done with Bank1?
BRA CLEARNEXT ; NO, clear next
End SUB
This was take directly from the 18F27K40 datasheet page 118 (Example 10-5) with some slight changes to work with GCB.
You should be able to use this method with a PIC16F chip as well, Just refer to the datasheet under "indirect addressing" ..
I do not recommend this for the inexperienced or the faint of heart And by all means ..test, test. test before including in any final code.
Elegantly setting the initial values of variables?
I was observing Evan's warning of ..... "Do not poke the variables address." . I'm sure he has a reason other than personal preference. I know it will affect code portability as will the code I posted
However if you poke the addresses using a loop, how would you prevent from clearing the loop counter variable? I suppose you could dim it last or assign it a memory location above the other variabes ...?
Like: "dim counter as byte at 100" and then clear all locations below 100 with poke?
The method I posted above clears the first 512 bytes of ram on an 18F27K40 without using a loop counter variable and with no need to look at the ASM code to see where variables are asigned. It should be run at the very beginning of the program.
I tested "poke" and it appears to work ok. Maybe Evan can ellaborate more on why not to use "poke"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mega328p sram starts 0x100 and ends 0x08FF. Where does gcb store variables, from the start or end? Are vars stored in order they are declared?
Do I need to know this as the number of vars depends on ram not like picaxe which has fixed number and then defined memory to peek/poke?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This doesn't print bytes 0x0102 to 0x0107 as 1,2,3,4,5 if they are the vars v1-v5 after dim ptr as word.
#chip mega328p ,16
#option explicit
#define USART_BAUD_RATE 9600
Dir PORTD.1 Out
Dir PORTD.0 In
#define USART_DELAY 10 ms
#define USART_BLOCKING
wait 500 ms
dim ptr as word ;0x0100
ptr=0x0102
dim v1 as byte :v1=1 ;0x0102
dim v2 as byte :v2=2
dim v3 as byte :v3=3
dim v4 as byte :v4=4
dim v5 as byte :v5=5
wait 3 s
repeat 5
HSerPrint peek (ptr)
HSerPrintCRLF
ptr++
end repeat
end
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have a look at the ASM file. It should tell you where the variables are stored. Click on Make ASM. or hit F7 ... When done (Shift F7) will open the resultant ASM file. Look for the lines with ".EQU."
If you want to know where a particular variable is located in memory you can do this trick ...
Hserprint @varname
This will print the memory location of varname
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks but the point is I can get by without knowing where gcb vars are stored.. so far that is.
I'll check asm equ
edit seems they are assigned in alphabetic not as defined order.
So poke with 0 to all ram or vars? as per the original post.
I just define init var vals so academic.
Does anyone have any clever idea or routines that ensure all variables are set to zero as and when the program starts?
I try to remember to keep all variable declarations together at the top of my code, then call a 'StartUp' routine into which I copy and paste a list of my variable declarations, then convert them from:
To:
And so on, and so forth.
I just wondered if there were any more elegant ways of achieving a similar result that might eliminate silly errors where I've later added a further variable, have forgotten to add it to my 'initialise' list and then used it in maths - causing an overflow - as it has not had the value anticipated.
Of course the best way to eliminate silly errors might be to keep me away from the keyboard!
If you know vars location and how many you could poke them with 0 in a loop.
Do not poke the variables address. If I could remove poke and peek I would.
As you are using #option explicit - you know the vars so set to 0 if this is concerning you. Another, methoid would be to take the ASM pull out all the variables, including the system and librtary variables = 0.
"As you are using #option explicit - you know the vars so set to 0 if this is concerning you. Another, methoid would be to take the ASM pull out all the variables, including the system and librtary variables = 0."
Would you be able to expand on this a little please?
in my .asm file, I have some variables:
How would I then use this information to set their values to 0?
I'll be honest, I was hoping someone might say "Why not use the overloaded declaration for variables?"
And that I should use:
Which would be both elegant, and easy for me to see if I'd missed one out.
"If I could remove poke and peek I would."..... and goto? NOoooo!
ps does anyone use peek/poke in gcb? picaxe it was normal because you soon ran out of variable space, joy.
Last edit: stan cartwright 2017-12-08
I must admit I try to avoid GoTo where possible. I'm not a fan of Peek or Poke either.
In PicAxe Basic I've often used Poke to build up a 'buffer' for my LCD displays, building the display components up, Pixel by Pixel, only updating individual Pixels as required, then putting 'Peek' into a loop that outputs the entire display sequentially if a full refresh is required, or just individual Pixels if only single Pixels have changed. I found this to be quicker than any other method of updating the LCD with the limited processor speed available to PicAxe. It also allows some simple routines to be made that can be called with values for the start Pixel and number of Pixels to update set so that the required Pixels can be updated in memory with similar routines for writing as many Pixels as required when updating the display. Probably wouldn't be simpler for other people, but it suited me at the time...
Peek n poke is very familiar to me from the 80's but this is 2017. Best never mentioned but the original post asked. Funny, I thought ram reverted to 0's when powered off.
Loads of fun mkstevo. I got a ssd1306 working and a graphic game working in picaxe but I nearly ran out off vars. That's why I appreciate the gcb glcd includes....and it's 100x faster.
I haven't used peek/poke in gcb and don't intend to.
Hello Stan,
I just came across your recent comments on clearing variables at startup. Seeing that GCB accepts
assembler; I use the following;-
;----------------Clear RAM 20h-7Fh in bank-0-------------------------
mov FSR,#20h ;Start location
STARTX ;
clr INDF ;Clear RAM pointed to !
inc FSR ;next location
sb FSR.7 ;End of RAM ?
jmp STARTX ;No,so return
;----------------All RAM now cleared !-------------------------------
clr PORTC ;Port-C output pins=0
; setb LCD_PWR ;POWER SOURCE OF LCD MODULE
; call DELAY2 ;
;===============================================
It's written in the old CVASM (8051 type) but the idea is there .
regards, Geoff
FFor safety, only when needed, I reset the variable before using it.
Without complicating my life ...
@mkstevo
The method you are using is probably the best way if there are not a huge number of variables. However it is possible to clear ram memory using indirect addressing as aluded to in Geoffrey's post above. For example on an 18F27K40 this will clear the Ram in Bank 1
This was take directly from the 18F27K40 datasheet page 118 (Example 10-5) with some slight changes to work with GCB.
You should be able to use this method with a PIC16F chip as well, Just refer to the datasheet under "indirect addressing" ..
I do not recommend this for the inexperienced or the faint of heart And by all means ..test, test. test before including in any final code.
Shouldn’t it also be possible to do it with GCB using Poke?
From: William Roth
Sent: Thursday, December 28, 2017 9:29 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Elegantly setting the initial values of variables?
@mkstevo
The method you are using is probably the best way if there are not a huge number of variables. However it is possible to clear ram memory using indirect addressing as aluded to in Geoffrey's post above. For example on an 18F27K40 this will clear the Ram in Bank 1
SUB ClearBank1
DIM FSR0 as WORD alias FSR0H,FSR0L
LFSR FSR0, 0x100
CLEARNEXT:
CLRF POSTINC0 ; Clear INDF register then inc pointer
BTFSS FSR0H, 1 ; All done with Bank1?
BRA CLEARNEXT ; NO, clear next
End SUB
This was take directly from the 18F27K40 datasheet page 118 (Example 10-5) with some slight changes to work with GCB.
You should be able to use this method with a PIC16F chip as well, Just refer to the datasheet under "indirect addressing" ..
I do not recommend this for the inexperienced or the faint of heart And by all means ..test, test. test before including in any final code.
Elegantly setting the initial values of variables?
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gcbasic/discussion/579125/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Poke? Maybe.
I was observing Evan's warning of ..... "Do not poke the variables address." . I'm sure he has a reason other than personal preference. I know it will affect code portability as will the code I posted
However if you poke the addresses using a loop, how would you prevent from clearing the loop counter variable? I suppose you could dim it last or assign it a memory location above the other variabes ...?
Like: "dim counter as byte at 100" and then clear all locations below 100 with poke?
The method I posted above clears the first 512 bytes of ram on an 18F27K40 without using a loop counter variable and with no need to look at the ASM code to see where variables are asigned. It should be run at the very beginning of the program.
I tested "poke" and it appears to work ok. Maybe Evan can ellaborate more on why not to use "poke"?
mega328p sram starts 0x100 and ends 0x08FF. Where does gcb store variables, from the start or end? Are vars stored in order they are declared?
Do I need to know this as the number of vars depends on ram not like picaxe which has fixed number and then defined memory to peek/poke?
This doesn't print bytes 0x0102 to 0x0107 as 1,2,3,4,5 if they are the vars v1-v5 after dim ptr as word.
Stan,
Have a look at the ASM file. It should tell you where the variables are stored. Click on Make ASM. or hit F7 ... When done (Shift F7) will open the resultant ASM file. Look for the lines with ".EQU."
If you want to know where a particular variable is located in memory you can do this trick ...
This will print the memory location of varname
Thanks but the point is I can get by without knowing where gcb vars are stored.. so far that is.
I'll check asm equ
edit seems they are assigned in alphabetic not as defined order.
So poke with 0 to all ram or vars? as per the original post.
I just define init var vals so academic.
Last edit: stan cartwright 2017-12-28
Using ssd1306 the 1K buffer is declared 1st with uno if include glcd 1st so nice to use that maybe.
SSD1306_BUFFERALIAS=256
Great cow basic dont care in witch order or where you declare a variable. So you can do the following:
Dim think as Byte
think = 0
Dim position as Byte
position = 0
Dim linesense as byte
linesense = 0
or simply:
Dim think as Byte : think = 0
Dim position as Byte : position = 0
Dim linesense as byte : linesense = 0
not as pretty as you wanted, but, I think, much better than messing with assembly.