Josh Koffman wrote: > On 2/7/06, Scott Dattalo wrote: > >>In other words, at the end of the macro, any set bits in W indicates >>that a change has occurred. So if you press and hold a key, you will >>see 4 iterations of the switch bit being zero, then 1 iteration of it >>being zero, and then N iterations back at 0. When you release the >>switch you'll see a similar thing. In both cases, the cva field matches >>the csa field after 4 consecutive samples of the two being different > > > Um...I'm guessing there's a typo here? Should be 1 iteration of it > being 1 instead of "1 iteration of it being zero", correct? Damn... Maybe I should avoid writing any comments! You're correct. > >>I'll go ahead and include it here (besides, maybe someone will ask how >>those assertions work). > > > Alright, I'll bite. How do assertions work? :) I'm guessing this is a > gpasm thing and I only use MPASM. Actually, the assertions are a gpsim thing. Both MPASM and gpasm can issue an assert directive (which is really just a macro for a .direct directive). The assertion gets placed into the .coff/.cod file. gpsim deciphers these directives and turns them into breakpoint assertions. A breakpoint assertion is a special gpsim execution breakpoint that has an expression associated with it. Normal execution breakpoints halt the simulation whenever they're encountered. Assertion breakpoints only halt the simulation when they're encountered AND they evaluate to false. You can think of them as conditional breakpoints. As you can imagine, these are useful for regression tests and code validation. Scott -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist