12f675_fuse_about_to_blow!

[HenrikOlsson]

Hi Dave,
Actually, it looks like you got me on this one... I'll HAVE to start verifying what I write before trying to look like I know what I'm talking about ;-) Don't know what's going on here, I'll have to try a few things out.

/Henrik.

EDIT: OK, I'm not sure exactly what's going on but this does seem to work:

RANDOM X
Y = X * 1000
Y = DIV32 21845

Thanks Dave for catching that and letting me know!

[mackrackit]

Henrik,
I think our student has been reading the manual and caught the "dummy" var in the examples given.

I think our student has also increased in rank!
Maybe now he is
NEWBIE.2

[LEDave]

mackrackit.

I think our student has been reading the manual and caught the "dummy" var in the examples given.

It was reading the DIV32 example that made me use the X,Y,Z VARS. Although I must fess_up and say that I wasn't 100% sure I'd spotted the 'right' typo in Henriks post.

I think our student has also increased in rank! Maybe now he is NEWBIE.2

Lol, I'm getting better but maybe NEWBIE1.5.......

Dave

[LEDave]

Following on from and using the theory we've already covered. I thought it might be a good idea to try and make the RANDOM time pause generated from the previous program slightly more RANDOM.

I noticed with the last program that RANDOM always 'seeded' with the same start value at power up a (2522_Mili_secs) pause and then followed the same number sequence on the display. So if you powered up and powered down the program in fairly quick succession you'd soon notice the start sequence wasn't that RANDOM at all, it was exactly the same!

So I got to thinking what if, when the program 'powered down' I saved the last RANDOM value in EEPROM memory and then re-loaded that value as the start 'seed' on 'power up' that would then continue the 'RANDOM' sequence (ok, RANDOM from 1-65535) so pretty RANDOM unless you're a memory man.

Here's the code I came up with (I changed from the Serial Communicator to LCD (why not, all good practice)). It seems to work too.
The program continually WRITES to EEPROM whilst the program runs but only READS from EEPROM on power_up. What do you think?

CODE:

X VAR WORD     
Y VAR WORD
Z VAR WORD     'STORED IN EEPROM LOCATIONS 0 AND 1

Start:
goto  Power_up: 'Load STORED last RAND_VAL


Power_up:             'Power_up subroutine
Read 0, Z.HIGHBYTE    'Read VAL_Z_high byte
Read 1, Z.LOWBYTE     'Read VAL_Z_low byte
LET X = z             'SEED X with the VAL Z
GOSUB RAN:

RAN:
Random X              'RANDOM program cycle continues
Y = X * 1000
Z = DIV32 21845
LCDOUT $FE,2,"MSECS=",DEC4 Z 'LCD displays RAND_VAL
PAUSE Z                      'Program PAUSES for 'Z_Mili_secs'
HIGH PORTA.2          'LED PORTA.2 lights up
PAUSE 500
low PORTA.2           'LED off
WRITE 0, Z.HIGHBYTE
WRITE 1, Z.LOWBYTE
GOTO RAN

Dave

[HenrikOlsson]

Hi Dave,
A couple of small things noticed:
1) You can read the value direct into X instead of first reading it to Z and then copying it to X. Nothing wrong with what you're doing it'll just save some program space and time.

2) The line GOSUB RAN: looks strange. First, there shouldn't be any colon after the label in the jump statement, only where you declare the actual label. Second, you don't want to GOSUB a routine from which you don't RETURN. In this case it may work but it's generally a bad idea.

3) Speaking of GOSUB and GOTO, you are making a couple of unneccessary jumps. At the beginning you say GOTO Power_Up even though the next line in the program is the beginning of the Power_Up routine. Same thing when Power_Up is done, then you jump to RAN which already is the next line so it will get there without needing to jump to it.

Now, if you have some other code "in between" then it makes sense, and as you've found it, it works the way you have it but it's not needed.

4) The EEPROM has a limited number of write-cycles. We're talking tens or even hundreds of thousands of cycles but if you write to it on average ever 1500ms, 100.000 writes are less than 42 hours.

There are ways to get around that but it requires a little hardware and the use of interrupts. Basically you have a capacitor that allows the PIC to stay powered long enough to make the EEPROM writes. The capacitor is charged from your powersupply thru a diode. Then you have a "direct" wire going to an input on the PIC which fires an interrupt when the powersupply goes down (the cap is keeping the PIC alive).

Again, just a couple of small things to consider. Good job!

/Henrik.

[LEDave]

Thanks for the pointers Henrik. Some lax programming there to say the least, I do agree. I'll have to sharpen things up. I did have a push button loop in there at one stage IF - THEN - LABEL but took it out and in my rush / excitement to get the program to work made things look untidy.

4) The EEPROM has a limited number of write-cycles. We're talking tens or even hundreds of thousands of cycles but if you write to it on average ever 1500ms, 100.000 writes are less than 42 hours.

I remember mackrackit commenting on the write cycles of an EEPROM, I was mindful of that, again my rush to get it to work overroad it and I looked the other for now.

To be honest I was pleased that the write to EEPROM idea worked (or seemed too).

Thanks again.

Dave

[mackrackit]

Use the EEPROM idea but write to the EEPROM once during run time.

But before you write Z, maybe add 37 or something to it.