标签: prototyping

Well, things are definitely going at a brisk pace here in the Pleasure Dome (my office). As you may recall from my previous blog on this topic, my chum Duane Benson and I decided to create our own prototyping shield for the Arduino. Originally, we dubbed this the Bodacious Bensonfruit Arduino Uno/Mega Proto Screwshield, but we now refer to it as the Universal Screw-Block Proto-Shield System for Arduino. Why the name change? There are a number of reasons. For example, we originally thought of our proto-shields only in terms of Arduino Unos and Megas, because these were the only types of Arduino we own. But then we realised that our system would also work with Arduino Dues and Leonardos, along with any chipKIT equiavlents, hence the universal part of our new moniker. The really exciting news is that we've decided to make this into a Kickstarter project. We started to research the use of the Arduino name on Kickstarter. It turns out that you aren't allowed to say things like "Arduino xxxxxx." Instead, you have to say "xxxxxx for Arduino," which explains this portion of our name change. I'll be talking about our Kickstarter project in the not so distant future, but first I wanted to bring you up to date on the state of play. The first boards are back from the manufacturer and shown below. We've since respun a couple of items (such as the silkscreens), but the fundamental design is unchanged.   Top view of the Universal Screw-Block Proto-Shield PCBs.   Bottom view of the Universal Screw-Block Proto-Shield PCBs. Of course, I immediately soldered all the headers, screw terminal blocks, and other components on to my Screw-Block Proto-Shields, and then I started to integrate them into my Inamorata Prognostication Engine project. My first task was to use the Screw-Block Proto-Shields to make it easier for me to connect my Adafruit RGB LCD Shield Kit to my Arduino Mega. Let me walk you through this step by step, so you can see just how cunning this is. Consider the following images, which show my Arduino Uno and my LCD Shield. First we see them laying side by side, and then we see the LCD shield plugged into the Arduino Uno.   Arduino Uno with LCD Shield separate.   Arduino Uno with LCD Shield mounted.   Now consider the following image of my Arduino Mega with the same LCD shield. This is the Arduino I'm using to control my Inamorata Prognostication Engine.   Arduino Mega with LCD Shield separate. Many shields designed for the Arduino Uno will work with Arduino Leonardos, Dues, and Megas—without any modification or messing around . Unfortunately, this is not the case with my LCD Shield, which is controlled via a two-wire I2C interface. One advantage of the interface is that we need only two pins to control the LCD display. Another advantage is that we can control a whole bunch of shields using the same two pins, because each entity on the I2C bus has a unique I2C address. What's the problem? Well, for reasons that probably made sense to the designers of the various flavours of Arduino, the I2C pins for the Due, Leonardo, and Mega are in different locations from the Uno's pins. Thus, until now, I've been obliged to connect my LCD shield to my Arduino Mega using flying wires.   Arduino Mega with LCD Shield connected by flying wires. At least, this works, but implementing things this way looks a tad untidy, and it's a bit of a pain. Now consider the image below, which shows my Arduino Mega in the foreground, my universal screw-block proto-shield boards in the middle, and my LCD shield in the rear.   Arduino Mega, proto-shields, and LCD Shield separate. In particular, observe the two yellow and green wires on the screw-block proto-shields. These link the I2C pins used by my Arduino Mega to the A4 and A5 pins used to implement the I2C interface on an Arduino Uno. Now I can simply stack all the boards together, and my Arduino Mega can drive my LCD shield directly, as illustrated below.   Arduino Mega, proto-shields, and LCD Shield mounted. By default, all the pins on an Arduino power up as high-impedance inputs, which means that the A4 and A5 pins don't interfere with the I2C interface. The downside is that I can no longer use the A4 and A5 analogue inputs for anything else, but this really doesn't bother me. The Arduino Mega has 16 analogue inputs to play with, and my project requires only a subset of these. The great thing about the LCD display is that I can easily use it to display the values of different variables in my program. This facilitates debugging (and I'm doing a heck of a lot of debugging). That's where we are at the moment. Well, not quite. Since these images were taken, I've added an I2C-based real-time clock and an I2C-based motor control shield to my shield stack. Soon, I'll be adding a bunch of discrete components to my screw-block proto-shields to drive my analogue meters, but that's a tale for another day. In the meantime, what do you think about our proto-shields so far? And are you interested in hearing more about the adventures involved in launching our Kickstarter project?  

I just read Max the Magnificent's blog: What? EEs who do not know how to solder? Sadly, unlike Max, I was not "shocked" or "flabbergasted" to learn that some engineers can't or don't solder. Like so many things in the modern world, hand-soldering is no longer a required skill. It's useful, and I personally think that everyone in the industry should have the skill, but it's not a requirement anymore. Years ago, I would draw a schematic on paper, acquire the requisite parts, and test the design using solderless breadboards. Once I was confident enough to create a more durable prototype, I would get out my wire-wrap tools or soldering iron. Even when wire-wrapping, I would often need to solder a few parts down. Soldering was inevitable and it wasn't really possible to be involved in electronics without the skill. Today, however, the situation is a quite a bit different. It is very possible, perhaps even common, for an engineer to go from idea to finished product without ever putting iron to solder. This is not to say that problems don't crop up in the process. Some of these problems could be fixed with a hot iron, but not always. The only choice may be to re-spin the PC board and have it built by someone else. Sometimes the problems simply can't be resolved by hand and—in those cases—soldering skills will help about as much as sewing skills. Take a common problem in the prototyping domain: an incorrect footprint on the PCB. This is probably the most frequent design issue to pop up in my world. It can have a couple of different causes: 1. Metric vs. SAE measurements: It's not just Mars Probes that have this problem. Connectors see this one a lot. If you have only four positions on a 0.1" (2.54mm) pitch header strip and you try to use a metric 2.50mm pitch header strip... no one will care. However, if you try that with 25 positions, even good soldering skills likely won't help make it fit. You'll need a new PCB. 2. QFN vs. QFP footprints: Many newer chips, especially in these form factors, don't have pre-made land patterns in CAD software. Either a footprint has to be custom made or a similar one has to be borrowed from a pattern that's close enough. QFP (quad flatpack) land patterns look very similar to QFN (quad flatpack, no lead) land patterns, but are typically larger. Swap the two and, again, hand soldering skills may not get you anywhere. Not long ago, I was designing in a Microchip MCP72833-AMI/MF. It's a compact LiPoly charger, requiring no more than a few resistors and capacitors. It comes in two form-factors: a 3 mm x 3 mm DFN (dual inline flatpack no leads) and a slightly larger MSOP. I picked the DFN to save PCB real estate. It wasn't until after I had PC boards in hand that I discovered the DFN isn't available in the small quantities I need. This was a bad time to discover such an issue. Had I checked and discovered that information early in the design cycle, I would have designed in the MSOP. The land patterns are close, but not close enough that I could place the MSOP on the DFN land. Some people might turn the chip upside down and run individual 24 gage wire from the chip legs to the PCB footprint, but with 0.5mm pitch leads, I just can't do that—despite 30 years of hand soldering experience. 3. Form factors not available: You may have designed in a BGA only to find that particular package unavailable and purchase time. Part availability in a different package won't help, nor will hand soldering skills. Take the NXP LPC11U14 ARM processor. It comes in a 4.5mm x 4.5mm BGA, a 7mm x 7mm QFP, and a 5mm x 5mm QFN. There are two other parts in the family: LPC11U13 and LPC11U12. All three are virtually identical except for the amount of Flash memory. The BGA would be idea for keeping things small. After completing the firmware, however, I might decide that I don't need all 32K of the Flash. The LPC11U12 only has 16K and costs less. That's fine, except the LPC11U12 doesn't come in the BGA form factor. Hand soldering won't help in any of the three scenarios described above. Of course, there are always a few exceptions to everything. I once met a guy who has hand-soldered 01005 passive components. He's a wizard though, so that doesn't really count. So, in summary, my personal opinion is that electronics engineers should know how to solder, but I do know that not all need to. What do you think? Duane Benson Marketing Manager Screaming Circuits  

EE Times Asia is going around asking engineers like yourself to talk about a technology or an application of a technology that you feel will affect us the most—the way we work, play and live our lives.   To get the ball rolling, I decided to first post my nomination and realized that it's not an easy task. If you get starry-eyed like me reading about the latest from the labs or pine for the newest gizmo, the job just gets tougher.   I've had to put aside a breakthrough in genetic engineering that's created the first coconut-flavoured pineapple. It's a game-changer for cocktails—it cuts the inventory required for making, say Piña Coladas, by a third! But the impact of this technology on engineers may not be desired by all.   I also had to reject my wife's suggestion of a robotic vacuum cleaner even though the algorithms they use are neat work—it's been around for some time and keeps getting better.   There are other worthy contenders, like FinFETs and in-memory computing to name a few, and I'm sure some of you may elect them as the key technologies for 2013. And indeed they will be important technologies this year. My favourite, however, is 3D printing.   The technology is currently at a stage where individuals and small-to-medium enterprises can use polymers to manufacture fairly complex designs. While there's a good choice for printing with various types of polymers, metal printing is also evolving and there's early research into tissue (yes, the human kind!) printing. The companies behind the printers are already targeting their products at consumer electronics, electric vehicle, medical, toy and repair/servicing segments.   Think rapid prototyping and just-in-time manufacturing. Think hospitals printing out not just custom prosthetics and hearing aids but implantable tissue. Think UAV parts for defence, and cellular phone cases and camera parts for the consumer. Think automotive parts… But those are not the only reasons this technology wins my vote. As 3D printing lowers the cost of prototyping and small-batch manufacturing, I believe it has the potential for lowering barriers to entrepreneurship in Asia. Think new products. Think empowering engineers.   Here's a smattering of companies, although there are many more in this field: 3D Systems Corp. , Stratasys Ltd (they acquired Objet last month; they have several companies, including the printing service provider, RedEye), Mcor Technologies , Solido3D and Asiga . There are also several companies that cater to 3D printing at a personal level, such as Afinia , 3D Systems' Cubify (above), Airwolf 3D , PP3DP , Makerbot and Printrbot . There are several printing service providers as well; a company called Shapeways even offers a community and a platform for you to sell your designs.   If you don't agree with my nomination, express your disagreement by sending in your own nomination at disruptiveengineering@gmail.com . Here are the rules of play:   1. Describe and justify your nomination in 300-500 words. You can write about a technology someone else has developed, but if you feel you have a winner in something you or your colleagues developed, go ahead and let everyone know about it. 2. Include citations, such as who developed the technology or is developing it, and source of market data if you are quoting any. 3. Tell us about yourself in about 50 words and include your full name, current job title, company name and a JPEG photo.   Oh! Do send your entries early. We are accepting entries until Feb.28, 2013.   If you do agree with my nomination, you can still participate: just let me know what you think in the comments section below.   Happy New Year!  

EE Times India is going around asking engineers like yourself to talk about a technology or an application of a technology that you feel will affect us the most—the way we work, play and live our lives.   To get the ball rolling, I decided to first post my nomination and realized that it's not an easy task. If you get starry-eyed like me reading about the latest from the labs or pine for the newest gizmo, the job just gets tougher.   I've had to put aside a breakthrough in genetic engineering that's created the first coconut-flavoured pineapple. It's a game-changer for cocktails—it cuts the inventory required for making, say Piña Coladas, by a third! But it just wouldn't cut it in a certain state.   I also had to reject my wife's suggestion of a robotic vacuum cleaner even though the algorithms they use are neat work—it's been around for some time and keeps getting better.   There are other worthy contenders, like FinFETs and in-memory computing to name a few, and I'm sure some of you may elect them as the key technologies for 2013. And indeed they will be important technologies this year. My favourite, however, is 3D printing.   The technology is currently at a stage where individuals and small-to-medium enterprises can use polymers to manufacture fairly complex designs. While there's a good choice for printing with various types of polymers, metal printing is also evolving and there's early research into tissue (yes, the human kind!) printing. The companies behind the printers are already targeting their products at consumer electronics, electric vehicle, medical, toy and repair/servicing segments.   Think rapid prototyping and just-in-time manufacturing. Think hospitals printing out not just custom prosthetics and hearing aids but implantable tissue. Think UAV parts for defence, and cellular phone cases and camera parts for the consumer. Think automotive parts… But those are not the only reasons this technology wins my vote. As 3D printing lowers the cost of prototyping and small-batch manufacturing, I believe it has the potential for lowering barriers to entrepreneurship in India and beyond. Think new products. Think empowering engineers.   Here's a smattering of companies, although there are many more in this field: 3D Systems Corp. , Stratasys Ltd (they acquired Objet last month; they have several companies, including the printing service provider, RedEye), Mcor Technologies , Solido3D and Asiga . There are also several companies that cater to 3D printing at a personal level, such as Afinia , 3D Systems' Cubify (above), Airwolf 3D , PP3DP , Makerbot and Printrbot . There are several printing service providers as well; a company called Shapeways even offers a community and a platform for you to sell your designs.   If you don't agree with my nomination, express your disagreement by sending in your own nomination at disruptiveengineering@gmail.com . Here are the rules of play:   1. Describe and justify your nomination in 300-500 words. You can write about a technology someone else has developed, but if you feel you have a winner in something you or your colleagues developed, go ahead and let everyone know about it. 2. Include citations, such as who developed the technology or is developing it, and source of market data if you are quoting any. 3. Tell us about yourself in about 50 words and include your full name, current job title, company name and a JPEG photo.   Oh! Do send your entries early. We are accepting entries until Feb.28, 2013.   If you do agree with my nomination, you can still participate: just let me know what you think in the comments section below.   Happy New Year!

The marketing claims of how a company's products can improve time to market, improve quality, and lower costs have been heard a million times. The three pillars of marketing rhetoric. It reminds me of those old comic book ads where some 97-pound weakling gets sand kicked in his face with his girlfriend nearby and then sends away for a body-building book. The final scene shows him as the hero of the beach after he beats up on the bully.   Times have definitely changed but the marketing hype hasn't, though there's certainly a place and time for pulling up a few tried and true marketing campaigns. More on that later. Instead of marking rhetoric, I'm going to describe two real case studies where the design teams on different continents were able to reduce their design cycle time and how they did it. In both of these examples, the design teams used virtual prototyping and accurate models to drastically reduce their development time. In each case, they went into production with the designs they developed with this methodology much earlier than they would have if they didn't use it. Case Study #1: A large European company designing a controller application for factory automation was implementing a system on chip (SoC) with ARM Cortex R series cores. The design team had already been using 100% cycle-accurate models and virtual prototyping tools to bring up, debug and optimise its firmware prior to having silicon available. This was a key part of the methodology because in the past they found that even if the firmware ran successfully on behavioural untimed models (or Fast Models), they still found many problems in the firmware after they replaced the behavioural models with cycle-accurate models. The reason for this was due to the fact that the behavioural models lacked the details and accuracy to expose many of the firmware bugs. The manager was confident in his methodology but wanted to quantify it somehow. He compared his virtual prototyping flow to similar projects that didn't use virtual prototyping. For projects using virtual prototyping, he found the firmware could be debugged and validated in about 4 to 5 weeks. For projects that didn't use virtual prototyping, he found the firmware took as much as 6 months to debug and validate. A five-month savings! The reasons for this savings was that the 100% accuracy, 100% visibility and controllability available in the virtual prototypes made bugs much easier to find, characterize, and debug compared with hardware prototypes. Because he used cycle-accurate models, they faithfully represented the real implementation and found problems that would have otherwise been hidden and impossible to find in higher level non-timed functional models.     Case Study #2: A fabless semiconductor company in Asia's project team was designing an SoC to go into tablet and netbook products. The design was based on a dual core ARM Cortex A processor with graphics, video, and image processing components interconnected with a complex AXI fabric. They needed to architect the system, develop their firmware and device drivers, and understand the go-to-market performance of their system in a very short timeframe. The problem was a big one: This was their first product based on the ARM Cortex A-series cores, so everything (architecture, hardware, and firmware) had to be designed from scratch and they had no past experience to fall back on. To overcome this daunting task, the team used a virtual prototype and 100% cycle-accurate models to provide the insight for their architectural and firmware teams to understand, optimise and debug their system. This platform allowed the architects to make quick and accurate decisions and provided the firmware engineers the insight to understand the dynamics of the new IP. In the end, they had a working silicon prototype ready for their customers 9 months after starting the architectural phase of their project. An amazing feat –– architecture to working silicon prototypes in 9 months! In addition, they spent less than 1 month in the lab debugging their silicon prototype before they had a system that they had enough confidence in to provide to their end customers. The team commented that, without the virtual prototype and cycle-accurate models, achieving this type of schedule would have been impossible to do. These are just two of many examples where using virtual prototyping with accurate models has proven to reduce the design cycle time to realise an SoC. And, while I left the marketing hype and rhetoric out of this article, I do acknowledge the importance of image building and creating interest, key aspects of a good marketing and messaging campaign. Without either, it's unlikely I'd be able to write these short case studies. These companies in Europe and Asia would have no way of knowing about this particular virtual prototyping tool or the cycle-accurate models.     About the author Andy Ladd is vice president of Sales for Europe and Rest of World, and is a member of the founding team at Carbon Design Systems. He has more than 16 years experience in the EDA industry managing and directing field resources. Previously, he was the director of applications for cycle-based simulation at Quickturn Design Systems which was acquired by Cadence. Prior to Quickturn, Ladd was part of the initial bring-up team for Speedsim, the first commercially viable cycle-based simulation product in the industry. He also worked on supporting major accounts while working at Viewlogic. In addition to his EDA experience, he worked in microprocessor design and development at both Digital Equipment Corporation and McDonnell Douglas. Ladd holds a Bachelor of Science degree in Computer Engineering from University of Illinois and a Master of Science degree in Computer Science and Engineering from University of Michigan.