Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #10716 > unrolled thread

baud rate autodetection on AVR 8-bit?

Back to article view | Back to comp.arch.embedded

Contents

  baud rate autodetection on AVR 8-bit? Ivan Shmakov <oneingray@gmail.com> - 2012-12-07 21:17 +0700
    Re: baud rate autodetection on AVR 8-bit? Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-07 10:28 -0500
      Re: baud rate autodetection on AVR 8-bit? Ivan Shmakov <oneingray@gmail.com> - 2012-12-07 23:31 +0700
        Re: baud rate autodetection on AVR 8-bit? Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-07 12:42 -0500
          Re: baud rate autodetection on AVR 8-bit? mike <ham789@netzero.net> - 2012-12-07 13:35 -0800
            Re: baud rate autodetection on AVR 8-bit? Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-07 20:07 -0500
            Re: baud rate autodetection on AVR 8-bit? Mark Borgerson <mborgerson@comcast.net> - 2012-12-07 23:43 -0800
        Re: baud rate autodetection on AVR 8-bit? Tim Wescott <tim@seemywebsite.com> - 2012-12-07 13:07 -0600
        Re: baud rate autodetection on AVR 8-bit? Dave Nadler <drn@nadler.com> - 2012-12-07 12:09 -0800
          Re: baud rate autodetection on AVR 8-bit? Ivan Shmakov <oneingray@gmail.com> - 2012-12-08 03:47 +0700
            Re: baud rate autodetection on AVR 8-bit? MK <mk@nospam.co.uk> - 2012-12-08 09:44 +0000
              8-bit vs. 32-bit MCU's Ivan Shmakov <oneingray@gmail.com> - 2012-12-08 18:31 +0700
                Re: 8-bit vs. 32-bit MCU's MK <mk@nospam.co.uk> - 2012-12-09 14:13 +0000
                  Re: 8-bit vs. 32-bit MCU's Ivan Shmakov <oneingray@gmail.com> - 2012-12-09 22:52 +0700
      Re: baud rate autodetection on AVR 8-bit? upsidedown@downunder.com - 2012-12-08 15:01 +0200
    Re: baud rate autodetection on AVR 8-bit? Dombo <dombo@disposable.invalid> - 2012-12-08 15:18 +0100
    Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] Glenn <glenn2233@gmail.com> - 2012-12-09 10:47 +0100
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-12-09 10:22 +0000
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] "Bruce Varley" <bv@NoSpam.com> - 2012-12-09 19:07 +0800
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] Paul <paul@pcserviceselectronics.co.uk> - 2012-12-09 13:27 +0000
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232   ? ] Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-12-09 16:19 +0100
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] "TTman" <pcw1.cad@ntlworld.com> - 2012-12-09 15:38 +0000
        Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] amdyer@gmail.com - 2012-12-09 07:45 -0800
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] upsidedown@downunder.com - 2012-12-09 17:45 +0200
        Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] Paul <paul@pcserviceselectronics.co.uk> - 2012-12-09 21:30 +0000
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> - 2012-12-09 09:02 -0800
        Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] Lanarcam <lanarcam1@yahoo.fr> - 2012-12-09 18:13 +0100
          Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] upsidedown@downunder.com - 2012-12-09 19:44 +0200
          Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] Paul <paul@pcserviceselectronics.co.uk> - 2012-12-09 21:32 +0000
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] Robert Wessel <robertwessel2@yahoo.com> - 2012-12-10 00:35 -0600
      Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ] josephkk <joseph_barrett@sbcglobal.net> - 2012-12-12 20:30 -0800
    Re: baud rate autodetection on AVR 8-bit? "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> - 2012-12-10 13:38 +0100
      Re: baud rate autodetection on AVR 8-bit? Ivan Shmakov <oneingray@gmail.com> - 2012-12-10 20:19 +0700
        Re: baud rate autodetection on AVR 8-bit? "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> - 2012-12-10 16:24 +0100
          Re: baud rate autodetection on AVR 8-bit? Arlet Ottens <usenet+5@c-scape.nl> - 2012-12-10 16:49 +0100
          Re: baud rate autodetection on AVR 8-bit? Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-12 08:50 -0500
    Re: baud rate autodetection on AVR 8-bit? j.m.granville@gmail.com - 2012-12-11 21:22 -0800
      Re: baud rate autodetection on AVR 8-bit? Robert Wessel <robertwessel2@yahoo.com> - 2012-12-12 00:29 -0600
        Re: baud rate autodetection on AVR 8-bit? Mark Borgerson <mborgerson@comcast.net> - 2012-12-11 23:43 -0800
          Re: baud rate autodetection on AVR 8-bit? Robert Wessel <robertwessel2@yahoo.com> - 2012-12-12 02:38 -0600
            Re: baud rate autodetection on AVR 8-bit? Mark Borgerson <mborgerson@comcast.net> - 2012-12-12 07:46 -0800
              Re: baud rate autodetection on AVR 8-bit? linnix <me@linnix.info-for.us> - 2012-12-12 10:50 -0800
                Re: baud rate autodetection on AVR 8-bit? Jon Kirwan <jonk@infinitefactors.org> - 2012-12-12 12:42 -0800
                  Re: baud rate autodetection on AVR 8-bit? Jon Kirwan <jonk@infinitefactors.org> - 2012-12-12 12:56 -0800
                  Re: baud rate autodetection on AVR 8-bit? upsidedown@downunder.com - 2012-12-12 23:22 +0200
                    Re: baud rate autodetection on AVR 8-bit? Robert Wessel <robertwessel2@yahoo.com> - 2012-12-12 15:39 -0600
                      Re: baud rate autodetection on AVR 8-bit? Jon Kirwan <jonk@infinitefactors.org> - 2012-12-12 15:13 -0800
                        Re: baud rate autodetection on AVR 8-bit? Jon Kirwan <jonk@infinitefactors.org> - 2012-12-12 15:28 -0800
                        Re: baud rate autodetection on AVR 8-bit? Robert Wessel <robertwessel2@yahoo.com> - 2012-12-12 18:41 -0600
                          Re: baud rate autodetection on AVR 8-bit? Jon Kirwan <jonk@infinitefactors.org> - 2012-12-12 17:12 -0800
                Re: baud rate autodetection on AVR 8-bit? Mark Borgerson <mborgerson@comcast.net> - 2012-12-12 12:43 -0800
                  Communications under pressure (was Re: baud rate...) Frnak McKenney <frnak@far.from.the.madding.crowd.com> - 2012-12-13 10:25 -0600
                    Re: Communications under pressure (was Re: baud rate...) Robert Wessel <robertwessel2@yahoo.com> - 2012-12-13 12:34 -0600
                      Re: Communications under pressure (was Re: baud rate...) upsidedown@downunder.com - 2012-12-14 10:33 +0200
                        Re: Communications under pressure (was Re: baud rate...) Mark Borgerson <mborgerson@comcast.net> - 2012-12-14 07:43 -0800
                    Re: Communications under pressure (was Re: baud rate...) Mark Borgerson <mborgerson@comcast.net> - 2012-12-13 16:47 -0800
                      Re: Communications under pressure (was Re: baud rate...) Jon Kirwan <jonk@infinitefactors.org> - 2012-12-13 18:22 -0800
                        Re: Communications under pressure (was Re: baud rate...) Jon Kirwan <jonk@infinitefactors.org> - 2012-12-13 18:27 -0800
                        Re: Communications under pressure (was Re: baud rate...) Mark Borgerson <mborgerson@comcast.net> - 2012-12-13 23:20 -0800
                          Re: Communications under pressure (was Re: baud rate...) Frank Miles <fpm@u.washington.edu> - 2012-12-14 17:50 +0000
                            Re: Communications under pressure (was Re: baud rate...) Mark Borgerson <mborgerson@comcast.net> - 2012-12-14 14:28 -0800
            serial host-to-device communication in amateur designs Ivan Shmakov <oneingray@gmail.com> - 2012-12-14 23:21 +0700
              Re: serial host-to-device communication in amateur designs Rob Gaddi <rgaddi@technologyhighland.invalid> - 2012-12-14 09:18 -0800
                Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-14 11:19 -0800
                  Re: serial host-to-device communication in amateur designs Ivan Shmakov <oneingray@gmail.com> - 2012-12-16 21:00 +0700
                    Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-16 13:46 -0800
                      USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-17 00:53 +0000
                        Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-16 17:46 -0800
                          Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-17 13:27 +0000
                            Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Mel Wilson <mwilson@the-wire.com> - 2012-12-17 10:32 -0500
                              Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs me@linnix.info-for.us - 2012-12-17 11:13 -0800
                            Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-17 12:03 -0800
                              Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-17 12:17 -0800
                                Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Christopher Head <chead@is.invalid> - 2012-12-17 23:36 -0800
                                  Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-17 23:54 -0800
                                    Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-18 13:06 +0000
                                    Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs j.m.granville@gmail.com - 2012-12-18 14:04 -0800
                                      Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-18 14:13 -0800
                                        Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Christopher Head <chead@is.invalid> - 2012-12-19 02:37 -0800
                                          Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-19 12:59 +0000
                                            Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Rocky <RobertGush@gmail.com> - 2012-12-19 10:19 -0800
                                            Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-19 10:43 -0800
                                          Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-19 10:39 -0800
                                            Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-19 10:44 -0800
                                              Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Christopher Head <chead@is.invalid> - 2012-12-19 18:42 -0800
                                                Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-19 21:05 -0800
                                                  Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-20 14:13 +0000
                                                    Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-20 11:58 -0800
                                    Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2012-12-24 00:41 +0000
                                      Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2012-12-24 15:45 +0000
                                        Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-24 11:40 -0800
                      Re: serial host-to-device communication in amateur designs Frnak McKenney <frnak@far.from.the.madding.crowd.com> - 2012-12-20 10:00 -0600
                        Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-20 11:54 -0800
                          Re: serial host-to-device communication in amateur designs Rob Gaddi <rgaddi@technologyhighland.invalid> - 2012-12-20 12:01 -0800
                            Re: serial host-to-device communication in amateur designs Jon Kirwan <jonk@infinitefactors.org> - 2012-12-20 12:27 -0800
              Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-14 17:53 +0000
                Re: serial host-to-device communication in amateur designs Ivan Shmakov <oneingray@gmail.com> - 2012-12-15 01:26 +0700
                  Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-14 19:30 +0000
                    Re: serial host-to-device communication in amateur designs Ivan Shmakov <oneingray@gmail.com> - 2012-12-15 11:25 +0700
                      Re: serial host-to-device communication in amateur designs Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2012-12-17 00:29 +0000
                        Re: serial host-to-device communication in amateur designs me@linnix.info-for.us - 2012-12-17 11:05 -0800
                  Re: serial host-to-device communication in amateur designs Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-14 14:34 -0500
                  Re: serial host-to-device communication in amateur designs Paul <paul@pcserviceselectronics.co.uk> - 2012-12-14 23:25 +0000
                    finer pitches Ivan Shmakov <oneingray@gmail.com> - 2012-12-16 20:48 +0700
                Re: serial host-to-device communication in amateur designs Mark Borgerson <mborgerson@comcast.net> - 2012-12-14 21:26 -0800

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#10716 — baud rate autodetection on AVR 8-bit?

	BTW, is there an easy way to autodetect the baud rate while
	using an AVR UART?  (Preferably something that works with
	ATmega8, given that those MCU's are such a cheap thing
	nowadays.)

	There're some ideas (and 8051 code) for that on [1], but I'd
	like to know if there could be any better techniques.

	TIA.

[1] http://www.pjrc.com/tech/8051/autobaud.html

PS.  It seems that I'm slowly drifting into designing my own, AVR-based
	Bus Pirate clone.  The good news is that the parts for this one
	will likely cost under $10... (connectors included.)

-- 
FSF associate member #7257

[toc] | [next] | [standalone]

#10717

On Fri, 07 Dec 2012 21:17:16 +0700, Ivan Shmakov <oneingray@gmail.com>
wrote:

>	BTW, is there an easy way to autodetect the baud rate while
>	using an AVR UART?  (Preferably something that works with
>	ATmega8, given that those MCU's are such a cheap thing
>	nowadays.)
>
>	There're some ideas (and 8051 code) for that on [1], but I'd
>	like to know if there could be any better techniques.

It's pretty straightforward if you can use a timer capture pin; it takes
care of grabbing the timer count on the active edge and you can examine
it at leisure. Essentially, you will want to listen to an incoming
serial stream to measure the narrowest pulse and when you've seen enough
identical pulses, that determines the rate. If you get a narrower pulse
(that is wider than a glitch width), start the count over.

A little more robust is to add N to an accumulator when you see a pulse
within epsilon of the current narrow width, subtract M if there is a
wider pulse, or reset to zero and start over if there is a narrower.
When the accumulator reaches Q, you've found the pulse width. If it
counts down to zero (from too many wider pulses), assume you saw a
narrow noise pulse and start over. A divide-by-16 (>>4) works pretty
well for epsilon.

-- 
Rich Webb     Norfolk, VA

[toc] | [prev] | [next] | [standalone]

#10718

>>>>> Rich Webb <bbew.ar@mapson.nozirev.ten> writes:
>>>>> On Fri, 07 Dec 2012 21:17:16 +0700, Ivan Shmakov wrote:

 >> BTW, is there an easy way to autodetect the baud rate while using an
 >> AVR UART?  (Preferably something that works with ATmega8, given that
 >> those MCU's are such a cheap thing nowadays.)

 >> There're some ideas (and 8051 code) for that on [1], but I'd like to
 >> know if there could be any better techniques.

 > It's pretty straightforward if you can use a timer capture pin; it
 > takes care of grabbing the timer count on the active edge and you can
 > examine it at leisure.

	Well, I guess I can use a pin change interrupt instead, and just
	save the timer's counter in the handler.  (Thus introducing a
	constant delay, which will disappear anyway in the delta.)

 > Essentially, you will want to listen to an incoming serial stream to
 > measure the narrowest pulse and when you've seen enough identical
 > pulses, that determines the rate.

	Indeed, thanks!

 > If you get a narrower pulse (that is wider than a glitch width),
 > start the count over.

 > A little more robust is to add N to an accumulator when you see a
 > pulse within epsilon of the current narrow width, subtract M if there
 > is a wider pulse, or reset to zero and start over if there is a
 > narrower.  When the accumulator reaches Q, you've found the pulse
 > width.  If it counts down to zero (from too many wider pulses),
 > assume you saw a narrow noise pulse and start over.  A divide-by-16
 > (>> 4) works pretty well for epsilon.

	I guess I'd need to meditate over this one for some time.
	Thanks.

-- 
FSF associate member #7257

[toc] | [prev] | [next] | [standalone]

#10719

On Fri, 07 Dec 2012 23:31:21 +0700, Ivan Shmakov <oneingray@gmail.com>
wrote:

>>>>>> Rich Webb <bbew.ar@mapson.nozirev.ten> writes:
>>>>>> On Fri, 07 Dec 2012 21:17:16 +0700, Ivan Shmakov wrote:
>
> >> BTW, is there an easy way to autodetect the baud rate while using an
> >> AVR UART?  (Preferably something that works with ATmega8, given that
> >> those MCU's are such a cheap thing nowadays.)
>
> >> There're some ideas (and 8051 code) for that on [1], but I'd like to
> >> know if there could be any better techniques.
>
> > It's pretty straightforward if you can use a timer capture pin; it
> > takes care of grabbing the timer count on the active edge and you can
> > examine it at leisure.
>
>	Well, I guess I can use a pin change interrupt instead, and just
>	save the timer's counter in the handler.  (Thus introducing a
>	constant delay, which will disappear anyway in the delta.)
>
> > Essentially, you will want to listen to an incoming serial stream to
> > measure the narrowest pulse and when you've seen enough identical
> > pulses, that determines the rate.
>
>	Indeed, thanks!
>
> > If you get a narrower pulse (that is wider than a glitch width),
> > start the count over.
>
> > A little more robust is to add N to an accumulator when you see a
> > pulse within epsilon of the current narrow width, subtract M if there
> > is a wider pulse, or reset to zero and start over if there is a
> > narrower.  When the accumulator reaches Q, you've found the pulse
> > width.  If it counts down to zero (from too many wider pulses),
> > assume you saw a narrow noise pulse and start over.  A divide-by-16
> > (>> 4) works pretty well for epsilon.
>
>	I guess I'd need to meditate over this one for some time.
>	Thanks.

The problem is that if a rogue pulse is detected then you could end up
waiting forever for the confirming pulses. Say you expect baud rates
from 4800 to 115200, corresponding to pulses from 2400 to 100 ticks wide
(picking an artificial clock rate) and selected a minimum of 80 ticks
(where 80 or less is ignored as a glitch).

Say the actual baud rate was 4800 but before you sync'd to it a noise
pulse from, say, inserting the connector was detected that was 1200
ticks wide. You'd wait forever watching the 4800 baud pulses (2400 wide)
and never see another, so there has to be some mechanism to abandon the
current minimum and start the search anew.

One way to avoid the trap is to add, say, 10 to an accumulator for every
pulse matching the currently observed minimum and declaring a valid
minimum if, say, a count of 50 is reached. Deduct 1 from the accumulator
whenever a pulse wider than the current minimum is seen and start the
search over if the count ever gets back to zero (or if a narrower pulse
is detected, of course).

-- 
Rich Webb     Norfolk, VA

[toc] | [prev] | [next] | [standalone]

#10723

On 12/7/2012 9:42 AM, Rich Webb wrote:
> On Fri, 07 Dec 2012 23:31:21 +0700, Ivan Shmakov<oneingray@gmail.com>
> wrote:
>
>>>>>>> Rich Webb<bbew.ar@mapson.nozirev.ten>  writes:
>>>>>>> On Fri, 07 Dec 2012 21:17:16 +0700, Ivan Shmakov wrote:
>>
>>>> BTW, is there an easy way to autodetect the baud rate while using an
>>>> AVR UART?  (Preferably something that works with ATmega8, given that
>>>> those MCU's are such a cheap thing nowadays.)
>>
>>>> There're some ideas (and 8051 code) for that on [1], but I'd like to
>>>> know if there could be any better techniques.
>>
>>> It's pretty straightforward if you can use a timer capture pin; it
>>> takes care of grabbing the timer count on the active edge and you can
>>> examine it at leisure.
>>
>> 	Well, I guess I can use a pin change interrupt instead, and just
>> 	save the timer's counter in the handler.  (Thus introducing a
>> 	constant delay, which will disappear anyway in the delta.)
>>
>>> Essentially, you will want to listen to an incoming serial stream to
>>> measure the narrowest pulse and when you've seen enough identical
>>> pulses, that determines the rate.
>>
>> 	Indeed, thanks!
>>
>>> If you get a narrower pulse (that is wider than a glitch width),
>>> start the count over.
>>
>>> A little more robust is to add N to an accumulator when you see a
>>> pulse within epsilon of the current narrow width, subtract M if there
>>> is a wider pulse, or reset to zero and start over if there is a
>>> narrower.  When the accumulator reaches Q, you've found the pulse
>>> width.  If it counts down to zero (from too many wider pulses),
>>> assume you saw a narrow noise pulse and start over.  A divide-by-16
>>> (>>  4) works pretty well for epsilon.
>>
>> 	I guess I'd need to meditate over this one for some time.
>> 	Thanks.
>
> The problem is that if a rogue pulse is detected then you could end up
> waiting forever for the confirming pulses. Say you expect baud rates
> from 4800 to 115200, corresponding to pulses from 2400 to 100 ticks wide
> (picking an artificial clock rate) and selected a minimum of 80 ticks
> (where 80 or less is ignored as a glitch).
>
> Say the actual baud rate was 4800 but before you sync'd to it a noise
> pulse from, say, inserting the connector was detected that was 1200
> ticks wide. You'd wait forever watching the 4800 baud pulses (2400 wide)
> and never see another, so there has to be some mechanism to abandon the
> current minimum and start the search anew.
>
> One way to avoid the trap is to add, say, 10 to an accumulator for every
> pulse matching the currently observed minimum and declaring a valid
> minimum if, say, a count of 50 is reached. Deduct 1 from the accumulator
> whenever a pulse wider than the current minimum is seen and start the
> search over if the count ever gets back to zero (or if a narrower pulse
> is detected, of course).
>
I gave up several times on a similar project when I couldn't determine
the characteristics of the data stream...or even if there was one.

Been thinking about this for an hour or so.

If you take a random pulse width measurement.
Save that as mmpw, minimum measured pulse width.
Have a table of pulse widths for the allowable baud rates.
Scan up the table till you find a number match.
IF not, multiply the table by 2 then three then four...
Eventually you should find a match.
Program that into the USART.  Have the character input interrupt
start looking for framing errors.

Take another random pulse width measurement.
If it's smaller than mmpw, plug it into mmpw and restart.
If it's larger, subtract the two numbers.  The difference should
be an integral multiple of the REAL pulse width for the actual baud rate.
Divide the numbers.  If the remainder isn't zero, mmpw isn't the
correct bit time.  I think the correct bit time is an integer multiple
of the remainder, but I haven't got my head fully around that one.
Use those numbers to scan for a higher baud rate and an inferred new mmpw.
Quit when you get tired of looking for narrower mmpw or those that
aren't an integral multiple of the trial bit time and aren't
getting framing errors.

Of course, there are all kinds of issues with timing synchronization,
error bounds, glitches etc. that need to be dealt with.  And the
simplest way of thinking about it seems to result in a recursive
algorithm which isn't nice on a simple processor...so maybe the
details kill the concept...but it would be interesting to play with.

I like it because I think it converges even if you never catch an actual
one-bit-wide pulse.

[toc] | [prev] | [next] | [standalone]

#10725

On Fri, 07 Dec 2012 13:35:14 -0800, mike <ham789@netzero.net> wrote:

>On 12/7/2012 9:42 AM, Rich Webb wrote:
>> On Fri, 07 Dec 2012 23:31:21 +0700, Ivan Shmakov<oneingray@gmail.com>
>> wrote:
>>
>>>>>>>> Rich Webb<bbew.ar@mapson.nozirev.ten>  writes:
>>>>>>>> On Fri, 07 Dec 2012 21:17:16 +0700, Ivan Shmakov wrote:
>>>
>>>>> BTW, is there an easy way to autodetect the baud rate while using an
>>>>> AVR UART?  (Preferably something that works with ATmega8, given that
>>>>> those MCU's are such a cheap thing nowadays.)
>>>
>>>>> There're some ideas (and 8051 code) for that on [1], but I'd like to
>>>>> know if there could be any better techniques.
>>>
>>>> It's pretty straightforward if you can use a timer capture pin; it
>>>> takes care of grabbing the timer count on the active edge and you can
>>>> examine it at leisure.
>>>
>>> 	Well, I guess I can use a pin change interrupt instead, and just
>>> 	save the timer's counter in the handler.  (Thus introducing a
>>> 	constant delay, which will disappear anyway in the delta.)
>>>
>>>> Essentially, you will want to listen to an incoming serial stream to
>>>> measure the narrowest pulse and when you've seen enough identical
>>>> pulses, that determines the rate.
>>>
>>> 	Indeed, thanks!
>>>
>>>> If you get a narrower pulse (that is wider than a glitch width),
>>>> start the count over.
>>>
>>>> A little more robust is to add N to an accumulator when you see a
>>>> pulse within epsilon of the current narrow width, subtract M if there
>>>> is a wider pulse, or reset to zero and start over if there is a
>>>> narrower.  When the accumulator reaches Q, you've found the pulse
>>>> width.  If it counts down to zero (from too many wider pulses),
>>>> assume you saw a narrow noise pulse and start over.  A divide-by-16
>>>> (>>  4) works pretty well for epsilon.
>>>
>>> 	I guess I'd need to meditate over this one for some time.
>>> 	Thanks.
>>
>> The problem is that if a rogue pulse is detected then you could end up
>> waiting forever for the confirming pulses. Say you expect baud rates
>> from 4800 to 115200, corresponding to pulses from 2400 to 100 ticks wide
>> (picking an artificial clock rate) and selected a minimum of 80 ticks
>> (where 80 or less is ignored as a glitch).
>>
>> Say the actual baud rate was 4800 but before you sync'd to it a noise
>> pulse from, say, inserting the connector was detected that was 1200
>> ticks wide. You'd wait forever watching the 4800 baud pulses (2400 wide)
>> and never see another, so there has to be some mechanism to abandon the
>> current minimum and start the search anew.
>>
>> One way to avoid the trap is to add, say, 10 to an accumulator for every
>> pulse matching the currently observed minimum and declaring a valid
>> minimum if, say, a count of 50 is reached. Deduct 1 from the accumulator
>> whenever a pulse wider than the current minimum is seen and start the
>> search over if the count ever gets back to zero (or if a narrower pulse
>> is detected, of course).
>>
>I gave up several times on a similar project when I couldn't determine
>the characteristics of the data stream...or even if there was one.
>
>Been thinking about this for an hour or so.
>
>If you take a random pulse width measurement.
>Save that as mmpw, minimum measured pulse width.
>Have a table of pulse widths for the allowable baud rates.
>Scan up the table till you find a number match.
>IF not, multiply the table by 2 then three then four...
>Eventually you should find a match.
>Program that into the USART.  Have the character input interrupt
>start looking for framing errors.
>
>Take another random pulse width measurement.
>If it's smaller than mmpw, plug it into mmpw and restart.
>If it's larger, subtract the two numbers.  The difference should
>be an integral multiple of the REAL pulse width for the actual baud rate.
>Divide the numbers.  If the remainder isn't zero, mmpw isn't the
>correct bit time.  I think the correct bit time is an integer multiple
>of the remainder, but I haven't got my head fully around that one.
>Use those numbers to scan for a higher baud rate and an inferred new mmpw.
>Quit when you get tired of looking for narrower mmpw or those that
>aren't an integral multiple of the trial bit time and aren't
>getting framing errors.
>
>Of course, there are all kinds of issues with timing synchronization,
>error bounds, glitches etc. that need to be dealt with.  And the
>simplest way of thinking about it seems to result in a recursive
>algorithm which isn't nice on a simple processor...so maybe the
>details kill the concept...but it would be interesting to play with.
>
>I like it because I think it converges even if you never catch an actual
>one-bit-wide pulse.

For any given algorithm [*] it's probably possible to construct a data
stream that can fool it. I have found the "accumulator with decrement"
method to be reliable and simple [**] to sync with ASCII (NMEA 0183)
data that's always at 4800 baud except when it isn't. It certainly helps
that on common 8N1 lines, ASCII's 0 MSB precedes the 1 of the stop bit
and that is followed by a 0 for the next start bit.

It is a good idea to check the discovered pulse width against expected
values for legal (for the application) baud rates and then take
appropriate action if there isn't a match.

[*] The exception may be the "Hit the <some specific> key until the
terminal replies with OK" method. Even then it might be possible to find
bogus inputs that "work" at the wrong baud rate for some keys.

[**] Always a plus when coming back do maintenance on the code several
years later.

-- 
Rich Webb     Norfolk, VA

[toc] | [prev] | [next] | [standalone]

#10726

In article <k9tnfa$8pf$1@dont-email.me>, ham789@netzero.net says...
> 
> On 12/7/2012 9:42 AM, Rich Webb wrote:
> > On Fri, 07 Dec 2012 23:31:21 +0700, Ivan Shmakov<oneingray@gmail.com>
> > wrote:
> >
> >>>>>>> Rich Webb<bbew.ar@mapson.nozirev.ten>  writes:
> >>>>>>> On Fri, 07 Dec 2012 21:17:16 +0700, Ivan Shmakov wrote:
> >>
> >>>> BTW, is there an easy way to autodetect the baud rate while using an
> >>>> AVR UART?  (Preferably something that works with ATmega8, given that
> >>>> those MCU's are such a cheap thing nowadays.)
> >>
> >>>> There're some ideas (and 8051 code) for that on [1], but I'd like to
> >>>> know if there could be any better techniques.
> >>
> >>> It's pretty straightforward if you can use a timer capture pin; it
> >>> takes care of grabbing the timer count on the active edge and you can
> >>> examine it at leisure.
> >>
> >> 	Well, I guess I can use a pin change interrupt instead, and just
> >> 	save the timer's counter in the handler.  (Thus introducing a
> >> 	constant delay, which will disappear anyway in the delta.)
> >>
> >>> Essentially, you will want to listen to an incoming serial stream to
> >>> measure the narrowest pulse and when you've seen enough identical
> >>> pulses, that determines the rate.
> >>
> >> 	Indeed, thanks!
> >>
> >>> If you get a narrower pulse (that is wider than a glitch width),
> >>> start the count over.
> >>
> >>> A little more robust is to add N to an accumulator when you see a
> >>> pulse within epsilon of the current narrow width, subtract M if there
> >>> is a wider pulse, or reset to zero and start over if there is a
> >>> narrower.  When the accumulator reaches Q, you've found the pulse
> >>> width.  If it counts down to zero (from too many wider pulses),
> >>> assume you saw a narrow noise pulse and start over.  A divide-by-16
> >>> (>>  4) works pretty well for epsilon.
> >>
> >> 	I guess I'd need to meditate over this one for some time.
> >> 	Thanks.
> >
> > The problem is that if a rogue pulse is detected then you could end up
> > waiting forever for the confirming pulses. Say you expect baud rates
> > from 4800 to 115200, corresponding to pulses from 2400 to 100 ticks wide
> > (picking an artificial clock rate) and selected a minimum of 80 ticks
> > (where 80 or less is ignored as a glitch).
> >
> > Say the actual baud rate was 4800 but before you sync'd to it a noise
> > pulse from, say, inserting the connector was detected that was 1200
> > ticks wide. You'd wait forever watching the 4800 baud pulses (2400 wide)
> > and never see another, so there has to be some mechanism to abandon the
> > current minimum and start the search anew.
> >
> > One way to avoid the trap is to add, say, 10 to an accumulator for every
> > pulse matching the currently observed minimum and declaring a valid
> > minimum if, say, a count of 50 is reached. Deduct 1 from the accumulator
> > whenever a pulse wider than the current minimum is seen and start the
> > search over if the count ever gets back to zero (or if a narrower pulse
> > is detected, of course).
> >
> I gave up several times on a similar project when I couldn't determine
> the characteristics of the data stream...or even if there was one.
> 
> Been thinking about this for an hour or so.
> 
> If you take a random pulse width measurement.
> Save that as mmpw, minimum measured pulse width.
> Have a table of pulse widths for the allowable baud rates.
> Scan up the table till you find a number match.
> IF not, multiply the table by 2 then three then four...
> Eventually you should find a match.
> Program that into the USART.  Have the character input interrupt
> start looking for framing errors.
> 
> Take another random pulse width measurement.
> If it's smaller than mmpw, plug it into mmpw and restart.
> If it's larger, subtract the two numbers.  The difference should
> be an integral multiple of the REAL pulse width for the actual baud rate.
> Divide the numbers.  If the remainder isn't zero, mmpw isn't the
> correct bit time.  I think the correct bit time is an integer multiple
> of the remainder, but I haven't got my head fully around that one.
> Use those numbers to scan for a higher baud rate and an inferred new mmpw.
> Quit when you get tired of looking for narrower mmpw or those that
> aren't an integral multiple of the trial bit time and aren't
> getting framing errors.
> 
> Of course, there are all kinds of issues with timing synchronization,
> error bounds, glitches etc. that need to be dealt with.  And the
> simplest way of thinking about it seems to result in a recursive
> algorithm which isn't nice on a simple processor...so maybe the
> details kill the concept...but it would be interesting to play with.
> 
> I like it because I think it converges even if you never catch an actual
> one-bit-wide pulse.

If you've got lots of time and continuous input, you can  try the
timing approach, then try to verify your estimate by looking
for known patterns in the data.  If you can't find the pattern
(or correct checksum, etc.), start over.


If the data has known patterns,  and you can assume a 
limited set of standard baud rates, you can simply 
look for a known character stream in the data.  I once
used an instrument which would accept any standard baud
rate.  The manual said "when you power up the instrument,
press the space bar repeatedly until the instrument 
responds with the startup message.   The instrument
simply stepped through baud rates with each incoming
character until it found a space character.

You could apply the same approach, with a more complex
algorithm, to any source that provides a data stream
with known characteristics.

Mark Borgerson

[toc] | [prev] | [next] | [standalone]

#10720

On Fri, 07 Dec 2012 23:31:21 +0700, Ivan Shmakov wrote:

>>>>>> Rich Webb <bbew.ar@mapson.nozirev.ten> writes: On Fri, 07 Dec 2012
>>>>>> 21:17:16 +0700, Ivan Shmakov wrote:
> 
>  >> BTW, is there an easy way to autodetect the baud rate while using an
>  >> AVR UART?  (Preferably something that works with ATmega8, given that
>  >> those MCU's are such a cheap thing nowadays.)
> 
>  >> There're some ideas (and 8051 code) for that on [1], but I'd like to
>  >> know if there could be any better techniques.
> 
>  > It's pretty straightforward if you can use a timer capture pin; it
>  > takes care of grabbing the timer count on the active edge and you can
>  > examine it at leisure.
> 
> 	Well, I guess I can use a pin change interrupt instead, and just 
save
> 	the timer's counter in the handler.  (Thus introducing a constant
> 	delay, which will disappear anyway in the delta.)

The delay will only be constant if you have no higher priority interrupt 
active.  Depending on what you're trying to do this will range anywhere 
from completely painless to an absolute deal-killer.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[toc] | [prev] | [next] | [standalone]

#10721

On Friday, December 7, 2012 11:31:21 AM UTC-5, Ivan Shmakov wrote:
> 	Well, I guess I can use a pin change interrupt instead, and just
> 	save the timer's counter in the handler.  (Thus introducing a
> 	constant delay, which will disappear anyway in the delta.)

No "capture" function available on the timer,
so that you get an exact measurement ?
Sorry I don't remember on this part...

[toc] | [prev] | [next] | [standalone]

#10722

>>>>> Dave Nadler <drn@nadler.com> writes:
>>>>> On Friday, December 7, 2012 11:31:21 AM UTC-5, Ivan Shmakov wrote:

 >> Well, I guess I can use a pin change interrupt instead, and just
 >> save the timer's counter in the handler.  (Thus introducing a
 >> constant delay, which will disappear anyway in the delta.)

 > No "capture" function available on the timer, so that you get an
 > exact measurement?  Sorry I don't remember on this part...

	AIUI, ATmega8 only allows for input capture to happen on an
	"event" occuring either on analog comparator output, or a
	specific ICP1 pin.  Unfortunately, I'd need the latter for GPIO.
	(Naturally, ICP1 is distinct from UART's RxD.)

-- 
FSF associate member #7257

[toc] | [prev] | [next] | [standalone]

#10727

On 07/12/2012 20:47, Ivan Shmakov wrote:
>>>>>> Dave Nadler <drn@nadler.com> writes:
>>>>>> On Friday, December 7, 2012 11:31:21 AM UTC-5, Ivan Shmakov wrote:
>
>   >> Well, I guess I can use a pin change interrupt instead, and just
>   >> save the timer's counter in the handler.  (Thus introducing a
>   >> constant delay, which will disappear anyway in the delta.)
>
>   > No "capture" function available on the timer, so that you get an
>   > exact measurement?  Sorry I don't remember on this part...
>
> 	AIUI, ATmega8 only allows for input capture to happen on an
> 	"event" occuring either on analog comparator output, or a
> 	specific ICP1 pin.  Unfortunately, I'd need the latter for GPIO.
> 	(Naturally, ICP1 is distinct from UART's RxD.)
>
Since you are starting out on a new project why use an obsolete processor ?
You can buy an LPC1113 (or some one else's ARM Cortex M0) for less money 
than an ATmega8 and it has much better timers with input capture. It 
also has a good 10x the performance !

Michael Kellett

[toc] | [prev] | [next] | [standalone]

#10728 — 8-bit vs. 32-bit MCU's

>>>>> MK  <mk@nospam.co.uk> writes:
>>>>> On 07/12/2012 20:47, Ivan Shmakov wrote:

	(I vaguely recall that there already was a discussion on this.)

[...]

 >> AIUI, ATmega8 only allows for input capture to happen on an "event"
 >> occurring either on analog comparator output, or a specific ICP1
 >> pin.  Unfortunately, I'd need the latter for GPIO.  (Naturally, ICP1
 >> is distinct from UART's RxD.)

 > Since you are starting out on a new project why use an obsolete
 > processor?  You can buy an LPC1113 (or some one else's ARM Cortex M0)
 > for less money than an ATmega8 and it has much better timers with
 > input capture.

	Apart from lacking any experience whatsoever with ARM, I'm also
	somewhat concerned about the ARM's /generally/ being unavailable
	in TQFP, SO or DIP packages, which may be important should I'll
	be making a "kit" of the design I'm currently working on.

	Besides, where can I find an ARM for $0.9 (or less; including
	shipping)?  (For the quantity, I'd readily buy 10 or so.)

 > It also has a good 10x the performance!

	... And what about the power consumption?

-- 
FSF associate member #7257

[toc] | [prev] | [next] | [standalone]

#10735 — Re: 8-bit vs. 32-bit MCU's

On 08/12/2012 11:31, Ivan Shmakov wrote:
>>>>>> MK  <mk@nospam.co.uk> writes:
>>>>>> On 07/12/2012 20:47, Ivan Shmakov wrote:
>
> 	(I vaguely recall that there already was a discussion on this.)
>
> [...]
>
>   >> AIUI, ATmega8 only allows for input capture to happen on an "event"
>   >> occurring either on analog comparator output, or a specific ICP1
>   >> pin.  Unfortunately, I'd need the latter for GPIO.  (Naturally, ICP1
>   >> is distinct from UART's RxD.)
>
>   > Since you are starting out on a new project why use an obsolete
>   > processor?  You can buy an LPC1113 (or some one else's ARM Cortex M0)
>   > for less money than an ATmega8 and it has much better timers with
>   > input capture.
>
> 	Apart from lacking any experience whatsoever with ARM, I'm also
> 	somewhat concerned about the ARM's /generally/ being unavailable
> 	in TQFP, SO or DIP packages, which may be important should I'll
> 	be making a "kit" of the design I'm currently working on.
>
> 	Besides, where can I find an ARM for $0.9 (or less; including
> 	shipping)?  (For the quantity, I'd readily buy 10 or so.)
>
>   > It also has a good 10x the performance!
>
> 	... And what about the power consumption?
>

ARMs are easily available in TQFP packages and I rarely use anything else.
As for prices:
100 off Digikey,
LPC1113FBD48/302,1 = $2.05
ATMEGA8A-AU	= $1.79

You'll need to compare power consumption yourself but generally ARM M0s 
are pretty good and will easily beat the AVR in terms of useful 
calculations per watt.

If you'll relax your package demands and accept LPC1111FHN33/201,5 in 
QFN it'll only cost you $1.38 (Digikey 100 off).

I've hand soldered quite  a few of these and it's perfectly feasible 
(you may need  a microscope but I use one for TQFPs any way.)

Michael Kellett

[toc] | [prev] | [next] | [standalone]

#10740 — Re: 8-bit vs. 32-bit MCU's

>>>>> MK  <mk@nospam.co.uk> writes:
>>>>> On 08/12/2012 11:31, Ivan Shmakov wrote:
>>>>> MK  <mk@nospam.co.uk> writes:
>>>>> On 07/12/2012 20:47, Ivan Shmakov wrote:

	[Cross-posting to news:comp.sys.arm, at last.]

 >>>> AIUI, ATmega8 only allows for input capture to happen on an
 >>>> "event" occurring either on analog comparator output, or a
 >>>> specific ICP1 pin.  Unfortunately, I'd need the latter for GPIO.
 >>>> (Naturally, ICP1 is distinct from UART's RxD.)

 >>> Since you are starting out on a new project why use an obsolete
 >>> processor?  You can buy an LPC1113 (or some one else's ARM Cortex
 >>> M0) for less money than an ATmega8 and it has much better timers
 >>> with input capture.

 >> Apart from lacking any experience whatsoever with ARM, I'm also
 >> somewhat concerned about the ARM's /generally/ being unavailable in
 >> TQFP, SO or DIP packages, which may be important should I'll be
 >> making a "kit" of the design I'm currently working on.

 >> Besides, where can I find an ARM for $0.9 (or less; including
 >> shipping)?  (For the quantity, I'd readily buy 10 or so.)

 > ARMs are easily available in TQFP packages and I rarely use anything
 > else.  As for prices:

 > 100 off Digikey,
 > LPC1113FBD48/302,1 = $2.05
 > ATMEGA8A-AU	= $1.79

	Well, I was able to order 10 ATmega8's for $8.80 on eBay.
	(Hopefully, I'll get them within a week from now.)  Besides, it
	isn't quite "for less money than," as was stated above.

	Digi-Key doesn't seem like a sensible choice /for me/, either.
	FWIW, they're located on a whole different continent.

 >>> It also has a good 10x the performance!

 >> ... And what about the power consumption?

 > You'll need to compare power consumption yourself but generally ARM
 > M0s are pretty good and will easily beat the AVR in terms of useful
 > calculations per watt.

	ACK, thanks.

 > If you'll relax your package demands and accept LPC1111FHN33/201,5 in
 > QFN it'll only cost you $1.38 (Digikey 100 off).

 > I've hand soldered quite a few of these and it's perfectly feasible
 > (you may need a microscope but I use one for TQFPs any way.)

	The point is that should I ever end up designing my own kits,
	there'd be a whole world of hobbyists that won't be able to
	tackle anything with pitch finer than that of TQFP.  (Or perhaps
	even finer than SO; but there, ARM seem to be in an advantage,
	as some LPC111x seem to be available in SO just as well.)

-- 
FSF associate member #7257

[toc] | [prev] | [next] | [standalone]

#10729

On Fri, 07 Dec 2012 10:28:41 -0500, Rich Webb
<bbew.ar@mapson.nozirev.ten> wrote:

>On Fri, 07 Dec 2012 21:17:16 +0700, Ivan Shmakov <oneingray@gmail.com>
>wrote:
>
>>	BTW, is there an easy way to autodetect the baud rate while
>>	using an AVR UART?  (Preferably something that works with
>>	ATmega8, given that those MCU's are such a cheap thing
>>	nowadays.)
>>
>>	There're some ideas (and 8051 code) for that on [1], but I'd
>>	like to know if there could be any better techniques.
>
>It's pretty straightforward if you can use a timer capture pin; it takes
>care of grabbing the timer count on the active edge and you can examine
>it at leisure. Essentially, you will want to listen to an incoming
>serial stream to measure the narrowest pulse and when you've seen enough
>identical pulses, that determines the rate. If you get a narrower pulse
>(that is wider than a glitch width), start the count over.

When using capture pins or using simple bit banging, if there are
something known about the signal source, some heuristics can be used
to reduce the possible combinations.

In asynchronous communication, the line is in the "idle" state (Mark,
logical 1) 20 mA in current lop, -12 V in RS-232 and so on. The
"fail-safe" termination will pull the line to idle state in RS-485.
Each character starts by the start bit (Space, logical 0, 0 mA, +12
V..) ), following by a number (usually 5-14) of data bits, followed by
an optional parity bit, followed by 1, 1.5 or 2 stop bits (logical 1).

After the last stop bit, if there are no more characters to send, the
idle period (logical 1) starts. The line remains in the idle state for
an arbitrary time, unless there is more characters to send. While this
time can be absolutely anything, typical UARTs start transmitting at
some clocked intervals, typically 1/16 multiples of the bit clock
period.

If there is a lot of characters in to be transmitted, immediately
after the last stop bit ("1"), the start bit ("0") will be immediately
sent.

However, in quite a few situations, the line remains longer or shorter
periods in the idle "1" state, thus detecting the if´dle state will
help in detecting the start bit "0" after the idle period and hence
help figuring out the timing.

For instance, if the signal source is a keyboard operated by a human,
even with autorepeat and line speeds above 300 bits/s, there are quite
long idle periods between characters. 

Even with half duplex protocols (request/response) even with full
duplex capable hardware, there are some idle periods between master
requests and slave responses (especially Modbus requires a 3.5
character idle period between request and response).  If you are only
listening to master requests or only slave responses, there are quite
long idle periods between two requests or two responses.

Once you have identified the idle state, wait for the start bit
"1"->"0" transition. Most UARTs use some kind of false start bit
detection to see, if the line is still in the "0" state, by sampling
at the middle of start bit of use three 1/16 bit time samples and
majority voting.  Of course, this assumes that the bit rate is known.

Since the bit rate is not known, check for each possible half bit
length point for various possible standard bit rates, is the line
still in "0" state and continue validation. However, if you get a "1"
state at some of the sampling points, it can be assumed, that the
original falling edge was not a true start bit and discard it or that
the data rate is higher than you expected. Search for other
alternatives.

[toc] | [prev] | [next] | [standalone]

#10730

Op 07-Dec-12 15:17, Ivan Shmakov schreef:
> 	BTW, is there an easy way to autodetect the baud rate while
> 	using an AVR UART?  (Preferably something that works with
> 	ATmega8, given that those MCU's are such a cheap thing
> 	nowadays.)

You might find something useful in this article which uses a ATtiny2313:
http://spritesmods.com/?art=autobaud

[toc] | [prev] | [next] | [standalone]

#10731 — Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ]

On 07/12/12 15.17, Ivan Shmakov wrote:
> 	BTW, is there an easy way to autodetect the baud rate while
> 	using an AVR UART?  (Preferably something that works with
> 	ATmega8, given that those MCU's are such a cheap thing
> 	nowadays.)
>
> 	There're some ideas (and 8051 code) for that on [1], but I'd
> 	like to know if there could be any better techniques.
>
> 	TIA.
>
> [1] http://www.pjrc.com/tech/8051/autobaud.html
>
> PS.  It seems that I'm slowly drifting into designing my own, AVR-based
> 	Bus Pirate clone.  The good news is that the parts for this one
> 	will likely cost under $10... (connectors included.)
>

(Please respond to news://comp.arch.embedded )

Hi!

I am so "pissed" about RS-232/EIA-232.

After so many years with that "stupid vintage" serial communications 
protocol, we still do not have autonegotiation (and auto-baud-detection) 
built into the protocol definitions. Why not?

Why have nobody made a request-for-comment about that, then so many 
people do not have to bother with a myriad of out-of-bound signals and 
in-band signal (xon, xoff) manually.

It is simply incredibly, that after so many decades, you manually has to 
find out, how to get it to work.

Please be inspired to release open and free RFC-definitions now, so that 
"vintage" serial communication will work smoothly - and with backward 
compatibility and of cause with auto "null-modem" functionality.

I am looking forward to, that all out-of-bound signals can automatically 
be mapped by software by a series of signal pertubations and response 
measurements.

I know I am very demanding, but it ought to be possible? At least the 
software should detect and notify the user, that a null-modem cable 
connection is required. But it is a bad compromise.

The communications world (and its users) would be much happier with a 
full blown software solution.

Let us exterminate 232 jumper boxes. They are the ultimate time eating 
stupid solution, that shows we have given up finding a better solution:
http://www.amazon.com/DB25-Female-RS-232-Jumper-Assembly/dp/B000I996EE

Instead we should have a 232 autonegotiation-box/cable, that can be 
inserted between no-negotiation 232 equipped equipment.

;-)

Glenn

PS: I know that USB exists...

[toc] | [prev] | [next] | [standalone]

#10732 — Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ]

Glenn wrote:

> On 07/12/12 15.17, Ivan Shmakov wrote:

[%X]

> I am so "pissed" about RS-232/EIA-232.
> 
> After so many years with that "stupid vintage" serial communications
> protocol, we still do not have autonegotiation (and auto-baud-detection)
> built into the protocol definitions. Why not?
> 
> Why have nobody made a request-for-comment about that, then so many
> people do not have to bother with a myriad of out-of-bound signals and
> in-band signal (xon, xoff) manually.
> 
> It is simply incredibly, that after so many decades, you manually has to
> find out, how to get it to work.

Having dealt with the RS232 protocol for many years I am wondering why you 
are suddenly so vexed about it. The protocol precedes computing devices, 
having been created as a communication protocol for teleprinters (originally 
the 5 bit code before becoming the 7 bit and 8 bit codes we have today).  
Auto-negotiation takes intelligence at each end. As that was not available 
at that time we just accepted the need to get things set-up right before we 
started.
 
> Please be inspired to release open and free RFC-definitions now, so that
> "vintage" serial communication will work smoothly - and with backward
> compatibility and of cause with auto "null-modem" functionality.
> 
> I am looking forward to, that all out-of-bound signals can automatically
> be mapped by software by a series of signal pertubations and response
> measurements.

I am sure there is an official way to propose a new RFC if you need to. You 
could try and do that if you have some ideas that you would like to see 
implemented as standard. I am not sure you would get much support with such 
an old protocol though.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#10733 — Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ]

"Glenn" <glenn2233@gmail.com> wrote in message 
news:50c45e31$0$284$14726298@news.sunsite.dk...
> On 07/12/12 15.17, Ivan Shmakov wrote:
>> BTW, is there an easy way to autodetect the baud rate while
>> using an AVR UART?  (Preferably something that works with
>> ATmega8, given that those MCU's are such a cheap thing
>> nowadays.)
>>
>> There're some ideas (and 8051 code) for that on [1], but I'd
>> like to know if there could be any better techniques.
>>
>> TIA.
>>
>> [1] http://www.pjrc.com/tech/8051/autobaud.html
>>
>> PS.  It seems that I'm slowly drifting into designing my own, AVR-based
>> Bus Pirate clone.  The good news is that the parts for this one
>> will likely cost under $10... (connectors included.)
>>
>
> (Please respond to news://comp.arch.embedded )
>
> Hi!
>
> I am so "pissed" about RS-232/EIA-232.
>
> After so many years with that "stupid vintage" serial communications 
> protocol, we still do not have autonegotiation (and auto-baud-detection) 
> built into the protocol definitions. Why not?
>
> Why have nobody made a request-for-comment about that, then so many people 
> do not have to bother with a myriad of out-of-bound signals and in-band 
> signal (xon, xoff) manually.
>
> It is simply incredibly, that after so many decades, you manually has to 
> find out, how to get it to work.
>
> Please be inspired to release open and free RFC-definitions now, so that 
> "vintage" serial communication will work smoothly - and with backward 
> compatibility and of cause with auto "null-modem" functionality.
>
> I am looking forward to, that all out-of-bound signals can automatically 
> be mapped by software by a series of signal pertubations and response 
> measurements.
>
> I know I am very demanding, but it ought to be possible? At least the 
> software should detect and notify the user, that a null-modem cable 
> connection is required. But it is a bad compromise.
>
> The communications world (and its users) would be much happier with a full 
> blown software solution.
>
> Let us exterminate 232 jumper boxes. They are the ultimate time eating 
> stupid solution, that shows we have given up finding a better solution:
> http://www.amazon.com/DB25-Female-RS-232-Jumper-Assembly/dp/B000I996EE
>
> Instead we should have a 232 autonegotiation-box/cable, that can be 
> inserted between no-negotiation 232 equipped equipment.
>
> ;-)
>
> Glenn
>
> PS: I know that USB exists...

The problem isn't RS232, it's simply end points that don't talk the same 
language. You can have just as much grief with any other comunication 
protocol, for exactly the same reasons. In fact, IME some others can deliver 
heaps more grief in setting up than serial async/RS232.

It's a matter of standards, and in the case of RS232 specifically, there's a 
lot to like. The voltage levels are compatible, as long as you don't violate 
the specified cable specs (and even if you do by a reasonable margin) 
crosstalk won't cause errors, and drivers are specified against damage from 
wiring errors. Higher up the stack - not RS232 any more, which deals with 
electrical behaviour only - the ASCII character set is locked in, including 
various standard control sequences if you want to use them.

Higher up still the situation is less clear, but that's due to the facts 
that there are a huge multiplicity of client devices involved, with little 
or no unifying behaviour in many cases, and mutiple producers of equipment. 
If the devices at each end of the link come from the same supplier, then 
you're likely to find the setup plug-n-play. If they don't then the chances 
of mismatch are greater, and the problem isn't clearly owned by anyone 
except yourself. This lack of ownership is a large part of the problem, and 
it can only be solved by more encompassing standards. 

[toc] | [prev] | [next] | [standalone]

#10734 — Re: baud rate autodetection on AVR 8-bit? [ User friendly RS-232/EIA-232 ? ]

In article <50c45e31$0$284$14726298@news.sunsite.dk>, glenn2233
@gmail.com says...
> 
> On 07/12/12 15.17, Ivan Shmakov wrote:
> > 	BTW, is there an easy way to autodetect the baud rate while
> > 	using an AVR UART?  (Preferably something that works with
> > 	ATmega8, given that those MCU's are such a cheap thing
> > 	nowadays.)
> >
> > 	There're some ideas (and 8051 code) for that on [1], but I'd
> > 	like to know if there could be any better techniques.
> >
> > 	TIA.
> >
> > [1] http://www.pjrc.com/tech/8051/autobaud.html
> >
> > PS.  It seems that I'm slowly drifting into designing my own, AVR-based
> > 	Bus Pirate clone.  The good news is that the parts for this one
> > 	will likely cost under $10... (connectors included.)
> >
> 
> (Please respond to news://comp.arch.embedded )
> 
> Hi!
> 
> I am so "pissed" about RS-232/EIA-232.
> 
> After so many years with that "stupid vintage" serial communications 
> protocol, we still do not have autonegotiation (and auto-baud-detection) 
> built into the protocol definitions. Why not?

As others have said it is old, but first of lets consider some things

RS-232 is a voltage levels and cable spec, nothing to do with how many 
bits or how transmitted in its framing.

You can use RS232 quite vailidly for on/off control of lights as DC 
levels.

There is NO protocol in RS232

Your problem is poor implementations higher up the chain.

UART and other communications can be done many ways even without any 
form of RS-xxx level conversions.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web