Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

12c508a - Power Timer

Status
Not open for further replies.
philba said:
with an available timer, why deal with code cycle counting at all? seems so much easier to wait for a timer to reach a desired value.

It's generally far easier to use a simple delay loop, and the 12C508 only has timer0 which is really pretty poor compared with the later timers.

As you can simply generate accurate delay code on the PICList generator (with more accuracy and versatility than timer0) there seems little point in using the hardware timer for it?. However, they do have many more useful uses!.
 
I think that's just an opinion. looping and looking at a timer is simple and small. One can easily generate accurate times both ways. there is nothing wrong with using the resources available.
 
philba said:
I think that's just an opinion. looping and looking at a timer is simple and small. One can easily generate accurate times both ways. there is nothing wrong with using the resources available.

No, nothing wrong with using the resources available, but why do it if it doesn't give any advantage?. You can generate equally accurate timing either way, but using the hardware timer restricts the possible options considerably - you can't get one instruction cycle resolution from low values to any high value you require (you can with software delays).
 
I don't think one size fits all. for very short delays, instruction counting is the way to go. for longer ones, I much prefer using timers and, if available, interrupts. Using timers allows you check for other things that are going on - like button presses, for example. using instruction counting ties you into just doing one thing and any changes forces you to recalculate your delay code.

In the above case, using a timer allows you to check for the reset button in a responsive manor with out having to factor in the time to check the button.
 
Personally, I only ever use software delays for short periods. Anything longer I will use a combination of timers and interrupts. However, for beginners, any hardware device is a bit daunting and so software delays are preferable in code meant to teach the basics.

Mike.
 
Pommie said:
Personally, I only ever use software delays for short periods. Anything longer I will use a combination of timers and interrupts. However, for beginners, any hardware device is a bit daunting and so software delays are preferable in code meant to teach the basics.

Yes, for implementing long delays I would usually use timer interrupts (basically making a real time clock) - however, the 12Cxxx series don't have interrupts, which make it rather difficult :p

As for checking for keypresses during the delay, without interrupts this is still 'difficult' when using the timer - as you may miss it's timeout - possibly by a considerably period?.

Horses for courses!.
 
Checking for keypresses during a delay is trivial. (yes, I now you said difficult)

I'll post a circuit and code soon that uses a 12c509 to read a 3*4 keypad. It reads the keypad and sends the key presses via RS232. It has 2 key rollover and repeat.

Is anyone going to fix the posted projects that now have no images?

Mike.
 
Nigel Goodwin said:
As for checking for keypresses during the delay, without interrupts this is still 'difficult' when using the timer - as you may miss it's timeout - possibly by a considerably period?

The pseudo-code I posted actually does exactly that - checks for keypress during delay easily. the error is calculable - basically the number of clocks of the loop, max. But the code can be constructed so as to minimized the default loop cycle to be quite low. I think I could do the above example in less than 20 I clocks. The counter update isn't a problem and the keypress check time is small. With out ints, your default loop has to be less than the pre-scale time - in this case, 128 clocks.
 
philba said:
The pseudo-code I posted actually does exactly that - checks for keypress during delay easily. the error is calculable - basically the number of clocks of the loop, max. But the code can be constructed so as to minimized the default loop cycle to be quite low. I think I could do the above example in less than 20 I clocks. The counter update isn't a problem and the keypress check time is small. With out ints, your default loop has to be less than the pre-scale time - in this case, 128 clocks.

Yes it does, but it gives no advantage over a software loop delay, in fact your pseudo code (which I copied and pasted) can be simply modified to use a software loop delay instead, which no loss of functionality.

Code:
loop 
   call short delay
   increment elapsed time counter
   if elapsed time counter is 2 hrs (or whatever) then
       do what needs to be done
   endif
   if switch is pressed then
      reset elapsed time counter
   endif
end loop

Obviously the trick here is simply to have a short delay (done by either method) called many times in a loop in order to check for a key press at short intervals. There's no need to do it too often, as a mechanical switch is a slow thing anyway - certainly 100mS should be plenty fast enough?, unless you're building a stop watch of course :p
 
Sorry to drift off topic a bit, but were their books, coursework, or something you guys went through to gain all this knowledge with PIC's? How long have you been working with them? Is learning about them more just getting your hands dirty figuring this stuff out through the datasheets, and what not?

It seems there is a breaking point where once you understand a certain level, everything else seems to click and make sense. I understand most of the various basic concepts with what is being done, but I've not found much really basic detail in a lot of the real "Beginner" type articles. No offense to Nigel, but even dumbfounded me. I don't fault him, as he clearly labels most every line, goes through some of the basic commands in the description. But, even coming in with some electronics background, developing professionally for a living, it was overwhelming at what I was seemingly not grasping.

I mean look at it from a complete beginner, ok so __config 0x3D18 "sets the configuration settings", what in the world is 0x3D18?!? Can you change this? Is it always this value? What is a W register, and why can't I just directly reference values? What does CMCMON mean? It's these type of things that I think are missing. For all I know they may be out there somewhere, I just haven't found them. I can't even find a reference on Microchip's site for the various assembly syntax!

I always feel bad asking the really dumb obvious questions, as I know there's more valid questions to be asked on the forum than "What is W register and why can't I pass a value directly" and you all would rather be answering more in-depth questions. I feel like I'm trying to ask the equivalent of "What farad rating do I need for my light emitting transistor capacitor". While I appreciate the amazing help from people on this forum, and people like Nigel who put together tutorials to help people, I still feel like there is still something that is missing that could really help people get started in PIC's.

So often the answer to questions is "You could probably do that with a pic", but even when you take the initiative to find the answer out on your own, you just hit a brick wall either in understanding or sheer unavailability of the information. Honestly, even huge resources like PicList seem utterly useless to me. Nothing you search for seems very well compiled and speaks to people with a much higher level of understanding than someone who is just getting started.

I know that there are 1000 schools of thought when it comes to pic's, using assembly, programmers, methodologies, which chips are better, etc. and you can't cover them all. I would be surprised if nobody else feels there is such a steep learning curve when trying to even get your feet wet. I want to learn and find answers on my own, I don't want others to do things for me, and I think that's a misconception. It would be nice if there was a consolidated resource that addressed things like just getting started and the really raw basics.

If I had the knowledge, I'd gladly help put together a preface for tutorials like Nigel's as I think it could really benefit people - and I'm sure Nigel has better things to do than go over all the low-level basics, but I'll be honest - I still feel clueless ;).

I suppose what I'm trying to say is I appreciate all of your help, and a sincere thank you to all of you who deal with the likes of me who probably sound absurd at times. I'll probably look back in the future and be amazed at the silly questions I've asked. Just be patient with me, I'll get it eventually :).
 
Last edited:
but how do you ensure that the elapsed time counter is accurate? If I make a change anywhere in the loop, I'd have to adjust the length of the short delay. Seems like unnecessary effort. also, the short delay needs to be less than, say, 50 mS or less to ensure responsiveness of the switch. (I can fast-press a switch and miss a 100 mS window) he'd need a 3 byte accumulator (144000 50 mS ticks in 2 hrs). not a killer but one more thing to do.

I agree that both can be made to work. I just think using the timer is easier. By the way, you could incorporate the switch check inside the delay loop to increase responsiveness but I'm a fan of seperating functions.
 
Last edited:
Just one question, PDubya.

Have you read the FAQ of this Microcontroller forum, ie. the sticky at the top of forum index?
 
philba said:
but how do you ensure that the elapsed time counter is accurate? If I make a change anywhere in the loop, I'd have to adjust the length of the short delay. Seems like unnecessary effort. also, the short delay needs to be less than, say, 50 mS or less to ensure responsiveness of the switch. (I can fast-press a switch and miss a 100 mS window) he'd need a 3 byte accumulator (144000 50 mS ticks in 2 hrs). not a killer but one more thing to do.

But wasn't your use of the timer just doing the same thing?. Because the delay call is so much longer than the time spent in the loop (50mS instead of a few uS) altering the main loop makes very little difference, but could easily be written accordingly anyway - but the same applies to a non-interrupt timer version.

But as I said previously, for a 2 hour delay I'd choose a PIC with timer interrupts :D

I agree that both can be made to work. I just think using the timer is easier. By the way, you could incorporate the switch check inside the delay loop to increase responsiveness but I'm a fan of seperating functions.

Same here both can work, but (the point I was making earlier!) if you check inside the delay loop using your timer version you could miss the exact rollover point - a software delay wouldn't have that limitation, plus can have a far wider range of values.
 
PDubya said:
Sorry to drift off topic a bit, but were their books, coursework, or something you guys went through to gain all this knowledge with PIC's? How long have you been working with them? Is learning about them more just getting your hands dirty figuring this stuff out through the datasheets, and what not?


I've been using pics for a couple of years. However, I've been designing operating systems and other system software for 30+ years, have a MSCS + minor in Digital EE and worked for a very large semiconductor company for many years (plus several significant software companies).

this sort of helps picking up new processors... :)

basically, I picked up PICs by reading datasheets, ap notes and forums.

my advice is to read everything you can find. starting with the datasheets. read them, know them. use the totorials if you are starting at 0. don't be afraid, experiment with the chips. when I get a new micro, I'll put it on a breadboard and exercise as much of the chip as I can. don't be afraid to try things - if you smoke it, so what? (well, be careful) get another. find as many forums on the subject as you can. read/scan through them. (being efficient is important here, most have a low SNR). I don't bother with books as they are mostly a waste of time. magazine articles can be useful. some great sources of information are application notes. microchip has a lot.
 
eblc1338 > Yes, I downloaded and sat through the Basic Training Modules a couple times, none of which really made sense as it talked mostly about features and how various call stacks worked, byte sizes, etc - really low level hardware stuff.

I read through various sections of the reference manual by microchip which answered a lot of questions for me about designations, OTP vs flash, etc. I even tried to read through the PWM section... but read this and tell me from a complete beginners perspective what you see:

The PWM duty cycle is specified by writing to the CCPRxL register and to the DCxB1: DCxB0
(CCPxCON<5:4>) bits. Up to 10-bit resolution is available: the CCPRxL contains the eight MSbs
and CCPxCON<5:4> contains the two LSbs. This 10-bit value is represented by DCxB9: DCxB0.

Even after a couple times reading through it, all I could muster was... "what?!?"

I purchased a handful of the 16F628A based on the recommendations, and I've obviously read quite a bit of Nigel's tutorials - and what I used to get my first blinking program working (Thanks Nigel!!!).

Are there other links on that page you recommend reading? I'd be happy to absorb anything anyone suggests.
 
I would suggest you try the book at **broken link removed**, the changes required for the 16F628 are VERY slight.

My tutorials aren't intended for absolute beginners, I expect you to do a little work yourself :)
 
PDubya said:
Are there other links on that page you recommend reading? I'd be happy to absorb anything anyone suggests.

I've only started learning PICs for a few months. I feel the same frustrated situation as you do for lack of tutorials on the internet for beginners. Most tutorials were writen by people who know the PIC so well that they often take things for granted and forget beginners haven't the faintest idea of what it is all about. The __config 0x3D18 you've quoted is a good example. I believe an explanation why one ends up with that value should be given for a beginner, without the need for a beginner to look at the datasheet and works backward to determine what options was chosen from the value.

The datasheet is actually really a datasheet, it does not explain why things work or why a certain configuration should be used. It just tell you what the chip is capable to do.

What I have done to learn the PIC is to cross reference the material from different sources, ask questions in forum and study(not merely read) the datasheet.

The situation is not unique to PIC, its all the same again when I venture into AVR, with even less suitable ASM tutorials available on the net.

The required information are scattered all around the internet and one must be patient in order to find them. The learning process will take weeks if not months. The only sure thing is "there is never a place with all the information on PIC" and there never will be.

Best of luck on your journey.
 
Last edited:
Status
Not open for further replies.

Latest threads

Back
Top