Page 1 of 4 1 2 3 ... LastLast
Results 1 to 10 of 39

Thread: Solving Serin & Serout Problems with 20M2 and 20X2

  1. #1
    Senior Member
    Join Date
    Feb 2010
    Location
    Austin Texas (Area)
    Posts
    2,046

    Default Solving Serin & Serout Problems with 20M2 and 20X2

    Resolving Serin & Serout Errors on 20X2 and 20M2 Picaxe Chips


    This note only deals with the Picaxe 20X2 and 20M2. However other Picaxe chips may have similar issues and should be tested.

    In the process of working on a project that used both a 20X2 and a 20M2, I tried to send 2 bytes of serial data from the 20X2 to the 20M2 at 9600 baud using software serout and serin. No matter what I did not single byte could be received without error.

    Both Picaxe Chips were set to 8Mhz. The 20X2 used " serout C.0, N9600_8, ($55,$55)" and the 20M2 used "serin c.0, n9600_8, b0,b1". A qualifier was added as well as delays but to no avail. The baud was reduced to 4800 but still no good. Only at 2400 baud was data able to be sent & received.

    So I got out my newly acquired TEK THS730A digital scope and started testing. Here is what I found.

    20X2
    1. When set to 9600_8 the actual serout baud rate is 9158. This is a -4% error.
    2. When set to receive with serin 9600_8, data can be reliably received only between 9808 and 10570, meaning serin 9600_8 is set by firmware to receive at a center baud rate of 10189. This is an error of 6.1% from a nominal 9600.

    20M2
    1. When set to 9600_8 the actual serout baud rate is 9882. This is an error of +3.0%
    2. When set to receive with serin 9600_8, data can be reliably received only between 9624 and 10650, meaning serin 9600_8 is set by firmware to receive at a center baud rate of 10137. This is 6% error.

    The inaccuracy at these setting renders the serial comm of both of these chips pretty useless when set to 8Mhz and incompatible with almost any device that sends data at the prescribed standard of 9600 baud. There is no wonder these 2 chips could not communicate with both set to 9600_8 . They are both so far off specification, and in opposite directions that at 9600_8 it would be impossible. A second pair of 20M2s and 20X2s confirmed these findings.

    The Fix ? ... There is none....at least not at 9600_8 and other some other settings. Calibfreq has to be taken all the way to 31 on the 20x2 and to -15 on the M2 to get a single byte through. And at these settings sertxd fails with corrupted data to the PE terminal, not to mention the adverse affects on pulsout & pwm timings.

    The good news is that the serout error on the 20X2 is less than 1 percent at 9600_16 with an actual baud rate of 9557. The serin error on the 20M2 is less than 1 percent at 9600_16 with an actual center baud rate of 9690... Both really good for software (bit- banged serial). And at this setting for both chips, unlimited back to back bytes can be sent & received without error.

    By doing extensive testing on both chips severe accuracy problems were found at certain settings on each.At other settings the accuracy is good.

    To keep this from being too boring, attached is a chart of the of the actual baud rates of serout and serin in for all possible frequency / baud combinations of these two Picaxe Chips from 2400 to 38400 baud and from 4Mhz to 32Mhz.

    Solutions? ... All are work arounds .

    1. Refer to the attached tables and use frequency / baud combinations that have the least error or that are compatible even with the error.

    For example, a 20M2 can send and receive data to another 20M2 at 9600_8 because the error for both serin and serout is in the same direction. However, a 20X2 at 4800_4 cannot send data to a 20M2 at 4800_4 because the actual serout baud rate of the 20X2 is outside of the serin range of the 20M2.

    2. If you must use a certain baud rate at a certain frequency/ baud combination that shows the 4% error or 6.1% serin error ( 9600_8 is very common), use hardware hserout instead of "serout" . This would be particularly applicable for serout 9600_8 with the 20X2 at 8mhz. 9158 baud is so far out of specification that it will likely fail with most any other device, even another 20X2.

    What won't work.
    1. Using a qualifier if the serout baud rate is outside of the "range" of the serin rate. The qualifier cannot be recognized reliably.
    2. Adding a delay between bytes sent when serout is outside of the range of serin. Delays will not solve gross accuracy problems.

    It is a myth that serin cannot process back to back bytes fast enough at 8mhz and above. Pacing, was only an issue in my testing at 2400_4 where the processor overhead is the highest and when the space between bytes was less than 900us. This can be easily proven at 8 Mhz and above by sending 32 back to back bytes at a rate within the serin expected range, (without a qualifier) . It works fine.

    Attached are tables that show the actual baud rates for every serin / serout setting on the 20X2 & 202M2 chips from 2400 to 38400 baud. 64mhz was not tested on the 20X2.

    EDIT:
    The tables have shaded rows that indicate serial baud / processor frequency combinations that should be avoided.

    It should be noted that a 20M2 CAN communicate with another 20M2 at these high error settings because the error for both serin and serout is in the same direction.

    However a 20X2 cannot
    communicate with another 20X2 at these settings because the baud rate error for serin and serout is in opposite directions.
    Attached Files Attached Files
    Last edited by Goeytex; 31-01-2012 at 14:41.

  2. #2
    Senior Member
    Join Date
    May 2011
    Location
    Atlanta, GA
    Posts
    773
    Blog Entries
    24

    Default

    So I got out my newly acquired TEK THS730A digital scope...
    Valuable info- thanks for compiling. Bit envious of the Tek... my old 422 is still hanging on after 30 years... I think I will die before the Tek!

    - Ray

  3. #3
    Senior Member
    Join Date
    Feb 2011
    Location
    Cardiff,UK
    Posts
    3,208

    Default

    Good work.

    Those really are substantial variances from the standard baud rate, I dont understand why the delays used in the soft UART routines are not a lot more accurate than that.

    Some of the variance could be down to the errors in the RC internal oscillator, but still ............

  4. #4
    Senior Member
    Join Date
    Feb 2010
    Location
    Austin Texas (Area)
    Posts
    2,046

    Default

    Quote Originally Posted by srnet View Post
    Good work.

    "...I dont understand why the delays used in the soft UART routines are not a lot more accurate than that.

    Some of the variance could be down to the errors in the RC internal oscillator, but still ..."
    I don't understand why the accuracy shifts way off only at certain settings, especially the serin nominal center
    baud rate going in a different direction than serout on the 20X2. If it were an oscillator error you would think
    the shift would be in the same direction and that the error would be seen in other command like pulsout or pwm.

    At 8mhz Serout 9600_8 goes to 9158 ...while Serin 9600_8 goes a nominal 10189 with 9608 being the lowest possible baud rate
    that it can work with. This has to be firmware related.

    All of these settings that show the huge error in accuracy parse the same baud_rate value to the compiler.
    That is a 7 where baud value = (Nxxxx_x) and a 3 where baud value = (Txxxx_x).
    Last edited by Goeytex; 26-01-2012 at 08:33.

  5. #5
    Senior Member
    Join Date
    Feb 2011
    Location
    Cardiff,UK
    Posts
    3,208

    Default

    Quote Originally Posted by Goeytex View Post
    I don't understand why the accuracy shifts way off only at certain settings, especially the serin nominal center
    baud rate going in a different direction than serout on the 20X2
    Well some of it could be explained by there being a couple or more bits of assembler routine working as standard delays.

    You call the routine once for 38400_32, 4 times for 19200_16 etc. If the base delay routine is way out, then you could expect this way outness to occur at particular baud and frequency combinations.

    I recall from other threads that Technical were preparing an explanation, did I miss it ?

  6. #6
    Senior Member
    Join Date
    Feb 2010
    Location
    Austin Texas (Area)
    Posts
    2,046

    Default

    Quote Originally Posted by srnet View Post
    Well some of it could be explained by there being a couple or more bits of assembler routine working as standard delays.

    You call the routine once for 38400_32, 4 times for 19200_16 etc. If the base delay routine is way out, then you could expect this way outness to occur at particular baud and frequency combinations.
    How does that fit with the fact that on the 20M2 both serin and serout error shift in the same direction with the "bad settings" while on the 20X2 the serin / serout error shifts in opposite directions with the "bad settings"?

    I recall from other threads that Technical were preparing an explanation, did I miss it ?
    Still waiting.

  7. #7
    Senior Member
    Join Date
    Feb 2011
    Location
    Cardiff,UK
    Posts
    3,208

    Default

    Quote Originally Posted by Goeytex View Post
    Still waiting.
    We are, still.

  8. #8
    Moderator
    Join Date
    Mar 2008
    Location
    Western Australia
    Posts
    10,964

    Default

    Asking questions and prompting for answers in the Finished Projects section would, I think, have a lower probability of being seen and/or a response.
    westaust55

    Hey Hamlet, 2B OR NOT 2B = $FF

  9. #9
    Senior Member
    Join Date
    Feb 2010
    Location
    Austin Texas (Area)
    Posts
    2,046

    Default

    Asking questions and prompting for answers in the Finished Projects section would, I think, have a lower probability of being seen and/or a response.

    The questions are mostly rhetorical and official answers from Rev-Ed are not really expected as Rev-Ed does
    not seem willing/ready to address these serial inaccuracy problems at this point.
    Last edited by Goeytex; 04-02-2012 at 10:06.

  10. #10
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    19,574

    Default

    Quote Originally Posted by Goeytex View Post
    The questions are mostly rhetorical and official answers from Rev-Ed are not really expected as Rev-Ed does not seem willing/ready to address these serial inaccuracy problems at this point.
    It's not really fair to suggest Rev-Ed are unwilling to address any issue or are ignoring this one. As Technical has said elsewhere there will be more information given but the matter needs to be investigated, analysed and assessed, plus a response has to be formulated.

    All that takes time and has to be fitted in with other things that Rev-Ed and their staff are doing; as always schedules, priorities and resource allocation come into play. "Are we there yet?", won't get anything produced any sooner.

Bookmarks

Posting Permissions

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