EEPROM Variables (EE_Vars.pbp)

Quote:

---

Originally Posted by brittons

I found a variable called EE_VarCount that is EXT (external?) which I believe means it is not available in the actual downloaded code.

---

If you do a FIND (ctrl-F) and type in EE_VarCount, you'll see that variable used many times in the program. So yes, it IS in the actual downloaded code.

Quote:

---

Can help me better understand what happens when the EE_Vars program is run the 2nd time after initialization is complete? ...

---

I already went through that in post#38.

Quote:

---

I understand that:
EEPROM EE_Start, [0]
Sets EE_Start to zero on 'first run' only. At the end of initialization EE_Start contains the number of EE_Vars assigned. After that I assume that EE_Start is never written to correct?

---

Correct.

Quote:

---

What is it examining to know that it is finished with initialization? Is there a variable I can look at to know to see what happens?

---

Again, it's looking at the EEPROM location designated by the EE_Start constant. (post#38)

Look, we can go round and round trying to blame the Tried and Tested code (EE_vars), or we can try to find the problem in your program, which you seem to have stopped looking at.

You get to see all my code.
I need to see yours.
The whole thing, not just 10 lines somewhere that might apply.
<br>

Hi again Bob,

After another similar question from a different user, I've found a possible reason for your problems.
Of course, there's no way to verify it because I still haven't seen your code, but ...

Something I didn't realize before is that the DATA and EEPROM statements use the same internal "counter" to keep track of the next available EEPROM location.

So if the EE_start location is changed to a higher value, and DATA statements come AFTER the EE_vars include file, then the DATA statements will place the data in the same locations that EE_vars uses, instead of 0 like expected.

In other words, to do what you were trying to do, the DATA statements would have to be placed PRIOR to including the EE_vars module.

hth,

Hi Darrel,
I'm just beginning to use the EEPROM of the PIC12F683 on the LAB-X4 platform with PB Pro 2.47 and using the MPASM compiler.
I downloaded the EE_Vars.PBP.txt file and copied it to my PBP folder where I resaved it as EE_Vars.PBP, I think I did right.
The good stuff:
I also download your EE_example_1 file to experiment with. After configuring the LCD setup, it works as advertised!

Code:

---

'****************************************************************
'*  Name    : EE_1_Example.bas                                  *
'*  Author  : Darrel Taylor                                    *
'*  Date    : 8/27/2005                                        *
'*  Version : 1.0                                              *
'*  Notes  : This is an Example program for the EE_Vars.PBP    *
'*          : Include file.                                    *
'****************************************************************
@ __config _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _CP_OFF
OSCCON = %01110001  ' Osc 8Mhz
ANSEL = %00111000        ' Fosc/64 and ANS3 set to analog
ADCON0 = %10001100  ' Right justified and AN3 selected
CMCON0 = 7                    ' Analog comparators off
GPIO = %00111101    ' Set all ports to inputs except port 1
TRISIO = %00111101  ' Port 1 to output, rest inputs

;-- Define LCD connections -- (change these to match your hardware) ------------
Include "modedefs.bas"        ' Mode definitions for Serout
INCLUDE "EE_Vars.PBP"          ; Include the EE_var routines

define OSC 8          ' Declare for PAUSE and PAUSEUS statements
pause 1000
'=========================================================================
'                        Variable pin names
'=========================================================================
'      Var GPIO.0      ' Pin 7
LCD        Var        GPIO.1                  ' Pin 6
'      Var GPIO.2      ' Pin 5
'      Var GPIO.3      ' Pin 4
'      Var GPIO.4      ' Pin 3
'      var GPIO.5      ' Pin 2



Days    VAR WORD  :  @  EE_var  _Days, WORD, 365
Cats    VAR WORD  :  @  EE_var  _Cats, WORD, 1024
Mice    VAR WORD  :  @  EE_var  _Mice, WORD, 10000
PowerOn VAR BYTE  :  @  EE_var  _PowerOn, BYTE, 0

PowerOn = PowerOn + 1          ; Increment number of Power-On cycles
@ EE_write_var  _PowerOn        ; save the new number to EEPROM

Serout LCD, T2400, [$fe, 1]        ' Clear screen
pause 1000
Serout LCD, T2400, ["Days= ",#Days," Cats= ",#Cats]
pause 100
Serout LCD, T2400, [$fe, $c0,"Mice= ",#Mice," PowOn= ",#PowerOn]
pause 100

RANDOM Mice                    ; get a new value for Mice
@    EE_write_var  _Mice        ; save it to EEPROM

stop

---

The funny stuff:
If I first select and copy any one of the EE variables such as:

Code:

---

PowerOn VAR BYTE  :  @  EE_var  _PowerOn, BYTE, 0

---

and change the Byte to a Word in both cases here, it gets mad when I compile it and reports these errors:

Quote:

---

Error[113] c:\program~on and on~ee_1_e~.asm 163: Symbol not previously defined (Byte)
Error[113] c:\program~on and on~ee_1_e~.asm 172: Symbol not previously defined (Byte)
Error[113] c:\program~on and on~ee_1_e~.asm 173: Symbol not previously defined (Byte)

---

So now if I change it back to BYTE in both cases, it still gets mad after compiling.

Here's the stranger part: I now select the troubled line of code and paste the original line of code prior to all this and the compiler is happy once more!?

I only tried this because when I wrote my own and got these messages, they stopped when I commented out my EE declaration lines and "pasted" your lines instead.

Are you using subliminal texts for this routine? Or did I not copy the Include file properly into my program?

Watch the CASE of the parameters.
Use WORD or BYTE instead of Word or Byte.

You can tell from the error message ... Symbol not previously defined (Byte).
<br>

Thanks again for your efforts Darrel!
That was it exactly. It turns out that I took the editor's "Auto cap" feature for granted when I typed the parameters. It's turned me into "Auto lazy".

That feature is no more.

Thanks again...

Thanks Darrel,

As usual your INCLUDES are awesome.


P.D.: I would buy you a beer but then is the problem of distance

Any local brewery that takes online orders? :)

Hi Darrel,

Just found your EE_Vars.PBP include file and have been playing around with it - thanks for making the documentation so thorough; it made getting started very easy. Is it possible to use a variable/constant/symbol in the default value portion of EE_var? Something like this:

Code:

---

NacelleSpeed VAR WORD  :  @  EE_var  _NacelleSpeed, WORD, initNacelleSpeed

---

MPASM throws this error no matter how I set up initNacelleSpeed (variable/constant/symbol):

Code:

---

Error[113] c:\pbp~1\pbp2.60c\ee_2~1.asm 122 : Symbol not previously defined (initNacelleSpeed)

---

Thanks,
Ross

With the thread as messed up as it got after HTML was turned off, I'm surprised you were still able to read it.

Constants that are declared in PBP will have an underscore before them in ASM.

Code:

---

initNacelleSpeed  CON 300

NacelleSpeed VAR WORD  :  @  EE_var  _NacelleSpeed, WORD, _initNacelleSpeed

---

The value must be known at compile time, so variables will not work. The default values must be constants.

Thanks Darrel! I should have guess that based on the underscore for the variable. The reason I wanted to use a constant is that I was having trouble with EE_write_default; it didn't seem to save the original value defined in EE_var to EEPROM when I turned off the circuit and restarted it, but now it seems to work (although the first time I powered up the chip after programming and when to show the value on an LCD screen using your example it had something like '366565' rather than '1000').

BTW, I spent about an hour removing all the HTML tags to make it readable. I've saved a copy in Word as I anticipate going back to it over and over.

Last question (unrelated to your include): does reprogramming a chip clear it's EEPROM memory?

Quote:

---

does reprogramming a chip clear it's EEPROM memory?

---

That depends on the programmer and options.

A bulk erase will erase everything.
But if you are using options for low voltage erase, or not programming config words, it's possible that EEPROM will not get erased.

With melabs programmer software, go to Options > More Options > Set Options to Defaults to be sure that "Bulk Erase" is being used.

Thanks Darrel!

I'm seeing some strange behaviour with my EEPROM variable - the first time the chip is powered up it seems like the linked variable isn't being set to the default as in this code:

Code:

---

MotorRPM VAR BYTE        :  @  EE_var        _MotorRPM, BYTE, 150

---

I know this because this loop is meant to spin up two motors connected to CCP1 & CCP2 on a PIC16F1825; rather than increase the duty to the mid-range RPM as in the default (150), it spins up to the max (255):

[CODE
IF MotorRPM > 66 THEN
FOR I = 65 to MotorRPM
pause 30
HPWM 1, I, 20000 ' Stbd engine (CCP1)
HPWM 2, I, 20000 ' Port engine (CCP2)
NEXT I
EndIf
[/CODE]

This only happens the first time the chip is powered up after re-programming. If I unplug the breadboard power and turn it back on again, the motors spin up to the expected default.

Full code attached. Any ideas? Should I put an EE_READ in even though it shouldn't be needed?

Attachment 6707

Looking over my post #49, this recent problem appears to be similar to what I was seeing there (but went away). I don't have enough available pins on my 16F1825 to display the start up value of _MotorRPM but I suspect the same thing is happening - after first programming the chip, the initial value is way over 150 (and why the PWM command to the motor ends up spinning it to its max value [255]).

I've switched to PBP3 and MicroCode Studio Plus (v5.0.0.3) and PBP compiler vPBPX 3.0.5.4. I tried what you posted in #50 but no lucy. Could this be a case of bulk erase not working? Why would that happen with one project but not another similar one (as I posted in this thread)

If I add this:

Code:

---

MotorRPM = 150

---

before the the PWM command, all works well (completely negating the use of EEPROM of course) so this does indicate to me that somehow the initial value of _MotorRPM is getting messed up after first programming the chip (if I use my mechanical rotary encoder to reduce the RPM, this does get saved properly and the motor starts up with this saved value next time power is turned on).

Darrel?

Ross,

Try putting a pause 100 or so at the very beginning of your program.

The programmer goes through several cycles of power-on and resets to program each section of memory.
And the EEPROM write is one of the first things that happens in the program.

The EEPROM write takes ~5ms, so it's probably getting powered down in the middle of the write cycle.

With a pause at the beginning, it will insure that the programming cycles are completed before it starts running the rest of the program.

I've single stepped through the program several times in the simulator, and everything works fine.
I'm not in the office today, so I can't try it with a real programmer.

Thanks Darrel! I'll try that tonight when I get home.

BTW, I've been using MCLR_OFF in my config but w/o a pull up resistor connected between the MCLR pin and +5v - should I have that resistor?

With MCLR disabled, you don't need a pull-up, unless your input requires one for a switch or something.
And on the 16F1 (Enhanced Core) devices, you don't even need a pull-up when enabled. They have an internal pull-up on MCLR.

Thanks again, Darrel! I remember now reading about the internal pull-up in the data sheet. This is what happens when you start a project and come back to it 6 months later :)

Hmm. That seemed to work on a simpler project but when I add it to the one I attached above (and which I'm attaching here for you to see) it doesn't help the _MotorRPM problem (motors still spin up to their maximum speed, i.e. MotorRPM >= 255) but what is weird is that it now takes almost 6 seconds for them to start spinning!?!??! I only added a pause of 100.

Attachment 6710

The internal oscillator runs at 500 Khz on power-up, which is 1/64th the 32 Mhz PBP is expecting.
So if you put it before the OSCCON statement, it will be equivelent to PAUSE 6400 or 6.4 seconds.

I'll try it on some real hardware tomorrow.

That solved the 6 sec delay (by moving the 'pause 100' to after the OSCON statement) but it still spins up to max RPM ...

Attachment 6711

Ross,

I've run your program here on real hardware and real programmers.
I still cannot duplicate your reported problems.

The EEPROM is initialized correctly on the first run after programming.
The PWM ramps up to 150 dutycycle every time, and never goes to 255.
I'm measuring the dutycycle with an oscilloscope. I do not have motors hooked up.

I've used an melabs U2 programmer.
I've also used a PICkit3 programmer, and single stepped through it.
It always works exactly like it should.

What are your software versions (PBP3 and meProg)?
How are you driving the motors?
Do you have a scope?

Here's what I've observed:

• Just adding the 'pause 100' doesn't seem to change anything
• Adding 'MotorRPM = 127' just before the spin up does work (although negating the use of EEPROM)
• I know the motors are spinning up to their max cycle becuase I have a mechanical rotary encoder which allows me to adjust the RPM; when I turn the knob CW the speed does **not** increase, while turning it CCW does reduce the speed. Also, this rotary encoder has a push button which I've set up to return the motor speed to default - this also works
• If I alter the speed (either by adjust the RPM up or down, or pressing the 'reset' button), the chip remembers this value the next time it's powered up
• If I grab a brand new chip, never previously programmed, it works straight away

I don't have a scope, Darrel - I wish I did :) Hopefully the above is helpful. Here are my version details:

• OS: Windows 7 (running on a VM on my MacBook Pro)
• MicroCode Studio Plus: 5.0.0.3
• PicBasic Pro compiler: PBPX 3.0.6.4
• meLabs Programmer: v4.50 (with the U2 programmer)

Here are the two .pbp files (the only difference being the addition of the 'MotorRPM = 127'):

Attachment 6712Attachment 6713

I've shared my .hex & .asm files here.

Here's my schematic. I'm using a SN754110 to drive the motors:

Attachment 6714

And here's a screenshot of my meLabs programmer settings:

Attachment 6716

Quote:

---

Originally Posted by Darrel Taylor

Ross,

I've run your program here on real hardware and real programmers.
I still cannot duplicate your reported problems.

The EEPROM is initialized correctly on the first run after programming.
The PWM ramps up to 150 dutycycle every time, and never goes to 255.
I'm measuring the dutycycle with an oscilloscope. I do not have motors hooked up.

I've used an melabs U2 programmer.
I've also used a PICkit3 programmer, and single stepped through it.
It always works exactly like it should.

What are your software versions (PBP3 and meProg)?
How are you driving the motors?
Do you have a scope?

---

Ross, after reading that, I would put my money on a hardware problem; mis-wired PIC, inadequate power, possibilities are countless.

You'd be surprised how often I put a resistor backwards. :D

Robert

But if I use the same chip and re-program it with the first code, it works; if I then pre-program it with the second code, it doesn't. And I can keep going backwards and forwards like that ...

Also: after I re-program the new chip from my inventory a second time, the problem re-appears.

Quote:

---

•Adding 'MotorRPM = 127' just before the spin up does work

---

The default value was 150, so it seems logical that setting it to 127 would make it run slower.

And I assume this is just a schematic error ?? Might cause a few problems. Sure confused me for awhile. :)

http://support.melabs.com/DT/BadEncoderInputs.png

Try the attached program.

I just changed it to 127 so it would be even slower to make it obvious. If I use 150 it has the exact same effect.

Thanks for spotting the schematic error! The board itself is fine, though.

BTW, this problem applies to both EE_vars (MotorRPM & PortEngDir) - unless I specifically set them in code they do not get initialized with the default values (150/127 & 0). I know this for the 2nd EE_var because in a later iteration of the same code I do a check on PortEngDir: if it's 0 make the motor spin CCW; else make the motor spin CW. Without the line 'PortEngDir = 0' the motor **always** spins CW after the chip has been programmed more than once.

Darrel - I missed seeing that you had provided a code file too. I'll try that out tonight after work (and thanks).

Darrel - your file works (all except the interrupt handler to reset the motor speed via the rotary encoder's button)! Does that tell you anything more about what's going on?

Oops,

Add this line after the WRITE command in the RotEncBtnPress: handler.

MotorRPM = MotorRPM_Default

It works! Thanks again Darrel.

Does this mean there's a problem with EE_var? I've used that include in a bunch of projects and love it. For this project, I still have more work to do (possibly with more EEPROM variables) and would ideally continue to use your EE_var if possible. Could this be a problem with my local version of DT_INTS-14.bas (which I had to modify for the PIC16F1825)?

Attachment 6723

First off, you should not be modifying DT_INTS-14.
It even says so in the code that you modified.
The changes that you made were incorrect (see the comments in DT_INTS-14), but I don't think they would have affected EE_Vars.

Since I cannot duplicate your problems with the same hardware and software, I can't agree that there is a problem with EE_Vars.
It all works perfectly here.

You don't have any way to debug your program/hardware, no LCD, the USART pins are used for other purposes.
So you are left to make guesses on what is happening, and I can't ask you to check register values.
Naturally, those guesses point blame at everything you didn't do. It's human nature.

I would recommend building in some form of debugging capabillity in your next project.
A serial LCD that only uses one pin can be extremely usefull.

With that said, there have been many changes to PBP since I wrote EE_Vars, and much of it's functionality is now included in the compiler.
So there's not much reason to use EE_Vars anymore. :(

I wasn't trying to blame you or the excellent EE_var include, Darrel. Honestly. It's worked so well for me in the past that I would prefer to continue using it if at all possible although I guess I should dig into your changed code and see if the code you used is easier than EE_var. The only reason I think there's something odd with the use of EE_var in this particular project is that the difference between working code and not-working code is the addition of the 'MotorRPM = 127 (or 150)' line into the working code, and that from then on it seems to remember the saved value.

I don't have a serial LCD, only one that needs 6 pins to work. It's been spotty at best and I did spend the better part of an evening removing code and trying to hook it up to see what the value was, but no luck. I will look into getting a serial LCD if I can find a suitable one.

As for your other include, DT_INTS-14.bas, I thought the instructions on your website or forum posting said to update if it you encounter compiler issues, which is what happens to me with this chip and a few others. Perhaps I misread the instructions, but how else do I resolve the compile errors?

Once again, thanks Darrel - seriously not trying to be a pain here, I just need to finish this project which I've been working on for almost 6 months now ...

Quote:

---

The only reason I think there's something odd with the use of EE_var in this particular project is that the difference between working code and not-working code is the addition of the 'MotorRPM = 127 (or 150)' line into the working code

---

That's pretty much my point.
You assume something is "odd" with EE_Vars, because you added a line that made it work without knowing why it worked.
Without any way to debug, you can't know why it worked. So the assumption is that is was EE_Vars fault.
It could very easily be something else.
And again, on the same chip for me, it works perfectly.

Quote:

---

Perhaps I misread the instructions, but how else do I resolve the compile errors?

---

Here is the section of DT_INTS-14 that you modified. Although this is the unmodified version.
The comments say it all.

Code:

---

;-- Place a copy of these variables in your Main program -------------------
;--  The compiler will tell you which lines to un-comment                --
;--  Do Not un-comment these lines                                      --
;---------------------------------------------------------------------------
;wsave  VAR BYTE    $20    SYSTEM      ' location for W if in bank0
;wsave  VAR BYTE    $70    SYSTEM      ' alternate save location for W
                                        ' if using $70, comment wsave1-3

' --- IF any of these three lines cause an error ?? ------------------------
'      Comment them out to fix the problem ----
' -- Which variables are needed, depends on the Chip you are using --
;wsave1  VAR BYTE    $A0    SYSTEM      ' location for W if in bank1
;wsave2  VAR BYTE    $120    SYSTEM      ' location for W if in bank2
;wsave3  VAR BYTE    $1A0    SYSTEM      ' location for W if in bank3
' --------------------------------------------------------------------------

---

I'm assuming you mean the 2nd 'wave' line that I modified in my earlier post, right? Then I guess I've seriously misunderstood how to implement this include for various PICs. Do I (temporarily) copy the two 'wave' lines to my code and on compile it will tell me which of the wave1, wave2, wave3 lines farther down to uncomment? And then remove the 'wave' lines?

Sorry to be so thick. Looks like I picked a bad week to reduce my caffeine intake ...

Quote:

---

Originally Posted by RossWaddell

I don't have a serial LCD, only one that needs 6 pins to work.

---

You can make your own serial interface to a parallel LCD using just about any PIC and this sample code ...
But it's easiest with a 16F676.
http://melabs.com/samples/LABX4-12F675/BPX4.htm

Quote:

---

Do I (temporarily) copy the two 'wave' lines to my code and on compile it will tell me which of the wave1, wave2, wave3 lines farther down to uncomment? And then remove the 'wave' lines?

---

No, copy the entire block to your main program (permanently). Do not uncomment the lines in the include file.
Compile your code, and uncomment the lines the compiler tells you to.

However, with the 16F1825 ... You don't need any wsave vars, because those chips have automatic context saving and the compiler would not tell you to uncomment anything, So you don't need them in your code, and you never needed to modify the include to begin with.

Wow. Totally missed that. Since I didn't see that section in the samples I looked at, I completely misinterpreted the instructions. Sure enough, restoring the original DT_INTS-14.bas and re-compiling with the 16F1825 was successful. Tried the same thing with other code on a 12F683 and it told me what to uncomment.

And guess what - reverting to the original DT_INTS-14.bas resolves the problem. No more runaway motor, no matter how many times I reprogram the chip. Sigh. The architect of my doom ... is me.

Quote:

---

Originally Posted by RossWaddell

The architect of my doom ... is me.

---

We've all been there, done than. Experience is a great instructor, but the lessons are often more painful than we'd like ;)