ARM (or other 32 bit) MCUs in PDIP ?

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.

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

How about this for only $200?

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.

some

found

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

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

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.

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

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.

Dimiter

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

------------------------------------------------------

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.

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

Mark Borgerson

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

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.

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

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.

I've used the off-shore pooling service that Sparkfun started 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

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

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.

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.

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

Well, good luck with that, then ;-)

I took a look at their three-minute video:

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 ---- \----------------------------\ | \ | +---------------- \ | \---------------------------------/

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

Frank McKenney

=A0 =A0 =A0 |

=A0 =A0|

---

=A0 =A0 =A0 =A0 =A0 |

=A0 =A0 =A0 =A0 =A0 | =A0Lead

=A0 =A0 =A0| =A0 +----------------

=A0 =A0 =A0 |

=A0 =A0 =A0 =A0 =A0 =A0+----------------

=A0 =A0 =A0 =A0 =A0 =A0|

=A0 =A0 =A0| =A0Lead

=A0 =A0 =A0 =A0 =A0 =A0|

=A0 =A0 =A0 =A0 =A0 =A0+----------------

=A0 =A0 =A0 |

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.

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 =3D SOME_ADDRESS;

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

ptr->fld1 =3D val1; ptr->fld2 =3D val2; ptr->fld3 =3D val3; ptr->fld4 =3D 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, wi= th 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), i= t'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

--=20 Zolt=C3=A1n K=C3=B3csi Bendor Research Pty. Ltd.

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

Agreed.

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

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.

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

Just out of curiosity, what would you get from

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

Mel.

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.