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. 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 | 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
ARM (or other 32 bit) MCUs in PDIP ?
Started by ●January 27, 2012
Reply by ●January 29, 20122012-01-29
Reply by ●January 29, 20122012-01-29
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.
Reply by ●January 29, 20122012-01-29
On Sun, 29 Jan 2012 09:52:48 -0000, Paul <paul@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). -- Rich Webb Norfolk, VA
Reply by ●January 29, 20122012-01-29
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 ;-)
Reply by ●January 29, 20122012-01-29
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.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...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
Reply by ●January 29, 20122012-01-29
On Jan 29, 9:58=A0am, 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: > > =A0 =A0[...] > > >>SchmartBoard has a line of adapters. =A0Easy to work with. =A0Never > >>had any issues ordering from them. > > >>http://www.schmartboard.com/index.asp?page=3Dproducts_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: > > =A0 =A0http://www.schmartboard.com/index.asp?page=3Dmovie > > and it looks like a neat technique. =A0I wonder if it could be > approximated by creating "Y"-shaped pads like these: > > =A0 =A0 Top View > > =A0 =A0 =A0 =A0 /---------------------------------\ > =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0 =A0 |> =A0 =A0 =A0 / =A0 =A0 =A0 =A0 Pad =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0==A0 =A0|> =A0 ---- =A0 =A0 =A0 /----------------------------/ =A0 =A0+-------------=---> =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0 =A0 =A0 =A0 |> =A0 =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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0==A0 =A0 =A0| =A0 +----------------> =A0 =A0 =A0 =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0 =A0 |> =A0 =A0 =A0 =A0 \---------------------------------/ > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0 =A0 =A0 =A0 =A0+----------------> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0 =A0 =A0 =A0 =A0|> =A0 =A0 Side View =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 =A0 =A0 =A0 ==A0 =A0 =A0 =A0 =A0 =A0|> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0 =A0 =A0 =A0 =A0+----------------> =A0 -----------------------------------------+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Pad =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ==A0 =A0 =A0 |> =A0 -----------------------------------------+ > > 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.
Reply by ●January 30, 20122012-01-30
On Sun, 29 Jan 2012 12:55:35 +0100 David Brown <david.brown@removethis.hesbynett.no> wrote:> To make such volatile bitfields more consistent (since people wanted to=20 > use them, despite being poorly specified by the C standards), gcc=20 > introduced the "-fstrict-volatile-bitfields" command-line option which=20 > makes the compiler always use the type-defined access size (16-bit in=20 > the example above). That way, you know exactly what you are getting. >=20 > 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 =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.
Reply by ●January 30, 20122012-01-30
On 30/01/2012 13:53, Zoltan Kocsi wrote:> On Sun, 29 Jan 2012 12:55:35 +0100 > 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. >> >> 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
Reply by ●January 30, 20122012-01-30
David Brown wrote:> On 30/01/2012 13:53, Zoltan Kocsi wrote: >> On Sun, 29 Jan 2012 12:55:35 +0100 >> David Brown<david.brown@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.
Reply by ●January 30, 20122012-01-30
On 30/01/12 17:43, Mel Wilson wrote:> David Brown wrote: > >> On 30/01/2012 13:53, Zoltan Kocsi wrote: >>> On Sun, 29 Jan 2012 12:55:35 +0100 >>> David Brown<david.brown@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. >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.
