Serin usage?


+ Reply to Thread
Results 1 to 15 of 15

Thread: Serin usage?

  1. #1
    Join Date
    Nov 2006
    Posts
    32

    Default 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.

  2. #2
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by champion View Post
    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.

  3. #3
    Join Date
    Nov 2006
    Posts
    32

    Default

    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.

  4. #4
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by champion View Post
    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.

  5. #5
    Join Date
    Nov 2006
    Posts
    32

    Default

    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.

  6. #6
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,283

    Default

    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.

  7. #7
    Join Date
    Nov 2006
    Posts
    32

    Default

    Quote Originally Posted by HenrikOlsson View Post
    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!

  8. #8
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,283

    Default

    Hi,
    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.

  9. #9
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by champion View Post
    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....

  10. #10
    Join Date
    Nov 2006
    Posts
    32

    Default

    Quote Originally Posted by skimask View Post
    > 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.

  11. #11
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by champion View Post
    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.

  12. #12
    Join Date
    Nov 2006
    Posts
    32

    Thumbs down Skimask is the man!!!

    Quote Originally Posted by skimask View Post
    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!!!

  13. #13
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by champion View Post
    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).

  14. #14
    Join Date
    Aug 2006
    Location
    Look, behind you.
    Posts
    2,817

    Default

    Quote Originally Posted by skimask View Post
    Somebody's sarcasm detector is broken...
    You think so? Look again at his avatar!
    If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
    .
    Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
    .
    There simply is no "Happy Spam" If you do it you will disappear from this forum.

  15. #15
    skimask's Avatar
    skimask Guest

    Default

    Quote Originally Posted by Joe S. View Post
    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...

Similar Threads

  1. Accurate serin usage?
    By sccoupe in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 10th July 2009, 08:36
  2. PIC16f877 code crosses boundary @800h
    By inventosrl in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 6th April 2009, 22:03
  3. serin question?
    By sachymo in forum General
    Replies: 5
    Last Post: - 27th July 2008, 10:04
  4. Problem with PBP interrupt and Serin, please help
    By rgregor in forum mel PIC BASIC
    Replies: 0
    Last Post: - 22nd August 2006, 19:02
  5. SerIn and SerOut
    By Dwayne in forum FAQ - Frequently Asked Questions
    Replies: 0
    Last Post: - 21st July 2004, 15:54

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts