Serin usage?

Printable View

- 16th January 2007, 21:19
champion

Serin usage?

Hi all!
I'm having some trouble/fun trying to communicate serially with a PIC16F627. I am using an optical (quadrature) encoder, with a quadrature decoder w/ a built in counter. The counter will count the up/down pulses, and hold them in a shift register where they can be read serially (in 22 bits). I want to be able to have the PIC read the serial data (as many bits as possible {8?}) and display it on an LCD. Should I be using the SERIN function? If so, how do I make sure that the bits that are read into the PIC start with the LSB of what the counter has in it's shift register? Also, I need a little help with selecting the baud rate. I have included a snippit of the code I am using as well as a brief explanation of how the counter's shift register works.

Code:

loop:

high plsr
low Plsr
low Cs
serin cntdata,4,total
pause 22
high cs
LCDout $FE, 1, "position", $FE, $C0, BIN total
Pause 1000

goto loop

Counter Shift Register Link:

http://www.genapta.com/WORD%20DOCS/A...nterfacing.pdf

Thanks a lot for all of your help, and any input would also be appreciated. As soon as this all works I have been working on a writeup that I will post on the forumn for all of those first time encoder users like me. :)
- 16th January 2007, 21:45
skimask

Quote:

Originally Posted by champion

Hi all!
I'm having some trouble/fun trying to communicate serially with a PIC16F627. I am using an optical (quadrature) encoder, with a quadrature decoder w/ a built in counter. The counter will count the up/down pulses, and hold them in a shift register where they can be read serially (in 22 bits). I want to be able to have the PIC read the serial data (as many bits as possible {8?}) and display it on an LCD. Should I be using the SERIN function? If so, how do I make sure that the bits that are read into the PIC start with the LSB of what the counter has in it's shift register? Also, I need a little help with selecting the baud rate. I have included a snippit of the code I am using as well as a brief explanation of how the counter's shift register works.

Thanks a lot for all of your help, and any input would also be appreciated. As soon as this all works I have been working on a writeup that I will post on the forumn for all of those first time encoder users like me. :)

Why even bother with the decoder/counter chip. The PIC has plenty of processing power to keep an eye on a few quad-encoders and do serial input/output at practically the same time. If I can do an mp3 player on a PIC16F877, with IR, hard drive, battery monitor, keypad monitor, LCD output, USB connection (thru an FTDI245AM), and a few other things, you can certainly count pulses from a few quad-encoders...

It's kinda like having english as your first language, but also knowing how to speak spanish, and then talking to a spanish-speaking person thru a spanish-english translator. It's like one extra middle-man (or middle chip in this case) that isn't really needed.
- 17th January 2007, 21:25
champion

I need an extremely high resolution. My encoder has 8192 pulses per revolution, however I need to be able to see a 1 minute change in angular position. This means that i need 360*60=21600 pulses per revolution. Thus with a quadrature decoder I can get 8192*4=32768 pulses per rev. Believe me, after all of this trouble, I would much rather do without the decoder, as I feel more comfortable with the PIC by itself.
- 17th January 2007, 22:53
skimask

Quote:

Originally Posted by champion

I need an extremely high resolution. My encoder has 8192 pulses per revolution, however I need to be able to see a 1 minute change in angular position. This means that i need 360*60=21600 pulses per revolution. Thus with a quadrature decoder I can get 8192*4=32768 pulses per rev. Believe me, after all of this trouble, I would much rather do without the decoder, as I feel more comfortable with the PIC by itself.

An 18F series PIC can run 40mhz, 10MFlops... you don't think that's fast enough to catch 21,600 pulses per rev?
If I can transfer 1MB/sec thru USB, do 2.5mbps on a serial line, mirror a hard drive with a custom interface at about 5MB/sec, you can surely read an encoder that fast.
- 18th January 2007, 14:36
champion

Skimask, we get it. You know what you're doing with a PIC, but it's not helping anyone to brag about what you can do or have done. This site is about helping people work out their issues with projects relating to the PIC and MELabs stuff. If you have a suggestion, please let me and the others know. But just bragging is a little lame. Also, my issue has to deal with the output of the encoder not generating enough ppr to have the kind of revolution that I need, thus requiring a quadrature decoder to increase the ppr of the encoder. I have no doubt that the PIC will be able to handle the pulses after that. The thing I can't figure out now is how to interface the decoder with the PIC from the PicBasic code side. Thanks for your help and I hope someone has an idea as to what I could try as far as the code to implement this contraption goes.
- 18th January 2007, 16:58
HenrikOlsson

Hi Champion,
That IC uses a synchronous serial interface so SERIN will not work. I think you need to have a look at the SHIFTIN command instead. I'm not sure if it can shift in all 22bits in one shot but perhaps it can. It can definetly read the lower 16bits in one go - perhaps that's enough for you.

Code:

Counter VAR WORD LOW CS 'Select chip HIGH PLSR 'Load counter to shift register 'Shift in 16bits of data. you may need to experiment with the mode number. Shiftin CNTdata, CLKsr, 3, [Counter\16] Low PLSR High CS 'Deselct chip. 'Display or whatever.

The datasheets indicates that the PLSR needs to be held high while reading the first bit so I guess it CAN be held high while reading the rest too since the shift register is loaded on the rising of PLSR going high. You'll have to experiment there.

Try to get it to read the lower 16bits first, then we can figure out a way to read all 22. I think that the tricky part will be what to to with the 22bits when you have them in the PIC.

/Henrik Olsson.
- 19th January 2007, 01:16
champion

Quote:

Originally Posted by HenrikOlsson

Try to get it to read the lower 16bits first, then we can figure out a way to read all 22. I think that the tricky part will be what to to with the 22bits when you have them in the PIC.

/Henrik Olsson.

Henrik,

I am wrong in thinking that I will just be able to convert however many bits I can get into a decimal? If it's over 8 bits I might have to do a little work with it but... I'm new, but I think it shouldn't be too bad. No? Thanks a lot for your help!
- 19th January 2007, 06:23
HenrikOlsson

Hi,

Quote:

I am wrong in thinking that I will just be able to convert however many bits I can get into a decimal? If it's over 8 bits I might have to do a little work with it but... I'm new, but I think it shouldn't be too bad. No? Thanks a lot for your help!

PBP performs math on variables up to 16bits wide (WORD). With more bits than that (22 for example) you will have to do a little work.

It all depends on your application. If you use the lower 16bits of the available 22 you won't loose any resolution but you are limited to 720 degrees on the encoder before the lower 16bits 'roll over'. If 720 degrees is enough - great! If not you will have to use all 22bits. I think it would be pretty easy to get all 22 bits into the PIC but then, again, it all depends on what it is you want to with them once they are there.

Remember that PBP does integer math only. You have 91.0222 encoder counts per degree but you can't simply do Degrees = Count / 91.0222. The result you'll get will be the integer partof the result only. There are way around this but the best aproach may vary depending on if you just want to display the encoder position in degrees or if you need to to more calculation on the result.

Hope it helps.

/Henrik Olsson.
- 21st January 2007, 08:20
skimask

Quote:

Originally Posted by champion

Skimask, we get it. You know what you're doing with a PIC, but it's not helping anyone to brag about what you can do or have done. This site is about helping people work out their issues with projects relating to the PIC and MELabs stuff. If you have a suggestion, please let me and the others know. But just bragging is a little lame. Also, my issue has to deal with the output of the encoder not generating enough ppr to have the kind of revolution that I need, thus requiring a quadrature decoder to increase the ppr of the encoder. I have no doubt that the PIC will be able to handle the pulses after that. The thing I can't figure out now is how to interface the decoder with the PIC from the PicBasic code side. Thanks for your help and I hope someone has an idea as to what I could try as far as the code to implement this contraption goes.

>Skimask, we get it.
We may get it, but you apparently haven't yet...
And I ain't braggin' 'bout squat... I haven't done anything miraculous or extraordinary or anything new and fantastic that anybody else has already done a dozen times. So...WAAAAAAAAAHHHHHHH!!!!

So, be that as it may, if you are having trouble with the decoder, get rid of it. IF you can make a PIC do the work of this optical encoder, and IF you can figure out how to transmit data between 2 PICs, then MAYBE, just MAYBE you could set up one PIC running at high speed doing nothing but reading the optical encoder and POSSIBLY send that data to another PIC to do work for you instead of a single PIC handling everything (which again, shouldn't be a problem in the first place). But with 2 PICs, you'd be splitting up the tasks into managable chunks.

And I'm out....
- 22nd January 2007, 03:33
champion

Quote:

Originally Posted by skimask

> if you are having trouble with the decoder, get rid of it. IF you can make a PIC do the work of this optical encoder

Um, what are you talking about? How should I measure angular position with the very high accuracy I need without an encoder? How am I gonna have the PIC do the work of the encoder? Youre lost.
- 22nd January 2007, 06:14
skimask

Quote:

Originally Posted by champion

Um, what are you talking about? How should I measure angular position with the very high accuracy I need without an encoder? How am I gonna have the PIC do the work of the encoder? Youre lost.

Yep, you're right, I am completely lost...After reading through the datasheet linked above and for teh 2122-5 itself, I found that what you're trying to do is physically impossible without a decoder/counter chip in between the PIC and the encoder. After all, who would've ever thought of using a couple of the interrupts and registers on a PIC to detect level changes on the outputs of an optical encoder. 'cause that would just be silly.

NOT! There are loads of 'google-able' references out there for directly connecting a quad-encoder to a PIC, with very high resolution/accuracy (which is obviously dependant upon the encoder itself), AND easily complete other tasks at the same time, all without missing pulses from multiple encoders...but I give up. Sometimes ya just can't tell a person anything.
- 23rd January 2007, 01:50
champion

Skimask is the man!!!

Quote:

Originally Posted by skimask

Yep, you're right, I am completely lost...After reading through the datasheet linked above and for teh 2122-5 itself, I found that what you're trying to do is physically impossible without a decoder/counter chip in between the PIC and the encoder. After all, who would've ever thought of using a couple of the interrupts and registers on a PIC to detect level changes on the outputs of an optical encoder. 'cause that would just be silly.

NOT! There are loads of 'google-able' references out there for directly connecting a quad-encoder to a PIC, with very high resolution/accuracy (which is obviously dependant upon the encoder itself), AND easily complete other tasks at the same time, all without missing pulses from multiple encoders...but I give up. Sometimes ya just can't tell a person anything.

Skimask, I don't think that you have read about my problem. I believe I said before that I need a resolution of at least 360*60=21600 pulses per revolution. Okay, try and find an encoder that has more than 8192 ppr for less than $100. You can't. Then I guess you could use a quadrature decoder along with the encoder to increase the resolution. There you have 8192*4=32768 ppr. That's enough resolution. So what is it that you think that is physically impossible? Didn't you read above that I was using a decoder? And why do you keep talking about missing pulses or any need for a higher frequency oscillator? I think you're probably a smart guy so that's why I must assume that you are simply not reading the entire thread carefully. Go back and read through all of the posts before you make any more comments. k?

PS. I now have the entire system up and running right now, so thanks for all of your help. You rock!!!
- 23rd January 2007, 06:58
skimask

Quote:

Originally Posted by champion

Skimask, I don't think that you have read about my problem. I believe I said before that I need a resolution of at least 360*60=21600 pulses per revolution. Okay, try and find an encoder that has more than 8192 ppr for less than $100. You can't. Then I guess you could use a quadrature decoder along with the encoder to increase the resolution. There you have 8192*4=32768 ppr. That's enough resolution. So what is it that you think that is physically impossible? Didn't you read above that I was using a decoder? And why do you keep talking about missing pulses or any need for a higher frequency oscillator? I think you're probably a smart guy so that's why I must assume that you are simply not reading the entire thread carefully. Go back and read through all of the posts before you make any more comments. k?

Somebody's sarcasm detector is broken...
I get it, got it, bought the movie...
1 minute of resolution - gear reduction works too, depending on the physical application of course
How do you increase the resolution from an encoder which only puts out X ppr?
Missing pulses? higher oscillator? what?
Read thru it -
You said you have an encoder All I said was that you could save some headache, not to mention PCB space, by using a PIC with some creative programming and still have loads of accuracy at high rpm, instead of relying on a dedicated decoder/counter/shift register and probably save a couple bucks on top of it. Not only that, but you never did say what the end product might be (crank trigger, star follower, gps guided egg cracker, etc).
- 23rd January 2007, 19:32
Archangel

Quote:

Originally Posted by skimask

Somebody's sarcasm detector is broken...

You think so? Look again at his avatar! :)
- 24th January 2007, 00:57
skimask

Quote:

Originally Posted by Joe S.

You think so? Look again at his avatar! :)

I saw that...
I'll give 10 points for originality on that...but...
subtract 100 points for not using a PIC where a PIC could be used...