Strange one

johnlong

Senior Member
Hi All
was just having a play with Allycat code for reading a battery
Code:
symbol CALVDD = 52429    ; 1024*1.024*1000/20  (DAC steps * Ref V / Resolution in mV) 
Vdd2dp:
    calibadc10 w1        ; Measure FVR (nominal 1.024 v) relative to Vdd (1024 steps)
    w2 = w1 / 2 + CALVDD    ; Effectively round up CALVDD by half a (result) bit
    w2 = w2 / w1        ; Take the reciprocal to calculate (half) Vdd (tens of mV)
    calibadc10 w1        ; Read the value again because noise may be present :)
    w1 = CALVDD / w1 + w2    ; Calculate Vdd/2 again and add in the first value
Show2dp:
    w2 = w1 / 100        ; Integer volts
    w1 = w1 // 100        ; Decimal part (remainder)
    b3 = b2 // 10        ; Hundredths digit
    b2 = b2 / 10        ; Tenths digit
    sertxd("Vdd= ",#w2,".",#b2,#b3," Volts ")
    readadc B.5,b5
    sertxd(" Light ",#b5,cr,lf)
    return
and got this coming up on the terminal
sent a blank program to slot 0,1,2,3 and then downloaded the above
and still got the same display on the terminal
weired
 

Attachments

Last edited:

johnlong

Senior Member
Hi
Removed the comp hum and hum results by getting rid of the return
and sticking a do loop in
but I as I understand it a new down load over writes all data on the chip
so obviously the programing even the blank programing of the 4 slots did not totaly
over write the previous program on the 28x2?
As the return must begoing back to the gosub where it came from, so should
it have passed syntax?
has anybody encounted the download not fully overwriting the chip
regards john
 

hippy

Senior Member
as I understand it a new down load over writes all data on the chip
No. A new download only overwrites enough of the program memory to put the new program in place. Anything else in the program memory is left as is. That old code does not need to be physically overwritten, because a properly specified program can never enter any of those areas. This saves time, allows shorter programs to be more quickly downloaded.

It is like having a multi-page book with a long story in it spreading over multiple pages.

You can create a new shorter story in that book, by erasing only the first page and writing to that. The reader opens the book at the first page and will stay on that page, following commands to go back to earlier in the story or reach "The End" and close the book.

The RETURN in the newly downloaded code, without there having been a previous GOSUB, will behave unpredictably. In this case jumping to areas of memory which have not been overwritten.

The compiler cannot give a syntax error that a RETURN has been wrongly used, even when there is no GOSUB, because it cannot determine if that is an error or just incomplete code, code written but not yet called, or the GOSUB temporarily commented out during debugging.

While it is possible to identify some wrong uses of RETURN, not all wrong uses of RETURN will be identified. So this is usually considered an awful lot of work for very little gain.
 

techElder

Well-known member
Removed the comp hum and hum results
I wish I knew what those words mean.

What you have is a "subroutine"; not a "program." You need a program to call a subroutine, so you can present something that the subroutine has produced.

That subroutine was never meant to be used alone.
 

johnlong

Senior Member
Hi tech
I wish I knew what those words mean.
the image of the terminal is showing that the results from a sub routine of a previous code
downloaded to the chip. prior to the above code being downloaded, is being displayed as
well as the above newly loaded code snippet, some thing I have never encounted before.
this was being due to leaving the return in the copyied code (comp = compensated, hum = humidity)
I was just testing the results of phil hornsbys code for a pair of attached lithium ion batteries.
to determin the rate of discharge
as i do not want the voltage to fall below 3.7V as specified by the manufactor before recharging

Thanks Hippy for explaining that the reprograming only uses enough space as it requires
on that note how much space does programing a blank program use
regards
 

inglewoodpete

Senior Member
Hi
Removed the comp hum and hum results by getting rid of the return
and sticking a do loop in
but I as I understand it a new down load over writes all data on the chip
so obviously the programing even the blank programing of the 4 slots did not totaly
over write the previous program on the 28x2?
As the return must begoing back to the gosub where it came from, so should
it have passed syntax?
has anybody encounted the download not fully overwriting the chip
regards john
I think I understand what you're say John. I also think I know what is happening.

After your first logging session, you didn't close the terminal window, so when logging started again after the new program was downloaded, the new log was just concatenated onto the old. The PE hijacks the serial port for the duration of the download and then hands it back to the Terminal once the download is finished - nothing tells the terminal window to clear before the PICAXE restarts.
 

AllyCat

Senior Member
Hi,
.... how much space does programing a blank program use
The Syntax check will tell you; normally it's 3 bytes (for the default END marker) unless you include the #no_end command. Didn't the "blank" program download much faster than a normal full-sized Program? There wouldn't normally be much point in writing "null" bytes to the whole of the EEPROM, which would waste time and perhaps contribute to "wearing it out".

Actually, it was my program from the Code Snippets section of the forum (simply do a search for
"CALVDD = 52429" , and I'm relieved to see that I did specifically "comment out" the RETURN when the program was not used as a Subroutine. ;)

As hippy has said, all bets are off for an executed RETURN without a prior GOSUB/CALL (or interrupt: ), but there is no syntax requirement to match the number of CALLs against RETURNs: Subroutines can have multiple entry and/or exit points and one of the main features of a Subroutine is that it can be called from multiple sources. Even a RETURN in a program, without any CALLs, is not necessarily an error; it might just be part of a subroutine planned for future use (perhaps in an #include file).

Cheers, Alan.
 

hippy

Senior Member
Thanks Hippy for explaining that the reprograming only uses enough space as it requires
on that note how much space does programing a blank program use
regards
There are about 3 bytes used just to place an END command which is what a blank program actually is, and what Clear Hardware Memory downloads.

But the actual download is roughly in 256 byte blocks.
 

johnlong

Senior Member
Actually, it was my program from the Code Snippets section of the forum
Hi Ally Cat
my deepest apologies in my defence I can only offer to much reading not enough consentration
I am how ever getting good results as to the battery status with the 28x2 so hats off to you sir
the only real problem I have at the moment is when the lithium batteries deplete they depleat very rapidly
Hi Inglewood pete the terminal was not connected at the time of download and the code for it was overwriten prior to the
download this morning when I was playing around with Hippys
#Define ToBin(bcd) bcd / 16 * $FA + bcd
#Define ToBcd(bin) bin / 10 * 6 + bin
with a ds1307 conncted.
the offending code is quite a large one 1320 bytes and the 2 subsequent ones in the region of 100 to 200 bytes
regards
 
Top