Hardware

Business Asset Tracker Template

When you run a company, you need some method to keep up with assets owned by your business (also known as "business personal property"). Such assets can include software, hardware, domain names, intellectual property, vehicles, and more. The typical motivation for tracking assets is to make sure that you're prepared when you need to file taxes - both you and your accountants will be happy that you have an up-to-date list, with prices, purchase dates, and expected lifetime.

Even more amazing to us, however, is just how many hardware businesses we've advised that don't have a system in place for keeping track of their equipment. Expensive lab equipment, reliability testers, calibration rigs, part kits, debug adapters, and computers just float around the company. Nobody knows exactly what the business owns, who it is assigned to, or where it can be found. Inevitably, these companies share a horror story about expensive hardware which can't be accounted for - often in the $10,000 - $50,000 range.

Don't let that happen to your company!

We developed an Excel template to keep track of our business assets. We have a list of all tangible and intangible assets owned by the business. We also track many relevant details that are useful come tax time, such as what year we claimed the expense and how taxes will be handled (accountants can get fancy).

If you're running a company, don't wait until tax time to worry about your business personal property. Stay on top of things with the same template we use in our own business.

USB IDs for Open Source Projects

USB-enabled products all have a Vendor ID (VID) and Product ID (PID) that are used as a unique identifier for that device. When writing USB device drivers, the PID/VID combination is used to determine which driver to load to communicate with the device.

In order to get a VID for your organization or product, you need to register with the USB-IF and pay a corresponding $5000 fee. If you are an individual or small team this registration fee can be a deal breaker.

Luckily, pid.codes exists to assist these individuals and teams. The pid.codes team inherited a Vendor ID from another company. Luckily the specific VID was registered prior to the change in USB-IF licensing terms which prohibits subassignments! Using this loophole, you are able to get a subassigned ID for your project.

If you have an open-source hardware project, you can apply to pid.codes for IDs. Here are some of the basic requirements listed on the pid.codes howto page:

  • Publicly available source code repository containing schematics or source code for a device with a USB interface.
  • Licensed under a recognized open source or open source hardware license. Your source code repository must contain a LICENSE file attesting to this fact.
  • If your project involves both hardware and software, both need to be licensed under recognised OSS and OSHW licenses. If your project involves only one or the other, we may ask for further justification as to why you need a PID associated with your software project / development board instead of allowing end-users to request their own.

I will definitely be looking to pid.codes for my future projects. Happy hacking!

Schematic Reviews for Firmware Engineers

As a firmware engineer, you will often be tasked with schematic reviews by your harware team. Take this seriously and provide a thorough review. Once a board is built, correcting mistakes may be difficult or impossible without re-spinning the board. If you don't understand the circuitry, sit down with the designer and walk through the schematics.

During early stages of a product cycle, I spend significant time reviewing schematics and brainstorming with the hardware team. During later stages, when the design is more mature, I often only perform sanity checks to make sure the latest changes look OK from a firmware perspective.

Phillip's Schematic Review Checklist

  • Does the system architecture make sense? If not, ask!
    • Is there a block diagram of the system? If not - do I understand the design enough to create one?
      • Understanding the big picture will help you catch mistakes
    • Are nets named consistently across connectors / different sets of schematics?
    • Are power rails labelled consistently?
  • Voltage domains
    • 3.3V goes to 3.3V parts, 1.8V goes to 1.8V parts, etc.
    • Do different IO blocks in the SOC have different voltage domains?
    • Can we use 1.8V instead of 3.3V for SOC?
    • Are there ways to eliminate voltage level translator ICs?
      • Powering different SOC IO blocks with different voltages?
  • Pullups (busses)
    • Do all busses that usually require pullups have them? (e.g. I2C, SPI)
      • Internal pullups are often not sufficient for busses - I highly recommend external pullups for most designs
    • Are signals pulled up to the correct voltage source?
    • Are pullups correctly sized?
  • Pullups/Pulldowns (default states)
    • Will the IO be initialized correctly when the board boots up?
    • Some IO rails from the SOC or PMIC may initialize with a certain state prior to software control - make sure this is accounted for!
  • Pin Mapping / alternative settings
    • Are pins mapped correctly?
      • A terribly nice engineer will cross reference each part's datasheet
    • Is there going to be contention on a bus due to parts in different power states?
      • I have seen poorly implemented I2C ICs take down a whole bus if the device is powered off.
    • Is a special purpose pin (e.g. IRQ or SPI friendly) being used when a normal pin (e.g. input/output only) could be used instead?
    • Do MSB/LSB assignments for busses map correctly? e.g. is bit 0 LSB on both busses, or is translation needed?
    • Do you need to set any alternative settings in firmware to account for the pin mapping?
  • Connectors
    • Do both sides of a connector have the correct pinout?
      • This is the #1 cause of schematic issues that I have seen in my career. Take your time, make sure they match in number of pins and pinouts.
      • If they don't match, have a damn good explanation for why.
  • Hardware Optimizations
    • Is there anything being done in hardware that can be handled in software?
      • This can be hard to find, but a big win if you identify a source of optimization. This is why it's important to understand the design and what each piece is doing.
      • Example: Reducing pins/resistors by utilizing internal fusing options
    • Is there anything hardware is expecting of software that is more easily handled in hardware (or totally infeasible)?
  • Debug options (early designs, development boards)
    • Are signals that you might need to scope brought out to debug headers or test points?
    • Do you have the ability to perform power measurements on a per-rail basis?
    • 0-ohm resistors for debug / rework options
      • Useful in evaluating multiple design paths, or having an escape option if you need to rework something.
    • Can any debug options be safely removed from a FF design?
      • You can regain space and reduce cost by removing these features once you are confident in a design. Keep them around on a dev board in case the need for debug arises.

Think something should be added to the list? Let me know in the comments.