There are many reasons to bring a consultant on your project, but in the end, the decision to even look comes down to time vs money. It may cost more engineering budget to bring consultants on your project, but you may save in the long run. Here are some considerations that may help: - "I have a spike in the development and I don't want to increase the size of my development team, but I need to stay on schedule". This is a perfect opportunity to offload development of a module(s) to a consultant and let them deliver to your requirements. - "I am firefighting bugs and my development team isn't fixing them quickly enough or can't find a solution". Consultants bring knowledge to the business and that adds value. You can get your problem fixed faster if you offload the issue to the consultant. Your team gets back to work on your project and they have less stress by not working on the impediment. Who likes working on impediments? We do! That's our business, offload the work that you don't want your dev team doing. - "I can't afford to hire a permanent engineer because we just don't have enough work to support that decision". Bringing in a consultant for a short time can gain you traction on the project and set you up for success. We can help in the development, and/or help you analyze the best route to obtain your goals. - "My team isn't performing at expectations", and the velocity is below 13 points per developer on each sprint, and we aren't improving. What's going on? "We've tried different tactics, but the sprints are still suffering". Bring in a consultant to fix this problem. We provide project management that is good for both the team and management. We work within the team and help the team achieve it's goals. If your team is motivated, then we are more than half way there to fixing these issues. We'll take it the rest of the way and find the correct solutions for your business. Or alternatively have us come in and start doing some of the development. We'll hit our targets. We'll educate your team on how to be successful by example. - We also find root causes to issues. Maybe some people on the dev team don't know how to run your software process. You might be missing SOPs and WIs on how you want them using Jira or making a delivery to the SCM, the developers might not have the proper hardware, or you need someone to write a software installation guide to help developers install the software consistently. We advise you of the issues and help you manage your team more effectively. We do so by listening to your concerns and implementing the solutions the way you want them, "Not the way the consultants wants them".

We hit our target schedules and we do so within your framework. We aren't going to tell you how to run your business, project or team. We listen to the way you want to run your project and implement solid engineering designs using your guidelines. "I've hired consultants that want to do things their way; they think they have more experience and know better". Sometimes that experience actually gets in the way of progress. Silver Bullet Engineering, Inc doesn't have that philosophy. We don't scrap your existing codebase and replace it because there are some issues. We know how to add new features and fix bugs to your existing codebase. We don't throw away prior work - that doesn't add business value. We are all about business value. We make decisions with you that add business value to the project. And we do that work within the policies, procedures and working environment that you want. We've never had a manager lose ground because we implemented our own consulting solutions.

If the project has only one microcontroller, then the answer is possibly it makes sense to roll your own hardware. But why do you want to expend engineering resources and delay time to market when you can purchase a SOM or Microcontroller platform module. For projects that have a GUI (Panel, Linux, Android, etc) and also need an embedded microcontroller the answer is usually No - don't do the hardware design yourself. Advantages of a SOM or Microcontroller Platform: - The Board Support Package is provided by the SOM manufacturer - All you need to do to have the current version of software is to continue to download new releases from the SOM manufacturer - The new release has been tested and configured for your hardware platform - Having a Board Support Package offloads that work from the software department (Yes most hardware departments don't care about this feature, but it's a huge advantage, and your software department will definitely care) - There is an upgrade path! - You design the custom carrier board that the SOM plugs into. The connector used is standardized by the manufacturer, so the next version of the SOM that has the lastest new microcontroller can be swapped out; it's plug and play. - Time to market - You save the development and board bring up time. This is a major part of any product development. Go design the carrier board with the appropriate peripherals and leave the microcontroller design to the experts (SOM manufacturers) - REUSE! - It's a Platform - This isn't your one project solution. This is a platform that you can use for most or all of your new designs. The experience you gain on this product will help you design your next product. Most of the hardware and software will be reused. - Plus if you come to Silver Bullet Engineering, Inc we will customize your board support package and Hardware Abstraction Layer (HAL) for reuse. You will reuse a large portion of the design on your next product. Our recommendation is to use a SOM for most new hardware designs. We can help you find the proper SOM for your design and help you integrate that into your product line as a platform. We can help you with the hardware and software design.

NXP and ST provide a toolchain that is sufficient to get a project up and running quickly. So starting with MCUExpresso or STM32Cube can save time. After initial use, it can be benefitial to download the latest version Eclipse platform and configure the proper add-ins. By building upon the Eclipse platform with the proper plugins you stay current with the latest version of Eclipse. If you use one of the semiconductor manufacturer toolchains, then you will be several versions behind the Eclipse latest release. To ensure all your developers are using the proper versions, downloading all the tools to your SCM (Software Configuration Management) storage and writing an installation guide to ensure the entire team uses the tools properly can help your team.

PIC has been the standard for many years when it comes to peripheral management (like implementing one wire) and offloading the work from the main microcontroller. PIC has many example projects that in some cases provide a fully working solution and save you time. One example is one-wire comms to peripherals (disposables). But there are other low-level embedded designs that the PIC doesn't have a full example provided. Should you still use a PIC? Yes, you can design that peripheral project using a PIC, but do you have time to do trial and error to make it fully functional? Do you need security? ARM has a secure platform built that even includes a secure bootloader (TrustZone). If you're in the medical device industry, you want to pay attention to security and that includes the bootloader. Using a smaller ARM processor like a Cortex M0, M3, or even the larger M4 (or the later versions of the secure ARM processors) gains you one main advantage, the ARM processor comes with a HAL (Hardware Abstraction Layer) software. Both NXP and ST provide a HAL. Microchip PIC doesn't come with a HAL. Configuring peripherals like CAN bus, I2C, and SPI can be tricky when you're bit banging registers off the data sheet. Sometimes you get it right and it works, sometimes you experiment and get it working, sometimes you get it working and still wonder if it's fully configured 100% properly. It's a judgment call. But having a HAL takes a lot of the guess-work out of the data sheet and final software deliverable. Some of these data sheets are tricky to interpret. You have to work intensely with both the peripheral data sheet and the microcontroller data sheet to get it right. Working with a HAL means you have less need to consult the microcontroller data sheet, and that saves time to market.

Security on safety related projects like medical devices meeting FDA standards (IEC-62304 Software Lifecycle), FDA guidance, robotics meeting SIL compliance (IEC-61508) can be an issue. We have had to lockdown UART ports from use so the CLI (command line interface) can't be used by unauthorized people, lockdown JTAG ports so unaurthorized people cannot load software onto your board, and security on bootloaders is always an issue. Bootloaders usually require a custom protocol, changes to the Build Server script to generate a proper download file, signatures on download images, and a lot of engineering work to architect the overal system security. The newer microcontroller platforms from ARM have a TrustZone that is used to configure the environment. There are many options to secure the microcontroller that cover all the existing secuity issues listed above plus more. We can work with you to solve your existing security concerns. We can work with you to configure the microcontroller and bootloader to meet your development needs and security needs.

By working in regulated environments, I've found the following processes useful when developing high quality software. Before the team starts working on the product it's useful to have most of the basic support systems and tools in place. Here's a list of some of useful items: - SOPs and WIs completed: Standard Operating Procecedures and Work Instructions are available to the team. The team needs to know the process that management wants to use to develop the software. Having these documents ready for the team allows them to learn the process and start development. Templates for the design document should be available for the dev team. - SCM: Software Configuration Management. This system is used to store the software and controls revision history. This software is usually installed on the build server. - Software Installation Manual: This is part of the documentation package for the dev team. The document describes how to install all of the developer tools. The tools should be available in the SCM. - Architecture document: fully developed for the modules that are needed first. And the foundation of the software architecture is fully developed - Build and Release Management: A build process has been developed and possibly uses a build server to do routine builds of the software. - Testing strategy and testing software: Testing can consist of automated testing, manual testing, or any combination. Identifying and documenting the test process helps the team achieve management's goals. The more you document, the easier it will be on the team. If you're trying to do automated testing, then managing that process with a build server can save project time. Simple processes that are well planned help the dev team deliver on-time. - Requirements Document: Starting from well defined requirements allows the team to know what is needed to fulfill the product goals. Requirements can and should be revisited as the project progresses, adding more details as required when a particular module is about to be developed. - Issue Tracking System / Bug Tracking: This is a system that allows entry and tracking of issues within the project. Having an SOP for this system is useful for the team; it allows the team to know how to use this system effectively. - Bug Scrub Team: This team is responsible for management of the Issues Tracking System. They routinely monitor and configure this system so that bugs are prioritized and fixed. - Software Quality Assurance: Having a dedicated team for quality assurance that is following the dev team allows for coordination of testing activities. If that team is following along with the development, it's very helpful to the dev team. In fact, having the SQA team integrated with the dev team makes for a more cohesive environment.