On 2012-01-29, David Brown <david.brown@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, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
ARM (or other 32 bit) MCUs in PDIP ?
Started by ●January 27, 2012
Reply by ●January 30, 20122012-01-30
Reply by ●January 30, 20122012-01-30
On 2012-01-29, Paul <paul@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 <bbew.ar@mapson.nozirev.ten> wrote: >> > On Sat, 28 Jan 2012 15:14:45 -0600, Joe Chisolm >> ><jchisolm6@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, Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●January 30, 20122012-01-30
On Jan 31, 1:36=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org- Earth.UFP> wrote:> http://www.schmartboard.com/index.asp?page=3Dproducts_smttodip&id=3D451 > > 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
Reply by ●January 31, 20122012-01-31
On 31/01/2012 00:06, Simon Clubley wrote:> On 2012-01-29, David Brown<david.brown@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
Reply by ●January 31, 20122012-01-31
In article <jg7d1i$fmq$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP says...> > On 2012-01-29, Paul <paul@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 <bbew.ar@mapson.nozirev.ten> wrote: > >> > On Sat, 28 Jan 2012 15:14:45 -0600, Joe Chisolm > >> ><jchisolm6@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: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=451Give 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 Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
Reply by ●January 31, 20122012-01-31
In article <jg7d1i$fmq$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP says...> > On 2012-01-29, Paul <paul@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 <bbew.ar@mapson.nozirev.ten> wrote: > >> > On Sat, 28 Jan 2012 15:14:45 -0600, Joe Chisolm > >> ><jchisolm6@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 ?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 -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
Reply by ●January 31, 20122012-01-31
On Sun, 29 Jan 2012 10:14:32 -0800 (PST), linnix <me@linnix.info-for.us> wrote:> 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. >> >> On Sat, 28 Jan 2012 17:23:01 -0500, Rich Webb <bbew...@mapson.nozirev.ten> wrote: >> > On Sat, 28 Jan 2012 15:14:45 -0600, Joe Chisolm >> ><jchiso...@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". >> > > 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.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 -- Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 Munged E-mail: frank uscore mckenney aatt mindspring ddoott com
Reply by ●January 31, 20122012-01-31
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.
Reply by ●January 31, 20122012-01-31
On Mon, 30 Jan 2012 23:53:29 +1100, Zoltan Kocsi <zoltan@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
Reply by ●January 31, 20122012-01-31
On 31/01/12 18:42, George Neuner wrote:> On Mon, 30 Jan 2012 23:53:29 +1100, Zoltan Kocsi > <zoltan@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. > > GeorgeMany 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.
