Decoding rotaries using a PIC

[Guest LeoL]

> Why do you say that you have 3ms of pulse width?The Panasonic specs indicate this clearly on their diagram. It could be meant as a general rule perhaps using an avg turn rate. I don't have a scope to check this out myself. I wish I did, it would have helped in debugging this thing.> Anyway since you have 3 spare pins on portB (what you actually called PORTC), why don't you think at some config flags?The PIC16F676 doesn't have a "Port B" as per the specs sheets. This wasn't a typo on my part. They have a Port A and a Port C! Who knows, someone must have been asleep on the job that day at Microchip. :-lolActually if you look carefully at my schem, you'll notice that all the pins are used. There are 6 for outputs (3 up/down pairs) and 6 for inputs (3 rotary A-B pairs). I would have to give up one rotary to have configuration pins free. Not worth it IMO, it's just as easy to re-program the PIC with new code and have that extra rotary. This way the code stays small and readable.-Leo

[Guest]

>The PIC16F676 doesn't have a "Port B" as per the specs sheets.>This wasn't a typo on my part. They have a Port A and a Port>C! Who knows, someone must have been asleep on the job that>day at Microchip. :-lolSorry, didn't know the 676...:(

[tigert 0]

Yeah, duct tape holds everything together.. :-)/t

[Guest kdarling]

Leo,I believe the 3ms is the maximum bounce for the Panasonic EVE (which is really good).I haven't looked at the PIC specs yet, and I don't know how/what interrupts you're using/are available... but can't you just hook all the rotary B outputs together at the PIC? If first change was B transition == watch for which A changes to determine CCW switch. Or if first was A transition then look at commmon B (or just figure it was CW). That way, you can hook up five rotaries. This may be difficult to program; have to think about it.When I said that you should be able to send 100 chars/sec, I was reading into things perhaps. Low-speed USB = 10ms scan, yes? Does the driver send a polling signal to your PIC, is that how it works? If so, then my idea was that if you see the rotary spin fast, then "lie" and give back more pulses to the PC over the next X scans than there really were. Sort of a warped translation of Mike's method... since you can't actually send a x8 value, just send x8 pulses. The user would visually see things move fast and he would subconsciously slow down to compensate near his destination. Does that make sense?Best regards,KevinDarling

[Guest LeoL]

> I believe the 3ms is the maximum bounce for the Panasonic EVE (which is really good).No No No...why won't anybody believe me? :-hahTake a look for yourself:http://forums.avsim.com/user_files/2927.jpgHmmm, I see what you mean, but it would get really messy on the firmware side of things if it

[Guest kdarling]

Re: 3ms and 3.5ms. Right, if the max bounce per A/B side is <=3ms, then the total detent to detent time would have to be slightly greater than that to give a readable output. I believe that's what they're trying to say in the diagram.Re: B common. I wasn't thinking well before (baby on my lap ). Yes, make all B's common. Then wait for any A to go ON via interrupt or poll. This tells you which rotary it is. At that point simply check the common B. OFF=CW, ON=CCW. Dirt simple. Should work, as long as the user isn't an alien turning multiple rotaries at once. The point is, no one needs to turn more than one at a time. Getting 5 rotaries vs 3 is well worth that simple rule. Umm. Well okay if they were using rotaries for multiple throttles, I could see it, but...Re: USB poll. I was thinking that if a person spun the rotary quickly (you see X transitions within a single poll interval), then you queue up X or perhaps X/2 button pulses to send for the next X or X/2 polls. Or something along those lines. Kind of like a button repeat. The faster the spin, the more repeats. (If the user reverses the spin, of course, null the old repeat queue.)Kevin

[Guest LeoL]

Actually, I remembered 3ms instead of 3.5ms. I meant 3.5ms the whole time...ooops. I only looked at the spec once...my bad!As for "alien turning multiple rotaries at once", In my career I've seen people do the strangest things to software / systems. You don't need aliens to find holes in code and then complain loudly and sometimes rudely about it. I instinctively do not like leaving firmware holes like that. I guess it come from years of abuse at the hands of military clients, some of which were nitpickers of the extreme kind (to put it politely). I guess they had a right to be...they were spending our taxpayer dollars, right? :-)-Leo

[Guest kdarling]

* laughing *Yes, I do know what you mean. Currently I write code for the phone company. Before that, I spent 25 years writing drivers for embedded devices. So yes, I too usually lean towards writing software so that it cannot fail or be failed.However, people also complain about cost . Myself, I'd rather have the 5 rotaries to use with my radios, than just 3. I suppose there could be two versions? OTOH, I'd take the 3 if they could do the fast OBS trick.Thanks for all your time!Best,Kev

[Guest LeoL]

I would really like to accommodate you and develop the 5 rot version, but I just don't believe that it would offer any major cost advantage to someone wiring them up themselves.There's really no cost advantage to having 5 per PIC vs 3. You don't need to buy my $15 PCB version. You can easily and cleanly solder the IC and the rotaries onto an inexpensive protoboard. You can even wire up the PIC to your parallel port to program it using the precompiled HEX file I provided with no extra parts. All it takes is a little extra time and some patience. So for the price of 1 of mine you could build 3 yourself! Sheesh, some salesman I make!! :-rollAs for the "fast OBS" version, its now in my todo list, but until I have a full-speed USB device to test it on, there's just no point in my working on itPerhaps Mike Powell would be persuaded to share his "fast" version if asked nicely. ;)-Leo

[Guest]

My knowledge of analog electronics is still small.Since the pic produces a positive pulse out of portc, and FSBUS need to ground a pin in order to detect contact, i shall use a transistor, or at least i think so.Would a standard 2n2222 NPN do the work?the output pin of the pic connected to the gate, the two pins of the FSBUS connected to base and emitter?Or what else?Also:Leo the code you provide would compile for a 16f84?Or did you use some model-specific declarations or calls?Because at the moment my supplier don't have 676 and i would like to try your code with the 16f84 i have lying around.Thanks you very much

[Guest LeoL]

OK firstly, the outputs are active low...which means it should work with FSBUS as is and does the equivalent of grounding a pin. No need for any 2n2222's. If you need an active high output, just email me and I'll send you the modified code & HEX file. It

[Guest]

Suppose i find these mcus (i'm in italy, it's nonsense to buy from digikey or other us based reseller :( ) how do i program them?No soft i have seen (epic-win, icprog and my personal programmer's soft) do support these mcus.So how can i do?

[Guest LeoL]

Oooops sorry. Didn't realize your were in Rome.I can email you a Beta version of IC-Prog, which supports the 676, or you can use the current release and select the 12F675 from the list. I made a mistake in my previous post where I said you could use the 628 from the list, its the 12F675 you need to select...my bad.Next go to the Microchip website. Find and go to the 676 page and click on the "Get Samples" link. Follow instructions to register and place your order online for your samples.If you do manage to get some, go to my page for instructions to retrieve the stored calibration value on your PIC. You'll need this value for best performance.Hope this helps.-Leo

[Guest LeoL]

Microchip distributors in Italy:http://www.microchip.com/1010/contact/sale...italy/index.htmI hope you have some luck getting some.-Leo

[Guest]

>I can email you a Beta version of IC-Prog, which supports the>676, or you can use the current release and select the 12F675>from the list. I made a mistake in my previous post where I>said you could use the 628 from the list, its the 12F675 you>need to select...my bad.Tried various resellers including the big RS-Components: none has the 676 or the 630.I'm requesting the samples.Now about programming: i assume that reading it and knowing where to read i can take the osc calibration value.But how do i program it?What programmer do you suggest me to build?I already have one, but unfortunately it still doesn't support the 676 (although it should, because basicly all pics are the same... must see if using 12F675 it correctly reads/writes the osc calibration...).What do you use?And also, how did you know i'm in Rome? :(