Latest Posts

NPI in Seven Steps – Part Availability

Published by Joe

This is part two of our look at New Product Introduction (NPI) where we will look at part availability. If you missed the first articles, get caught up here. In this section, we dive into Part Availability, alternative parts, and lead times.

Products need parts. Otherwise, they would just be ideas.

But they can’t be just any parts. You’ve carefully engineered the exact parts into the product to make it spectacular. But what happens if those parts don’t exist at production scale, or are so expensive they would double the product cost?

You’ve picked the parts that solve the solution. In this section of the NPI process, your manufacturer finds parts that can make the product.

Part Availability Analysis

It’s important to both your team and the manufacturer to ensure that the product will be able to be built at a very specific cost. To achieve this, they will look over your Bill of Materials and assess each part for its availability and if any is nearing end-of-life.

Parts that are hard to find or difficult to buy in bulk create a variable cost that neither side wants to deal with. There are a few things that could cause significant availability issues. Some are temporary (see lead times below) or permanent. Both can cause serious design impacts.

End-of-Life (EOL). Most parts are eventually replaced with newer versions that the silicon manufacturer believes better and eventually stop production on the current design.
Extremely high demand. If a large company is about to launch its new smartphone, they may buy out the available product on the market to meet their needs, which will cause a backup for everyone else.
Natural disasters. Typhoons, earthquakes, floods and other disasters where manufacturers are located can completely shut down production for months as everybody scrambles to relocate.
New product. Often silicon vendors will share their coolest chips yet and attempt to convince you to use them, but then the details come out that full production isn’t for another year.

Lead Time

Even if a part isn’t suffering from one of the issues above, it may still take a long time to procure. So the other aspect of the availability analysis is checking the lead-time of parts.

This is the estimated time between ordering the parts and having the manufacturer receive them. Commodity parts (resistors and capacitors) are typically just a few weeks, if not fully stocked by the manufacturer already. High demand or high-cost components such as microprocessors can have lead times of 6-8 weeks or even 6-8 months.

Why such a long lead time on parts you can get from Digikey in a few days?

It’s all about scale.

Your manufacturer won’t be buying a small section of cut tape, but full reels of parts. With thousands of parts on each. Combine this with silicon manufacturers not wanting to hold inventories on shelves; it creates a manufacture-on-demand scenario.

The benefits of this mass quantity buying are that the parts come at a significant discount. A $1 part on Digikey could be as little as ten cents for the manufacturer, so your $200 BoM cost for your prototype just got reduced to $20-$30, doing nothing but scaling up.

Distributors

Most manufacturers don’t buy parts directly from silicon manufacturers. Many are just too small to make it worth their time. Instead, distributors step in to broker between each side, but also to carry a supply inventory for you.

Digikey is often the first distributor engineers think of to buy parts because you can easily buy prototype quantities, but the Arrows and Avnets of the world are the major suppliers for the manufacturers.

Working with the distributor allows you and the manufacturer to pre-allocate parts that have longer lead times so when you are ready to build they have them waiting for you.

Alternative Parts

Lead time constraints aren’t the only thing the manufacturer will look at, but potential part alternatives as well.

Some manufacturers have a strong relationship with certain vendors which may provide a price break to you. So if they find parts in your design that have real alternatives, they may suggest changing the part vendor assuming it doesn’t alter the function of the design.

Other part suggestions could also involve changing part chemistry as well. Electrolytic capacitors used to be common in designs, but the materials have become so expensive that they are now hardly used.

Alternative parts allow for the manufacturer to find the best price and lowest lead times for parts. So anything that isn’t critical to the design (like processors) may get second (or third) sourcing.

The Result

The result of the manufacturer’s Part Availability analysis will be a report of all at-risk items and suggested alternatives.

This report will identify which parts are significant drivers of the cost and schedule so that your team can make decisions on if design changes need to be made.

Sometimes hard to get parts must be used due to design, regulation, or environmental conditions, and this document doesn’t prohibit those parts, but only calls them out to have agreement on them.

With the parts all agreed upon, the next article will get into the first build: the Engineering Verification stage.

Workplace Gossip, What’s an Engineer to Do?

Published by Joe

Gossip, scuttlebutt, water-cooler talk, chit-chat. Call it what you will, but let’s talk about what you talk about at work.

People gossip, and the more time you spend with your teammates away from the office, the more gossip you will hear.

Workplace Gossip

As the Oxford Dictionary defines gossip as the “casual or unconstrained conversation or reports about other people, typically involving details that are not confirmed as being true.”

Now, defining the word is nice and all, but let’s dive into some specific areas where we can apply it to our engineer careers.

Sets a Precedent

One of the unforeseen side effects of partaking in gossip is that it sets a precedent in your coworker’s mind. If they know they can talk to you about the ridiculous thing they just heard, they may come back to you to share even more.

This could quickly spiral out of control and next thing you know you are playing therapist (but without the paycheck). When ‘shit gets real’ you have become the one person they go and unload. Not only does this interrupt your own work progress, but over time, it wears you down.

Erodes Trust

Gossip also erodes the trust that your coworkers have in you. Ironically, even if they are the one sharing the little secret with you. You have become a conspirator, and those can’t be up to any good.

If you are the one sharing rumors, and they see that you can’t keep secrets and speculations to yourself, how could they trust you with actual, important things?

Creates Embitterment

Now, what happens if the person or team you are gossiping about hears of it? Offices are only so big and the guy sitting quietly in the corner might actually be good friends with the person of interest.

You’ve now made yourself an enemy, or, at least, created a very difficult situation to climb yourself out of. With the work environment being competitive enough, why make it even harder for yourself?

My Basic Rules on Gossip

Can we now agree that workplace gossip sucks? It has huge potential to cause harm to your potential career, saying nothing of the harm it may be causing to others around you.

With that said, I’ve put together some basic rules I try to follow for myself. Not that I’m in anyway perfect on this subject, but I find that by writing these rules down it helps solidify them so I can remember to follow my own advice.

My first rule on gossip: don’t.

Stupid simple perhaps, but important to try to follow through.

Talking about others in any negative light will only hurt your credibility and may break any trust some may have with you because if you gossip about Tim, who says you wouldn’t gossip about Carroll.

So when the welling desire to share something juicy boils within you, remind yourself of the cost. Is the information you are about to share beneficial to you and your career? Will it help a teammate with theirs?

Second rule on gossip: filter.

Deciding not to spread rumors and gossip yourself is hard enough, but how do you stop everyone else? The short answer is you can’t.

But you can actively ignore and avoid all the negative conversations about people. Don’t listen, don’t contribute, and don’t act on it. People have many reasons why they talk about each other. Sometimes it’s a credible, real issues the person has. Many other times the gossiper just wants to knock the person down the political ladder to promote their own agenda.

Either way, listening to gossip about others only damages your perspective of the target before you may have had a chance to know them yourself.

Third rule on gossip: salt.

Overhear that project Grassy Oak Field is getting additional funding and priority? This could be critical if you have been wanting to work on the project but no positions have been open.

If funding and priority are rising, now may be the chance to reach out to the project lead and have them request your transfer. On the other hand, if you are hearing that layoffs are coming and the business is doomed, welcome to the cynical world of engineering.

These may seem like actual benefits of listening to gossip, but if you followed every lead and feared every layoff you could quickly get burned out. By adding a bit of salt to these rumors, you can start to feel out what may be coming down the road – and prepare for it – and what is complete nonsense.

Your Takeaway

So the final word on workplace gossip is to leave it to the TV shows, and remember the wise saying: if you don’t have something nice to say, don’t say anything at all.

If you have some of your own gossip rules, share them below so we can all benefit from the learnings.

NPI in Seven Steps – Design for Manufacturing and Test

Published by Joe

This is the first part of our mini-series on New Product Introduction. If you missed the getting started post, read it here. In this post, we will talk about the first step in the NPI process: Design for Manufacturing and Design for Test (DFM and DFT).

No one likes broken products. Customers hate them. Engineers scoff at them. Manufacturers don’t get paid. It just sucks when a brand new thing just doesn’t work.

This is why, before even building the first one, the Contract Manufacture spends a good deal of time going over the design to make sure they can build it right and that they have a way to test all the functionality before it even leaves their doors.

Design for Manufacturing and Design for Test Analysis

In this step of the New Product Introduction, the CM does a review of all the files you provided, from schematics to assembly documentation to labels. While PCBs are often a big part of this process due to their complexity, the plastic enclosures and custom metal attachments must also be examined carefully.

What the CM is looking for:

Can they physically build to your design – no matter how hard engineers try, physics still wins
Are components of the design within acceptable tolerances – placing PCB components too close can cause them to interfere or plastics don’t always come out at exactly 1.115mm thick
What can be automated and what needs hand assembly – human intervention is expensive and prone to error
How long do they think it will take to build – time literally is money
Once pieces are built, do they have a way to verify its right – they hate building bricks as much as customers hate receiving them

This process is broken down into two main sections:

Design for Manufacturing where they will analyze the build
Design for Test where they analyze how to verify success.

Design For Manufacturing

Design for Manufacturing, or DFM, is a review of the design and how easy it will be to assemble. This includes looking at how close PCB components are to each other, the shape of the footprints, and tolerance levels in the drawings. The primary goal of this step is to catch any problems with how the product would be manufactured before time and investment are made to attempt the build.

After all this careful analysis the CM will provide to your team a report of their requests. Usually, these requests fall into three buckets:

Can’t Do – meaning they physically can’t manufacture this piece without changes
Yield Loss – meaning that the tolerances are too tight or parts are too close and it may cause higher failures during build, and you must accept them or make the changes
Cost Reduction – meaning that if you make this change it will reduce the part and assembly cost

Sometimes the feedback from the DFM is simple adjustments to reduce assembly complexity with no impact on the design such as:

Adjusting footprint sizes to prevent tombstoning or solder bridges
Increasing the distance between parts so the pick and place machine doesn’t bump other parts
Move all components to one side of board (if it only has a few) so they don’t have to re-run on the bottom side
Suggesting easier to place parts such as replace BGA with QFN
Adjust the board outline to fit more on a panel if that last one just barely don’t squeeze in

By Megger Ltd. (http://www.megger.com) [CC BY 3.0], via Wikimedia Commons

Others changes may require redesigning elements of the product that will cost too much to produce. These are the elements that CMs want to get early input on before either of you have invested too much time and money into the design. It may seem counter-intuitive that the CM is trying to reduce your cost, but they generally get the most profit when they finish your boards so the more boards you sell (by making them cheaper) the more money they will ultimately get.

Accept or Reject

Other than any changes that are labeled “Can’t Dos,” the CM’s list can be looked as suggestions. Typically very good suggestions, but it’s still up to your team if you want to accept each change or reject it and leave the design as is.

Sometimes you have to reject cost reduction changes because its the only way it will fit for the application, such as buttons and LEDs on both sides or size constraints mean parts have to be very close together. The point of the DFM is for the CM to make you aware of these decisions and sign off that you are consciously accepting or rejecting each one.

An important thing to remember here is that the CM is part of the team, their job is to manufacture your product as accurate and cost effective as possible, so listen to their suggestions as you would a teammate.

Design For Test

Design for Test, or DFT, is the second analysis that the CM will perform before building any product. This analysis will look at how well they will be able to verify the complete functionality and look of the finished good.

Just as your customer expects a working product from you when they receive it, the CM knows that you expect working product off their lines. So before boxing it up and shipping it to you, they want to verify that everything was built correctly and looks like new.

The DFT looks at how they will be able to verify that all the parts are placed correctly, interconnects are plugged in, and firmware was flashed. They will also look at how they can verify the assembly was done correctly and any manufactured parts (plastic or metal enclosures) were made to specification and free of blemishes.

To accomplish this they may request:

Test points on data lines and voltage rails so they can create a bed-of-nails
Test firmware and a way to communicate with it so they can verify functionality automatically
Requirements for power levels and current consumption during various parts of the test
Specifications for mechanical tolerances so they can measure with calipers
Documentation for normal operation so they know what they are looking for

By Cschirp (Own work) [GFDL or CC-BY-SA-3.0], via Wikimedia Commons

Who Creates the Tests

At the DFT stage, the CM is looking for how they would test it, not how they would implement the test. This is an important distinction (one we will come back to in the Test stage of the NPI) as not all CMs have the capability to engineer the test code and hardware.

If they have design engineers on staff the CM may be able to build test fixtures (something to hold the assembly with pogo pins connecting to test points) and write test software (in something like LabView).

Other CMs will rely completely on your team to design everything including supplying test equipment and computers to run it.

Hopefully, the CM’s capabilities would have been known when they were selected, but it is during the DFT stage that everything should be clarified.

The Result

Once Design for Manufacturing and Design for Test have been completed, the manufacturer will provide to you a list or document describing the desired changes and the impact each element has on the cost and assembly complexity. Your team can then decide on what changes will be made (such as all the easy ones) and which are important to the final product (such as the look and feel) and are worth the extra cost.

Along the lines of cost and complexity, the next article looks will look at Part Availability and its impact on your price and schedule.

Dealing with Experienced Coworkers and Learning From Them

Published by Joe

It doesn’t matter if this is your first job or your third, you will have the opportunity, and challenge, of working with a broad range of individuals.

As an early engineer working on building your credibility and proficiency, perhaps the most daunting group of people are the experienced coworkers.

The experienced coworkers

I am not talking about the guy with only a year left before retirement and just coasting, I’m talking about the engineer who is the expert in her field and has ten patents and nine papers to her name.

Perhaps every time you bring up an idea they have 10 reasons to shoot it down. Or they can seemingly walk up to your computer and instantly point out a critical mistake.

After a few of these incidents, you quickly learn to avoid them or get an anxiety attack just by knowing they are going to be in the same meeting.

The difference of years

Why are so many early engineers intimidated or even threatened by senior engineers?

When you look at the differences between the two groups the cause for potential conflict becomes more apparent. While the list below is general to the extreme, I think you could relate to a few of the differences.

Early Engineer	Senior Engineer
Fresh from school and eager to go, but little to no experience	Decades of experience
Excited to try the hot new things from school but have never used the alternatives	Comfortable and knowledgeable with what they have been using
Naïve and optimistic	Perhaps a bit jaded and cynical
Used to flitting from one thing to the next (Myspace, Facebook, Twitter, Snapchat…)	Learned that diligence and follow through earn respect

Guess what, just as the list above can be causes of conflict, they are also the same reasons that can accelerate your growth as an engineer and professional.

Think about it, that guy who always insists on a certain format could probably list a dozen good reasons if you only bothered to ask why. And the gal that always seems to know about every technical aspect of the project, well maybe you could ask her how she came to master it.

Ok, you may say, but you don’t know my co-worker, he is impossible to ask anything – when I do, he just makes me feel like an idiot!

Been there, and no, it isn’t a good feeling.

It is difficult to try to ask for help only to be made the fool, but a simple difference in perspective is all it could take to overcome your differences.

An exercise of perspective

In my first career job, I had a project to automate some test equipment at our CM to verify the boards were built correctly.

As an aspiring engineer just out of school, I was working hard to get the project done, but holding me up was Jack (clearly not his real name), an engineer with 30 years of hard experience.

The issue all hinged around my wanting to use USB or Ethernet to communicate with the lab equipment – you know modern day technology. Jack continued to insist that this new fangled tech was unreliable and that GPIB was the only way to go.

By Alkamid (Own work) [CC BY-SA 3.0], via Wikimedia Commons

Decades-old protocols, very expensive cables, and bloated software interfaces. All sorts of reasons to not use GPIB.

Whenever I tried to ask Jack why he insisted on this protocol, he simply answers that this is how it had always been done, and if it worked for the Military, it could work for us.

I was in a difficult situation. I was trying to prove myself as a competent engineer and believed that the newer protocol could save the company time and money. I was at odds with Jack’s senior opinion.

What is going on here? Was Jack really being a set-in-stone Luddite?

Doubtful. More likely he had been using the old protocol for so many years that he was intimately knowledgeable about the benefits and pitfalls that it contained and had a hundred ways to avoid those pitfalls.

The new protocol was still hot off the presses (relatively speaking), and while it may have looked like a great new thing, Jack had enough experience to know that looks could be very misleading.

Help them to help you

Think about my situation, I was trying to do what I thought was the best solution and felt that Jack was holding me back.

Humor me for a moment.

Let’s change the perspective to Jack, in his years of working he had probably seen a number of new things come and go, each costing the company an untold number of dollars and hours, and yet his go-to standard was still holding steady. So, when yet another new thing was being presented, he was sure of where it will end up.

So where does that leave us?

The five whys

After trying and seeing many possible solutions, my suggestion is this: ask why.

Not in that childish tone that grated on your mother’s nerves. But really ask why he has this opinion.

Show Jack that you want to learn and the conversation may turn a whole different direction. Most people love to share their expert knowledge, and if it is on an eager ear, all the better.

Once you have Jack talking about why he trusts the tried and true method, keep probing deeper into the details – why is it more secure? Why does that make it simple to maintain? Why do all the CMs use it?

This is a method I learned from Eric Ries where discusses this idea in his book “The Lean Startup”. He uses the Five Whys to diagnose bugs in his software project or customer complaints. His point was that if you keep probing into a problem, or an opinion, you can move past the blame game and uncover some surprising results.

Back in our example, if I had sat down with Jack and asked my whys, I may have learned a good deal about the ‘old’ protocol that made it a great candidate for a number of non-apparent reason.

Alternatively, as the discussion went on, I may have learned that Jack trusted the GPIB protocol because an established company built and maintained it, whereas all the open source standards he’s seen have backfired for lack of unified support.

I could have just gleaned a priceless gift: a tiny piece of Jack’s years of learning and personal experience.

That does not mean I would need to give up my proposal. Indeed, I may have just found a number of reasons why Jack would get excited about it now that I know what’s important to him.

Let’s say I found a USB driver for Agilent oscilloscopes that were written and supported by them.

Supported by an established company, check.
Provides a secure channel, check.
Proven examples of maintainability, check.

If I had spent the time to figure out Jack’s whys it might have saved numerous arguments and painful hours attempting to get NI’s VISA drivers to actually run.

Your take away

So what can you take away from all of this?

First and foremost: remember to be open minded – yep the same thing you wish the ‘older’ crew would be. This is not to say that they are right, but if you can stay open-minded to their opinion and concerns, you might be able to create a better solution than either of you had thought of.

Ask the Five Whys. Following up to being open minded, try to dig into why this experienced coworker has this opinion or choice made. The Five Whys is meant to dig past the surface level questions and truly understand the motivations.

And finally, take advantage of the experience and thoughts these seasoned engineers have. Think of how many projects they have worked on and how many decisions they have had to make over the years. Realize that they are where they are because of this experience. And no matter the gruff exterior, if you pay attention you might be able to get a head start in your career.

Your Thoughts?

Hit up the comments below if you have had some of these experiences or think I am way off base. We are here to learn from each other, so add your voice below.

New Product Introduction - Getting Started

New Product Introduction in Seven Steps – The Beginning

Published by Joe

This post kicks off a seven part series on New Product Introduction. Here we will be introducing the concepts.

How many failed Kickstarters are out there that couldn’t raise enough cash to make their project into a shelf-worthy product? How many more failed to deliver or even went bankrupt right after because they couldn’t afford to build a second round?

It’s not just the makers. Even large corporations that attempt to branch out into the hardware space have failed to bring their product to market.

For many, the reason is they do not understand, or they misjudge the requirements needed to make a prototype into a ready to ship product. This process to get from mockup to saleable item is called the New Product Introduction.

What happens after the prototype

Let’s say your company has a cool little prototype that will be a game changer. Your team has proven it can work. The marketing group is so excited that they want to launch it at the next big expo – which is in two months.

To get there, a magic machine needs to take this one prototype and build thousands of them a week. This magic machine is a contract manufacturer, or often just CM (JDMs and ODMs fit too but let’s leave it to one acronym).

As an engineer, we may naively think we have accomplished our work at the functional prototype, and it is the role of the operations group to take it from here. Perhaps at large companies, this is the case, but for most engineers, you will be involved right up to the point product is shipping out the door.

Creating a prototype is hard, but creating a product that can be built the same way, thousands of times, and always meet the requirements set for that product – no tweaking, no white wires, and no last minute whacks with a hammer, has its set of challenges.

The Manufacturer

When a manufacturing company gets started with a new product, they use the term New Product Introduction (NPI). For them, they know they are about to enter a very interactive and intense period with your company. Read that as: ‘high cost and no revenue.’

The NPI is an investment on their part into your company and this new product since they don’t make a profit until products roll off the line. This is why they will have optimized the NPI processes to get the product running while minimizing the hiccups.

While you and your team work through this process with the CM, always remember that they are a partner in this endeavor and are experts in their specialty: producing a product. They are also a business trying to make a profit, which does, in fact, come from your company, but as long as they are providing a valuable service, this is an useful thing.

NPI Overview

As I mentioned at the top, I’ve broken New Product Introduction down into seven steps. I’ll introduce each below but will go into more depth on each of their posts.

DFM/DFT – Design for Manufacturing/Test is where the manufacturing team will evaluate the design for how easy it will be to build and test. This is an important first step because, as we will see through this process, the further along it goes, the harder it will be to change.
Part Availability – Next all the parts will go through an availability analysis to make sure there won’t be any parts that will drag the schedule. Any problem parts will be flagged to find alternatives or the manufacturer may suggest changes to lower price.
Engineering Verification – The first build out of the CM is the Engineering Verification build. This may have additional components or PCB features to enable testing and board verification and may not even fit into any housing. The goal is to ensure the design is sound.
Testing – Now that the CM has actual boards to work with, they will start developing the test systems in earnest. We will go into why testing is so important to both you and the CM, and how the product can get tested.
DV – The second build is usually called the Design Verification. This build is meant to be close to the final production unit but may use 3D printed plastic and other low volume mechanicals to get the look and feel correct before spending money on tooling.
PV – The final build in the NPI process is the Product Validation. This build is essentially a dry run of full production. Housing, mechanical, labels, shipping boxes, everything that a finished product would go through. This is the last gate before releasing the flood.
Full-Scale Production – Now leaving the NPI process, full-scale production is where the product gets built as fast as the CM can make it and shipped to your customers.

Getting Started

After getting past any legal paperwork hurdles, the CM will kick everything off with a request for an ‘assembly package’ that could include:

Product Requirements Document (PRD)
Detailed Bill of Materials (BoM)
Assembly instructions
Approved part vendors
Schematics
PCB files
CAD drawings
Sales forecast

These files enable them to get an estimate of how much it will cost to build your product and what parts they need to start ordering. It also gives them guidance on the complexity of the project so that they can calculate their budgets. If necessary, they will also assess who they need to bring in to consult.

Thus begins the NPI process and the road from prototype to production. In the next article, we look at Design for Manufacturing and Design for Test.

Advanced Uses of the SPI Interface

Published by Joe

The SPI interface has become as ubiquitous in embedded design as the UART or ADC. This is for good reasons as the SPI protocol has a number of great advantages. It is these advantages that we will talk about today and how to best utilize them in your design.

Advanced uses of the SPI interface

If you are just getting started with the SPI interface, Sparkfun put together a nice intro on SPI or even check out the Wikipedia article on it.

Below I have gathered a list of advanced uses of the SPI interface hardware that could either improve SPI communications between your devices or use the hardware in an unusual way – often to provide means to a different protocol not supported by the hardware.

Single direction allows for isolation or level shifting

In one of my recent designs, I’ve been using a micro that is limited to 2.8v to 3.3v power source but found an extremely low-power, and low-cost sensor that could only run at 1.8v.

Because of the single direction of each of the SPI interface lines, the voltage levels could have been solved (as compared to using I2C). Something as simple as a MOSFET with the correct power rail for each line could be used to drive each side.

In another project, a 3v system needed to interact with 24v controls (industrial equipment). A single MOSFET wouldn’t have been able to handle this voltage gap and instead, optoisolators were used. These nifty devices combine an LED and a phototransistor to completely isolate the electronic interface.

Both designs took advantage of the single direction of each SPI pin to interface between power domains.

Connecting multiple slave devices to the SPI bus

Like I2C, the SPI interface allows for connecting multiple slave devices to a single host port. Sounds nice and easy in practice, but the nuances of actually implementing this can create additional complications.

Electrical considerations for attaching multiple slave devices

Paul on DorkbotPDX put together a good list of a Better SPI Bus Designs. His focus was on the Arduino hobby market but contains some great insights for all embedded design.

Tristate

To allow sharing the MISO pin, all non-active SPI devices are required to put this pin in a high-Z state, aka tri-state output. Otherwise, the device that is currently active would create a short against the non-compliant device.

This is an example of the importance of checking the device’s data sheet, even for something as common as SPI.

If one of the devices does not implement the tri-state mode, you have two options: move it to its own SPI port or add a tri-state buffer on its MISO pin (as Paul recommended below).

From Paul on DorkbotPDX, used under CC4.0

Pull up nCS

Paul’s design recommendations included adding a pull-up to each chip select.

The pull-up is supposed to prevent devices from being left in an unknown state if the processor wasn’t configured correctly. This may be important for something like an Arduino shield where the user may not realize there is a device there.

For standalone systems, the pull-up shouldn’t be needed as you have complete control over the design. An exception to this could be an embedded Linux environment to ensure the UBoot or other non-typical scenarios don’t break something.

Firmware considerations for attaching multiple slave devices

When attaching multiple SPI devices to a single bus, there are firmware considerations to think of as well.

The most critical component is the latency tolerance each device can tolerate. Simple sensors such as temperature and humidity would cause little loss of information if they didn’t get read right away.

Radio transceivers aren’t so tolerant of delays. If your system is busy communicating with another device the radio may have to drop a packet that wasn’t acknowledged in time.

This could again be solved by putting critical or time intensive (like flash memory) devices on their own dedicated port. Alternatively, if spare pins are a premium, the firmware must be architected in a way that gives priority to the time critical devices – and handles dropping the noncritical ones in a way that they can continue later.

Speaking of the firmware architecture, the software design must also take into account that only one device may access the SPI interface at a time.

If using something like FreeRTOS, a mutex should be used for each task that wants to communicate with its attached device. This prevents another task from attempting to talk to its own device and writing random data in the active device.

No addressing or ACKs allow for blind communication and non-standard protocols

I’ve often seen the lack of ACKs in the SPI interface as a con to the protocol. While this is true for many applications that require reliable communication to the end device (such as our flash memory again), the lack of an ACK signal can also provide a benefit to non-standard uses.

One that I have used on a previous design was to use the SPI MOSI pin to drive an FM modulator. This was a simple broadcast device but required precise bit timing for the receiver to work correctly. By using the SPI hardware within the chip, it was able to achieve this precision and utilize the bit buffer to enable other tasks to run in parallel.

I’ve also seen the SPI interface used to drive LEDs, primarily the neoPixels that AdaFruit is so fond of. These RGB LEDs have a non-standard serial interface that allows multiple LEDs to be chained together on a single port.

The interface requires a pulse width modulated signal where a 1 has one duty cycle, a 0 another with very specific timing requirements as shown below:

also note they have a +/- 0.15us tolerance

For small embedded projects it could bit-bang this in a timer interrupt, but a better alternative is to use the SPI port. You can set up a function that sends 0xE0 for logic 0 and 0xF8 for a logic 1. Adafruit has a tutorial for a USB-to-SPI chip that does exactly that.

Because the port can blindly transmit the bits, it doesn’t care that there isn’t an SPI device on the other end.

Adding IRQ Lines

Another seeming downfall of SPI is the lack of request for attention built into the protocol like I2C’s clock stretching and SMBus. This has led many chip vendors to add an IRQ pin to provide an out of band signal to the host.

I actually believe this is a huge advantage to the design.

Since each device can trigger its own IRQ pin, the host immediately knows which device requires attention rather than poll each one.

It also doesn’t interrupt the communication bus. If you are busy writing to one chip you don’t want a different one to barge in and start talking.

The IRQ pin allows your firmware to decide on when, and if, it wants to talk to the device.

Yes, it takes additional pins. But a clever design and a few additional components could provide a workaround. Perhaps adding an OR gate with all the IRQ pins into a single input of the processor. A second input could be gated by AND gates with the chip select acting as the selector, in this way the firmware could cycle through each chip select until it found which was active.

Go beyond the standard

The best embedded systems use every resource the chip has to offer to create the solution.

The SPI interface is just one of the useful peripherals on a micro, and I hope this article has inspired you to take your design a bit further and think of creative uses.

Have a nifty use of an SPI port you would like to share? Hit up the comments below to share with the community.

Bill of Materials – Creation and Control

Published by Joe

Ever look at something and wonder how they keep track of all those parts? Or how about when you see two products, almost identical, but with slightly different labels and wonder how they keep track of the differences? This is the world of the Bill of Materials (or BoM for short, though don’t use that word in public spaces).

With only this document, any manufacturer, anywhere, could (in theory*) rebuild the exact product specified within.

* Clearly they would need the source files for PCBs, plastics, software, etc.…

What Is a Bill of Materials (BoM) and What is it Used For

A BoM is a document, which may be as simple as an Excel spreadsheet or as fancy as an Oracle Agile database, but in the end, it is a document that lays out what parts are used to assemble a product, how many, and a way to identify them.

Before we get too deep, we need to define a few terms; your company or tool may call them something different, but speak of the same thing.

Part: Any discrete thing is a part. Resistors, plastics, screws. In addition, Assemblies and Products are ‘parts’ in that they are a newly created thing.
Assembly: A grouping of parts that make up part of the Product, which may include sub-assemblies, or even be what you would think of the product (but without the packaging and all that).
PCBA: a specific assembly that is a PCB board with the components attached. Often called out because it goes through a specific process of creation.
HLA: High-Level Assembly, often used for the finished good without the packaging. Think of the thing that a customer sees as what they are buying.
Product: the actual thing that sits on a shelf or is delivered to the customer. This would include the HLA, its packaging, papers, cables, software, and shrink-wrap.

Example: think of a USB keyboard. The buttons, resistors, and USB chip are parts that are then attached to the PCB, creating a PCBA. This new part is then attached to another assembly, the keyboard top – creating yet another, higher level assembly. The bottom assembly is then attached that included the rubber feet and its sticker. We now have the HLA, or what’s sitting on your desk. When you stick it in a box with those warning stickers and product information, it’s ready to sit on a shelf and be called a Product.

As hinted above, a Bill of Materials describes what parts go into assemblies, what assemblies go into HLAs, and what HLAs go into a Product. Each level is broken down into a hierarchy so each assembly can verify it has all the pieces, and each assembly now creates a part for the assembly above it.

When it gets to the final packaging step, the BoM describes exactly what (and how many) goes in the box.

How to Read It

Depending on the tool being used and how it is displayed, the BoM will usually have a set structure and common elements. This common language helps manufacturers and other companies understand the document.

Level – Each Part will live somewhere in a hierarchy of parts. The Product will often be Level 1 with the HLA and its packaging being Level 2. Assemblies in the HLA will be Level 3 and so on. The level helps to break down each sub-component and gives structure to an otherwise complex set of parts.
Part number – Every part must have a unique part number that points to exactly one part or assembly. The reason for the unique number is there are many “10ohm 0603 Resistors” that vary by manufacturer, tolerance, wattage, or other attributes, but your part number will map to a very specific part (or parts, see Alternatives below). A specific Assembly also has a unique part number, with assemblies that are similar – but with a different color, for example, having different part numbers.
Description – This is the human readable description of the part. Generally, the description should include the attributes that are important to you. For the resistor above, if the wattage or tolerance doesn’t matter to the design, don’t put it in the description, but if it does, make sure it is part of the description. The description isn’t necessarily binding, but it does help to differentiate between parts.
Manufacturer and Manufacturer Part Numbers – This is where your companies part number is mapped to a specific manufacturer’s part. This is essentially the shopping list for the CM, or where and how they can order the actual part. Custom made parts or assemblies often don’t have this field, as the CM is the one actually creating the item.
Alternative Parts – for many parts, especially commodity parts, alternative manufacturer and manufacturer part numbers are listed, creating a one-to-many relationship between your part number and manufactured parts. The reason for the alternative is to give your CM options to find the best cost or shortest lead-time. These must be a true drop in replacements, a 0603 resistor can’t be an alternative to a 0402 part, but a 10% tolerance part could replace a 5% if your design isn’t affected by it.
Quantity – The quantity shows how many of the specific item are used in its level of assembly. An important distinction here is that this quantity is how many are used in the assembly in the hierarchy above it, not how many are in the product. So it may take 5 screws to attach this assembly, and if 10 are used elsewhere, only 5 are listed on this line.

There are many other fields that can be used such as distributor part numbers or PCB reference designators, but the ones above hit the most common.

How Manufacturers Use It

When you create a BoM, you are constructing a very specific recipe. A recipe for how to build your product with exact precision. This isn’t like your grandma’s recipe where she modifies it a bit as she goes, using whatever is in the fridge. No, the manufacture is very strict about sticking to this recipe, even if they think it is wrong (see MCRs below).

You have to remember the manufacturer’s existence depends on making thousands or even millions of your product – exactly the same. Every. Single. Time.

To do this, they only buy the parts listed as approved manufacturer part numbers and use exactly the part listed for each assembly. No more, no less, and no ‘creative changes.’ The manufacturer may make suggestions or requests to create changes (as we will see next) but will not deviate from the documents until told otherwise – which is exactly what you want them to do anyway.

Depending on their process, your manufacturer will take the Bill of Materials and break it down into each of the sub-assemblies. Any PCBAs will be programmed into their pick-and-place lines, mechanical assemblies will be batch assembled, and final assembly grouped together right next to shipping. Since they get paid by the product going out the door, they want to streamline the whole process from when they are loading the feed trays to taping boxes shut.

Change Requests (ECR and MCR) and Change Orders (ECO and DCO)

Because of the complexity of manufacturing and the liability of creating faulty products, manufacturers will not make any changes to the BoM, or any other procedure, unless a formal change process happens.

Every company and tools have a slightly different process and naming convention, but they generally fall into two major groups: Change Requests and Change Orders.

Change Requests

A change request is where a change to the BoM is being requested ( a giveaway from the name), but the distinction is that this is only a request, and not actually approval to make the change.

If a manufacturer is requesting the change (Manufacturer Change Request, or MCR), they may be asking to use a different part for cost reduction or change the footprint on the PCB due to solderability issues. They would like to make a change to improve the manufacturing reliability or their cost and need your team to buy off on the change.

If your side is making the request, it comes through as an Engineering Change Request (ECR). You may want to change the design for performance reasons but before it can be implemented, the manufacturer will need to make modifications to their system. The ECR is a way for engineering to gauge the impact of the change and notify all parties that this change could be coming.

A completed Change Request has two paths: rejection or acceptance. A rejected request may sound like a failed marriage proposal, but it could be as simple as the details were not correct or marketing didn’t like the fact the LEDs were blue – red and orange are the way to go.

Accepted Change Requests must be signed by all parties involved that they agree the change makes sense to move forward with.

Change Orders

Once a Change Request has been signed off by all parties, a Change Order can be created. This is the process to formalize the change and have all sides verify that they are in agreement with the change. This isn’t something that is taken lightly as it requires the CM to interrupt their process flow, make the change, and hope that everything continues to run smoothly when they start back up.

Think of your computer announcing that updates are ready to be installed. You know they are important, but you can never be sure it won’t brick your perfectly running device.

Since a change order creates such a drastic change to the process, often times it requires numerous sign-offs from both sides. The engineer that made the change must sign, send it to their engineering manager to sign, have someone in operations sign off, maybe even marketing and finance if it effects the look or cost of the product, and finally go to the CM to sign off.

Change orders come in many flavors depending on how your company wants to break it down, but generally, there are two major types: Engineering Change Orders (ECO) and Document Change Orders (DCO). Notice there isn’t a Manufacturer Change Order – they make requests but you are their customer and they won’t order you around.

ECOs are generally the more impactful of the change orders. They include changing parts used within the BoM, updating revisions of custom parts (PCBs and plastics), or new firmware release. Even the initial BoM and assembly documentation is released through an ECO to initiate the first build.

DCOs are usually more benign in that they are only updating documentation. It could be to fix typos or clarify descriptions, but it could also change test process or assembly documentation.

BoM Management Tools

So how do companies manage all the complexities of a Bill of Materials and maintain all the complications of change management?

The answer, as so often with life, comes from software. Depending on the size of your company’s product development, there are tools specifically designed to handle BoMs and change management. Often called Product Lifecycle Management (PLM) tools, a handful in the space are listed below.

Excel Spreadsheet

For small projects or companies that are just starting out, the BoM usually lives in Excel Spreadsheets. The benefit of using Excel is that most people already have it and it doesn’t require much overhead.

Each BoM is a new spreadsheet, and perhaps one spreadsheet maintains all the part numbers in a central location.

Once your company is building more than a few products, or even multiple derivations on a product, maintaining spreadsheets becomes a big issue.

Oracle Agile

On the opposite end of the spectrum is Oracle’s Agile PLM. As with anything Oracle, Agile is immense, expensive, and extremely powerful. Many big companies use Agile since it ties into their other business tools that track expenses, forecasts, and sales channels.

The integration and deep insights that Agile could provide are incredible, but at a significant cost – both in license fee per user, but also in requiring consultants to modify the tool to fit your company’s needs.

Arena

Born in the Web 3.0 era, Arena PLM is a web-based platform that provides many of the benefits of Agile but at a significant discount in price and complexity. This is the tool I’ve had the most experience with having set it up at two different companies.

While Arena has a number of options and configurations that you can modify to fit your company’s process, you don’t have full control as you would with Agile (since it is a web app). On the plus side, they maintain a single, centralized server network for you and continue to push updates to the system, at no extra charge.

Aras PLM

Almost as the Fedora Redhat of the PLM world, Aras actually provides their PLM software as open source. For no charge, you could download their software, install it on your own server, and get a PLM tool up and going.

Where they are looking to make their money is by providing the consulting and support service to get their tool connected into the rest of your services. They can also host their platform for you as an additional service.

Wrap Up

We covered a lot here with the Bill of Materials. To sum it all up, the BoM is a document that specifies what parts, and how many of them, go into a product. A manufacturer follows this document as a precise recipe to build a continuous line of products rolling out the door into your customers’ hands.

If you got something from this description of BoMs or have a great story to tell about your own experiences with change management, add it to the comments below and share it with the community.

The Power of the Lunch Table

Published by Joe

Time for your annual review!

As a new engineer, it may be understandable to think that your merits and promotions will be based on your work alone. Makes sense. That’s how it worked in school, and seems like an objective way to attain your worth to the company.

The reality is, how much you are liked could influence your position within the company more than how well you can engineer.

Surprised?

You are not alone, many people get out of academia thinking that getting a good grade at work is just a matter of doing the homework (finishing a task), passing a tests (meeting project deadline), or showing up to office hours (working those extra hours).

Now, don’t get me wrong, missing deadlines and not being proficient at your job will hurt, but so will getting on your boss’s nerves (the person who approves your promotion) or making another team member look bad (the person giving peer reviews).

Making Friends

As you progress in your career, it will become more important to be liked, or in other words, to be friendly. Unlike your professors, or maybe just like some of them, your grade at work will be reflected by if your management team views you as a friend, or, at least, friendly.

A classic book on this subject is the long-standing How to Win Friends & Influence People by Dale Carnegie. Its purpose is to show how to become on great terms with others and how to ask for what you need from them.

Notice how I phrased that?

The whole point of Carnegie’s book and this article is not to manipulate others to get what you want, but rather how to directly or indirectly ask for what you need, including that promotion or special task.

Lunchtime Talks

The best way I have found to build relationships with my peers and managers is to simply eat lunch in the lunchroom or join a group eating out.

The point is to mingle with others away from the lab benches and conference rooms, where the main topics of conversation are not about the project deadline but rather about people’s hobbies and families.

Where did you hike this weekend? Or, did you play that new game? How about following the local sports team or TV drama?

During the lunch conversations are where you will find out that your boss’s boss also is an avid hiker, or your teammate’s gamer handle is someone you know.

Even the ‘small talk’ banter builds your report with your coworkers as it can show your sense of humor, awareness of the team, and cultural experiences. Something that doesn’t happen with focus in the cubes.

The Importance of Being a Person

What these lunch conversations are doing for you is helping others see you as a person rather just a cog in the company machine. Cogs can be replaced, but when you attach a personhood, or better yet, a friendship, to that name, things change.

Imagine the conversation your management team is having during review time about you:

Conversation A:

OK so who has thoughts on Mike? Anyone?

Mike always seems to be in his seat from 9 to 5, and has never been late on a project.

Have you seen his desktop background though…

Conversation B:

OK, who wants to speak about Julie first?

Oh, she is fantastic, always delivers her projects on time and her reports are always professional, probably because she volunteers at the school in the morning.

Did you know she’s an avid golfer? We should invite her out the next time we go.

Which would you prefer to be spoken about you? The difference between Mike and Julie is that the management team knows about her, or hears about her from their reports.

Both finish projects on time and both could be exceptional engineers, but Mike is currently only a cog.

Practical Step

Ready for your three-step plan, four things to do and one to simply avoid, or magic diet pill? Forget it. All you need to do is help others think of you as a person and not a cog when they hear your name.

So, on your next lunch break, get away from your desk and meet your coworkers.

Bonus points: invite your manager out to lunch and find out what she likes to do on the weekend, does he have a family and a favorite hobby? Stop being a cog in their machine.

Importance of Version Control for All the Work You Do

Published by Joe

In your Documents folder do you have a Final-Report-V1, Final-Report-vFinal, Final-Report-vFinal-Johns-comments, etc.? How about the experience of having worked on a software assignment all night long, only to have something, somewhere cause a crash minutes before it is due?

Then you have seen a glimpse of the importance of version control to your company, and more importantly, to your career.

The Importance

As a student, backups and constantly saving files was a personal CYA, and unless you were working on a team, a lost file only hurt you. You also had the generous benefit that when the term was done, you could burn, delete, kill, or otherwise maim any document you had spent so much time on and have no repercussions.

Now, as the professional you, there is much more at stake when a file goes missing or bugs creep in at the last moment.

While there is a large amount of personal CYA that benefits of good use of version control, the company has a legal and financial obligation to keep good records and backups of the work created by you and your team.

Product and business decisions may need documented reasons to satisfy auditors and heads may literally roll if the next release is delayed due to an undocumented change.

What Version Control Is, and Is Not

Version control is a software tool or procedure that is designed to track changes to a file and allow a user to backtrack changes to specific revision when needed.

The details of implementation vary, but the idea is that every change is logged and could be reverted.

Version control should not be viewed as a hard drive, as it’s not meant to store everything in your documents folder. An example is the build output of your software, which lives on your hard drive, and not in version control.

The rule of thumb of what should be stored is the minimal documents required to recreate the output. Things such as external libraries should not be stored, but rather fetched by software scripts to download from their source.

Best Practices

There are a number of easy ways to protect yourself and your company by using version control to its full potential.

Before going into my own experience, the best place to start is seeing if your company has a version control procedure. If not, maybe by the end of reading this you could write one up that fits the tools your company uses and submit it up the chain – perhaps even earning yourself a nice kudos along the way.

1. Find the right tool for the problem.

Git has become the dominating tool for software development, but it is not so helpful for binary files such as CAD, Office documents, or images.

Some applications such as SolidWorks have built in tools (at an additional cost of course) but are specifically designed for the file contents. Microsoft Office 365 has some version control available, but for many other files, a documented convention on a shared drive may be the only option.

Do a bit of digging to find the right tool for your application, even if that means multiple tools for large projects.

2. Research the conventions for the tool.

Tools such as Git have their own dialect and conventions that, while easy to copy and paste commands, they are not always intuitive until you understand the inner workings.

Managing versions on SolidWorks has a different convention and use case that are equally important to understand.

As with any tool or software the more you understand the ins and outs, the faster and easier it is to use. So spend some time up front learning about the tool and its best practices.

3. If the current solution works, don’t fix it.

Imagine a shared server drive that has sub-folders named current and archive, where the convention is that before you make changes, save the current file into the archive, update the filename revision, and edit away.

Clunky and ugly?

Oh, yeah, but sometimes this is all the more that is needed, and trying to force a change will only cause more headaches.

As engineers, especially as fresh engineers, we are often hot to try the newest things and find ‘old’ practices, well, old. The procedure may be terrible and outdated, but if it works you must find good justification to initiate the change – and it better be a good reason because change is hard and expensive for companies.

4. Commit incremental changes.

When modifying a project, be it code or CAD drawings, make sure you are committing multiple, incremental changes along the way – not just the big at-the-end-of-the-day commit.

This has bit me more than once when I have been hacking away getting one thing working, move onto the next and find that I broke the first. If I had saved a version in between, I could have reverted to a previous change and moved forward until something broke.

Instead, I spent a great deal of time backtracking all the changes and tried to remember what I did earlier.

Save often, commit often. But…

5. Only commit what works.

As a contradiction to number 4 above, you should only commit something that is ‘working.’ If it is software, it should compile, CAD drawings should render, and documents should have completed sentences.

This is especially true if multiple people are working on the project, you do not want to be the one who is blamed for breaking the build.

‘Working’ doesn’t have to mean complete. You maybe be adding complex features to a project that will require many changes. So instead of waiting until it is completed, stub out new features, add incremental changes, verify it builds, and commit.

Finding a balance can be tough, but well worth the effort when something breaks.

6. Use branches.

If your software tool allows branches, this would allow exceptions to number 5.

Branches are a way to take the current version of a project and create a copy of it. You could then do anything you want here such as experiment with a new idea or commit every line of code change.

If the changes you made are needed back in the main line, then the tools will allow a way to ‘merge’ you changes back in. If they don’t work out, you can toss the branch without hurting anything.

The other benefit of branches is that anyone can check out the master, or trunk, and know it is stable – all new development is in the branches.

7. Make the best use of commit messages.

Most tools allow you to make comments when you commit changes.

What is not needed is for you to list the files and line numbers, the tool should do that for you. Instead, make notes of why you changed something, bug/case numbers that relate to the change, and notes for how to test the new changes.

When someone goes back through your change log, they should be able to understand why you made the decisions you did without needing to corner you in the lunchroom.

This also comes back to point number 4: Commit Often, by splitting changes into small commits, it is much easier to document and follow the changes.

8. Preach it, but do not force it.

If your office does not use revision control, it may not be wise to attempt to force it upon your co-workers.

They may have their own systems they like and are used to and do not always take kindly to new ideas. Instead, demonstrate the usefulness that you are getting out of it and the benefits to the company.

Tools like Git don’t require external servers or cost any money so you could easily set it up on your machine and demonstrate to your coworkers how it has been helping you and offer to set it up for them.

Your Challenge

So now I’ve hopefully got you fired up for why version control is so important, and the basics of how you can implement it within your company.

Now that you have learned it, now make it.

Your challenge is to implement version control within your workflow or improve your process by studying the tools and procedures used by your team.

If you have a great story of version control or want to share how you helped your team implement it, hit up the comments below and share with the community.

Hello World – or the inaugural post of Learn It, Make It

Published by Joe

Hello world. It doesn’t matter what programming language you use, this has become the de facto standard for an introduction. When Kernighan wrote that first program, I wonder if he knew how it would last.

Even embedded engineering has their version of this classic with a blinking LED. It is no wonder that every development kit, experiment board, or hobby set has, at least, one LED populated.

You have to start somewhere.

And that is the point of this inaugural post for Learn It, Make It. This is my hello world. Nothing fancy, nothing deep but a way to break the ice and introduce this site and myself.

Why

When starting any endeavor, it is important to ask why. Why bother, why start, why is it important. For me, I started Learn It, Make It because I wanted to help give back to the embedded community, utilizing the strengths I possess.

Do I hope to become rich and famous from it? Not in the least, I hope that someday I could use it to provide a side source of income for my family and provide a tangible incentive to continue, but I am committed that for every dollar I make, some will be going to support non-profits focused on education for those who may not be able to afford it.

At this point, I have selected Pencils of Promise as they have a great mission of helping every child have access to education.

Who

Now for the question of who is this guy? My name is Joe Baird and I have been building, testing, and producing electronics for nearly ten years including embedded microcontrollers, RF electronics, and extremely low power wireless sensor networks. Such as a wireless sensor with over 10-year life on a single coin-cell battery or an RF antenna area that can beam-steer in 52 unique states. You can see my professional background on my LinkedIn Profile or find a more personal look on the About Page.

But, I am not an expert, professor, or a sage. I am however very passionate about learning, building, and tinkering. Which brings us to the…

What

My plan for Learn It, Make It is twofold:

provide enriching content that will enable engineers, makers, hackers, and software developers learn embedded devices
enable those same engineers, makers, hackers, and software developers to bring their hardware ideas to market

As I go through these processes myself, I will be able to share my thoughts, concerns, and delights along the way.

So now it is your turn. Hit up the comments below or send me a message on twitter (@learnitmakeit) and introduce yourself with your own hello world.