[Moved] want help for delay code for pic 12F629

Hi every one
Actually i want to construct automatic light controller using pic 12f629 or some other i mentioned it because i dont know how to provide long delays using 555 hence i found this ic form some website
the the light should remain on on for 12 hours and off for rest of the time
the counter should remain on if power to micro-controller is interrupted
Microcontrollers are new for me and dont know much abour that
so i requesting everone kindly help me for programme code also tell me how to convert .asm file in to binary format and how and using which circuit it can be write on pic
Pls help me on this project
also suggest if anyone having the better idea for that project

Let us assume that 12 hour timer is generated through timer interrupt code. The time starts the moment the PIC starts or at some button press. What happens if the uC resets? The time also starts from 0. If you make sure that power to uC will not fail or uC will not reset then you can use software timer.

jayanth.devarayanadurga said:

Let us assume that 12 hour timer is generated through timer interrupt code. The time starts the moment the PIC starts or at some button press. What happens if the uC resets? The time also starts from 0. If you make sure that power to uC will not fail or uC will not reset then you can use software timer.

Click to expand...

He can use 128bytes of internal EEPROM to save current time.

For example: after returning power to uC/circuit if data exist at specific EEPROM addresses then read EEPROM datas and continue counting. When timer reach 12hour EEPROM datas are cleared.


Best regards,
Peter

;-)

Ashu11,


The working process are not similar to a simple long term timer ?
This could be performed by using an OSC 32.768KHz crystal, whose timebase could be proportional to 1 second.
Further postscaler can be achieved by firmware.

( note that processing power is not a requirement to this application )


+++

How many times will he write to eeprom. Once a minute or once every 5 minutes. What will happen to the life of eeprom?.

Hello!

In a traffic light system, the bulb or leds are operated in a sequence. The total time to complete a sequence must be known, let say 150 seconds (This time can be on interrupt timer), then divide 12 hour duration by the time of a sequence. the result you get is the time counter value to run for 12hur. save the values in ram and decrement it at every completed sequence.

Most compilers generate an intel hex file as object code, which is to burn on chip. Meanwhile, your programmer interface load the .hex file into the chip. So, why binary conversion?

Good lock.

jayanth.devarayanadurga said:

How many times will he write to eeprom. Once a minute or once every 5 minutes. What will happen to the life of eeprom?.

Click to expand...

I think on something like that.

Lets say to log on each minute, and that timer is used each day at once:

Its 60 logs per hour * 12 hour = 720 logs/day

720 logs/day * 365 days/year = 262800 logs per year

PIC EEPROM lifetime (1000000 cycles) = 1000000 / 262800 = 3,8 year usage of this PIC each day once.


Additional options:
- If log time interval is increased to lets say 5min EEPROM lifetime will also increased.
- PIC12F629 is cheap and can be replaced when old uC EEPROM stop working.
- When some EEPROM location stop working we can use next address which is not used before. This require fault tolerance section in code.



Best regards,
Peter

ahmed-agt said:

...In a traffic light system, the bulb or leds are operated in a sequence...

Click to expand...

We must consider that real trafic light systems are not properly only sequential logic state machine, but a little bit more complex :
https://www.edaboard.com/threads/230186/#post982099

jayanth.devarayanadurga said:

How many times will he write to eeprom. Once a minute or once every 5 minutes. What will happen to the life of eeprom?.

Click to expand...

If counter storage during power failure is a design requirement, it makes more sense to use a low cost RTC ( such as 1307 ) to keep counting, instead save last value at EEPROM, once during blackout event, the system will not be able to increment timer anymore.


+++

andre_teprom said:

If counter storage during power failure is a design requirement, it makes more sense to use a low cost RTC ( such as 1307 ) to keep counting, instead save last value at EEPROM, once during blackout event, the system will not be able to increment timer anymore.
+++

Click to expand...

I agree with that, but this is different concept from required original concept.

Plus DS1307 is I²C and PIC12F629 I²C ports ?

I²C must be done with software on PIC12F629, which will increase size of code and require size of µC memory and PIC12F629 have only 1,75KB for program.



Best regards,
Peter

In a real time situation that is if the system will be use on the road and not student prototype project; make use of external RTC to keep time. When ever the system reset predefine values are reloaded in ram, and not in the eeprom. However, if the system is having an input menu to change time event ( that is programmable traffic type) then eeprom can be use to store time event.

Meanwhile, I have experience in traffic and road system design, and at least two of my design is being used on the road, and a lot of prototype design as well.

Peter,


I prefer perform I2C access not by HW built-in modules, but by firmware, due to this proceed turn the code program easily portable to other core platforms, once is not dependent to specific hardware resources.


+++

ahmed-agt said:

In a real time situation that is if the system will be use on the road and not student prototype project; make use of external RTC to keep time. When ever the system reset predefine values are reloaded in ram, and not in the eeprom. However, if the system is having an input menu to change time event ( that is programmable traffic type) then eeprom can be use to store time event.

Meanwhile, I have experience in traffic and road system design, and at least two of my design is being used on the road, and a lot of prototype design as well.

Click to expand...

There is uC with RTC and lithium battery inside DS5000T 40-pin its 8051 family and have very high price. Will be nice to see some uCs with that in PIC and AVR families.

I hope that real life devices for road traffic lights dont use 12F family or some NE555 control circuits.


Best regards,
Peter

Hello everyone! let us make thing workable for this guy, he his only doing a school project............ Please, let's guide him to improve in his programming skills and design, and not to make him get more confuse.

Thank for all your support.

@Tpetar

You are right. 5 minutes logging will be ok. If he logs minute every 1 minute then he needs 1 byte for minute value. He can use a counter to count 1000000 eeprom cycles for minute. The counter is also saved in another 3 bytes. If counter value becomes 1000000 then it means the minute byte in eeprom is dead and then the program should start saving minute value to another eeprom location for another 1000000 cycles.

ahmed-agt said:

...he his only doing a school project...let's guide him to improve in his programming skills...

Click to expand...

ahmed,

Fell free to give him your valuable contribution, and let everyone raise what questions we consider relevant, due is not out of scope :

Ashu11 said:

also suggest if anyone having the better idea for that project

Click to expand...

+++

thank you very much sir for your reply
it is good idea to save counter in EEPROM
but how we can know that for how much time the power is not there because that time also required to add to previously stored count
there must some provision that counter should remain on even if power to uC is interpreted

- - - Updated - - -

thank you for your reply
sir
i am not going to use single circuit for entire traffic light sequence actully i want to use this for single light only to give it automation and there should be no mannual operation each and every day

Ashu11 said:

thank you very much sir for your reply
it is good idea to save counter in EEPROM
but how we can know that for how much time the power is not there because that time also required to add to previously stored count
there must some provision that counter should remain on even if power to uC is interpreted

Click to expand...

Simple we can count crashed cars on street, each car is one minute.

Then you should use RTC IC and ensure power supply for that IC. This is also good idea.

Maybe to use two or more the same circuits as fault tolerant in parallel with separate battery backup.


Best regards,
Peter

Counter is used just for counting the no. of eeprom write cycles. One counter for minute and one for hour. memory location for minute and minute eeprom write counter will expire in 3.8 years as Tpetar said.

Hour and minute are stored in eeprom.

For power failure situation RTC has to be used.

Additional to this topic, usage of FRAM can give new look on this.

Non-Volatile Memory FRAM MB85RS256A
https://www.fujitsu.com/global/services/microelectronics/product/memory/fram/app-mb85rs256a.html

MB85RS256A is a 256K-bits FRAM LSI with serial interface (SPI), using the ferroelectric process and CMOS process technologies for forming the nonvolatile memory cells. Module uses the ferroelectric process and silicon gate CMOS technologies for forming the nonvolatile memory cells. It is able to retain data without using a back-up battery. The memory can be used for 10 bilion read/write operations and does not take long time to write data unlike Flash memories or EEPROM. It uses SPI to communicate with the target device. Maximum operating frequency is 25MHz. Because FRAM is able to write high-speed even though a nonvolatile memory, it is suitable for the log management and the storage of the resume data, ...

NoDelay Write: FRAM writes so quickly that there is no need to wait for the write to complete. Typical write speed for FRAM is around 55 nanoseconds as compared to the much slower 5 milliseconds write speed for EEPROM.

Using FRAM is simple. Serial FRAMs are compatible with serial EEPROMs and parallel FRAMs are compatible with parallel SRAMs. Existing software will work with FRAMs but most engineers chose to re-work the software. There are two significant software modules that may be employed with EEPROM or flash that are not needed for FRAM. Removing this redundant code makes software faster to run, easier to debug, and consumes less code space.

The first of these modules is the function necessary to wait for EEPROM or flash to complete the write operation. There is no point in polling the FRAM to see if the write has completed (the write will have finished before you can check), but this feature is supported in case you don’t want change your EEPROM software.





Best regards,
Peter