Odd, never-before-seen EEPROM error

N

nbw

Senior Member
Hi all, I've just encountered an error while programming a 40x2. Yesterday it was fine, today I've added a case statement at the end of the program, and it's come up with a bizarre error - saying I can't use EEPROM in an if-statement. The funny thing is, I'm not, and neither version of the program does. In fact, this is very standard eeprom code to write to an LCD screen - and it's worked perfectly to date.

Any ideas how to get past it? Before the case statement, I'd used about 2700 of the 4000 bytes programming space available, the case statement would probably add maybe 800-1000 bytes. I thought it might have been some kind of weird out-of-space error .... but I don't think so now.

Thoughts?!

thanks
Barney

p.s. I'll attach a screenshot of the section of code + error.
 

Attachments

hippy

hippy

Technical Support
Staff member
Not sure what the cause of the error may be. Please can you post your full code which gives that error along with details of which PE version used so we can see if we can duplicate it here.
 
I

inglewoodpete

Senior Member
It is more common to put EEPROM statements in the definitions part of a program file, since they are directives to initialise the EEPROM.

Is it possible that you have defined the locations more than once in the program?
 
S

srnet

Senior Member
You get that error if the complier sees an if statement and no matching end if before it sees the EEPROM statement.

Comment out the EEPROM statements, what happens when you now compile ?
 
N

nbw

Senior Member
Not these ones; this particular group of EEPROMs is in a subroutine that gets called right at the start of the program. The EEPROMs themselves are tucked away at the back of the program... and haven't caused an issue before. I'll triple-check and post code as Hippy asked... though it is very long, and I haven't tidied it up / made it more efficient yet! (A heads-up :) )
 
N

nbw

Senior Member
OK, here we go - the full code is attached as a txt file. I know there are definite ways it could have been written tighter, but anyway :) Everything has been working fine until I fixed the check humidity, write humidity, and added the case statements just the other day. I can't check if I've exceeded the program space of course, because I get this EEPROM error. Any questions about what the code is trying to achieve, let me know. In short, this is a device that reads temp, humidity, and LDR sensors, responds to 2 push buttons, and controls banks of red / blue / white LED strips for my orchid area. It also controls 2 small fans, and a low-wattage 220V heater. It writes to a small LCD screen also, the character layout of which is stored in EEPROM values.
 
A

AllyCat

Senior Member
Hi,

Yes, as srnet suggested, if you comment out the offending EEPROM lines (and after fixing two missing symbols and patching the "Error: Memory full - program far too long!"), you get (around line 430) :

if temp <> 0 then

Error: If without Endif

The following (for example) seems to fix the "EEPROM" error:
Code: 
		if temp <> 0 then
			return				' only update the accumulated LDR every 15 minutes
		else
			acc_ldr = acc_ldr + temp_word	' temp_word contains averaged LDR from above
			return
		endif        				; complete the IF construct
Cheers, Alan.
 
N

nbw

Senior Member
Ah there's the cheeky little mistake. thanks Alan! I'm not at home with the compiler, but will edit that later and find out what two symbols are missing. I can also revise that long case statement to trim out LDR values I will seldom use. Instead of having a value for every 2 ADC steps, e.g. 800, 802, 804 - I could make it every 3 or 4 steps to squeeze it into the 4,000 bytes. Have a great day over there in sunny England :)
 
A

AllyCat

Senior Member
Hi,

That SELECT ... CASE looks to be very greedy on program memory (around 15 bytes per line ?) so it might need very severe pruning.

I'd try a LOOKUP, e.g. :

Code: 
	temp_word = temp_word - 300 / 2
	LOOKUP temp_word,(10,11,11,11,12,   ..... 4100),temp_word2
which I believe uses little over 1 byte per value (at least up to 255). Note that a long LOOKUP is not "fast" (neither would be the SELECT ... CASE) but it does have constant execution time (for the length). I'm not sure if there is a maximum length, so it might need to be split into a few subgroups

Cheers, Alan.
 
N

nbw

Senior Member
Definitely worth a go in the lookup - I have 200 bytes left in RAM after b0 - b55 are accounted for, but that will only get me about 65 readings at 3 bytes a piece. Time isn't too much of an issue, if it found the right value in about a second, that would be ok. It only reads the humidity once per minute. cheers! Barney
 
S

srnet

Senior Member
nbw said:
Hi all, I've just encountered an error while programming a 40x2. Yesterday it was fine, today I've added a case statement at the end of the program, and it's come up with a bizarre error - saying I can't use EEPROM in an if-statement.
Click to expand...
The 'if then' without an 'end if' will produce the EEPROM error you described.

So why did the error occur when all you did was add a case statement ?
 
N

nbw

Senior Member
I'll have to read up on these two methods. I only glanced over the four-slot concept, thinking it had a total of 4096 bytes spread across the 4 slots, so it wouldn't help. But, if it has 4096 per slot, that would be pretty handy. As would a spare 1024 bytes in scratchpad - I always (probably incorrectly) thought scratchpad ate into the main 4096 program allocation, as in: writing data using PUT would use up memory? All these memory / storage types can be confusing at times :) I guess I'll just have to give it a go !
 
N

nbw

Senior Member
Hmm, the PUT command just kept eating into the 4096 bytes of memory. I might try an exercise when instead of the CASE / SELECT, I try PUT - it might be a bit more efficient. First though, I'll see if I can get something working with an additional program slot.
 
You must log in or register to reply here.
Top