| View previous topic :: View next topic |
| Author |
Message |
saksun
Joined: 01 Jun 2017
Posts: 15
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
 Posted: Wed Nov 01, 2017 9:55 am |
 |
|
Honestly, no.
It would be possible to write something using the same 'principle', and polling the only timer on your chip, but it will be bulky, and fussy.
It's a case that you'd be far better off getting a chip with more abilities. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Thu Nov 02, 2017 5:05 am |
|
|
I downloaded the datasheet and was surprised that the PIC doesn't have ANY interrupts ! wow....
As for the 15 second delay..
You could just code something like..
main()
{
...some 'before' code
delay_ms(5000);
delay_ms(5000);
delay_ms(5000);
...some 'after' code
}
This will work but know that during the delays, the PIC will NOT be able to do anything else, like read I/O pins, write to I/O pins, etc.
Delay_ms() is 'inline code', meaning the PIC will do NOTHING but the delay during execution.
This may be OK for your project.
As Mr. T says, it'd be best to choose another PIC if possible or be 'happy' with the inline delay code.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Thu Nov 02, 2017 5:46 am |
|
|
Yes.
If he absolutely 'must' use this chip, and needs something to give a 15second delay while doing something else, then (potentially), he could 'poll' the timer with it set to a slow speed, and generate a counter this way. However the danger is that you might miss the count you want if other jobs take a lot of time.
Anything better than the simple 'delay_ms' version is going to be more work than it is honestly worth doing, given how limited the chip is.... 
The PIC16F676 for example, is pin compatible with two timers and interrupts. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Thu Nov 02, 2017 7:10 am |
|
|
He could break up the 15s delay into 100 x 150ms short delays and Read I/O in between or other short functions.... granted this will change the overal length of the 15s delay as reading I/O or other functions will add to the delay time.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Thu Nov 02, 2017 7:47 am |
|
|
Agreed.
It totally depends on what is actually required. Any of the experienced programmers here could do it, but they probably would not want to start with an 'RTC'. Unwanted complexity for a simple delay. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Nov 02, 2017 9:29 am |
|
|
| Ttelmah wrote: |
If he absolutely 'must' use this chip, and needs something to give a 15
second delay while doing something else, then (potentially), he could 'poll'
the timer with it set to a slow speed.
|
Here is a sample program for this method:
http://www.ccsinfo.com/forum/viewtopic.php?p=101541
| Gabriel wrote: |
He could break up the 15s delay into 100 x 150ms short delays and Read
I/O in between or other short functions.... granted this will change the
overal length of the 15s delay as reading I/O or other functions will add to
the delay time.
|
Here is sample code for this method:
http://www.ccsinfo.com/forum/viewtopic.php?t=40578&start=3 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Thu Nov 02, 2017 9:39 am |
|
|
Just as a joke, I decided to code a 'polled' timer based on this chip.
| Code: |
#include <16F526.h>
#device ADC=8
#FUSES NOWDT, NOPROTECT, NOMCLR, IOSC8
#use delay(internal=8000000)
#define TICKS 7812 //ticks per second for the timer
//for timer running at 128uSec per count
//8MHz/(4*256)
int32 time=0;
int32 get_time(void)
{
//The CCS get_ticks refuses to operate correctly with this timer
//so coding manually
static int8 last=0;
int8 val;
val=get_timer0(); //new timer value
if (val<last)
time+=0x100; //timer has wrapped
time=(time & 0xFFFFFF00)+val; //combine upper 24bits with timer value
last=val;
return time;
}
//clear the timer
#define clear_time() set_timer0(0); time=0
void main()
{
int32 end;
setup_timer_0(T0_INTERNAL | T0_DIV_256);
setup_adc_ports(NO_ANALOGS);
clear_time();
end = TICKS*15; //15 seconds delay
while(TRUE)
{
if (get_time()>=end)
{
//do what you want to happen at 15 seconds
delay_us(10);
//reset 'end' if you want to continue (add ticks)
}
//do other jobs - ensure though these do not take too long
delay_ms(10); //just as a demo.
}
}
|
Now, it does work, and stop at just on 15seconds, but is already using 95% of the RAM!... Not exactly going to be practical for anything much.
The timer RTCC code wouldn't even have a hope of fitting, even if the chip had got interrupts. I had hoped the CCS #USE TIMER and 'get_ticks' might work, but it doesn't. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Fri Nov 03, 2017 5:19 am |
|
|
I decided, since it's dark and raining cats and dogs here, to cut code for a simple delay_ms(15000) version of Mr. T's program.
Mine uses 3% ROM and 16-21% RAM. So it _might_ be possible for the OP do what he needs.
| Code: |
//version 2
#include <16F526.h>
#device ADC=8
#FUSES NOWDT, NOPROTECT, NOMCLR, IOSC8
#use delay(internal=8000000)
void main()
{
setup_timer_0(T0_INTERNAL | T0_DIV_256);
setup_adc_ports(NO_ANALOGS);
while(TRUE)
{
delay_ms(15000); //hard,inline 15 second delay
//do other jobs - ensure though these do not take too long
delay_ms(10); //just as a demo.
}
} |
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Fri Nov 03, 2017 7:00 am |
|
|
My assumption was that he needed to be doing something else _[u]while[/u_] the time was counting. Provided the 'get_time' is called a few times a second, mine allows this...  |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Fri Nov 03, 2017 7:07 am |
|
|
Yeah I figured that too, just wanted to see what 'inline delay' would compile to.
Still amazed PIC has NO interrupts ! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Fri Nov 03, 2017 7:29 am |
|
|
Yes. As with several PIC's, it shows signs of actually having been made to fulfill a specific requirement from a customer, with 'minimum' abilities designed to meet their target requirements with no other abilities, and then been 'included' in the general distribution almost 'by accident'....
What is surprising is how recent it is. It has a lot in common with the original 16C84, and think how long ago that was made. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Fri Nov 03, 2017 8:19 am |
|
|
re:
| Quote: | | It has a lot in common with the original 16C84, and think how long ago that was made. |
No , don't want to know...LOL...
I still have a tube of them and 16C71s in the drawer here,though WHERE the UV eraser machine is...well, that's anyone's guess..
Now you got me thinking I should toss out all my 7400 and 4000 series chips....
There have been a few improvements since the early 80s....
It's real nice not having to wait 15 minutes to erase code in a PIC for one !!
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Fri Nov 03, 2017 9:07 am |
|
|
The 16C84, was great. It was the first EEPROM based PIC. At that time they hadn't decided to use 'F' to signify this, so used another number in the same sequence as the slightly earlier chips. It was later 'renamed' as the F84, when they improved the security at the same time (the early versions were very easy to hack...).
Engineering quantities shipped late 1992, though production started in 1993.
I actually have some boards still running using a few of these. Though some started losing their EEPROM contents a couple of years ago, and had to be upgraded to newer versions!.. The customers still like them!...
<https://spectrum.ieee.org/tech-history/silicon-revolution/chip-hall-of-fame-microchip-technology-pic-16c84-microcontroller> |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
