Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MCUs with USB device in PDIP and a open source toolchain ?

41 views
Skip to first unread message

Simon Clubley

unread,
Jan 27, 2012, 5:33:41 AM1/27/12
to
I'm trying to find out what MCUs have a USB device capability and are
available in PDIP with a open source toolchain. Up until now, I've either
used various serial interfaces on AVRs, or preassembled ARM boards, but
now I need to build some small circuits with USB device built in.

This is what I currently know about:

HC08 (The JB8 is far too limited for my needs)
PIC18F (Lousy, lousy architecture)
PIC24F ([USB OTG] Better architecture, but gcc/binutils port not in mainline)
PIC32MX ([USB OTG] A interesting discovery, but I know nothing about MIPS yet)

I've also looked at the AVR, ARM and MSP430 MCUs but didn't find anything
in PDIP with USB device.

(I also looked for USB to SPI ICs in PDIP but I would strongly prefer the
USB capability to be in the MCU itself.)

Are there any options I've missed ?

[As I only need USB device, and I know nothing about the PIC32MX yet, (and
have no development infrastructure setup to use it yet) it's looking like
the PIC18F is the one I am probably going to have to use.]

Thanks,

Simon.

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

John Devereux

unread,
Jan 27, 2012, 5:59:20 AM1/27/12
to
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> I'm trying to find out what MCUs have a USB device capability and are
> available in PDIP with a open source toolchain. Up until now, I've either
> used various serial interfaces on AVRs, or preassembled ARM boards, but
> now I need to build some small circuits with USB device built in.
>
> This is what I currently know about:
>
> HC08 (The JB8 is far too limited for my needs)
> PIC18F (Lousy, lousy architecture)
> PIC24F ([USB OTG] Better architecture, but gcc/binutils port not in mainline)
> PIC32MX ([USB OTG] A interesting discovery, but I know nothing about MIPS yet)
>
> I've also looked at the AVR, ARM and MSP430 MCUs but didn't find anything
> in PDIP with USB device.
>
> (I also looked for USB to SPI ICs in PDIP but I would strongly prefer the
> USB capability to be in the MCU itself.)
>
> Are there any options I've missed ?
>
> [As I only need USB device, and I know nothing about the PIC32MX yet, (and
> have no development infrastructure setup to use it yet) it's looking like
> the PIC18F is the one I am probably going to have to use.]

Hi Simon,

The DIP requirement is a HUGE restriction, eliminating 99.99% of the
parts out there, and a lot of interesting new chips. If it is for your
own use perhaps reconsider the SMT parts, they are perfectly amenable to
manual assembly and a range of DIP adapters are available for various
packages if you really need that.


--

John Devereux

Rocky

unread,
Jan 27, 2012, 6:34:43 AM1/27/12
to
On Jan 27, 12:33 pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> I'm trying to find out what MCUs have a USB device capability and are
> available in PDIP with a open source toolchain. Up until now, I've either
> used various serial interfaces on AVRs, or preassembled ARM boards, but
> now I need to build some small circuits with USB device built in.
>
> This is what I currently know about:
>
> HC08    (The JB8 is far too limited for my needs)
> PIC18F  (Lousy, lousy architecture)
> PIC24F  ([USB OTG] Better architecture, but gcc/binutils port not in mainline)
> PIC32MX ([USB OTG] A interesting discovery, but I know nothing about MIPS yet)
>
> I've also looked at the AVR, ARM and MSP430 MCUs but didn't find anything
> in PDIP with USB device.
>
> (I also looked for USB to SPI ICs in PDIP but I would strongly prefer the
> USB capability to be in the MCU itself.)
>
> Are there any options I've missed ?
>
> [As I only need USB device, and I know nothing about the PIC32MX yet, (and
> have no development infrastructure setup to use it yet) it's looking like
> the PIC18F is the one I am probably going to have to use.]
The PIC32MX has sample code (that actually worked for me!) for
implementing USB. Admittedly that was for a starter kit. I have built
projects for the PIC32 using my own board and one more-or-less doesn't
need to know much about the MIPS architecture.

Simon Clubley

unread,
Jan 27, 2012, 7:28:42 AM1/27/12
to
On 2012-01-27, John Devereux <jo...@devereux.me.uk> wrote:
>
> Hi Simon,
>
> The DIP requirement is a HUGE restriction, eliminating 99.99% of the
> parts out there, and a lot of interesting new chips. If it is for your
> own use perhaps reconsider the SMT parts, they are perfectly amenable to
> manual assembly and a range of DIP adapters are available for various
> packages if you really need that.
>
Hello,

Yes, it's for my own hobbyist use.

Unlike the software side of things, (where I am quite capable of, for
example, writing yet another BSP or device driver on demand as and when
needed), when it comes to hardware, I still prefer to work in PDIP for
my own circuits.

Some of that is not wanting PCB chemicals around at home or wanting to
have to wait for PCBs to be made up. Some of that is that it's so easy
to prototype when using PDIP sized through-hole parts.

I do like the idea of using DIP adapters though, especially if they were
reasonably priced. It would allow me to work with non-PDIP parts while
continuing to work in a otherwise PDIP sized world.

WP

unread,
Jan 27, 2012, 7:39:18 AM1/27/12
to
On 27 Sty, 11:33, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> I'm trying to find out what MCUs have a USB device capability and are
> available in PDIP with a open source toolchain. Up until now, I've either
> used various serial interfaces on AVRs, or preassembled ARM boards, but
> now I need to build some small circuits with USB device built in.
>
> I've also looked at the AVR, ARM and MSP430 MCUs but didn't find anything
> in PDIP with USB device.
>
> Are there any options I've missed ?

There is a software USB device for AVR ATMega: http://www.obdev.at/products/vusb/index.html

I tried it and it worked.

WP

Simon Clubley

unread,
Jan 27, 2012, 7:50:44 AM1/27/12
to
On 2012-01-27, Rocky <rober...@gmail.com> wrote:
> The PIC32MX has sample code (that actually worked for me!) for
> implementing USB. Admittedly that was for a starter kit. I have built
> projects for the PIC32 using my own board and one more-or-less doesn't
> need to know much about the MIPS architecture.

Sample code from a manufacturer which works. What a unusual concept. :-)

One of the things about me is that I like to have a firm understanding
of any architecture/device I use, which means among other things writing
my own driver/BSP/etc code when possible.

Also, writing that code is something I enjoy doing and it's also a
learning opportunity as well. In a work environment, you couldn't
justify doing that if the code already existed in some vaguely useful
form, but in a hobbyist environment, you can.

Unfortunately this little project is something I want to complete as
soon as possible so it looks like it's going to be the practical option
(PIC18F) instead of the nice new device option (PIC32MX).

Thanks for the information though; it's something to keep in mind.

Simon Clubley

unread,
Jan 27, 2012, 8:14:01 AM1/27/12
to
I had forgotten about that software USB stack.

Unfortunately, for this application I would prefer a hardware based
USB device as I will be running code which has real time requirements
and I don't want to get into having to evaluate how this stack would
affect the real time capability of other code running on the AVR.

I would also need to assess what general overheads this implementation
would incur.

Thanks for the pointer however; I appreciate you having suggested it.

sbattazzo

unread,
Jan 27, 2012, 9:03:35 AM1/27/12
to
You could also use an FTDI-chip UM245R module, which is only about $20
for a piece, and comes in a sort of wide DIP module size. I think there
may even be some vendors which sell cheaper rip-offs of this.

The beauty of this is that on the host PC side, it just looks like a
virtual COM port, so you don't have to write any special drivers. And,
the baud rate is effectively meaningless in this case, it simply goes up
to 12Mbit per second (or maybe slightly less). Then if you have any MCU
with an 8-bit parallel IO bus plus a few control pins, you can move data
in and out a whole byte at a time. The end result is that it's nice and
fast, probably much faster than the software USB stack in the AVR, and
faster than using the PIC USB API as a CDC-ACM device.

John Devereux

unread,
Jan 27, 2012, 9:28:54 AM1/27/12
to
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2012-01-27, John Devereux <jo...@devereux.me.uk> wrote:
>>
>> Hi Simon,
>>
>> The DIP requirement is a HUGE restriction, eliminating 99.99% of the
>> parts out there, and a lot of interesting new chips. If it is for your
>> own use perhaps reconsider the SMT parts, they are perfectly amenable to
>> manual assembly and a range of DIP adapters are available for various
>> packages if you really need that.
>>
> Hello,
>
> Yes, it's for my own hobbyist use.
>
> Unlike the software side of things, (where I am quite capable of, for
> example, writing yet another BSP or device driver on demand as and when
> needed), when it comes to hardware, I still prefer to work in PDIP for
> my own circuits.
>
> Some of that is not wanting PCB chemicals around at home or wanting to
> have to wait for PCBs to be made up. Some of that is that it's so easy
> to prototype when using PDIP sized through-hole parts.
>
> I do like the idea of using DIP adapters though, especially if they were
> reasonably priced. It would allow me to work with non-PDIP parts while
> continuing to work in a otherwise PDIP sized world.

The other way is I think there may be some of the very low cost
development boards in a DIP form factor. Some of them are not much more
than a USB socket and the chip. Sorry don't have any specific
recommendations.

But really a DIP adapter is the way to go, somewhere like sparkfun might
have something.

--

John Devereux

Bob

unread,
Jan 27, 2012, 10:32:30 AM1/27/12
to
I hear that NXP have one DIP package ARM CPU (LPC1114) in development status, but not USB. DIPs are pretty thin on the ground in this segment, and even less with USB.

I am in a similar boat, I try to avoid getting too deep into hardware maufacturing, so I sympathise with the PDIP problem, but PDIP adaptors are things you can buy cheaply off ebay or order yourself fairly easily. Soldering them is another thing, I find my standard 0.1 techniques don't work so well!

I am currently looking at designing some 0.1 friendly CPU modules, similar to the Opendous LPC1343 design http://code.google.com/p/micropendousx/wiki/Older_Designs. I have ordered some boards from BatchPCB. Atmel, NXP, and STM all have cheap ARMs which are easily available, I'd like to get designs for each of them, in a 40 pin DIP package, and also maybe an SMT module. Although, the STM discovery board is so cheap it would be hard to beat the price.

Mark Borgerson

unread,
Jan 27, 2012, 10:54:38 AM1/27/12
to
In article <jfu59p$2jk$1...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...
>
> On 2012-01-27, John Devereux <jo...@devereux.me.uk> wrote:
> >
> > Hi Simon,
> >
> > The DIP requirement is a HUGE restriction, eliminating 99.99% of the
> > parts out there, and a lot of interesting new chips. If it is for your
> > own use perhaps reconsider the SMT parts, they are perfectly amenable to
> > manual assembly and a range of DIP adapters are available for various
> > packages if you really need that.
> >
> Hello,
>
> Yes, it's for my own hobbyist use.
>
> Unlike the software side of things, (where I am quite capable of, for
> example, writing yet another BSP or device driver on demand as and when
> needed), when it comes to hardware, I still prefer to work in PDIP for
> my own circuits.
>
> Some of that is not wanting PCB chemicals around at home or wanting to
> have to wait for PCBs to be made up. Some of that is that it's so easy
> to prototype when using PDIP sized through-hole parts.
>
> I do like the idea of using DIP adapters though, especially if they were
> reasonably priced. It would allow me to work with non-PDIP parts while
> continuing to work in a otherwise PDIP sized world.
>
The task of putting a modern microcontroller on a board with DIP-spaced
pins has already been done for you. Look at the various development
boards at www.sparkfun.com.

For example:

http://www.sparkfun.com/products/9564

Mark Borgerson



hamilton

unread,
Jan 27, 2012, 11:02:24 AM1/27/12
to
http://leaflabs.com/devices/#Maple-Mini

Works well.

And free software too !

Stef

unread,
Jan 27, 2012, 10:58:22 AM1/27/12
to
In comp.arch.embedded,
Bob <bobcou...@googlemail.com> wrote:
> I hear that NXP have one DIP package ARM CPU (LPC1114) in development status, but not USB. DIPs are pretty thin on the ground in this segment, and even less with USB.

Why are there suddenly a lot of posts on usenet (not only Bob's) with very
long lines? Is there some google groups usenet client that no longer breaks
long lines? In some posts I now have to scroll hundreds of chard to the
right to be able to read it all.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Paul Revere was a tattle-tale.

Bob

unread,
Jan 27, 2012, 12:06:31 PM1/27/12
to
Yeah, sorry about that. Google group's web interface annoyingly broken.

Bob

unread,
Jan 27, 2012, 12:29:42 PM1/27/12
to
On Friday, 27 January 2012 15:54:38 UTC, Mark Borgerson wrote:
>
> The task of putting a modern microcontroller on a board with DIP-spaced
> pins has already been done for you. Look at the various development
> boards at www.sparkfun.com.
>

Done, at a price. Thing about hobbyists, is they tend to be on a budget. I
guess beginners might be prepared to pay 5x the cost of a chip just to get it
onto a convenient package, which is the market Sparkfun and others aim at.

mBed is nice, good libraries, not the cheapest; free, no limit web based compiler.
Not every task needs 512KB though, a cheaper package with say 16/32KB would be desirable.

Rocky

unread,
Jan 27, 2012, 1:34:59 PM1/27/12
to
On Jan 27, 7:06 pm, Bob <bobcousin...@googlemail.com> wrote:
> Yeah, sorry about that. Google group's web interface annoyingly broken.

Curiously, I post via Google web interface and all the lines are
trimmed to round-about 70 odd characters. Are you using the 'new'
version?

mike

unread,
Jan 28, 2012, 2:43:57 AM1/28/12
to
I have a keyboard with a "return" key.
Seems to help with that problem.
YMMV

Dennis

unread,
Jan 28, 2012, 3:39:43 AM1/28/12
to

"mike" <spa...@gmail.com> wrote in message
news:jg092k$q56$1...@dont-email.me...
A "return" key? You sure?

I just checked all of my computers and they all have an "enter" key.

No luck finding the "any" key though.


Paul

unread,
Jan 28, 2012, 6:00:14 AM1/28/12
to
In article <jfu59p$2jk$1...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...
>
> On 2012-01-27, John Devereux <jo...@devereux.me.uk> wrote:
> >
> > Hi Simon,
> >
> > The DIP requirement is a HUGE restriction, eliminating 99.99% of the
> > parts out there, and a lot of interesting new chips. If it is for your
> > own use perhaps reconsider the SMT parts, they are perfectly amenable to
> > manual assembly and a range of DIP adapters are available for various
> > packages if you really need that.
> >
> Hello,
>
> Yes, it's for my own hobbyist use.
>
> Unlike the software side of things, (where I am quite capable of, for
> example, writing yet another BSP or device driver on demand as and when
> needed), when it comes to hardware, I still prefer to work in PDIP for
> my own circuits.
>
> Some of that is not wanting PCB chemicals around at home or wanting to
> have to wait for PCBs to be made up. Some of that is that it's so easy
> to prototype when using PDIP sized through-hole parts.
>
> I do like the idea of using DIP adapters though, especially if they were
> reasonably priced. It would allow me to work with non-PDIP parts while
> continuing to work in a otherwise PDIP sized world.

Then consider getting a batch of Schmart boards see

http://www.schmartboard.com/

Various pin pitch and sizes, with the design making iteasy to hand
solder devices in.

I have knocked up some proof of principles circuits with these
inerlocking 3 or four together. Even USB 2.0 hub chips and other
devices like PLDs.

I have often stacked them on top of 0.1 in strip board using 1mm
tinned copper wire as standoff and ground connection.

Then you can use a lot of other devices

> Simon.



--
Paul Carpenter | pa...@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

Dombo

unread,
Jan 28, 2012, 12:03:43 PM1/28/12
to
Op 27-Jan-12 14:14, Simon Clubley schreef:
Another consideration could be the Parallax Propeller chip. It doesn't
have a hardware USB, but I suppose it is possible to reserve one of the
COG to handle USB communication and use the remaining COGs for the
real-time tasks.

I don't have experience with this chip. Parallax seems to be mainly
targeting hobbyists, and the Propeller chip appears to be a hobbyist
friendly device. However it is not exactly a mainstream architecture and
must programmed in assembly or SPIN. A (free) C compiler for this chip
seems exist, though my understanding is that the architecture of this
chip is less than ideal for C.

JW

unread,
Jan 30, 2012, 5:50:52 AM1/30/12
to
On Fri, 27 Jan 2012 16:58:22 +0100 Stef
<ste...@yahooI-N-V-A-L-I-D.com.invalid> wrote in Message id:
<2dafd$4f22c99e$5f6173bc$91...@abuse.newsxs.nl>:

>In comp.arch.embedded,
>Bob <bobcou...@googlemail.com> wrote:
>> I hear that NXP have one DIP package ARM CPU (LPC1114) in development status, but not USB. DIPs are pretty thin on the ground in this segment, and even less with USB.
>
>Why are there suddenly a lot of posts on usenet (not only Bob's) with very
>long lines? Is there some google groups usenet client that no longer breaks
>long lines? In some posts I now have to scroll hundreds of chard to the
>right to be able to read it all.

I've noticed that as well from Google posters. I don't know about your
newsreader, but using Forte Agent if I press the "O" key it will line wrap
the display so it fits in the window.

rickman

unread,
Jan 30, 2012, 4:12:21 PM1/30/12
to
On Jan 27, 8:14 am, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2012-01-27, WP <palanti...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On 27 Sty, 11:33, Simon Clubley <clubley@remove_me.eisner.decus.org-
> > Earth.UFP> wrote:
> >> I'm trying to find out what MCUs have a USB device capability and are
> >> available in PDIP with a open source toolchain. Up until now, I've either
> >> used various serial interfaces on AVRs, or preassembled ARM boards, but
> >> now I need to build some small circuits with USB device built in.
>
> >> I've also looked at the AVR, ARM and MSP430 MCUs but didn't find anything
> >> in PDIP with USB device.
>
> >> Are there any options I've missed ?
>
> > There is a software USB device for AVR ATMega:http://www.obdev.at/products/vusb/index.html
>
> > I tried it and it worked.
>
> > WP
>
> I had forgotten about that software USB stack.
>
> Unfortunately, for this application I would prefer a hardware based
> USB device as I will be running code which has real time requirements
> and I don't want to get into having to evaluate how this stack would
> affect the real time capability of other code running on the AVR.
>
> I would also need to assess what general overheads this implementation
> would incur.
>
> Thanks for the pointer however; I appreciate you having suggested it.
>
> Simon.

I didn't know that any USB stacks were done in hardware. I've never
heard of that. Even the separate USB interface chips use a software
stack and have an embedded CPU. The FTDI CPU is quite fast.

Rick

Simon Clubley

unread,
Jan 30, 2012, 6:16:46 PM1/30/12
to
On 2012-01-30, rickman <gnu...@gmail.com> wrote:
> On Jan 27, 8:14 am, Simon Clubley <clubley@remove_me.eisner.decus.org-
> Earth.UFP> wrote:
>> On 2012-01-27, WP <palanti...@gmail.com> wrote:
>> > There is a software USB device for AVR ATMega:http://www.obdev.at/products/vusb/index.html
>>
>> I had forgotten about that software USB stack.
>>
>> Unfortunately, for this application I would prefer a hardware based
>> USB device as I will be running code which has real time requirements
>> and I don't want to get into having to evaluate how this stack would
>> affect the real time capability of other code running on the AVR.
>>
> I didn't know that any USB stacks were done in hardware. I've never
> heard of that. Even the separate USB interface chips use a software
> stack and have an embedded CPU. The FTDI CPU is quite fast.
>

Loose wording on my part.

The library in question implements all parts of a USB device, including
the on the wire signalling, in software by manipulating GPIO lines.
This means you can use it on a AVR which does not have any USB hardware
support at all.

I was looking for a device which has a hardware USB module built in and
only requires the traditional USB device software infrastructure to support

Jim Granville

unread,
Jan 30, 2012, 11:02:10 PM1/30/12
to
On Jan 31, 12:16 pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> The library in question implements all parts of a USB device, including
> the on the wire signalling, in software by manipulating GPIO lines.
> This means you can use it on a AVR which does not have any USB hardware
> support at all.

Then there are hybrid solutions, somewhere in the middle.
IIRC Ubicom had a shifter/bit-stuff block, and the next layer was all
software.
XMOS also have a similar 'minimal hardware' approach.
You can start with XMOS, from $49

-jg
0 new messages