Getting acquainted with Timer1 is essential at this point in the discourse of CCP applications, because CCP is symbiotic with Timer1 for most of its timing control operations related to Capture and Compare functions.

Timer1 is a 16-bit incremental timer/counter made up of the TMR1H:TMR1L 2-byte pair. It has 3 modes of operation, as an externally pulsed counter, connected to its own independent RC oscillator, and incremented based on the internal PIC clock, often referred to in the datasheet as Fosc/4. For all examples in this series on CCP, Timer1 operates as a function of the internal PIC clock, which is the main oscillator divided by 4 cycles.

Timer1 actually gets its pulses from a Prescale Counter, and not directly from the PIC’s clock. The Timer1 Prescale Counter increments from a direct connection to the PIC’s internal clock, and it’s output is connected to Timer1. The Prescale Counter divides the normal clock into 4 ratios, 1:1, 1:2, 1:4, and 1:8. Put another way, the Prescaler clocks/increments Timer1 on the same, 2nd, 4th, or 8th clock pulse of the PIC.

These Prescale counter ratios are set in the T1CON (Timer1 Control) register. Typically, at bit4, and bit5. T1CON also controls other features of Timer1 operation, most notably TMR1ON, which is the Timer1 On/Off “button”.

The following code is an example of setting up Timer1 as part of a CCP function.

Interrupts are about detecting important events and then doing something about it. 2 flag bits are assigned to every different PIC interrupt. An interrupt event is considered active/armed if its Interrupt Enable bit is set (=1), and the Interrupt Flag bit is cleared (=0). Additionally, if the interrupt is a peripheral type, the master PEIE (peripheral interrupt enable) bit must be set (enabled =1). CCP is identified as a Peripheral function of the PIC. The master of master enables is the GIE (global interrupt enable). Until that bit is set (=1) no interrupt events, whether peripheral, or otherwise, can happen.

If you look at the datasheet’s interrupt “tree” (left to right) it first appears as a mass of lines and logic gates. Break it down and it becomes less confusing. Note: Each interrupt function is an AND gate. Logical AND simply states that ALL inputs (no matter how many) must be “1″ to get a “1″ at the output. Any other input condition…. no output! Note: in the drawing that the final destination is the “GIE” enabled AND gate. An output here triggers an automatic jump to the ISR (Interrupt Service Routine) which was previously designated in the program code by the compiler. This is a built-in feature of PIC’s. Compilers simplify some of the task by writing the necessary preamble and finally the RETFIE (return from interrupt) ISR code. There will be more reference to this compiler code later.

Pay attention to the AND gate at left-center of the above schmatic. Find CCP1IF and CCP1IE. When both of these flags are set (=1) the output is set (=1). The signal passes through the multi-input OR logic gate on to the PEIE AND gate. If PEIE is set the output is set because both inputs are set. Following the path you reach the final GIE AND gate. If GIE is set then the CPU interrupt is activated.

This walk-thru actually demonstrates the path of any and all of the different possible interrupt events of the PIC. But, our focus from this point with regards to interrupt events will be related to the CCPx module. To be more specific, this means paying close attention to the GIE and PEIE bits of the INTCON (interrupt control register), the CCP1IE bit of the PIE1 (peripheral interrupt enables #1) register, and the CCP1IF of the PIR1 (peripheral interrupt register #1) register.

When a CCP event occurs it sets the PIR1.CCP1IF bit. If the INTCON.GIE, INTCON.PEIE, and PIE1.CCP1IE bits are all set, that is, enabled, then setting the CCP1IF flag bit will create a jump to the ISR (interrupt service routine), so that the event is processed. In all the code examples found in following articles, please note the attention given to these 4 components of the CCP1 interrupt.

Interrupt Enable bits only need to be set up once in the program (usually near the beginning) and will not change unless the programmer disables them in code. In order for a CCP interrupt event to be detected and processed, the CCP1IF bit must first be cleared. When the CCP event happens this flag bit will become set. It must be cleared again inside the ISR before leaving if another CCP interrupt is to be detected and acted upon.

The first page of the CCP chapter in the datasheet is an important reference to the capability of this PIC hardware module. Hardware module is a reference to a builtin feature of the PIC which can perform important tasks independent of other code operations. In the PIC18F877a datasheet the CCP reference is Chapter 8.0.

CCP is a high performance timing mechanism within the PIC related to Timer1, Timer2, and Timer3. Depending on the selected control mode of operation will determine which of these timers can be utilized.

What makes CCP so powerful is that it turns an 8-bit machine into an 16-bit event processor. CCP has the ability to utilize its 16-bit register, CCPRxH:CCPRxL (.. some PIC’s have 2 or more CCP modules and so the ‘x’ can be replaced with a 1 or 2 depending on the application), through capture or comparison to a 16-bit Timer and instantly alert the program that a 16-bit processing event has occurred. When an edge triggers the CCP input, there is a Capture feature that seamlessly loads the Timer value into the CCPR register. All 16-bits at the same moment. When Timer1 increments to a value that matches a pre-loaded 16-bit value in the CCPR register, the Compare feature will instantly set a flag to alert the program that the match occurred.

There are many features and modes. Look to the first CCP page in the datasheet and the CCPxCON control register. Below the bit settings can create up to 10 different operational modes. These features open a new panorama of design opportunities and flexibility because they are so powerful.

PWM, the last control mode listed, is the more sophisticated of the 3 main CCP modes. This will be explained later, without a log(2) mathematical formula, as the datasheet presents pwm resolution, and will intentionally remove the wrong assumptions, miscalculations, mistakes in application, and general mystery surrounding this mode.

I have now been programming 8-bit PIC’s using Basic and ASM for 3 years. For 2 of those years I learned just about everything there was to know about PIC timers, and using them in projects of all types. How I missed CCP (Capture, Compare, PWM) during that time is a little disconcerting to me personally. When I actually read that chapter in the datasheet, the bells went off in my head. A new world of applications and solutions opened up. Some of these simple application ideas I will explain and demonstrate through a series of CCP articles on this blog.

Also, consider the added benefit of my soon to be posted CCP examples. They are not only real applications but can also be compiled with the free demo-version of the mE compilers.

A quick note about PIC’s. PIC16 is alive and well. That said, I recommend that every PIC programmer become familiar with the PIC18 series. PIC18 mcu’s have machine language, internal memory architecture, and speed capability, which are different, and better, than the PIC16. If cost in a project is not an issue, consider using PIC18. It’s a move toward better performance and the future.

Now, we can move this discourse away from the first person and let the datasheet and code do the explaining, with a nudge from the author. Enjoy the next few CCP articles and see the possibilites.

Suffering a serious health crisis has taken its toll on me recently, not so much with my thinking and motor skills as much as it takes away my physical energy. For those of you who missed the details, here I am after brain surgery late in February. I’m home and looking much better (the wound is almost gone and the hair is growing out…. although the radiation may take some back):

Why GUI’s? Because they make all the difference in a project. The appeal is both aesthetic and economical… a winning approach for a good design idea. A GLCD with Touchscreen not only eliminates expensive mechanical pushbuttons and switches (even cheap ones add measurable cost), requiring extra panel design and silkscreening/etching, but can be far more descriptive and understandable for the customer. After all, what pop electronic product doesn’t have a GUI these days?

I will be posting some new stuff about GLCD and Touchscreen interfaces soon, especially that CircuitED released the “EZ-FPC” (very popular!), which allows any 4-wire touchpanel to be connected to any of the development boards. I intend to demonstrate how to use EZ-FPC to quickly determine the X/Y Plates, and also the direction of voltage drop across the panel, in about a 2 minute operation on a development board. All this without seeing a touchpanel datasheet.

Next, will be more information about actually connecting and operating the 4-wire touchpanel directly from the microcontroller. It only requires 4 IO (any IO pins), 2 of which must be ADC inputs. Nothing else! No transistors, resistors, capacitors, etc. I have 2 new designs (in software) which are both different but effective, accurate, and fast. They are nothing like my original newbie touchpanel attempts many months ago (yuck!). All I needed was time to play and some good things happened.

I inadvertantly created a hullaballoo in some forum comments several weeks ago (pre brain cancer) about not giving away code that required some hours and expertise to develop and which could have all the possibilities of promoting other commercial venues other than my own. My comments were a reaction to a phone conversation with another commercial developer, who was digging for some good touchpanel sourcecode/examples, and then also dropped the idea that he might go directly to my Chinese LCD source (for a better price break) once he had a designed his new GUI product. That was like cutting me twice. Then the reaction in the forums also raised a red flag. While the free flow of good code and ideas in the forums is generous, some see it is as their privilege to criticize, scoff, and, demand, for those things which they are generally incapable of doing themselves, or at least doing well. It’s a little hard to stomach sometimes…. but I’m over it now.

So, Forward With GUI’s. More will come, including a couple new GUI projects complete with sourcecode.

NEW EZ-FPC TUTORIAL AVAILABLE

Warren

There was that initial energy to get the blog started and ranting is always easy, so a couple good rants helped fill some space.

Coming soon, are some really neat optimizations for coding that I’ve been working on and will post some soon as I work out a couple glitches I encountered with one of them. While software debuggers are wonderful and the simulator in mikroBasic is no exception, it does not do a good job updating the DC Status register flag, and cannot manage the DAW instruction correctly. These 2 never used and little understood event and instruction are essential to my approach to some “new” concepts, and the simulator let me down. Code problems can be resolved very quickly by stepping through code as long as the registers change as expected and planned, that is, reported correctly.

Fortunately, the PIC itself is not fooled when loaded with the instruction(s) and run, and will correctly output according to its design. It just makes life as a programmer more difficult since I must add LCD code and output something that proves whether the code is doing the right thing. If not, then back to the code and making changes and outputting appropriate information that tells me what I need to know. The biggest problem is that it’s a right/wrong end result rather than a good indicator of where the problem lies inside of the algorithm.

Maybe ICD will help here…. if it really reads the live PIC registers and reports correctly. If not…. damn!

Maybe I will resort to MPLAB for simulation. Or, maybe I will suffer the trial and error tribulations and get these routines done and posted. I will be reporting something soon.

mikroElektronika has started distributing their new EasyPIC5 development board and it looks like a beauty. See it here. While we wait and anticipate its arrival to the US to begin distribution to customers, we have been eagerly reading the online documentation for the board, especially focused on the outstanding new feature, an on-board touchscreen controller and FPC connector right next to the Graphical LCD mount. The electrical circuit for the controller is found on page 25 of the EP5 User’s Manual. So how does it work?

It’s relatively straightforward. 2 PIC port pins, RC0 and RC1, are used for a simple control scheme. When one of these two pins is high and other is low one plate becomes electrically energized (Vcc on one side and Ground on the other) while the other plate is made high impedance. Reversing the high-low state of RC0 and RC1 switches reverses this energized and non-energized state of the X and Y touch plates.

The EP5 touchscreen controller uses 5 transistors, a mix of NPN and PNP BJT’s, to do the actual electrical switching work. In theory this small array of transistor switches should simplify the code required to read the touchpanel and maybe keep someone from smoking a touchscreen… if that were possible.

The non-energized plate is what ‘reads’ the voltage drop produced by a touch location on the energized plate. The transistor switching makes the non-energized plate very high impedance on one side and the opposite side is connected to a PIC ADC input. PIC ADC inputs are relatively high impedance and appear as an insignificant load to an energy source, somewhere in the neighborhood of a few tens of millionths of an amp. But… mikroElektronika has done some interesting engineering. They added a 1000 Ohm resistor and small capacitor to ground at each ADC input. The cap works as a filter for noise and other irregularities common to electrical contact surfaces. The pulldown resistor is likely intended to keep the PIC input from floating.

This drawing is the basic electrical scheme of the EP5 touchpanel during a plate read cycle:

The small cap is a good idea. The pulldown resistor..??? Ouch! This resistor creates a voltage divider for the incoming signal to the ADC. A voltage divider is not inherently bad, but in this application it’s not good. The touch voltage drop of the energized “send” plate remains constant along a perpendicular line over the full resistance range of the “read” plate. That means that the fixed touch voltage runs through any number of series resistance values within the “read” plate’s range before it reaches the ADC input. By itself, this series resistance, which is usually less than 1000 Ohms for small touchpanels, is of little to no significance when connected directly to the high impedance input of the ADC. In a voltage divider circuit where one of the resistances is fixed and the other is variable, it is predictably non-linear. Furthermore, the result is unreliable in this particular application of it.

The drawing in this post provides a particular electrical scenario where the “read” plate has a range of resistance from 100 to 900 Ohms and the energized “send” panel voltage is 2.25V at the point it is touched. With a fixed 1000 Ohm resistor to ground, the range of voltages the ADC will see is from 1.18V to 2.05V. Those are vast errors in reading when 2.25V is the correct target voltage. Of course, changing the fixed pulldown resistance to 10,000 Ohms, the amount of possible error can be greatly reduced, resulting in readings from 2.06V to 2.28V with a 2.25V supply, which is worst case 10% error. 10% error can equate to missing a screen location by 13 pixels in the X direction, and 6 pixels in the Y direction on a 128×64 Graphical LCD in terms of the full-range voltage.

For the sake of argument, if the “read” plate’s resistance range is smaller than the previous example, and very likely is smaller, the degree of possible error is further reduced. Just remember that the schematic shows a fixed value of 1000 Ohms to ground and the plate’s resistance would need to be significantly lower to get errors close to some semblance of acceptability.

It’s entirely possible something has been overlooked in this dissection of the new touchscreen controller circuit, and needs correction. Feel free to include another point of view.

Warren Schroeder

Please… when will someone intelligent explain the superiority of C over BASIC using PIC microcontrollers? A Google search does not turn up much discussion on the matter. To make matters worse for the “other” high-level languages, Microchip makes the claim that their PIC18 processor instruction set is optimized for C. Somehow, after using structured Basic compilers like mikroBasic and Swordfish and realizing some diverse and optimized assembly code being generated, this makes no sense.

C seems to be the appropriate buzzword for the modern programming crowd, and maybe such claims by Microchip sells more MCU’s.  If your the code is written in C then there is mainstream acceptance. But browse the PIC C forums and become unimpressed. PC C programmers wander into the realm of PIC’s and find themselves readily blaming PIC C compilers for all sorts of ANSI non-compliance and various other “bugs”.  Closer inspection usually reveals a vain attempt to hide a baseline ignorance of low-level CPU operations and a further inability to operate outside of an RTOS running 32-bits at 2GHz. Such are the purists who have no clue of the machinations of managing 8-bits of raw muscle directly, but claim competence as programmers.

Back to the subject. Is there a mysterious C function that cannot be replicated in Basic? After all, with only a few more than 30 machine instructions to manage all possible algorithms in a PIC, what is missing in BASIC?

The PIC forums are clogged with postings by ‘newbie’ and ‘wannabe’ PIC programmers who open up a compiler, write the simplest 4 lines of code to make an LED turn on and off on a port pin, compile and program the PIC without errors, and then are completely befuddled why their PIC is not doing what the simple code commanded the PIC to do. What could possibly be wrong?

This type of problem should not be oversimplified, since the next 5 replies from the “experts”, while different, might all be valid guesses at the source of the problem. Finally, Mr. Helpless, our newbie poster, begins the task of applying some of the suggestions, and Voila!, it now works as expected. Kudos and accolades to the guesser who played the 1 out of 5 odds and was right.

This type of post and reply game gets played out daily, ad nauseum, on every PIC forum. What is the benefit to the original poster and to those who reply to such posts? PIC’s, datasheets, compilers, applications, and a myriad of books and internet websites that explain everything in detail, are freely available. Did someone forget to do some homework? You know it!

Visit a first grade classroom and all the smart kids in the room constantly raise their hands because they have the answer. The more dormant minds in the class eventually learn that it is easier to let those more enthusiastic learners/answerers do the work and then benefit themselves by copying homework and looking over shoulders for answers. Maybe this is a poor analogy of the forums, but the first grade scenario certainly gets its fair share of playtime in many of the discussions found there. The pathetic part is that it’s still a room of first-graders, the dormant-minded helpless one, and all those enthusiastic raise-my-hand-I-have-the-answer classmates. Note that the adult of the group, the first-grade teacher, would have never given away the answer, except in a lesson.

Once in a while, there is a mature/insightful reply which coaches and directs Mr. Helpless to reading materials, examples, and files, that contain the answer to his dilemma. Mr. Helpless replies back that he has read it and doesn’t understand. Mr. Helpless is now exposed. Note, that there are 5 possible solutions, and his comeback reply is “I don’t understand”. What happened to the specifics of the reference materials? Any questions about anything in particular? This is Mr. Dormant-Brain from first grade. His laziness, narcissism, and expert manipulation are perfected forms of his socio-pathology…. work the room and find those zealous hand-raisers. It’s not difficult to test such features of a suspect poster’s personality. Just insist again that the answer exists in its simplicity where you directed him. There will be no thank-you’s for his pain, and expect nothing less than an accusation that your attitude sucks.

In contrast, there is some sensibility in the question of a poster when he has done some reading and is attempting to understand an incomprehensible (to him anyway) concept, and his hands are dirtied from building an electrical interface. There is a certain light on in his questions. That person should be helped and given assistance; he deserves it. This type of person appreciates the reference to the solution as much, and probably more, than pointing out the solution to the problem.

There is no particular benefit to anybody assisting those who demonstrate no inclination to do work or implement the simplest techniques of logical/critical thinking. Also, being an enthusiastic hand-raiser and blurting out an answer, or guess, might be a piece of the persona/psyche of the child more beneficially left behind in an elementary school room. Changing the tenor of discourse in this way will likely encourage everyone else in the group to be more mature, especially in how they ask and respond to forum questions.

If anyone is wondering where “xor” is dwelling these days, you will find him here.  It’s time to take a break from the forums for a few weeks.  They are a bit addicting and they detract from some real work that needs completion.

Lots of projects, fresh ideas, and the capability to do all of them…. but nothing finished.  That’s not a good success story.   For those moments that might require a break from from the silicon, soldering iron, and compilers, the overflow may show itself here.

A new year and a fresh start for another technical blog.

The articles/comments published here in the time to follow will focus on code and interface/application examples for PIC microcontrollers. And for all the probability that everything has been said and done with a PIC, I have seen and realized recent innovations in coding and applications for these popular microcontrollers. Therefore, while there will be the unavoidable repetition of well-known and oft-published concepts in microcontroller coding and technology, code and application creativity takes precedence… always.

I encourage publishing of original peer articles on this site, and also peer reviews of articles posted here. Contact me directly by email to be included.

Enjoy the articles.

Warren Schroeder/ Administrator