>> Yes, you're right.  Nobody should ever be taught interrupts.  It must
> remain
>> a dark secret known only to a few high priced consultants.
> 
> In other words, if I apply myself, and follow the advice of those more
> knowledgeable, the skills are not entirely beyond reach?  I hope not.

ASCII does not convey the irony level very well, so I am not sure what 
Olin meant exactly. He might either agree with me or disagree completely :)

My standpoint (and experience) is that there are 10 kinds of 
programmers: those who understand concurrency and those who don't. In 
one of my first jobs there was a mixture of database and 
real-time/concurrent programming. Learning a 'concurrent' programmer 
SQL, foreign keys, normalisation, etc turned out to be easy. Learning a 
DB programming concurrency was almost impossible. Sample size was 
definitely > 2.

By understanding concurrent programming I don't mean passing an exam on 
the subject, I mean really being able to program concurrent programs, 
with mutual use of data, and using the smorgasbrod of exclusion and 
communication mechanisms. Having two parts of your program running 
concurrently is easy. It knowing when things should not run concurrently 
(and enforcing this) hat is the real trouble.

For using interrupts on PICs:

1. really understanding the PIC interrupt mechanism, and its 
consequences in combination with the spartan instruction set is not 
easy, but can of course be mastered. But it is a few steps beyond basic 
assembly programming. (my experience is old-style 14-bit cores. maybe 
16-bit cores and/or enhanced 14-bit cores are somewhat easier)

2. Once you have mastered the PIC-specifics there is still the general 
'hardness' of concurrent/interrupt-driver programming. How to divide 
between main and interrupt(2)? How to protect shared data?

This second point is not PIC-specific. It leads me to state that 
"concurrent program is only for those with a quite some experience in 
programming". Real-time concurrent programming with hard timing 
constraints is even worse. Don't try that until you really understand 
things like priority inversion, deadline-driven prioritizing, and timing 
analysis ;)

My personal taste is to avoid interrupts, and if I use interrupts it is 
only for some very small task, like buffering for the UART or 
timestamping events.

-- 

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist