ARM (or other 32 bit) MCUs in PDIP ?

[Simon Clubley]

Are there any mainstream 32 bit MCUs other than the MIPS based PIC32MX
available in PDIP ?

I'm especially interested in ARM architecture MCUs, but any 32 bit
architectures are of interest; they don't need to have USB built in.

When I was looking for the currently available MCUs with USB device
built in, it was a major surprise to discover a 32 bit MIPS MCU range
available in PDIP.

I had a look to see if there were any ARM MCUs available in PDIP but
without success. I know you can buy ARM MCUs mounted on a PDIP package,
but I'm interested if the MCU itself is available in PDIP.

Thanks,

Simon.

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

[John Devereux]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> Are there any mainstream 32 bit MCUs other than the MIPS based PIC32MX
> available in PDIP ?
>
> I'm especially interested in ARM architecture MCUs, but any 32 bit
> architectures are of interest; they don't need to have USB built in.
>
> When I was looking for the currently available MCUs with USB device
> built in, it was a major surprise to discover a 32 bit MIPS MCU range
> available in PDIP.
>
> I had a look to see if there were any ARM MCUs available in PDIP but
> without success. I know you can buy ARM MCUs mounted on a PDIP package,
> but I'm interested if the MCU itself is available in PDIP.

Digikey is good for searches like that. You can go into
embedded/microcontrollers, filter by ARM core, then look at the
available DIP packages.

There aren't any.


--

John Devereux

[Simon Clubley]

On 2012-01-27, John Devereux <jo...@devereux.me.uk> wrote:
>
> Digikey is good for searches like that. You can go into
> embedded/microcontrollers, filter by ARM core, then look at the
> available DIP packages.
>
> There aren't any.
>

Thanks for looking.

I didn't think of Digikey, but I did try other places, including
manufacturer websites, and also came up empty.

It was just seeing the PIC32MX available in PDIP (and not knowing about
it until now) made me wonder if anyone else was also doing 32 bit PDIP
MCUs and I just had not come across them yet.

[John Devereux]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2012-01-27, John Devereux <jo...@devereux.me.uk> wrote:
>>
>> Digikey is good for searches like that. You can go into
>> embedded/microcontrollers, filter by ARM core, then look at the
>> available DIP packages.
>>
>> There aren't any.
>>
>
> Thanks for looking.
>
> I didn't think of Digikey, but I did try other places, including
> manufacturer websites, and also came up empty.
>
> It was just seeing the PIC32MX available in PDIP (and not knowing about
> it until now) made me wonder if anyone else was also doing 32 bit PDIP
> MCUs and I just had not come across them yet.

I suppose Microchip and to a lesser extent Atmel are traditionally the
more "hobbiest friendly" manufacturers.

Recently the others seem to be trying for this market too, perhaps
realising that the hobbiests of today could be the product designers of
tomorrow. But they are doing it with very low cost development boards
(and free tools). Not as DIP packaged chips.

--

John Devereux

[Rich Webb]

On Fri, 27 Jan 2012 10:46:16 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>Are there any mainstream 32 bit MCUs other than the MIPS based PIC32MX
>available in PDIP ?
>
>I'm especially interested in ARM architecture MCUs, but any 32 bit
>architectures are of interest; they don't need to have USB built in.
>
>When I was looking for the currently available MCUs with USB device
>built in, it was a major surprise to discover a 32 bit MIPS MCU range
>available in PDIP.
>
>I had a look to see if there were any ARM MCUs available in PDIP but
>without success. I know you can buy ARM MCUs mounted on a PDIP package,
>but I'm interested if the MCU itself is available in PDIP.

There's no (or very limited) industrial/commercial demand for new
architectures in DIP form-factors and the miniscule hobby market isn't
enough to support making them. Besides, a 40-pin DIP is pretty danged
big already; imagine a 64- or 100-pin monster.

Your best bet is probably to look for the device already mounted in a
header board with breakout pins. See, for example,
<http://www.sparkfun.com/products/8559>

If you're more into roll your own, look for prototyping adapters that
break-out the SMT processor's pins into accessible headers. Bellin makes
a lot of these in various configurations http://www.beldynsys.com/ and
there's the Schmartboard system http://www.schmartboard.com/

--
Rich Webb Norfolk, VA

[Anders....@kapsi.spam.stop.fi.invalid]

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
> Are there any mainstream 32 bit MCUs other than the MIPS based PIC32MX
> available in PDIP ?

I don't know of any currently available one. NXP's LPC1114FN28/102
(Cortex-M0 in DIP28) is still in development, supposed to be out later
this year. I have a vague memory of old Luminary having a DIP-packaged
Cortex-M3, but if so it's been cancelled a long time ago.

-a

[DJ Delorie]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> Are there any mainstream 32 bit MCUs other than the MIPS based PIC32MX
> available in PDIP ?

What I do is put the chip on a "breakout" board and put it next to my
breadboard. It's rare to find interesting (to me) MCUs in DIP format
these days. Example breakouts:

http://www.delorie.com/electronics/rx/rx62n-breakout.html
http://www.delorie.com/electronics/rx/rx62t-80-breakout.html
http://www.delorie.com/electronics/r32c-breakout/

The RX is a 32-bit part, and the 62N has built-in host/device USB and
ethernet MII.

http://www.delorie.com/electronics/m16c-26-adapter/

a 16-bit MCU breakout specifically designed for breadboarding

http://www.delorie.com/electronics/r8c-3mk/

DIP adapter for 16-bit R8C with host/device USB (the breakout only
supports device as-is)

http://www.delorie.com/electronics/usb-gpio/

MCU with an FT232R interface, can use plug-ins or wire-to-breadboard
(example use: http://www.delorie.com/electronics/bin2seven/proto-all.html)

http://www.delorie.com/electronics/gR8C/

Has a photo with various dip-packaged MCU adapters

There are plenty of places online to have one-off or small-batch
breakout/adapter PCBs made, if you don't mind soldering the chip to it.
Solder once, then use it with your breadboard.

[Simon Clubley]

Now _that's_ the kind of device I am thinking of. :-)

Thank you. The Farnell pricing on the packaging variants which are
currently available is very reasonable so I hope PDIP follows the same
general pricing pattern when it becomes available.

It's a pity it doesn't have USB device, but there are still a number of
things I can use this device for.

[Simon Clubley]

Thanks for the interesting selection of links and ideas.

Thanks also to everyone else for breakout board suggestions.

For now, I would like to use continue using PDIP in my own circuits,
but I agree with people here in that I think I am going to be forced
into a breakout board type situation in the future as newer devices
come along.

And you are quite correct; it would not be too difficult to have a
series of generic breakout boards made once I make that move.

Thanks everyone,

[hamilton]

On 1/27/2012 3:39 PM, Simon Clubley wrote:
> On 2012-01-27, Anders....@kapsi.spam.stop.fi.invalid<Anders....@kapsi.spam.stop.fi.invalid> wrote:
>> Simon Clubley<clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
>>> Are there any mainstream 32 bit MCUs other than the MIPS based PIC32MX
>>> available in PDIP ?
>>
>> I don't know of any currently available one. NXP's LPC1114FN28/102
>> (Cortex-M0 in DIP28) is still in development, supposed to be out later
>> this year. I have a vague memory of old Luminary having a DIP-packaged
>> Cortex-M3, but if so it's been cancelled a long time ago.
>>
>
> Now _that's_ the kind of device I am thinking of. :-)
>
> Thank you. The Farnell pricing on the packaging variants which are
> currently available is very reasonable so I hope PDIP follows the same
> general pricing pattern when it becomes available.
>
> It's a pity it doesn't have USB device, but there are still a number of
> things I can use this device for.
>
> Thanks,
>
> Simon.

> ion
Hello Simon,

Please do not take this badly,

What is so wrong with coming into the 21st century ?

If you want to play with the big boys, you've got to learn what the big
boys know.

With the number of devices within the soldering abilities of most
beginners, using a 48 or 64pin tqfp will get you more and better devices.

Why is dip the only game you want to play ??

I would really like to know what keeps you in the 1980s ?

Thanks

don'

[Simon Clubley]

On 2012-01-27, hamilton <hami...@nothere.com> wrote:
> Hello Simon,
>
> Please do not take this badly,
>

I won't; it's a fair question.

>
> Why is dip the only game you want to play ??
>

Because up until now, it's been sufficient for my projects.

As I mentioned in another post, I suspect I am going to have to move
to using breakout boards in the future.

[Bob]

On Saturday, 28 January 2012 09:05:23 UTC, Simon Clubley wrote:
> As I mentioned in another post, I suspect I am going to have to move
> to using breakout boards in the future.
>

I would also like to ask, why not use one of the breakout boards now? People
often ask similar questions, and it generates a lot of answers, but without much
feedback on what the "stopper" is. Is it cost? Complexity? Availability?
Unfamiliarity? Cost of tools? I have no real idea, which makes it hard to tailor
future suggestions.

One problem I see is that a lot of breakout boards are quad package, or dual row,
which is not convenient for stripboards. Or they are DIP package, but have a
lot of extras added, which bumps up the cost and forces you into specific design
choices. I suspect what people really want, is just a chip on a DIP board, as
cheaply as possible. There is little profit in that, and hundreds of possible chips,
so it is unlikely to attract commercial interest.
BatchPCB makes it really easy for people to order bare boards, so that is half the job.
The other half is finding an enterprising amateur willing to provide a soldering
service for a few $.

[Rich Webb]

On Sat, 28 Jan 2012 04:15:38 -0800 (PST), Bob
<bobcou...@googlemail.com> wrote:

>The other half is finding an enterprising amateur willing to provide a soldering
>service for a few $.

Or bite the bullet and learn to DIY. Once one has gotten past the scary
place of a side by side comparison between a 0.1" DIP and 0.5 mm TQFP,
it turns out that surface mount work is remarkably easy. The how-to
videos over at Sparkfun and Dave's EEVBlog provide good demonstrations.

<http://www.sparkfun.com/tutorials/category/2>
<http://www.eevblog.com/2011/07/18/eevblog-186-soldering-tutorial-part-3-surface-mount/>

[Bob]

It's great that you find it remarkably easy, but did you stop to think that some
people with failing eyesight and unsteady hands may have also tried it and found
it remarkably difficult?

[Simon Clubley]

On 2012-01-28, Bob <bobcou...@googlemail.com> wrote:
> On Saturday, 28 January 2012 09:05:23 UTC, Simon Clubley wrote:
>> As I mentioned in another post, I suspect I am going to have to move
>> to using breakout boards in the future.
>>

You ask a series of good questions. I will try and answer them in detail
below.

>
> I would also like to ask, why not use one of the breakout boards now?

Simply because the trade off with the issues I mention below versus the
wide-ranging availability of PDIP parts means that (for projects for
which PDIP parts are available) I prefer to use those PDIP parts.

For something which requires a ARM7 (and above) processor, I just buy
a board from somewhere like Olimex.

> People often ask similar questions, and it generates a lot of answers,
> but without much feedback on what the "stopper" is.

I understand. Below is my current thinking on the questions you ask.

> Is it cost? Complexity? Availability?

The breakout boards I see have a whole lot of extras added onto them
which are of no interest to me and just bump up the price and size.

A number of them are also designed as standalone units instead of
something which can be plugged into a stripboard/veroboard base unit.
In that case, you have to work with what is on the board, instead of
been able to build your own circuit around it.

Complexity is not a issue in that I can just ignore the parts of a board
I don't need.

Availability is not really a issue; they tend to be freely available
here in the UK.

When I get a idea for something, I like to be able to design something
which contains just the components I need, and nothing else. There's
also the fact that projects could involve more than one breakout board,
which rapidly starts multiplying the price difference.

Therefore, this leaves the option which we have been discussing which is
having some bare generic adapter templates made which, when populated,
would contain nothing but the IC in question plus the 0.1 inch pitch
pinouts.

The price of having custom boards made is not really too much of a issue
for me. For designing them, I would just use gEDA and the cost of a batch
of boards does not seem too bad (at least the last time I looked).

The real problem with this, and this is the core problem here, is working
with components that small. I don't currently have the skill set required
for that and I am not sure what extra equipment is required in case I need
help soldering something that small in case my hands are not steady enough.

> Unfamiliarity? Cost of tools?

Cost of development tools for software development is not a problem.
For the hardware side of things, I just use a low cost JTAG tool for the
ARM boards (a Wiggler clone from Olimex) and I built a programmer for
the AVRs which I use with AVRdude.

On the software side of things, both for AVR and ARM, I just use a open
source toolchain (gcc/binutils and, for the ARM boards, OpenOCD/gdb/ddd).

I don't need any of the handholding stuff which you see in the commercial
toolchains. I just write my own headers (using the datasheet) if they are
not available or the manufacturer uses coding conventions I disagree with.

Likewise, on the ARM, I am now using my own startup code template, which I
alter based on the manufacturer's documentation and any issues raised by
the manufacturer supplied startup code (which I just view as documentation
for things which should have been in the datasheet/reference manual but
wasn't :-)).

Unfamiliarity isn't really a major problem in a number of cases, but it
depends on the degree of unfamiliarity. Learning another ARM MCU isn't a
problem. Learning a completely new architecture (ie: MIPS) requires a
far larger amount of time to be available.

Assuming I had the time on a specific project, I would take the lack of
familiarity as a opportunity to learn something new.

> I have no real idea, which makes it hard to tailor future suggestions.
>
> One problem I see is that a lot of breakout boards are quad package, or
> dual row, which is not convenient for stripboards. Or they are DIP package,
> but have a lot of extras added, which bumps up the cost and forces you into
> specific design choices. I suspect what people really want, is just a chip
> on a DIP board, as cheaply as possible. There is little profit in that, and
> hundreds of possible chips, so it is unlikely to attract commercial interest.

This is exactly the problem. I am quite capable of building my own circuits
provided the parts are in a size I can work with. I am not interested in
breakout boards that are loaded with a whole set of parts which bump up the
size and price.

> BatchPCB makes it really easy for people to order bare boards, so that is
> half the job.
> The other half is finding an enterprising amateur willing to provide a
> soldering service for a few $.

Thanks for the pointer.

BTW, when I finally go down this route, it will be me doing the soldering
as I will regard it as another skill to be learnt. :-)

I hope this helps you understand the issues I consider and the priority I
assign to each type of issue.

[John Devereux]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:


[...]

>
> When I get a idea for something, I like to be able to design something
> which contains just the components I need, and nothing else. There's
> also the fact that projects could involve more than one breakout board,
> which rapidly starts multiplying the price difference.
>
> Therefore, this leaves the option which we have been discussing which is
> having some bare generic adapter templates made which, when populated,
> would contain nothing but the IC in question plus the 0.1 inch pitch
> pinouts.
>
> The price of having custom boards made is not really too much of a issue
> for me. For designing them, I would just use gEDA and the cost of a batch
> of boards does not seem too bad (at least the last time I looked).
>
> The real problem with this, and this is the core problem here, is working
> with components that small. I don't currently have the skill set required
> for that and I am not sure what extra equipment is required in case I need
> help soldering something that small in case my hands are not steady enough.

Hi Simon,

If you search the archives for this group and perhaps
sci.electronics.design and sparkfun you will see lots of
advice/tutorials on soldering surface mount chips.

But basically the key ingredients are

- bright light
- magnification (e.g. headband magnifier)
- flux (which is in the solder but only lasts a few seconds)

I don't find steady hands to be an issue; you just rest them on the work
surface,

[...]

>
> BTW, when I finally go down this route, it will be me doing the soldering
> as I will regard it as another skill to be learnt. :-)
>
> I hope this helps you understand the issues I consider and the priority I
> assign to each type of issue.
>
> Simon.

--

John Devereux

[dp]

On Jan 28, 8:29 pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> ...

> The real problem with this, and this is the core problem here, is working
> with components that small. I don't currently have the skill set required
> for that and I am not sure what extra equipment is required in case I need
> help soldering something that small in case my hands are not steady enough.

I seriously doubt you would have a problem soldering SMT boards,
it is probably just a matter of being a bit daring the first time.
You will discover it will cost you much *less* time and effort; put
the
solder paste on the board, place the parts then bake in a kitchen
oven (I use a $100 2kW one, of those small ones, sort of microwave
oven sized). Get an IR thermometer and you will be equipped well
enough.
Oh, and for rework you will need two soldering irons, that is how
I do it at least. I also have a blower (hot air station, I believe),
but I have been getting away without having one in the past.
And I manage boards like this one more or less routinely:

http://tgi-sci.com/misc/nmc3top.gif

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[Mark Borgerson]

In article <30778030.282.1327757815830.JavaMail.geo-discussion-
forums@vbbfd4>, bobcou...@googlemail.com says...

>
> It's great that you find it remarkably easy, but did you stop to think that some
> people with failing eyesight and unsteady hands may have also tried it and found
> it remarkably difficult?

I solved the failing eyesight part many years ago with a $300 binocular
microscopy. I haven't reached the shaky hands stage yet, so I keep on
soldering those TQFPs.

OTOH, I find doing that soldering for more than an hour or two a bit
boring, so I hired my teenage kids at well above minimum wage
and well below what it costs to hire a part-time technician (~$21/hr).
They still complain about the repetitive nature of 100 pins of 0.1"
headers, but the attraction of gas and movie money usually wins.

Mark Borgerson

[Mark Borgerson]

In article <jg1er7$md3$1...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

I would add to that a handful of decoupling capacitors---which will be
more effective when not separated from the MCU power pins by the
connectors and traces of the breakout board.

You should also consider adding parts you know you'll need for most
cases, like a crystal and, perhaps, resistors that set default boot
behavior (boot0 and boot1 pins on the STM32 series).

>
> The price of having custom boards made is not really too much of a issue
> for me. For designing them, I would just use gEDA and the cost of a batch
> of boards does not seem too bad (at least the last time I looked).
>
> The real problem with this, and this is the core problem here, is working
> with components that small. I don't currently have the skill set required
> for that and I am not sure what extra equipment is required in case I need
> help soldering something that small in case my hands are not steady enough.

If you can print legibly, your hands are probably steady enough. A good
binocular microscope is handy for more than soldering and shouldn't cost
more than $300.

>
> > Unfamiliarity? Cost of tools?
>
> Cost of development tools for software development is not a problem.
> For the hardware side of things, I just use a low cost JTAG tool for the
> ARM boards (a Wiggler clone from Olimex) and I built a programmer for
> the AVRs which I use with AVRdude.
>
> On the software side of things, both for AVR and ARM, I just use a open
> source toolchain (gcc/binutils and, for the ARM boards, OpenOCD/gdb/ddd).
>
> I don't need any of the handholding stuff which you see in the commercial
> toolchains. I just write my own headers (using the datasheet) if they are
> not available or the manufacturer uses coding conventions I disagree with.

For some of the more complex ARM chips, the headers can run to several
thousand lines. I usually start with the headers from the software
provider and often replace some with my own definitions when I disagree
with their style.

Mark Borgerson

[Ed Beroset]

dp wrote:

> Oh, and for rework you will need two soldering irons, that is how
> I do it at least. I also have a blower (hot air station, I believe),
> but I have been getting away without having one in the past.
> And I manage boards like this one more or less routinely:
>
> http://tgi-sci.com/misc/nmc3top.gif

The large IC on that board looks like a BGA package. I've been avoiding
BGA for home projects because I can't figure out how I would possibly
troubleshoot and rework such a board with exotic stuff like an X-ray
inspection machine, etc. Have you got experience with BGA on a budget?

Ed

[Joe Chisolm]

On Fri, 27 Jan 2012 23:01:59 +0000, Simon Clubley wrote:
<snip>

>
> Thanks for the interesting selection of links and ideas.
>
> Thanks also to everyone else for breakout board suggestions.
>
> For now, I would like to use continue using PDIP in my own circuits, but
> I agree with people here in that I think I am going to be forced into a
> breakout board type situation in the future as newer devices come along.
>
> And you are quite correct; it would not be too difficult to have a
> series of generic breakout boards made once I make that move.
>
> Thanks everyone,
>
> Simon.

SchmartBoard has a line of adapters. Easy to work with. Never had any
issues ordering from them.

http://www.schmartboard.com/index.asp?page=products_smttodip

--
Chisolm
Republic of Texas

[Rich Webb]

One feature of the Schmartboard is their "ez technology" which puts the
SMT leads onto recessed pads, so they sort of "fall into place." Can't
get much easier...

[Simon Clubley]

On 2012-01-28, Mark Borgerson <mborg...@comcast.net> wrote:
> In article <jg1er7$md3$1...@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP says...
>>

>> Therefore, this leaves the option which we have been discussing which is
>> having some bare generic adapter templates made which, when populated,
>> would contain nothing but the IC in question plus the 0.1 inch pitch
>> pinouts.
>
> I would add to that a handful of decoupling capacitors---which will be
> more effective when not separated from the MCU power pins by the
> connectors and traces of the breakout board.
>

That's a good point. Thanks.

> You should also consider adding parts you know you'll need for most
> cases, like a crystal and, perhaps, resistors that set default boot
> behavior (boot0 and boot1 pins on the STM32 series).

As long as I didn't do anything which stopped the board template from been
used for different ICs which happen to share the same packaging, that's
something to consider.

>>
>> The real problem with this, and this is the core problem here, is working
>> with components that small. I don't currently have the skill set required
>> for that and I am not sure what extra equipment is required in case I need
>> help soldering something that small in case my hands are not steady enough.
>
> If you can print legibly, your hands are probably steady enough. A good
> binocular microscope is handy for more than soldering and shouldn't cost
> more than $300.

While such a microscope would be affordable, for me, that would count as a
investment I would not want to make until I was sure of myself. Therefore,
when I finally take the plunge, I would build up experience with the larger
pitch sub-DIP sized packages before trying to get too adventurous. :-)

>>
>> I don't need any of the handholding stuff which you see in the commercial
>> toolchains. I just write my own headers (using the datasheet) if they are
>> not available or the manufacturer uses coding conventions I disagree with.
>
> For some of the more complex ARM chips, the headers can run to several
> thousand lines. I usually start with the headers from the software
> provider and often replace some with my own definitions when I disagree
> with their style.

Oh, I know just how big some of them are. :-)

What I did on the last set of headers was to copy-and-paste the register
summaries in the documentation for the register blocks I needed to access
into emacs and then edited them using keyboard macros. It doesn't take all
that long once you've done a couple or so.

The last set of headers was for a ARM9 processor and once I stopped trying
to define register bitfields using structs[*] and went back to using masks,
creating the header files was a little tedious but quite painless otherwise.

Simon.

[*] I wanted to try writing headers which used structs instead of masks to
access register bitfields (at least for those registers whose usage was
suitable for such a struct), but while gcc was loading the register using
a ldr, it was sometimes writing the field back using strb instead of str.

A walk through the gcc manual didn't reveal any pragma or attribute
directives of interest, so I reverted back to masks.

(And yes, everything was marked as volatile.)

[Simon Clubley]

Several people have now pointed me in the direction of these people.

I'll have a look through their website and get up to speed on what they
offer.

Thanks for the pointer everyone.

[David Brown]

I presume the trick is to solder it correctly the first time, so you
don't need rework or troubleshooting.

In general, wide-pitch BGA's (1 mm or 1.25 mm) are easier to solder
correctly than fine-pitch SMTs (0.5 mm or 0.6 mm), because there is more
space between the "legs". But you have to get your board layout
correct, and avoid having too many bulky or high components nearby -
they disrupt the airflow and make the heating uneven.

I have no experience of doing this myself at home - though I have heard
of people doing it using a toaster (on its side).

[Mark Borgerson]

In article <jg1umi$k7o$1...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

Great minds think alike! The excessive use of structs was one of the
reasons I ended up with some of my own headers for the STM32 series.

OTOH, the ARM instruction set and the IAR compiler do produce pretty
efficient code for struct-type headers using the base + offset
addressing modes.

> Simon.
>
> [*] I wanted to try writing headers which used structs instead of masks to
> access register bitfields (at least for those registers whose usage was
> suitable for such a struct), but while gcc was loading the register using
> a ldr, it was sometimes writing the field back using strb instead of str.
>
> A walk through the gcc manual didn't reveal any pragma or attribute
> directives of interest, so I reverted back to masks.

I've used IAR for most of my non-Linux projects with the ARM chips.
When I was writing for a StrongArm system using GCC, I didn't spend
too much looking at the assembly language results. Other problems
with making Linux behave in a near-real-time system got most of my
attention.

>
> (And yes, everything was marked as volatile.)

Mark Borgerson

[Mark Borgerson]

In article <JdmdnV5Ln4uVHrnS...@lyse.net>,
david...@removethis.hesbynett.no says...

I've used the electric frying pan technique with some boards for which
I purchased a stencil and solder paste. I found it worked better with
the dozens of 0805 resistors and capacitors than with the fine-pitch
ADC chips on that board. When the order came in for another 80 boards
after the first 20, I bit the bullet and took the time to document
things well enough for a local assembly house with a pick-and-place
machine.

Mark Borgerson

[Rich Webb]

On Sat, 28 Jan 2012 23:00:34 +0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2012-01-28, Mark Borgerson <mborg...@comcast.net> wrote:

>> If you can print legibly, your hands are probably steady enough. A good
>> binocular microscope is handy for more than soldering and shouldn't cost
>> more than $300.
>
>While such a microscope would be affordable, for me, that would count as a
>investment I would not want to make until I was sure of myself.

How about this for only $200?
<http://www.microscope.com/omano-om24l-stereo-microscope.html>

I've had one for a couple of years and love it, although I mostly use it
for inspection and do the actual work while wearing an OptiVisor.

Pros: Inexpensive. Good optical range, where 20x isn't too much
magnification to work under when it's really necessary and 40x is good
for inspection (some folks prefer 10x/30x). Rechargeable battery-powered
LED illumination, so you can take it to the work w/o (more) cords
getting in the way.

Cons: 3.25" to the center of the FOV from the mounting post limits the
size of the possible working piece (although it's possible to gain an
additional 1/2" by lifting the work up to clear the metal piece that
holds the post). Not the best optics in the world (some internal
reflections) but decent.

Lots of other choices for a stereo 'scope at the parent site, from
around $110 to north of $5000.

[dp]

Like David mentioned getting the board right is important.
But this is almost never 100% doable so one wants to be as
flexible as possible. On that (and other 1.27mm BGA boards
I have done) I drill _every_ BGA pad, and route up to 3
traces between the pads on the top and bottom board sides.
The inner layers are ground and power only (somewhat split,
e.g. the 2.5 and 3.3V on that board are on the same split
plane under the BGA).
Works OK and one does have some - indeed not big - room for
error. Soldering the thing right is not an issue (once you
get used to it... the first board I did 10+ years ago got
a lot of reflows but worked eventually).
Having drilled (0.2mm after plating) under each ball it
is essential to have all balls well attached to the BGA chip;
they do not always come like that from the manufacturer.
If a ball is "cold" soldered to the BGA it flows all down
the hole and soldering has been a failure. To prevent this
I reflow the BGA once balls up with some flux, then wash it
for the final usage - has always worked.

[John Devereux]

Mark Borgerson <mborg...@comcast.net> writes:

> In article <jg1umi$k7o$1...@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP says...

[...]

>>
>> Oh, I know just how big some of them are. :-)
>>
>> What I did on the last set of headers was to copy-and-paste the register
>> summaries in the documentation for the register blocks I needed to access
>> into emacs and then edited them using keyboard macros. It doesn't take all
>> that long once you've done a couple or so.
>>
>> The last set of headers was for a ARM9 processor and once I stopped trying
>> to define register bitfields using structs[*] and went back to using masks,
>> creating the header files was a little tedious but quite painless otherwise.
>>
> Great minds think alike! The excessive use of structs was one of the
> reasons I ended up with some of my own headers for the STM32 series.
>
> OTOH, the ARM instruction set and the IAR compiler do produce pretty
> efficient code for struct-type headers using the base + offset
> addressing modes.

I quite like the peripherals defined as structs on STM32 but I threw
away most of the rest. Great for debugging, you can just print the
struct in gdb and see the state of the peripheral.

[...]

--

John Devereux

[Paul]

In article <jg1uu7$k7o$2...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

>
> On 2012-01-28, Rich Webb <bbe...@mapson.nozirev.ten> wrote:
> > On Sat, 28 Jan 2012 15:14:45 -0600, Joe Chisolm
> ><jchi...@earthlink.net> wrote:
> >
> >>SchmartBoard has a line of adapters. Easy to work with. Never had any
> >>issues ordering from them.
> >>
> >>http://www.schmartboard.com/index.asp?page=products_smttodip
> >
> > One feature of the Schmartboard is their "ez technology" which puts the
> > SMT leads onto recessed pads, so they sort of "fall into place." Can't
> > get much easier...
> >
>
> Several people have now pointed me in the direction of these people.
>
> I'll have a look through their website and get up to speed on what they
> offer.
>
> Thanks for the pointer everyone.
>
> Simon.

They are available UK, I have used them and keep a few.

The STRIP board space used up is generally 2 x 2 inches, the recessed
tracks and pads are pre-soldered so you heat and flow the solder.

They have a video of 10 year old doing it.

Any strip boarding involves wires or wire links

Any part with over 64 pins in DIP were generally made with 0.05in pitch
and would need adapters for 0.1in stripboard, and would take up more
board area than a 2in x 2in schmart board. Even the consider a dip 100
pin device, has to have 50 pins a side meaning its length is

0.1" pitch 5 inches
0.05" pitch 2.5 inches

It would probably be 2 inches wide for the internal pin leads fanout.

I have in the distant past dealt with 64pin DIP 0.1" pitch video A/D
chips. In those days we were glad when everyone went to 28pin as 0.1"
pich devices.

As to getting PCBs made I have used a few pooling servces over the years
for one or two offs at reasonable cost which actually getting PCBs even
for a mock up SAVES a lot of soldering time. The projects often involve
other coding work so you can always do other bits of projects. As a
hobhyist this can make life easier as life and work gets in the way of
the hobby.




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

[David Brown]

On 29/01/12 00:00, Simon Clubley wrote:
> What I did on the last set of headers was to copy-and-paste the register
> summaries in the documentation for the register blocks I needed to access
> into emacs and then edited them using keyboard macros. It doesn't take all
> that long once you've done a couple or so.
>
> The last set of headers was for a ARM9 processor and once I stopped trying
> to define register bitfields using structs[*] and went back to using masks,
> creating the header files was a little tedious but quite painless otherwise.
>
> Simon.
>
> [*] I wanted to try writing headers which used structs instead of masks to
> access register bitfields (at least for those registers whose usage was
> suitable for such a struct), but while gcc was loading the register using
> a ldr, it was sometimes writing the field back using strb instead of str.
>
> A walk through the gcc manual didn't reveal any pragma or attribute
> directives of interest, so I reverted back to masks.
>
> (And yes, everything was marked as volatile.)
>

The trouble here is that when you have volatile bitfields, there is no C
specification saying whether accesses will be by the smallest access
size from the field width, the most efficient instruction, or using
access sizes based on the field type. So if you have a bitfield defined
as "volatile uint16_t x : 6" on an ARM, the compiler may implement reads
and writes as 8-bit (that's the smallest needed), 16-bit (to match the
width of the field's type), or 32-bit (the most efficient on most ARM
cores).

gcc aimed to pick the most efficient code - typically a 32-bit read or
write, but sometimes a smaller access.

To make such volatile bitfields more consistent (since people wanted to
use them, despite being poorly specified by the C standards), gcc
introduced the "-fstrict-volatile-bitfields" command-line option which
makes the compiler always use the type-defined access size (16-bit in
the example above). That way, you know exactly what you are getting.

However, using masks is always well-defined, and often a safer choice.

[Rich Webb]

On Sun, 29 Jan 2012 09:52:48 -0000, Paul
<pa...@pcserviceselectronics.co.uk> wrote:


>As to getting PCBs made I have used a few pooling servces over the years
>for one or two offs at reasonable cost which actually getting PCBs even
>for a mock up SAVES a lot of soldering time. The projects often involve
>other coding work so you can always do other bits of projects. As a
>hobhyist this can make life easier as life and work gets in the way of
>the hobby.

I've used the off-shore pooling service that Sparkfun started
<http://batchpcb.com/index.php/Products> and was quite happy with the
price and quality (and quantity, since it was a relatively small board
and they ran a few extras on the panel to fill in the odd spaces, no
additional charge).

One I haven't tried yet, but almost want to gen-up a project just to try
out, is the Fusion PCB service from SeeedStudio
<http://www.seeedstudio.com/depot/fusion-pcb-service-p-835.html?cPath=185>
The price is $25 for a lot of ten boards 10cm x 10cm ($2.50/board!) plus
shipping. Soldermasked, silkscreened, and 50% of the boards electrically
tested (another $10 to test the entire lot).

[Hans-Bernhard Bröker]

On 28.01.2012 19:29, Simon Clubley wrote:

> Simply because the trade off with the issues I mention below versus the
> wide-ranging availability of PDIP parts means that (for projects for
> which PDIP parts are available) I prefer to use those PDIP parts.

But that's just the catch: that "wide-ranging availability of PDIP
parts" is very close to finally turning from fact to history. PDIP
parts in general are going, going, ... gone.

They're just _too_ cumbersome for most applications these days. Most of
them won't even have been updated for ROHS compliance, which makes them
unacceptable for all customers with the buying power to sustain
production. Hobbyists alone can't do that.

Sticking to PDIP is becoming more and more equivalent to insisting that
your next car must have a steam engine.

> Therefore, this leaves the option which we have been discussing which is
> having some bare generic adapter templates made which, when populated,
> would contain nothing but the IC in question plus the 0.1 inch pitch
> pinouts.

Won't work, particularly for CPUs. Some of the supporting parts,
particularly the oscillator and some decoupling capacitors, just _have_
to be so close to the CPU itself that they cannot be anywhere else but
on the breakout board. CPU manufacturers don't publish detailed PCB
trace specifications for the connection between CPU and quartz for the
sheer fun of it, you see.

And of course, those pins needing really very short traces will be
different for every device --- and that's what really kills the idea of
a universal break-out board.

> The real problem with this, and this is the core problem here, is working
> with components that small.

So how would you get them onto your break-out boards?

> BTW, when I finally go down this route, it will be me doing the soldering
> as I will regard it as another skill to be learnt. :-)

Well, good luck with that, then ;-)

[Frnak McKenney]

This is a branch from the "ARM (or other 32 bit) MCUs in PDIP ?"
thread.

On Sat, 28 Jan 2012 17:23:01 -0500, Rich Webb <bbe...@mapson.nozirev.ten> wrote:
> On Sat, 28 Jan 2012 15:14:45 -0600, Joe Chisolm
><jchi...@earthlink.net> wrote:

[...]

>>SchmartBoard has a line of adapters. Easy to work with. Never
>>had any issues ordering from them.
>>
>>http://www.schmartboard.com/index.asp?page=products_smttodip
>
> One feature of the Schmartboard is their "ez technology" which
> puts the SMT leads onto recessed pads, so they sort of "fall
> into place." Can't get much easier...

I took a look at their three-minute video:

http://www.schmartboard.com/index.asp?page=movie

and it looks like a neat technique. I wonder if it could be
approximated by creating "Y"-shaped pads like these:


Top View

/---------------------------------\
/ |
/ Pad |
---- /----------------------------/ +----------------
| |
| | Lead
---- \----------------------------\ |
\ | +----------------
\ |
\---------------------------------/

+----------------
|
Side View | Lead
|
+----------------
-----------------------------------------+
Pad |
-----------------------------------------+

where the copper shape and thickness itself provided the "trough"?
The "trough" might not be as deep as the ones manufactured by
SchmartBoard, but all it has to be is "good enough".

Assuming that pads could be etched / deposited with a narrow enough
width and not present other problems (current capacity, etc.),
this might be accomplished by a simple (and possibly automated)
edit of the appropriate component libraries.

( Heck, a suitable ALIDHTBI 3D CNC machine could "rout"-out
troughs, lay down a thin layer of conductive paint, and even
drill holes for a few through-hole components! )

Jes' curious...


ALIDHTBI: "As long as I don't have to build it..." <grin!>

Frank McKenney
--
In every age "the good old days" were a myth. No one ever thought
they were good at the time. For every age has consisted of crises
that seemed intolerable to the people who lived through them.
-- Brooks Atkinson / Once Around the Sun
--
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney aatt mindspring ddoott com

[linnix]

On Jan 29, 9:58 am, Frnak McKenney

<fr...@far.from.the.madding.crowd.com> wrote:
> This is a branch from the "ARM (or other 32 bit) MCUs in PDIP ?"
> thread.
>

With this, you would have to cut out every other pins of the chip to
prevent shorting. A better way may be to pre-groove the fiber board
prior to copper deposit. Easy enough for prototypes, but might not be
cheap enough for productions.

[Zoltan Kocsi]

On Sun, 29 Jan 2012 12:55:35 +0100
David Brown <david...@removethis.hesbynett.no> wrote:

> To make such volatile bitfields more consistent (since people wanted to
> use them, despite being poorly specified by the C standards), gcc
> introduced the "-fstrict-volatile-bitfields" command-line option which
> makes the compiler always use the type-defined access size (16-bit in
> the example above). That way, you know exactly what you are getting.
>
> However, using masks is always well-defined, and often a safer choice.

I would steer away from volatile bitfields with gcc. There are some very
serious issues regarding to that.

First, the standard specifies that each volatile access has to be a separate
actual access. That generates a lot of unnecessary code:

typedef struct { int fld1:20, fld2:5, fld3:5, fld4:2; } myreg;

volatile myreg * const ptr = SOME_ADDRESS;

then you want to initialise the register (say it's some config reg):

ptr->fld1 = val1;
ptr->fld2 = val2;
ptr->fld3 = val3;
ptr->fld4 = val4;

will read and write the register 4 times and of course it will mask and set
the fields individually. Except when some buggy versions of gcc decide to
optimise it out and do a single write. Or possibly 2 reads and 2 writes, with
half sized accesses. If you go through gcc versions from say, 4.0.x to 4.5.x
and see what it generates from volatile bitfield code (at least for ARM), it's
sheer horror.

Anyway, using masks guarantees that you have full control over the number of
accesses to the register; for the above example you could read/write it 4
times, read it once and write four times, modifying only one field at a time
or you can not read it at all, just load the new value into it.

With a relatively small effort and with overloading of the comma operator
one could modify the C standard to allow the programmer to handle bitfields
efficiently and in a very well defined manner, but that would possibly break
existing code and bare-metal embedded system programmers and device driver
writers are probably not a large enough target market to make standard
changes anyway (after all, the assignment operator with a volatile lhs has not
been fixed in over a decade either and that would only be a half sentence
wording change).

So, if you want to control the number of accesses to your register, you
should use masks and keep clear of bitfields. They would be elegant and
readable but unfortunately they are unpredictable, which is definitely
a Bad Thing when dealing with hardware.

Zoltan
--
Zoltán Kócsi
Bendor Research Pty. Ltd.

[David Brown]

On 30/01/2012 13:53, Zoltan Kocsi wrote:
> On Sun, 29 Jan 2012 12:55:35 +0100
> David Brown<david...@removethis.hesbynett.no> wrote:
>
>> To make such volatile bitfields more consistent (since people wanted to
>> use them, despite being poorly specified by the C standards), gcc
>> introduced the "-fstrict-volatile-bitfields" command-line option which
>> makes the compiler always use the type-defined access size (16-bit in
>> the example above). That way, you know exactly what you are getting.
>>
>> However, using masks is always well-defined, and often a safer choice.
>
> I would steer away from volatile bitfields with gcc. There are some very
> serious issues regarding to that.
>

Most of what you write applies to /all/ C compilers, not just gcc.

> First, the standard specifies that each volatile access has to be a separate
> actual access. That generates a lot of unnecessary code:
>

Agreed.

> typedef struct { int fld1:20, fld2:5, fld3:5, fld4:2; } myreg;
>
> volatile myreg * const ptr = SOME_ADDRESS;
>
> then you want to initialise the register (say it's some config reg):
>
> ptr->fld1 = val1;
> ptr->fld2 = val2;
> ptr->fld3 = val3;
> ptr->fld4 = val4;
>
> will read and write the register 4 times and of course it will mask and set
> the fields individually. Except when some buggy versions of gcc decide to
> optimise it out and do a single write. Or possibly 2 reads and 2 writes, with
> half sized accesses. If you go through gcc versions from say, 4.0.x to 4.5.x
> and see what it generates from volatile bitfield code (at least for ARM), it's
> sheer horror.

Well, as you note the standard specifies that each access is
independent, since it is volatile. So any compiler will generate either
horrible code with multiple accesses, or incorrect code doing combined
writes. For code like this writing adjacent fields, volatile bitfields
will always be less efficient than bitmasks (unless the compiler is
broken, of course).

>
> Anyway, using masks guarantees that you have full control over the number of
> accesses to the register; for the above example you could read/write it 4
> times, read it once and write four times, modifying only one field at a time
> or you can not read it at all, just load the new value into it.
>
> With a relatively small effort and with overloading of the comma operator
> one could modify the C standard to allow the programmer to handle bitfields
> efficiently and in a very well defined manner, but that would possibly break
> existing code and bare-metal embedded system programmers and device driver
> writers are probably not a large enough target market to make standard
> changes anyway (after all, the assignment operator with a volatile lhs has not
> been fixed in over a decade either and that would only be a half sentence
> wording change).
>

There are many things that could be changed in the C standards to make
life better for either the users, or the compiler writers, or both. A
few of these are addressed in newer C standards, but mostly they would
mean incompatible changes with existing code, and the standards
committees are understandably reluctant to make such changes.

> So, if you want to control the number of accesses to your register, you
> should use masks and keep clear of bitfields. They would be elegant and
> readable but unfortunately they are unpredictable, which is definitely
> a Bad Thing when dealing with hardware.
>

Correct. Bitfields can be nice, but you have to be careful with them
(even if they are not volatile). For volatile bitfields, pay close
attention to what your compiler generates - since the standards are not
specific here, compilers can do different things and still be "correct".

> Zoltan

[Mel Wilson]

David Brown wrote:

> On 30/01/2012 13:53, Zoltan Kocsi wrote:
>> On Sun, 29 Jan 2012 12:55:35 +0100
>> David Brown<david...@removethis.hesbynett.no> wrote:
>> typedef struct { int fld1:20, fld2:5, fld3:5, fld4:2; } myreg;
>>
>> volatile myreg * const ptr = SOME_ADDRESS;
>>
>> then you want to initialise the register (say it's some config reg):
>>
>> ptr->fld1 = val1;
>> ptr->fld2 = val2;
>> ptr->fld3 = val3;
>> ptr->fld4 = val4;
>>
>> will read and write the register 4 times and of course it will mask and
>> set the fields individually. Except when some buggy versions of gcc
>> decide to optimise it out and do a single write. Or possibly 2 reads and
>> 2 writes, with half sized accesses. If you go through gcc versions from
>> say, 4.0.x to 4.5.x and see what it generates from volatile bitfield code
>> (at least for ARM), it's sheer horror.

Just out of curiosity, what would you get from

myreg init_vals = {val1, val2, val3, val4};
*ptr = init_vals;

Mel.

[David Brown]

I don't know - I don't believe it is specified, so you'd have to try it
and see.

It is quite common to define structures of this sort like this:

typedef union {
uint32_t r;
struct {
uint32_t fld1 : 20;
uint32_t fld2 : 5;
uint32_t fld3 : 5;
uint32_t fld4 : 2;
} b;
}

The previous code is then:
ptr->b.fld1 = val1;
ptr->b.fld2 = val2;
ptr->b.fld3 = val3;
ptr->b.fld4 = val4;

(with the same slow and bulky code).

Your code would be:

myreg init_vals = { .b = {val1, val2, val3, val4}};
ptr->r = init_vals.r;

This is well-defined, and will result in a single 32-bit volatile write.

[Simon Clubley]

On 2012-01-29, David Brown <david...@removethis.hesbynett.no> wrote:
>
> To make such volatile bitfields more consistent (since people wanted to
> use them, despite being poorly specified by the C standards), gcc
> introduced the "-fstrict-volatile-bitfields" command-line option which
> makes the compiler always use the type-defined access size (16-bit in
> the example above). That way, you know exactly what you are getting.
>

Thank you. This sounds exactly like the functionality I was hoping was
in gcc somewhere.

This must be a new feature because it's not documented in gcc.info for
gcc 4.5.1 (which is the gcc version in my standalone ARM toolchain).

Simon.

[Simon Clubley]

On 2012-01-29, Paul <pa...@pcserviceselectronics.co.uk> wrote:
> In article <jg1uu7$k7o$2...@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP says...
>>
>> On 2012-01-28, Rich Webb <bbe...@mapson.nozirev.ten> wrote:
>> > On Sat, 28 Jan 2012 15:14:45 -0600, Joe Chisolm
>> ><jchi...@earthlink.net> wrote:
>> >
>> >>SchmartBoard has a line of adapters. Easy to work with. Never had any
>> >>issues ordering from them.
>> >>
>> >>http://www.schmartboard.com/index.asp?page=products_smttodip
>> >
>> > One feature of the Schmartboard is their "ez technology" which puts the
>> > SMT leads onto recessed pads, so they sort of "fall into place." Can't
>> > get much easier...
>> >
>>
>> Several people have now pointed me in the direction of these people.
>>
>> I'll have a look through their website and get up to speed on what they
>> offer.
>>
>> Thanks for the pointer everyone.
>>
>> Simon.
>
> They are available UK, I have used them and keep a few.
>

I am now mostly up to speed on them; this is a very nice product.

I was worried about the comments here about using jumper wires to connect
to the board, but I see they also offer boards (for the QFN parts) in
which you can insert the traditional 0.1 inch pitch connector strips which
makes for a robust connection to the stripboard/veroboard.

BTW, where do you buy your boards from in the UK ?

Two distributors are listed for the UK; Active Robots and Proto-Pic,
neither of which appears to sell this type of board:

http://www.schmartboard.com/index.asp?page=products_smttodip&id=451

A question about this product is the placement of decoupling capacitors
and crystal (thanks to whoever pointed this out) next to the MCU
instead of on the baseboard which the adapter would plug into.

For the people here who have actually used this product, how did you
solve this problem ?

Did you use the spare pads provided on the board and was this sufficiently
close to the MCU manufacturer's specifications to work ok ?

Thanks,

[Jim Granville]

On Jan 31, 1:36 pm, Simon Clubley <clubley@remove_me.eisner.decus.org-

Earth.UFP> wrote:
> http://www.schmartboard.com/index.asp?page=products_smttodip&id=451
>
> A question about this product is the placement of decoupling capacitors
> and crystal (thanks to whoever pointed this out) next to the MCU
> instead of on the baseboard which the adapter would plug into.
>
> For the people here who have actually used this product, how did you
> solve this problem ?

It is surprising they have not added SMD decoupling pads interleaved
with the 0.1" fanouts ? Their artwork would easily fit in the 45'
channels.

-jg

[David Brown]

On 31/01/2012 00:06, Simon Clubley wrote:
> On 2012-01-29, David Brown<david...@removethis.hesbynett.no> wrote:
>>
>> To make such volatile bitfields more consistent (since people wanted to
>> use them, despite being poorly specified by the C standards), gcc
>> introduced the "-fstrict-volatile-bitfields" command-line option which
>> makes the compiler always use the type-defined access size (16-bit in
>> the example above). That way, you know exactly what you are getting.
>>
>
> Thank you. This sounds exactly like the functionality I was hoping was
> in gcc somewhere.
>
> This must be a new feature because it's not documented in gcc.info for
> gcc 4.5.1 (which is the gcc version in my standalone ARM toolchain).
>
> Simon.
>

I believe it was added to a later 4.5 revision, and to the 4.6 tree.
Gcc tries to avoid adding new features in different revisions, so in the
mainline gcc trees it is available from 4.6 onwards. But patches were
made for the 4.5 trees, so you might find it in particular 4.5 builds (I
believe the current CodeSourcery arm gcc 4.5 has it, for example).

mvh.,

David

[Paul]

In article <jg7d1i$fmq$1...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

I have used Active Robots as my source a few times over the years.
Generally spoke to them on the phone, helpful bunch of folks.

> http://www.schmartboard.com/index.asp?page=products_smttodip&id=451

Give them a ring and ask them, they also distribute Sparkfun so you
avoid customs and import paperwork, if that is an issue for you.

> A question about this product is the placement of decoupling capacitors
> and crystal (thanks to whoever pointed this out) next to the MCU
> instead of on the baseboard which the adapter would plug into.
>
> For the people here who have actually used this product, how did you
> solve this problem ?

I have used the square boards and put decouplers usually 0805 or 0603
caps on the corner SMT mounting pads, sometimes a few pullups there as
well.

Generally my projects involve many clocks and often I have external
oscillator solution (a few gates and quartz as not too high frequency)
this works best as often same clock or subclock is needed eleswhere
so instead of multiple crystals I run the buffered clocks around the
board. In one case I needed one 12 MHz and two 6MHz so I created a
master 12MHz oscillator at 3V3 uning picogates, fed into PLD and did
divide by 2 in there and then ran 6MHz from 2 picogate buffers. The
two buffers were for a 5V and 3V3 clock. A few picogates uses less
space than multiple cystals.

>
> Did you use the spare pads provided on the board and was this sufficiently
> close to the MCU manufacturer's specifications to work ok ?

For caps it was, not normally enough room for a crystal, so buffered
clock drive was easier.

> Thanks,
>
> Simon.

[Paul]

In article <jg7d1i$fmq$1...@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...
>

For an example, with USB hub FTDI USB device, PLD with master 12 MHz and
20 MHz clocks, the PLD contains a frequency counter with gate timing
from 20MHz clock, amongst many other things.

See

http://www.pcserviceselectronics.co.uk/assembledfirstpass.jpg

[Frnak McKenney]

Hi, Linnix. Thanks for responding.

However, I'm a bit confused, and I suspect that (to quote an old
film) "Whut we hayev heah is fail-yuh tuh c'mun'cate"... I'm just
not sure how. <grin!>

I'll try to add a bit more description to the two drawing above
(Top and Side views). Imagine a PC board is etched leaving a set
of "standard" copper pads for a (say) TSOP-8 package. Then
imagine that a router (the drill kind, not the packet-shovelling
kind) is then used to remove a strip down the center of that pad.
The result is (vary roughly) "Y"-shaped, where the base of the "Y"
is the trace leading off to other components or traces.

This should leave a "trough" that the TSOP-8 (or whatever) lead
can lie in, and this will help keep the IC from moving about as
much as it would on an unaltered pad.

Does that make more sense? Or have I misunderstood what you were
saying? If the latter, could you explain in a bit more detail?

I agree that adding a groove in the board itself (as in the
SchmartBoard "ez" process) would add even more "stability"
(non-moving-ness) to the IC, but it requires an additional step in
creating the board. It seems as if a slightly differently-shaped
pad could accomplish much of the same purpose without that extra
step, and easing the soldering effort for boards from any source
with minimal redesign effort.


Frank
Frank McKenney
--
This evening they began to push the cars around to make way for
the wrecker train. The English soldiers turned out and so did the
nurses and Friends. Maran Lu got off a statement that will go
down in history. "I hope we never have to travel by airplane like
the Sixth Army girls," she said. "We travelled by jeep and had to
get out and push the jeep. We travelled by truck and pushed the
truck, by raft and had to push the raft, by train and had to push
the train. I shouldn't like to have to get out and push an
airplane!" -- Gordon S. Seagrave / Burma Surgeon

[Mel Wilson]

Frnak McKenney wrote:

> This should leave a "trough" that the TSOP-8 (or whatever) lead
> can lie in, and this will help keep the IC from moving about as
> much as it would on an unaltered pad.

On the board I'm looking at, the SMT pads are the same width as the leads.
A routed trough that leaves any copper on the board at all will be too
narrow for the lead. There isn't a lot of room to widen that pads either.
(Really covet one of those AdaFruit USB microscopes right now.) Risk solder
bridges or frying the infinitesimal copper strips off the board during
rework. From what I've read, the current scheme of things counts on the
surface tension of the melted solder to pull the part into alignment.

Mel.

[George Neuner]

On Mon, 30 Jan 2012 23:53:29 +1100, Zoltan Kocsi
<zol...@bendor.com.au> wrote:

>First, the standard specifies that each volatile access has to be a separate
>actual access. That generates a lot of unnecessary code:
>
>typedef struct { int fld1:20, fld2:5, fld3:5, fld4:2; } myreg;
>
>volatile myreg * const ptr = SOME_ADDRESS;
>
>then you want to initialise the register (say it's some config reg):
>
>ptr->fld1 = val1;
>ptr->fld2 = val2;
>ptr->fld3 = val3;
>ptr->fld4 = val4;
>
>will read and write the register 4 times and of course it will mask and set
>the fields individually. Except when some buggy versions of gcc decide to
>optimise it out and do a single write. Or possibly 2 reads and 2 writes, with
>half sized accesses. If you go through gcc versions from say, 4.0.x to 4.5.x
>and see what it generates from volatile bitfield code (at least for ARM), it's
>sheer horror.

One thing I haven't seen mentioned in this thread is the possibility
of the CPU combining multiple narrow writes into a single wide write,
or swallowing (only writing the last of) back to back writes to the
same location. The compiler has no control over any of this.

Much of the discussion has been about too many (code visible)
accesses. Regardless of the disassembly, the hardware actually may be
doing something different. If you really need multiple writes to
occur, some CPUs require a pipeline flush or write barrier occur after
each write. I am not aware of any compiler that correctly handles
this.

George

[David Brown]

Many processors allow you some control over this through an MMU or
similar mechanism - you can define areas that will not be cached, and
for which all reads and writes are executed as originally ordered. For
some cpus you may also need some sort of synchronisation or barrier
instruction to enforce the order (like the PPC's "EIEIO" instruction).
Compilers won't generate these automatically - you need to add them
yourself where you need them, and be aware that they often cost a fair
number of cycles due to pipeline flushes/stalls.

[Simon Clubley]

On 2012-01-31, Paul <pa...@pcserviceselectronics.co.uk> wrote:
> In article <jg7d1i$fmq$1...@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP says...

>>
>> BTW, where do you buy your boards from in the UK ?
>>
>> Two distributors are listed for the UK; Active Robots and Proto-Pic,
>> neither of which appears to sell this type of board:
>
> I have used Active Robots as my source a few times over the years.
> Generally spoke to them on the phone, helpful bunch of folks.
>
>> http://www.schmartboard.com/index.asp?page=products_smttodip&id=451
>
> Give them a ring and ask them, they also distribute Sparkfun so you
> avoid customs and import paperwork, if that is an issue for you.
>

Thanks. I've been in touch with them and am waiting to hear back from
them on pricing.

(And yes, customs is a major importing issue as far as I am concerned. :-))

>> A question about this product is the placement of decoupling capacitors
>> and crystal (thanks to whoever pointed this out) next to the MCU
>> instead of on the baseboard which the adapter would plug into.
>>
>> For the people here who have actually used this product, how did you
>> solve this problem ?
>
> I have used the square boards and put decouplers usually 0805 or 0603
> caps on the corner SMT mounting pads, sometimes a few pullups there as
> well.
>
> Generally my projects involve many clocks and often I have external
> oscillator solution (a few gates and quartz as not too high frequency)
> this works best as often same clock or subclock is needed eleswhere
> so instead of multiple crystals I run the buffered clocks around the
> board. In one case I needed one 12 MHz and two 6MHz so I created a
> master 12MHz oscillator at 3V3 uning picogates, fed into PLD and did
> divide by 2 in there and then ran 6MHz from 2 picogate buffers. The
> two buffers were for a 5V and 3V3 clock. A few picogates uses less
> space than multiple cystals.
>
>>
>> Did you use the spare pads provided on the board and was this sufficiently
>> close to the MCU manufacturer's specifications to work ok ?
>
> For caps it was, not normally enough room for a crystal, so buffered
> clock drive was easier.
>

Thanks for the detailed design notes (and thanks for the example
photograph in your other posting). It helps me to understand how
you are using the boards.

[Frnak McKenney]

Hi, Mel.

Thanks for jumping in.

On Tue, 31 Jan 2012 11:08:17 -0500, Mel Wilson <mwi...@the-wire.com> wrote:
> Frnak McKenney wrote:
>
>> This should leave a "trough" that the TSOP-8 (or whatever) lead
>> can lie in, and this will help keep the IC from moving about as
>> much as it would on an unaltered pad.
>
> On the board I'm looking at, the SMT pads are the same width as
> the leads. A routed trough that leaves any copper on the board

> at all will be too narrow for the lead. ...

Oh.

> ... There isn't a lot of

> room to widen that pads either. (Really covet one of those
> AdaFruit USB microscopes right now.) Risk solder bridges or
> frying the infinitesimal copper strips off the board during
> rework. From what I've read, the current scheme of things
> counts on the surface tension of the melted solder to pull the
> part into alignment.

... "Nevermind!" (*)

This is probably what linnix was trying to tell me. (Sorry about
that!)

For what it's worth, I have one of those USB 'scopes, and it takes
really nice pictures, but it does have a few drawbacks for someone
who wants to use it in place of an assembly/inspection microscope.
First, it's hard to focus: the "knurled" focus adjustment is stiff
and tends to shift the microscope while you adjust it. It's often
easier to set the focus, then move the microscope around to get
the view you want. Second, it's light, and unless you're
extremely careful it gets bumped so the object being disappears
out of frame. Hand-held pictures are not impossible, but tricky
without an arm rest.

I've been meaning to build something out of an old gooseneck lamp,
but haven't gotten "a round tuit" yet.

If you're curious, you can find a number of USB microscopes here:

http://www.bhphotovideo.com/

Just do a search on... well, "usb microscope". <grin!>


Frank

(*) http://en.wikipedia.org/wiki/Emily_Litella

--
The study of history is a painful antidote to contemporary
arrogance. It is humbling to discover how many of our glib
assumptions, which seem to us novel and plausible, have been
tested before, not once but many times and in innumerable guises;
and discovered to be, at great human cost, wholly false.
-- Paul Johnson

[Tim Wescott]

It sounds like an excellent solution to a nearly-nonexistent problem.

I have no trouble soldering 0.5mm pitch parts onto bare (no solder mask)
boards; while I have the advantage of an assembly microscope, even before
I got it I could still get the job done with a watchmaker's loupe and
some care taken.

You just tack down the corners of the chip, goober solder on all over
everything without worrying about solder bridges, then use desoldering
braid to remove all the bridges you just created.

That seems "schmarter" than using someone else's prototyping board, to me.

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

[Przemek Klosowski]

On Sat, 28 Jan 2012 23:00:34 +0000, Simon Clubley wrote:

> On 2012-01-28, Mark Borgerson <mborg...@comcast.net> wrote:

>> If you can print legibly, your hands are probably steady enough. A
>> good binocular microscope is handy for more than soldering and
>> shouldn't cost more than $300.
>
> While such a microscope would be affordable, for me, that would count as
> a investment I would not want to make until I was sure of myself.

While a nice binocular microscope with large field of view and focal
distance, and perhaps with long and movable arm is expensive, I am using
a ghetto microscope that I got on Ebay for $30. I use it for electronics
and for ton of other household tasks (splinter removal and other domestic
surgeries), probably at least once a week over last several years. One of
the better tool investments I made.

I don't see it now for the price I got it from, but it is almost exactly
like this one:
http://www.ebay.com/itm/Inspection-Binocular-Microscope-Coin-Rock-Stamp-
Circuit-/200279748681?pt=LH_DefaultDomain_0&hash=item2ea19a7049

[Przemek Klosowski]