12f675_fuse_about_to_blow!

[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.

[LEDave]

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.

Now why couldn't I have thought of that.....

I went to use the rfpic transmitter the other day and the battery was flat, would the module continually be draining power with the battery in place or was it just that the battery was unused but old do you think?

Dave

[mackrackit]

The EEPROM thing was your idea...

Sounds like a weak battery or the transmitter was stuck on transmit.
Can you check the amps when "not in use" ?

[LEDave]

Sounds like a weak battery or the transmitter was stuck on transmit.

I'm hoping the former.The battery I used was unopened but had been my draw for a long, long time.

Can you check the amps when "not in use" ?

Tricky and I guess I'll need a new battery which I don't have right now. I guess try a new battery.

I read in the TX pdf that the TX output power can be set and adjusted via different resistor values set on a pin. This might be a way of increasing the transmit range (at the cost of battery power/life I guess).

Here's (another) project I'd like to do next Spring (gives me time to learn how to do this). Most Years we have birds use a nesting box in our apple tree. When the young hatch, the parents are really busy bringing in food. I'd like to:

1/ Have a beam set across the entrance whole to the nest box.

2/ When the beam is broken (parent bring in food) a counter is incremented and stored.

3/ Set a Light_Dependant_Resistor up so that when night falls the days DATA is rfpic'ed back to the RX module and displayed on the Serial Communicator.

LEDave, so many projects, too little knowledge.