How do you keep your MOSFETs running cool?
- Flyback diodes?
- Managing the PWM frequency?
- Big heat sinks?
- More MOSFETS in parallel?
Remember, no matter where you go, there you are.
Down at the Company Blog
How do you keep your MOSFETs running cool?
Remember, no matter where you go, there you are.
I've been spending some time with the mbed here and I'm convinced that there are a lot of good uses for this little thing. One in particular popped in to my head with a lot of vigor.
Back in December of 2008, I listed ten (Octal) things to do to help get through a lousy economy (read #3). If you're pretty much a pure hardware engineer, now might just be a good time to develop some firmware skills.
In my mind, one of the biggest problems going from hardware to firmware isn't the programming itself. That's not really as tough to pick up as you might think. But it's the environment. The tool chains. The configurations. Make files, environment variables, linked libraries, boot loaders, ICSP, flag bits... There's a load of ancillary junk that gets in the way. Some micros require purchased proprietary compilers. Some use open source. Should you use C or C++ or ASM? Too many choices.
Well, here's something that gets rid of all of that extra junk. Plug in an mbed and in minutes you can be experimenting with C programming on an embedded micro controller. Use the onboard LEDs and sample programs to get instant gratification. Plug in some external LEDs or a sensor of some type (maybe from sparkfun) as you get a little more versed in the language. Save the data to the FLASH and graph it in Excel or something.
My personal feeling is that a hardware engineer is much more employable these days with the ability to write firmware. I haven't found a better way to get started then with an mbed. You can worry about all of the other details later, but use this little guy to teach yourself to code.
It's been a soft day's night, and I've been coding like a frog
I wrote about the new mbed development board a while back and mine just arrived over the holiday weekend. I have to say, true to it's promise, It was the easiest piece of development hardware that I've ever brought up:
That's ten steps, but it's only ten steps. There was nothing else to do. Nothing. The longest step was number seven which took me about two minutes. I programmed a "Knight Rider" sweeper with the four on-board LEDs. I made one of those for my Jack-o-lantern back at Halloween, so it was the first test program that popped into my head.
I built the Jack-o-lantern sweeper with eight LEDs and an 8 bit PIC16F819. The PIC I used came in an 18 pin thru-hole DIP package, costing $3.22 at Digi-Key, and I hand soldered it all on an old perf board. It runs at 20MHz, has 16 GPIO, 3.5K program code space, 256 bytes of FLASH and 256 bytes of RAM.
The 32 bit NXP LPC1764 runs at 100MHz in a 100 pin LQFP and costs $8.70 in quantity of one at Digi-Key. (The dev board, of course, costs more then that) It has 512K of program FLASH and 64K of RAM. The dev board can have up to 25 GPIO (the chip can have up to 70 GPIO with your hardware) along with the standard assortment of peripherals that can be configured, including six hardware PWM channels. The mbed dev board is like a breakout board configured as a 40 pin 0.1" DIP so it will be easy to prototype with.
The processor, being a fine-pitch package really isn't hand-solderable like the PIC except for by the most adventurous of folks, but that's where Screaming Circuits comes in. Why wait for your custom hardware before starting on the software. Get one of these mbed dev boards to work on your software while the EE folks are designing the custom hardware. Then, when they're done, we'll assemble up the prototypes and you can integrate it all together. Take some time out of your development schedule that way.
I've wanted to try out an ARM processor for quite a while, but prior to this, haven't found the right way to do so while keeping within the limits of my time availability and skill set, but this looks like it could very well do the job.
I posed a question about using copper pours (AKA flood) a not long ago. The premise was a simple microcontroller board with a 20MHz clock and no special requirements.
I had a couple of different comments on the post with some very good insight. Myself, I generally don't use copper pours. My only reason is that I think it usually looks better without. Although, I do like the look of the cross-hatch pour on the Arduino. A well done flood can be pretty cool, but still my inclination is to only use it if it's needed. If it's a shop doing the PCB, the metal will be recovered and recycled, so the conservationist in me is pleased.
If it's a home etched deal, then a pour is probably a better idea because it will reduce the amount of etchant needed. Although you do need to be careful to keep plenty of space between things to prevent solder bridges. Solder bridging isn't such a big deal on a PCB with a good solder mask, but it certainly is on a board with no mask or thin mask.
If there is a good reason, I will. Like a high-current motor driver - I use the pour to keep the current capacity up and the kelvons mellow. Heat sinking is a good reason for a pour. Hi speed stuff usually benefits from a flooded plane of some sort too and in four-layer boards, using the inner planes for power and or ground is nice and convenient. But you all know that. I'm just rambling now.
Does high speed stuff on a flooded plane require a speed boat?
Will too much heat sink it?
I know there are plenty of times when a copper-pour ground or power plane is a good idea, sometimes even a requirement. But, is it always so? Take a simple embedded microcontroller board. It has a 20MHz clock speed. Nothing too dramatic. No big power drains anywhere. Just milliamps going here and there.
Does it still help? What about the "greenness" of it? If more of the copper is etched off, more metal will be recovered from the fab company's chemical vats. Or does the additional etch time and and acid required for clearing the board of copper outweigh the benefits of the additional recovered copper?
Looking at all of the boards we get through our assembly lines here, I can't really tell a general industry preference. It's hard to detect an internal plane visually and surface pours don't seem to be any more popular then the lack of them. So, I don't know what the world says.
Any thoughts on this? Anyone? Anyone?
Screaming Circuits and Sunstone Circuits have partnered for board fab and assembly for many years and now, we've made things easier for our common customers. You can order Screaming Circuits Assembly at Sunstone while your order your board fab.
Just order your boards from Sunstone like you always have, but on the Sunstone.com quote page (for PCBexpress or Full Featured PCBs), check the box labeled: "NEW! Quote & Order Assembly" as shown in the screen capture below.
Check the box pointed at by the big red arrow I added in to the screen capture above. Then, you'll get a box to pop up with two choices: "Drop Ship Assembly" and "Bundle Assembly". If you select to drop ship with the button "Select Assembly", after your boards are fabbed, they will be sent directly to Screaming Circuits. With this option, you'll have to go ahead and come to our website and place your order separately before the boards get here. We've had that option for quite a while.
If you choose the new option, to bundle, by clicking "Quote Assembly" you will see a quote form and you'll be able to quote and order your assembly right then and there. The order will be placed with us, the boards will be shipped to us and you'll get fully assembled boards from us. You will still have to send us the parts and make sure we have all the files we need though. We'll get your order ready in our system and give you a call to make sure that we have everything that you need.
You can, of course, still order your boards and your assembly separately. That's not a problem at all, but if you are getting your PCBs fabbed by Sunstone Circuits, we hope this added feature will make your job just a little bit easier.
I've written a bit about open source hardware before, mostly in reference to the Beagleboard. I'm pretty sold on the concept, myself. But, while open source has become a household concept in the software world, it's still fairly new to hardware. In the case of the Beagleboard, it's really cool because it can give a designer a big head start on using the Ti OMAP processor. Anything from the whole schematic down to just the BGA escape routing can be applied to any design.
But it's not just that. Say I have a little microcontroller board that I've put together. I use it for robots and other sorts of tinkering. It's PIC based and pretty simple. Right now, it just communicates with the outside world via RS232, but I want to add USB to it. I could start with Digi-Key and search for all of the various USB chips and spend hours digging through data sheets to see which one looks best/easiest to implement for my application. Or...
Arduino. Beagleboard is open source hardware based on the ARM Cortex-A8 OMAP3530 processor from Ti. Arduino is open source hardware based on an 8-bit Atmel microcontroller. They both have USB interfaces and I know that both boards work well and have been pretty thoroughly debugged.
Here's two examples that a lot of other folks have already spent time on. I want to spent my design time on the unique parts of my board - the things I've done to make it easy for the types of projects that I want to do with it. USB is USB. I don't want to spend my time doing something that a million other people have already done. I can take a look at the two approaches here and pick one and be done with it. I don't have to dig through web sites to find data sheets and then try to interpret the manufacturers reference design and hope it was fully thought out and tested. I hate that. Some chips come with great reference designs. Some don't come with any and some come with half-baked schematics that only work in the very specific test environment of the chip company's lab.
I know these two work. I can pick one, plop it into my design, make sure I give proper attribution and then just run with it. Very nice and a big time saver.
Eeny, meeny, miny, moe
Catch a usb-controller by the Vcc.
This is the third or fourth in this series. I paused for a while and just picked it back up again. As I eat my soup and write this, it occurs to me that I've given each post a different name so if anyone actually wants to follow my progress, I've made it quite difficult to do so. I'll recap first and then later, try to be more consistent with post titles.
From now on, I'll identify this series as "PCB123 ZigBee Robots, Part X".
Anyway, enough of that rubbish. I've picked it up again and this morning created the library part for the QFN28 PIC18F2321 microcontroller. I'm lousy at building footprints so I consider that a major accomplishment.
I have a couple more footprints to make - a DFN8 regulator and a CSP BGA RS232 chip. I muddled through the microcontroller but after I do those other two chips, I should be clear enough to able to post some hints on how to make your library components in PCB123.
Later - I'm going to finish my soup now.
First things first. I still haven't received the little ZigBee modules. Microchip said they'd ship out on the 14th so I shouldn't expect any different. I'm going ahead and getting started on the schematic anyway.
When I get the modules, I'll probably write the code and try them out on an old PIC board that I designed and built a while back. But eventually, I want a nice small integrated package so that means a new schematic and layout. I have the schematic partially done in another CAD package, but I'm rolling with Sunstone's PCB123 this time.
The first thing to do is start looking at the components. I expect the footprints will be there for all of the passives, but given that PCB123 V3 is fairly new, I would also expect that some of the more complex parts won't be there. I'm tackling the PIC 18F2321 in a QFN28 package first. It will be a good opportunity to see if I can follow my own advice and make an easily and reliably manufacturable library component.
Most of it will be easy, but I will likely put some vias in the center pad area. I'll mask them properly. I'll also make sure that I create a proper paste stencil area. It's a 6x6x0.9 mm, 28 lead QFN package. The datasheet has the basic outline, but it also references a more detailed packaging specification on the Microchip website. I'll go there and get as much footprint information as they have.
Of course, even there I can find room for confusion. Microchip lists eight 28-Lead QFN footprints. Ugh. Just to be clear, this is the 6x6x0.9 mm with .40 mm contact length. Page 135. Ironically, the page in that detailed specification is the same one as in the datasheet and it even uses the same "For the most current package drawings..." statement referring to it's self. And no where in this 192 page document could I find anything on the paste layer. I'll segment the paste opening in the middle pad and shoot for about 50% coverage.
You must go here to be told to go there
I like the ZigBee module from Microchip that I wrote about below. But theory and practice aren't always the same, so I've ordered two of the modules to try out.
In my spare time, I sometimes build little robots and I've wanted to try out wireless for some time now. I don't have enough time to dig into the low level stuff and figure out how to do it from scratch so these modules seem like they might just be the ticket.
I'm going to see if I can integrate some ZigBee into my robots with these modules and I'll keep you posted on the progress. The modules are backordered at Microchip until November 14th, but that will give me some time to dig out some of the old bot boards and get ready. I'll prototype up the software with my old boards and at the same time, I'll get PCB123, from Sunstone Circuits, out and do a re-design to use more surface mount and shrink the boards.
Check back here periodically to see my progress and if all goes well, I'll have the actual bots in our booth at Embedded Systems Conference, Silicon Valley in April 2009.
Wireless minds want to know