I guess the harder part is due to the fact RBIF triggers on both edges, rather than a single edge. RBIF from what I understand is not configurable for the edge. Maybe I am looking at from a wrong angle. Have been looking at this for a long time continuously and everything starts to look very weird. I guess maybe time to get a bit of rest. Regards, Manu On Tue, Jun 11, 2013 at 4:33 AM, Christopher Head wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Remember if you do full-resolution decoding (i.e. a 16-entry lookup > table indexed by mapping to +1, 0, or -1), > then you don=92t need to waste any time doing debouncing because any > bounce will occur on only one channel at a time, causing the count to > jitter between values X and X+1 only (unless that is itself actually a > problem=97for my application, motor shaft rotation measurement, it isn=92= t). > So that can save resources. I agree that the RBIF is probably the way > to go to kick off the lookup process. > > Chris > > On Tue, 11 Jun 2013 03:48:46 +0530 > Manu Abraham wrote: > >> The whole idea of bitbanging, polling etc is useless in this context: >> I could've used a Timer and polled the encoder pins (only a single >> encoder is used), but then the system cannot be taxed to do >> additional polling, as I wrote originally, it is doing quite some >> other work too.. >> >> The point is to use a single encoder with an 18F4550 using the bare >> minimal resources (now, that I have freed up pins, so RB change >> interrupt is also possible), while the decoded results provide quite >> good results. It is as simple as that. The conceptt of adding >> separate chips and additional microcontrollers are pointless. In the >> old days, when computing power was very limited, it was acceptable to >> add chips for each and everything, but in the new world, most likely >> you can pack some of the features that you find in dedicated chips, >> directly into a micro, which has some free resources that can be used >> for an additional functionality. >> >> Yes, we can keep on adding hardware more and more, but that is not an >> effecient way of doing things. Isn't it ? >> >> >> Regards, >> Manu > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (GNU/Linux) > > iF4EAREIAAYFAlG2WysACgkQMcVpqLZH/3zySgD7B6D0U0uIvKztAaFPknpnVI1w > EgI0BsGe4OFkr+MfUPcA/iJO13a8X8PnWlYBfcKB4J2eocE2qYf8HT1ai5pWwcK/ > =3DIA1v > -----END PGP SIGNATURE----- > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .