Toggling an LED using Timer Interrupt

[kalliskalyan]

Hi all,
I am a beginner with PSoC 1. Having gone through many app note, i tried my first ever project in PSoC. My aim was to toggle an LED every 1s. Maximum possible configuration ( Vc1 divider= 16, vc2 divider= 16, vc3 (sourced by Vc2) =256 and timer period = 256) gave me 0.6 s . Since it is perceptible i continued as such. In my power Psoc board an LED is connected to P1_5 . I configured those pins (initial value as 1) . when i programmed the Psoc my led kept on glowing(remaining in its inital value assigned) no toggling. I have checked for declaration of interrupts and all. I couldnt find more mistakes with my knowledge.

I have attached my project.
Kindly help
Thanks,
Sundar

[bobmarlowe]

The magic was to insert into the file LEDFlashTinerINT.asm at the right (clearly marked) place an LJMP to your interrupt routine.
I took the right to correct some minor uncertainities.

Happy coding

Bob

[kalliskalyan]

Thanks Bob

[danadak]

Some other thoughts on timer usage -

Generally you always want to minimize HW resource waste, so that you can
maximize total functionality in a design. Essentially, you look at all the timing
requirements you have, and try to optimize the amount of HW used to effect it.

So consider the following cases, with a requirement that you need 1 sec timer
for LED, 100 ms timer for bouncing in and out key closures.

Bad design -

You create two timer chains from a VCx clock in PSOC, wasting a lot of
digital blocks.

Good design -

You use sleep timer which does not use digital blocks, freeing you up to
use them for other functionality. You set the sleep timer to ~ 100 mS rate.
That takes care of button debounce. In the 100 mS sleep ISR you flip a flag,
indicating a 100 mS time period has occured, and in main(), using a counter,
count 10 of those to get your 1 S blink control.

It can be a little more complicated than this, eg. allocating VC1/2/3 clocks,
and all the other timing requirments you have. But you get the idea.

Regards, Dana.

[kalliskalyan]

Thanks dana
I am a beginner so the concepts you are telling .. i couldn't catch those . So is there a set of code examples with description for each user module describing all pros and cons like you are telling?... Such links would be more helpful. I shall also clarify with you if any doubt in those examples..

Thanks again

Regards,
Sundar

[danadak]

I don't have any good training links per se, but here is some stuff I have
acquired over the years -

If you added ISR driven code, a couple of rules of thumb -

1) Do not make f() calls from within ISR unless you cannot avoid it. That
is because compiler will do a ton of saves, like full stack, etc. to make sure
it can return fully and properly. That in turn slows machine down considerably.
Look at your listing file to see what the compiler does with your ISR code.

2) Best practice is simple, set a flag inside ISR and return to main() to process ISR.

3) Set up ISR to "fire" as infrequently as possible. If you only need ISR at a low rate,
don't "oversample" it, that would be just a waste of MIPS.

4) Look at coding. If you have multiple ISRs, is there any ISR that can essentially
negate the need to process another pending ISR, eg. compute not when not
needed. If you have an ISR that needs a lot of MIPs occasionally, you can always
skip another pending ISR if by doing so nothing terrible happens.

5) If list file shows compiler generating wacky stuff, consider ASM for the ISR
routine.

6) Turn off optimization when first debugging ISRs, then look at it again after
optimization turned back on, to make sure compiler did not "optimize" in some
crazy jump or other unnecessary code.

7) If display issues are affected, jitter, etc.., consider creating a display buffer in
RAM. And when a write is needed first check if RAM already displaying what you
want, if so do nothing, or update RAM and write to display if needed. This some-
times can cure ISR driven display update issues.

======================================================================================
To mimize code/FLASH wasted -

1 - If any float math minimize the number of lines you do divides, if possible convert
to multiplies. Convert float to integer math where possible. Pay attention to factoring
of expressions, possible operation reduction, hence code reduction may result.

2 - Lines with function calls, minimize f(g()) compound typed expressions.

3 - Make sure you only use a variable type no larger than needed.

4 - Use unsigned variables wherever possible.

5 - Watchout for structures with mixed const and ram pointers within them,
some compilers choke on this.

6 - If you are heavy on Flash, light on RAM use, convert routines to RAM based
wherever possible.

7 - Try test cases of looping structures, to see what affects code size generation.

8 - Examine .lst file for code that looks wacky in bytes used, understand what
compiler did, and consider rewrite.

9 - Use inline ASM where .lst file C generation looks excessive.

10 - Look at module reuse, sharing, dual purpose, to eliminate # modules
needed, like counters/timers....Also look at data sheets of modules that could
serve function needed, and compare ROM/RAM requirements needed. Optimize
global HW, like clocks VC1/2/3/Sleep, to eliminate need for other timer/counters.
Use register routing control to "share" module from one task to another, one pin
to another.

11 - Extended library, functions within them are written to be perfectly general,
hence larger code size, you may be able to write one with less code needed for
your specific requirements that result in smaller code size.

12 – Look for approximations to compute transcendental functions if used.

13 - Although no longer supported by HiTech or Cypress, the HiTech Pro compiler
yielded on first try ~ 40% code reduction in my design when I first converted
to it. Then the prior comments yielded another 4 K later in design as I was up
against 32 K Flash limitation.

14 - Some compilers have a setting to optimize code size or speed, the latter
prone to larger code size. Also look at compiler vendors web site for ap notes
and suggestions on optimization, compilers from different vendors behave and
optimize differently.

15 - const data, strings, etc.., look for ability to reuse common string mnemonics,
text.

16 - pointer usage can lessen code size, see url's below.

17 - Most compilers will optimize when indexes, pointers, a power of 2, or divides,
divide becomes a shift.

18 - Look at how linker distributed code and data segments, sometimes you can discover
a poor decision by linker and force code/data into certain psects using pragma constructs,
thereby minimizing wasted ROM space.

19 – When you debug generally you want to turn off optimization, as compiler/linker will
remove code and make jumps that do not make “sense” but are the result of optimization.
When you are up to Flash boundary you may not be able to turn it off, otherwise
application will not load. Keep this in mind, that your debug strategy may have to change.
I also found if using ICE Cube that debugger may no longer report “watch” variables, this
occurred at ~ 31.5K bytes. In either case you may want to comment out large code sections
to effectively debug.

20 – f() calls take overhead, if you only call a f() once you might eliminate it as a f() call and
place code inline.

21 – Look for f() opportunities, wherever you are coding and repeating similar operations.
This is obvious, but sometimes missed.

22 – Check compiler on macros, to see if they are being optimized or just being used inline
using more code space vs a f() call solution.

23 – Examine compiler/linker parameter control. For example in HiTech there is the AUTOBANK
setting that controls where local variables are stored, in my case setting to 1 lowered code size by
~ 250 bytes.

Some help -

http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization

http://www.eventhelix.com/realtimemantra/basics/optimizingcandcppcode.htm

http://www.azillionmonkeys.com/qed/optimize.html

By using these techniques I was able to regain ~ 4K Bytes of code space in a 32K design, which
I promptly then used up again


Regards, Dana.