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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#10815 — Re: Communications under pressure (was Re: baud rate...)

In article <kafotg$2mn$1@dont-email.me>, fpm@u.washington.edu says...
> 
> On Thu, 13 Dec 2012 23:20:52 -0800, Mark Borgerson wrote:
> 
> [snip]
> 
> > Here's what one of our turbulence sensors looks like after about 6
> > months to a year on a mooring at the equator:
> > 
> > https://dl.dropbox.com/u/24841567/P3120108.JPG
> > 
> > The copper probe at the lower left has the fast-response thermistor that
> > is the primary sensor.
> 
> Fun!  It looks comparatively unslimed!
> 
> In my work biocompatibility is often important.  Seems like you need 
> materials that are somewhat bio-incompatible to retard these growths.  Do 
> you try for that?  Or is there too great a concern with adding toxic 
> substances to the environment?

In the past,  I've seen instrument housings painted with anti-fouling
paint.  The effectiveness of those paints on moorings diminished
when tin disappeared from the formulas.  Many of the new AF paints
rely on occasional bursts of water velocity, which sheds surface
growth as the paint ablades.  That doesn't work so well on moorings.

For the instrument shown, the growth away from the sensors 
isn't much of an issue.  The Delrin is generally ok for redeployment
after pressure washing.  The copper around the thermistors seems
to keep the thermistors working OK for up to a year.

The folks who make optical instruments that need a clear window
into the ocean have tried small wipers, copper covers, and a number
of other approaches to handling biofouling.  None are perfect,
to my knowledge, and there is still a lot of experimentation
going on.


Mark Borgerson

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

#10804 — serial host-to-device communication in amateur designs

>>>>> Robert Wessel <robertwessel2@yahoo.com> writes:

[...]

 > And frankly the use of RS-232/async ports should not be a first
 > choice these days.

	Given the intended application, I tend to agree -- the use of
	USB would probably simplify the things there a lot.

	Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
	perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem
	to fit well, for its CDC-ACM capability is necessarily a hack.)
	The best I've found so far are some STM32's for under $4.  I'd
	like to see if there could be anything else at half that price.

	(Though USB identifiers may become an issue.  They provide one
	allowing for relatively unrestricted use with V-USB, but I don't
	know what's the current practice for the MCU's with hardware USB
	ports.)

-- 
FSF associate member #7257

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

#10807 — Re: serial host-to-device communication in amateur designs

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

> >>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
> 
> [...]
> 
>  > And frankly the use of RS-232/async ports should not be a first
>  > choice these days.
> 
> 	Given the intended application, I tend to agree -- the use of
> 	USB would probably simplify the things there a lot.
> 
> 	Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
> 	perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem
> 	to fit well, for its CDC-ACM capability is necessarily a hack.)
> 	The best I've found so far are some STM32's for under $4.  I'd
> 	like to see if there could be anything else at half that price.
> 
> 	(Though USB identifiers may become an issue.  They provide one
> 	allowing for relatively unrestricted use with V-USB, but I don't
> 	know what's the current practice for the MCU's with hardware USB
> 	ports.)
> 
> -- 
> FSF associate member #7257


Half that price is easy, buy them at kilounit quantities.  Digikey's got
the LPC1342, 250p at $2.57, and 1000p at $1.95.  If you need fewer
pieces than that, then at the end of the day you're just not talking
about much money as compared to the other engineering costs.


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

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

#10812 — Re: serial host-to-device communication in amateur designs

On Fri, 14 Dec 2012 09:18:00 -0800, Rob Gaddi
<rgaddi@technologyhighland.invalid> wrote:

>On Fri, 14 Dec 2012 23:21:11 +0700
>Ivan Shmakov <oneingray@gmail.com> wrote:
>
>> >>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>> 
>> [...]
>> 
>>  > And frankly the use of RS-232/async ports should not be a first
>>  > choice these days.
>> 
>> 	Given the intended application, I tend to agree -- the use of
>> 	USB would probably simplify the things there a lot.
>> 
>> 	Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
>> 	perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem
>> 	to fit well, for its CDC-ACM capability is necessarily a hack.)
>> 	The best I've found so far are some STM32's for under $4.  I'd
>> 	like to see if there could be anything else at half that price.
>> 
>> 	(Though USB identifiers may become an issue.  They provide one
>> 	allowing for relatively unrestricted use with V-USB, but I don't
>> 	know what's the current practice for the MCU's with hardware USB
>> 	ports.)
>> 
>> -- 
>> FSF associate member #7257
>
>Half that price is easy, buy them at kilounit quantities.  Digikey's got
>the LPC1342, 250p at $2.57, and 1000p at $1.95.  If you need fewer
>pieces than that, then at the end of the day you're just not talking
>about much money as compared to the other engineering costs.

To Rob: The title of the thread includes the word "amateur,"
so probably not kilounit qty. More likely, it's more about
posting up a web page on some completed project or another.

To OP: For a cheap hobbyist one-off with USB connection I'll
probably just grab an MSP430 LaunchPad off the shelf if the
application idea fits. It's already got connectors for a
daughterboard, the cpu is socketed, comes with two cpus, a
32kHz xtal, two different colored LEDs, two different
pushbuttons, a USB cable, and uses RS232 between the target
and the host via USB. It is $4.30, good tools are available,
and most anyone can easily get one. You still write simple
rs232 drivers that way, as well.

Jon

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

#10830 — Re: serial host-to-device communication in amateur designs

>>>>> Jon Kirwan <jonk@infinitefactors.org> writes:
>>>>> On Fri, 14 Dec 2012 09:18:00 -0800, Rob Gaddi wrote:
>>>>> On Fri, 14 Dec 2012 23:21:11 +0700 Ivan Shmakov wrote:

[...]

 >>> Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
 >>> perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem to
 >>> fit well, for its CDC-ACM capability is necessarily a hack.)  The
 >>> best I've found so far are some STM32's for under $4.  I'd like to
 >>> see if there could be anything else at half that price.

 >> Half that price is easy, buy them at kilounit quantities.  Digikey's
 >> got the LPC1342, 250p at $2.57, and 1000p at $1.95.  If you need
 >> fewer pieces than that, then at the end of the day you're just not
 >> talking about much money as compared to the other engineering costs.

 > To Rob: The title of the thread includes the word "amateur," so
 > probably not kilounit qty.  More likely, it's more about posting up a
 > web page on some completed project or another.

	The point is that if I'd be able to get in touch with the fellow
	amateurs in my vicinity, then we'd probably "waste" a few dozens
	of chips together, in relatively short time.  1000 PCS of any
	given IC would most probably be beyond our demands.

 > To OP: For a cheap hobbyist one-off with USB connection I'll probably
 > just grab an MSP430 LaunchPad off the shelf if the application idea
 > fits.  It's already got connectors for a daughterboard, the cpu is
 > socketed, comes with two cpus,

	Somehow, I was unable to find out what exactly comes with this
	board?  But given the price, it indeed looks like a nice thing
	to have.

 > a 32kHz xtal, two different colored LEDs, two different pushbuttons,
 > a USB cable, and uses RS232 between the target and the host via USB.

	Does that mean CDC ACM?  Or that the board includes an USB to
	Serial (UART) converter (which is TUSB3410, I guess)?

 > It is $4.30, good tools are available, and most anyone can easily get
 > one.

	... But what surprises me is that while one can get this one for
	under $5, the TUSB3410 chip alone costs over $6.

 > You still write simple rs232 drivers that way, as well.

-- 
FSF associate member #7257

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

#10831 — Re: serial host-to-device communication in amateur designs

On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov
<oneingray@gmail.com> wrote:

>>>>>> Jon Kirwan <jonk@infinitefactors.org> writes:
>>>>>> On Fri, 14 Dec 2012 09:18:00 -0800, Rob Gaddi wrote:
>>>>>> On Fri, 14 Dec 2012 23:21:11 +0700 Ivan Shmakov wrote:
>
>[...]
>
> >>> Unfortunately, I'm yet to find a really cheap MCU (8-, 32-, or
> >>> perhaps even 16-bit) with an on-chip USB.  (V-USB doesn't seem to
> >>> fit well, for its CDC-ACM capability is necessarily a hack.)  The
> >>> best I've found so far are some STM32's for under $4.  I'd like to
> >>> see if there could be anything else at half that price.
>
> >> Half that price is easy, buy them at kilounit quantities.  Digikey's
> >> got the LPC1342, 250p at $2.57, and 1000p at $1.95.  If you need
> >> fewer pieces than that, then at the end of the day you're just not
> >> talking about much money as compared to the other engineering costs.
>
> > To Rob: The title of the thread includes the word "amateur," so
> > probably not kilounit qty.  More likely, it's more about posting up a
> > web page on some completed project or another.
>
>	The point is that if I'd be able to get in touch with the fellow
>	amateurs in my vicinity, then we'd probably "waste" a few dozens
>	of chips together, in relatively short time.  1000 PCS of any
>	given IC would most probably be beyond our demands.

yeah, that's about where my mind was at after reading what
you were saying. Rob is a sharp person, but I didn't think
Rob had noticed your context -- or, if he had, had discounted
it for other reasons when he wrote, "If you need fewer
pieces than that, then at the end of the day you're just not
talking about much money as compared to the other engineering
costs." It's spoken from a professional perspective, but one
that has long since fogotten their roots and/or hobbyist
perspectives.

> > To OP: For a cheap hobbyist one-off with USB connection I'll probably
> > just grab an MSP430 LaunchPad off the shelf if the application idea
> > fits.  It's already got connectors for a daughterboard, the cpu is
> > socketed, comes with two cpus,
>
>	Somehow, I was unable to find out what exactly comes with this
>	board?  But given the price, it indeed looks like a nice thing
>	to have.

You get:
•    Nice box
•    Paperwork
•    ½ m USB cable
•    Microcrystal MS3V-T1R tuning fork 32.768kHz crystal
•    MSP430G2231 cpu, DIP
•    MSP430G2211 cpu, DIP
•    LaunchPad board, which includes a USB to host section
and a developer section with socket for cpu, two pushbuttons
for user use (as well as reset), two leds, one green, one
red, jumpers for enabling and disabling features, a special
interface for using the board to program target boards as
well (6-pin EZ430 connector), a power connector for your use
to run the board, and of course a USB connector
•    four headers for daughter card extensions, 2 male-female
and 2 male-male

You can look for the documents, SLAU318 and the "Student
guide and Lab manual" for the LaunchPad (I don't know the
number for that one.)

There are two pins (dedicated if you want, or reusable for
any reason you want by pulling two jumpers) used for RxD and
TxD that talk with the USB section of the board. That section
then communicates with the host by setting up a HID virtual
COM port, automatically. Any serial port software can talk
with it.

> > a 32kHz xtal, two different colored LEDs, two different pushbuttons,
> > a USB cable, and uses RS232 between the target and the host via USB.
>
>	Does that mean CDC ACM?  Or that the board includes an USB to
>	Serial (UART) converter (which is TUSB3410, I guess)?

Not sure what CDC ACM means. I'm sorry. But yes, I think it
uses the TUSB3410 chip plus another dedicated MSP430 as well
to run it and communicate with your target processor.

> > It is $4.30, good tools are available, and most anyone can easily get
> > one.
>
>	... But what surprises me is that while one can get this one for
>	under $5, the TUSB3410 chip alone costs over $6.

Yeah. I know. And you can get completed AD9850 boards from
ebay for way less than you can buy an AD9850 chip, too.
Regardless, that's one reason this board is such a steal of a
deal. I've used it as the base of several successful projects
-- the first of which was snap onto a parallel-port printer
output of a device and to convert the output into a text file
on the PC, via the USB interface. Used both cpus for that
one, one to handle the parallel port interface comms and the
other to handle the rs-232 section, and using a versatile
protocol in between the two for synchronization and
buffering.

Jon

> > You still write simple rs232 drivers that way, as well.

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

#10833 — USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov
><oneingray@gmail.com> wrote:
>>
>>	Does that mean CDC ACM?  Or that the board includes an USB to
>>	Serial (UART) converter (which is TUSB3410, I guess)?
>
> Not sure what CDC ACM means. I'm sorry. But yes, I think it
> uses the TUSB3410 chip plus another dedicated MSP430 as well
> to run it and communicate with your target processor.
>

CDC ACM is the standards based way to implement a serial port over USB.

Many vendors (ie: FTDI and Prolific [PL-2303]) implement serial ports
over USB by using their own protocols which (a) require you to install a
driver on the host PC and (b) for which the specifications are not freely
available unless you sign a NDA.

However, the USB specifications include the Communications Device Class
(CDC) which has implemented within it the Abstract Control Model (ACM)
and which can be used to implement a serial port. It's main limitation
(for me) is that there's no way to signal CTS changes from the device
attached to the USB serial port back to the host PC.

The way Microchip (for example) appear to handle the problem in their
MCP2200 USB serial port is to implement the RTS/CTS handling on the
MCP2200 itself instead of passing the CTS signal back to the host PC.
They appear to have a out-of-band mechanism by which a host PC
configuration utility can turn on and off RTS/CTS flow control handling
on the MCP2200.

I also have implemented a CDC ACM driver within my own USB device stack
and when I add RTS/CTS flow control to it, I also plan to handle the
flow control on the USB device itself, so in practice, I don't see this
as been a major issue for at least some usage patterns.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

#10834 — Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Mon, 17 Dec 2012 00:53:21 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
>> On Sun, 16 Dec 2012 21:00:41 +0700, Ivan Shmakov
>><oneingray@gmail.com> wrote:
>>>
>>>	Does that mean CDC ACM?  Or that the board includes an USB to
>>>	Serial (UART) converter (which is TUSB3410, I guess)?
>>
>> Not sure what CDC ACM means. I'm sorry. But yes, I think it
>> uses the TUSB3410 chip plus another dedicated MSP430 as well
>> to run it and communicate with your target processor.
>>
>
>CDC ACM is the standards based way to implement a serial port over USB.
>
>Many vendors (ie: FTDI and Prolific [PL-2303]) implement serial ports
>over USB by using their own protocols which (a) require you to install a
>driver on the host PC and (b) for which the specifications are not freely
>available unless you sign a NDA.
>
>However, the USB specifications include the Communications Device Class
>(CDC) which has implemented within it the Abstract Control Model (ACM)
>and which can be used to implement a serial port. It's main limitation
>(for me) is that there's no way to signal CTS changes from the device
>attached to the USB serial port back to the host PC.
>
>The way Microchip (for example) appear to handle the problem in their
>MCP2200 USB serial port is to implement the RTS/CTS handling on the
>MCP2200 itself instead of passing the CTS signal back to the host PC.
>They appear to have a out-of-band mechanism by which a host PC
>configuration utility can turn on and off RTS/CTS flow control handling
>on the MCP2200.
>
>I also have implemented a CDC ACM driver within my own USB device stack
>and when I add RTS/CTS flow control to it, I also plan to handle the
>flow control on the USB device itself, so in practice, I don't see this
>as been a major issue for at least some usage patterns.

I think I may like to discuss this subject at more length,
sometime soon. I'm actually interested in the details (data
structures that must be used, what they are filled with, the
order of communications, etc.)

I'm currently fairly ignorant, excect from glancing through
the 1000 page USB 2.0 spec -- which to my reading does not do
any tutorials on the actual data structures that a slave
device must use, nor much detail on the Windows drivers (or
Linux, freeBSD, etc) side. I know there is code out there to
read, but I'd like to get an overview of subsets, one at a
time, to consider and then master before moving on. Mostly,
it seems an all-or-nothing approach in the USB 2.0 manual --
which makes taking the time quite daunting to start out. And
I consider Jan Axelrod's book almost useless, as well.

If you would consider the idea, perhaps in a few month's time
I may want to contact you. I'd be pretty dumb, to start,
except that I have 35 years embedded programming practice --
so this would mostly be about me reading and testing and then
asking questions when I get stuck on something. (Which, at
first, I expect to be often.  sadly.)

Or perhaps there is a great forum for someone focused on
mastering various details but starting out largely ignorant
of the terms and the domain space?

Jon

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

#10839 — Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
>
> I think I may like to discuss this subject at more length,
> sometime soon. I'm actually interested in the details (data
> structures that must be used, what they are filled with, the
> order of communications, etc.)
>

Assuming I have the time available when you want to discuss this,
I don't have a problem with this. However, I think the discussion
should be in comp.arch.embedded because it could benefit others
as well. Another advantage would be that any opinions or comments
I have would also be reviewable by others here.

> I'm currently fairly ignorant, excect from glancing through
> the 1000 page USB 2.0 spec -- which to my reading does not do
> any tutorials on the actual data structures that a slave
> device must use, nor much detail on the Windows drivers (or
> Linux, freeBSD, etc) side. I know there is code out there to
> read, but I'd like to get an overview of subsets, one at a
> time, to consider and then master before moving on. Mostly,
> it seems an all-or-nothing approach in the USB 2.0 manual --
> which makes taking the time quite daunting to start out. And
> I consider Jan Axelrod's book almost useless, as well.
>

Don't focus on the size of the USB 2.0 spec; you only have to read
a few chapters of it in order to implement a USB device stack as
the spec covers physical specifications as well as hub/host requirements.
You don't need to read much of that in order to implement a device only
stack.

I found I spent the vast majority of my time in Chapters 8 and 9 along
with some dipping into Chapter 5. However, I already knew much of what
is in Chapter 5 when I started, so you may spend more time there than
I did.

I also very strongly recommend you start out with a full speed device
instead of a high speed one. This means you can ignore the high speed
specific parts of the protocol until later.

Your jumping on point for following the USB protocol at data structure
level is the SETUP packet which your device will receive from the host
as part of any operation on the control endpoint (endpoint 0). This is
in table 9.2 of section 9.3. Look at this table while reading 8.5.3
(Control Transfers) which shows how this packet fits into the scheme of
things.

Higher level protocols (such as the CDC layer) have their own data
structures and are documented in their own specifications.

When you plug your USB device into the host, the USB device controller
will be reset. When you have enabled endpoint 0 and have come out of
reset, the next thing which will happen is that you will receive a
SETUP packet from the host on endpoint 0.

Your control endpoint logic is geared around interpreting these requests
and responding to them as required. One of these requests will be for the
device descriptor which, along with the configuration/interface/endpoint
descriptors, describes your device's capabilities.

I recommend you start out by making the device descriptor a vendor specific
descriptor (table 9.8, bDeviceClass = 0xff) so that the host does not
recognise it. In this way you don't have to worry about higher level
protocols throwing requests at your device stack (at least on Linux,
I don't know about Windows), but you will still go through the process
of been asked for your descriptors, been assigned a address by the host
and been told which configuration to use.

This will allow you to start out by developing and testing the lower
levels of the USB stack without having to worry about the higher level
function layers just yet.

Be warned however, that if you want to write a USB device stack, there will
be a lot of work involved in understanding the details. Given the multiple
layers to the protocol as well as it's scope, this cannot be avoided.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

#10843 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

Simon Clubley wrote:

> On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>
>> I think I may like to discuss this subject at more length,
>> sometime soon. I'm actually interested in the details (data
>> structures that must be used, what they are filled with, the
>> order of communications, etc.)
>>
> 
> Assuming I have the time available when you want to discuss this,
> I don't have a problem with this. However, I think the discussion
> should be in comp.arch.embedded because it could benefit others
> as well. Another advantage would be that any opinions or comments
> I have would also be reviewable by others here.

[ ... ]
Thanks for these tips.  I know USB is not hard because the guy working next 
to me did it, based on the implementation for PIC32.  Because he did it, I 
didn't have to.  Now on another project I have to.

	Mel.

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

#10845 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Monday, December 17, 2012 7:32:24 AM UTC-8, Mel Wilson wrote:
> Simon Clubley wrote:
> 
> 
> 
> > On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
> 
> >>
> 
> >> I think I may like to discuss this subject at more length,
> 
> >> sometime soon. I'm actually interested in the details (data
> 
> >> structures that must be used, what they are filled with, the
> 
> >> order of communications, etc.)
> 
> >>
> 
> > 
> 
> > Assuming I have the time available when you want to discuss this,
> 
> > I don't have a problem with this. However, I think the discussion
> 
> > should be in comp.arch.embedded because it could benefit others
> 
> > as well. Another advantage would be that any opinions or comments
> 
> > I have would also be reviewable by others here.
> 
> 
> 
> [ ... ]
> 
> Thanks for these tips.  I know USB is not hard because the guy working next 
> 
> to me did it, based on the implementation for PIC32.  Because he did it, I 
> 
> didn't have to.  Now on another project I have to.
> 

There are Atmel and LUFA USB stacks for AVR and Microchip stacks for PICs.  You don't have to write them, just use them.

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

#10847 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Mon, 17 Dec 2012 13:27:53 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2012-12-16, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>
>> I think I may like to discuss this subject at more length,
>> sometime soon. I'm actually interested in the details (data
>> structures that must be used, what they are filled with, the
>> order of communications, etc.)
>>
>
>Assuming I have the time available when you want to discuss this,
>I don't have a problem with this. However, I think the discussion
>should be in comp.arch.embedded because it could benefit others
>as well. Another advantage would be that any opinions or comments
>I have would also be reviewable by others here.
>
>> I'm currently fairly ignorant, excect from glancing through
>> the 1000 page USB 2.0 spec -- which to my reading does not do
>> any tutorials on the actual data structures that a slave
>> device must use, nor much detail on the Windows drivers (or
>> Linux, freeBSD, etc) side. I know there is code out there to
>> read, but I'd like to get an overview of subsets, one at a
>> time, to consider and then master before moving on. Mostly,
>> it seems an all-or-nothing approach in the USB 2.0 manual --
>> which makes taking the time quite daunting to start out. And
>> I consider Jan Axelrod's book almost useless, as well.
>>
>
>Don't focus on the size of the USB 2.0 spec; you only have to read
>a few chapters of it in order to implement a USB device stack as
>the spec covers physical specifications as well as hub/host requirements.
>You don't need to read much of that in order to implement a device only
>stack.
>
>I found I spent the vast majority of my time in Chapters 8 and 9 along
>with some dipping into Chapter 5. However, I already knew much of what
>is in Chapter 5 when I started, so you may spend more time there than
>I did.
>
>I also very strongly recommend you start out with a full speed device
>instead of a high speed one. This means you can ignore the high speed
>specific parts of the protocol until later.
>
>Your jumping on point for following the USB protocol at data structure
>level is the SETUP packet which your device will receive from the host
>as part of any operation on the control endpoint (endpoint 0). This is
>in table 9.2 of section 9.3. Look at this table while reading 8.5.3
>(Control Transfers) which shows how this packet fits into the scheme of
>things.
>
>Higher level protocols (such as the CDC layer) have their own data
>structures and are documented in their own specifications.
>
>When you plug your USB device into the host, the USB device controller
>will be reset. When you have enabled endpoint 0 and have come out of
>reset, the next thing which will happen is that you will receive a
>SETUP packet from the host on endpoint 0.
>
>Your control endpoint logic is geared around interpreting these requests
>and responding to them as required. One of these requests will be for the
>device descriptor which, along with the configuration/interface/endpoint
>descriptors, describes your device's capabilities.
>
>I recommend you start out by making the device descriptor a vendor specific
>descriptor (table 9.8, bDeviceClass = 0xff) so that the host does not
>recognise it. In this way you don't have to worry about higher level
>protocols throwing requests at your device stack (at least on Linux,
>I don't know about Windows), but you will still go through the process
>of been asked for your descriptors, been assigned a address by the host
>and been told which configuration to use.
>
>This will allow you to start out by developing and testing the lower
>levels of the USB stack without having to worry about the higher level
>function layers just yet.
>
>Be warned however, that if you want to write a USB device stack, there will
>be a lot of work involved in understanding the details. Given the multiple
>layers to the protocol as well as it's scope, this cannot be avoided.
>
>Simon.

Thanks, Simon. I agree with you about posting on here about
this subject when the time comes. I will air my ignorance and
take all the abuse, if any, with good nature. My interest is
to learn.

Yes, I'd like to actually do all of the detailed work
involved of writing everything. I'm not interested in just
using someone's library, except perhaps as another technical
reference "book" I can study along with the spec. There is
nothing quite as good at teaching all of the details. Once I
know them, I can then __intelligently__ make decisions about
what some minimal implementation can be for some application.
There are times when I may not be able to afford a "library"
and need to know if I can do with less. Just using a library
will never enable that kind of knowledge.

And thanks for the above writing, as well. That will give me
a leg up, as well.

Jon

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

#10848 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Mon, 17 Dec 2012 12:03:22 -0800, I wrote:

>Thanks, Simon. I agree with you about posting on here about
>this subject when the time comes. I will air my ignorance and
>take all the abuse, if any, with good nature. My interest is
>to learn.
>
>Yes, I'd like to actually do all of the detailed work
>involved of writing everything. I'm not interested in just
>using someone's library, except perhaps as another technical
>reference "book" I can study along with the spec. There is
>nothing quite as good at teaching all of the details. Once I
>know them, I can then __intelligently__ make decisions about
>what some minimal implementation can be for some application.
>There are times when I may not be able to afford a "library"
>and need to know if I can do with less. Just using a library
>will never enable that kind of knowledge.
>
>And thanks for the above writing, as well. That will give me
>a leg up, as well.

Oh, and although I know that some of this can be done using
HID drivers written already for linux or Microsoft's O/S, I
am also interested in the work involved on the host side. But
I'll start on the slave side. It is just that I may want to
write a host side implementation for embedded use, too. There
are those occasional times when that would be a "nice to
have" for hobby work so that I could attach keyboards, for
example.

Jon

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

#10852 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Mon, 17 Dec 2012 12:17:55 -0800
Jon Kirwan <jonk@infinitefactors.org> wrote:

> Oh, and although I know that some of this can be done using
> HID drivers written already for linux or Microsoft's O/S, I
> am also interested in the work involved on the host side. But
> I'll start on the slave side. It is just that I may want to
> write a host side implementation for embedded use, too. There
> are those occasional times when that would be a "nice to
> have" for hobby work so that I could attach keyboards, for
> example.

I definitely recommend NOT trying to solve both halves of the problem
(device side and host side) at the same time! Start out building a
device. Get it to enumerate and show up in lsusb (or the equivalent for
a different OS). Then start talking to it with user-space host-side
software via libusb. Then decide whether you want to move to
implementing a standard device class if it makes sense for your device,
write a kernel-mode OS driver, or just stick with libusb.

Chris

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

#10854 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Mon, 17 Dec 2012 23:36:48 -0800, Christopher Head
<chead@is.invalid> wrote:

>On Mon, 17 Dec 2012 12:17:55 -0800
>Jon Kirwan <jonk@infinitefactors.org> wrote:
>
>> Oh, and although I know that some of this can be done using
>> HID drivers written already for linux or Microsoft's O/S, I
>> am also interested in the work involved on the host side. But
>> I'll start on the slave side. It is just that I may want to
>> write a host side implementation for embedded use, too. There
>> are those occasional times when that would be a "nice to
>> have" for hobby work so that I could attach keyboards, for
>> example.
>
>I definitely recommend NOT trying to solve both halves of the problem
>(device side and host side) at the same time! Start out building a
>device. Get it to enumerate and show up in lsusb (or the equivalent for
>a different OS).

Yeah, I think I know that much, ignorant as I am otherwise
about USB.  ;)

>Then start talking to it with user-space host-side
>software via libusb.

Hmm.

>Then decide whether you want to move to
>implementing a standard device class if it makes sense for your device,
>write a kernel-mode OS driver, or just stick with libusb.
>
>Chris

Doesn't sound like where I'd like to be. I am thinking, say,
about hooking up a standard, cheap, PC keyboard to a ...
well, let's say an MSP430 with ... let's give it 16k flash
and 512 bytes sram total. Hmm. There are six different ones
with that spec. Three at $1 and three at $2.

Any chance? It is just a keyboard, after all.

Jon

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

#10856 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On 2012-12-18, Jon Kirwan <jonk@infinitefactors.org> wrote:
>
> Doesn't sound like where I'd like to be. I am thinking, say,
> about hooking up a standard, cheap, PC keyboard to a ...
> well, let's say an MSP430 with ... let's give it 16k flash
> and 512 bytes sram total. Hmm. There are six different ones
> with that spec. Three at $1 and three at $2.
>
> Any chance? It is just a keyboard, after all.
>

I have not done anything with the HID layer yet so I don't have a
feeling for what is involved there. However, Microchip have fitted
both a CDC layer and a HID layer (to control GPIO lines, not a
keyboard) into it's MCP2200 device. The MCP2200 is widely reported
to just be a PIC18F14K50 with custom Microchip firmware.

I don't know how the code density of the PIC18 compares with the MSP430
but that should give you a feeling for what is possible on the PIC18.

Note that this does not take into account the additional code needed to
poll the keyboard and also note the PIC18F14K50, when you add in the 256
bytes of USB RAM in bank 2, has 768 bytes of SRAM in total compared to
the 512 bytes you mention above for your MSP430 device.

Here is Microchip's PIC18F14K50 page so you can compare it to your
MSP430 device:

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en533924

I am not familiar with the MSP430 range. Is the USB device controller
in the MSP430 you are looking at a high speed, full speed or a low
speed controller ?

I see TI have a PDF writeup about creating a USB keyboard using a full
speed MSP430 device connected to a keyboard:

http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=slaa514&fileType=pdf

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

#10857 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Tuesday, December 18, 2012 8:54:00 PM UTC+13, Jon Kirwan wrote:
> 
> Doesn't sound like where I'd like to be. I am thinking, say,
> about hooking up a standard, cheap, PC keyboard to a ...
> well, let's say an MSP430 with ... let's give it 16k flash
> and 512 bytes sram total. Hmm. There are six different ones
> with that spec. Three at $1 and three at $2.
> 
> Any chance? It is just a keyboard, after all.

Hi Jon, 

Sure, just wiggle the lines for PS/2 mode, which you can hope is still there somewhere in the corner of the silicon ;)

Otherwise, you need a USB HOST capable uC, and they are still not 'bottom end' parts.

Cheapest mini host is OTG, and Digikey says PIC32 is lowest cost stocked version.
See also 
http://ww1.microchip.com/downloads/en/DeviceDoc/USB_OTG_ver_1.0.pdf

-jg

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

#10858 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Tue, 18 Dec 2012 14:04:30 -0800 (PST),
j.m.granville@gmail.com wrote:

>On Tuesday, December 18, 2012 8:54:00 PM UTC+13, Jon Kirwan wrote:
>> 
>> Doesn't sound like where I'd like to be. I am thinking, say,
>> about hooking up a standard, cheap, PC keyboard to a ...
>> well, let's say an MSP430 with ... let's give it 16k flash
>> and 512 bytes sram total. Hmm. There are six different ones
>> with that spec. Three at $1 and three at $2.
>> 
>> Any chance? It is just a keyboard, after all.
>
>Hi Jon, 
>
> Sure, just wiggle the lines for PS/2 mode, which you can
> hope is still there somewhere in the corner of the silicon
> ;)

Presume it is a new keyboard that doesn't support PS/2 mode.

>Otherwise, you need a USB HOST capable uC, and they are still not 'bottom end' parts.

But I think, if all I need is a stripped down host support
for a keyboard then perhaps I can fit it. The question is
about knowledge to know for sure.

>Cheapest mini host is OTG, and Digikey says PIC32 is lowest cost stocked version.
>See also 
>http://ww1.microchip.com/downloads/en/DeviceDoc/USB_OTG_ver_1.0.pdf

Nah. Not going there for just adding a keyboard. I'd find
another way for some of the cheap stuff I'm thinking about.

I'm interested in seeing if I can get to the point where I
can code up a keyboard-minimal version of USB hosting on a
small proc. May be impossible. But by the time I can say,
from personal knowledge, that it is impossible I will know a
lot more about USB. ;)

Jon

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

#10861 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On Tue, 18 Dec 2012 14:13:46 -0800
Jon Kirwan <jonk@infinitefactors.org> wrote:

> But I think, if all I need is a stripped down host support
> for a keyboard then perhaps I can fit it. The question is
> about knowledge to know for sure.

Code-wise, supporting just keyboards is certainly easier than supporting
a wider variety of devices, and if you use BOOTP, even easier than
supporting a full variety of *input* devices. BOOTP is a simplified
form of HID protocol intended for use by things like embedded systems
and BIOS configuration menus; keyboards (and I think mice) support it.
However, you will still need "full" host support at the hardware level.
This is a property of USB: the hardware for a host is somewhat
different to (and bigger than) the hardware for a device. It’s not
physically possible to take a chip that does device mode only and hack
around it to do any kind of host mode. I’m afraid I’m not familiar with
the MSP430 series, but I do know that the STM32F4 series does host
mode, as do some of the higher-end PICs (which jg mentioned). You sound
like you’re looking for something pretty low-end, though, and I agree
with jg, you’re unlikely to find such a chip.

You are right that my advice earlier about using libusb sounded
completely wrong. I thought you were trying to build a USB device, not
a USB host. They’re very different problems, so ignore my earlier
message!

Chris

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

#10863 — Re: Writing a USB device stack, was: Re: USB CDC ACM, was: Re: serial host-to-device communication in amateur designs

On 2012-12-19, Christopher Head <chead@is.invalid> wrote:
>
> You are right that my advice earlier about using libusb sounded
> completely wrong. I thought you were trying to build a USB device, not
> a USB host. They?re very different problems, so ignore my earlier
> message!
>

That's exactly what I thought as well and it's what my responses have
been assuming. When Jon then talked about adding a keyboard, I thought
he was planning to learn about USB by combining a PS/2 (or similar)
keyboard with a USB device capable MCU to create a USB based keyboard.
Now I don't know. :-)

Jon, are you planning to connect a PS/2 type keyboard to a MSP430 and
then create a USB keyboard for use with a host PC or are you wanting to
take a USB keyboard and connect it to a MSP430 with the final destination
target for the keystrokes been a program running on the MSP430 itself ?

If it's the former, you only need a MCU with USB device support and there
are plenty of those. If it's the latter, then as already mentioned you
are going to need to a MCU with USB host capability and the most hobbyist
or student friendly of those (if they are building their own circuits)
is probably the PIC32MX.

I do know there's a AVR based software-only USB stack but it is USB device
only and only supports low speed connectiosn to a host PC; it does not
have any host support.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

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

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

csiph-web