Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 11 of 11

Thread: Microcontroller from scratch

  1. #1

    Microcontroller from scratch

    Hi all,

    I have made a successful proof-of-concept prototype based on a Teensy3.2 (thanks Paul BTW). Now I would like to turn that into a pre-industrial minimum viable product. It is extremely likely that I am going to outsource this part as its is way over my abilities, but just to have an idea, how much work does that represent to buy a Microcontroller (e.g. the MK20) and write the firmware/libraries to make it work like my POC ?

    Thanks !

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    If it looks like this Teensy 3.2 DIY Reference Board and uses the bootloader MCU sold by PJRC you'll be in good shape to use the years of work in development of the Teensy software.

  3. #3
    Too bad, I was about to go for another MCU, a low power one such as the STM32

    Regardless, my question was more of a general one. What do you have to do programming-wise when you buy a chip directly
    from the manufacturer and you want to use it.

    I guess the availability of libraries should be an important factor when it comes to choosing an MCU, just as much as the specs.

    Thanks !
    Last edited by MattH; 02-06-2019 at 07:58 PM.

  4. #4
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Portland, OR
    There are arduino cores for STM32, but it really depends on the exact version. For example, this supports a few of the STM32s:


    Either you're finding a microcontroller with an Arduino core already available or the manufacturer sometimes has tools to help generate startup code and you get to learn how to use CMSIS or HAL layers available for your boards. Different manufacturers also have different methods of uploading code. It's a definite learning curve.

  5. #5
    Senior Member
    Join Date
    Apr 2013
    Re programing if sticking to the supported micro controllers, common method is to do early versions with bootloaders from PJRC and once you are sure your firmware is solid delete the bootloader from the PCB and use a bootloader IC on a plug in board to program on the production line (so single bootloader IC programs every unit off the line). since in normal operation the bootloader IC does not actually do anything. This will still be slower than using a production programmer to load the chips prior to soldering but works without expensive hardware.

    Does mean you need to consider how your future software updates would work to avoid situations like

  6. #6
    Very interesting article thanks GW !
    Again I won't be the one doing it but I want to know the general principle of MCU firmware development and what sort of skillset I should be looking for. As I expected development environment seems to be even more important than pure specs :
    For my specific application it sounds like a PSoC6 would be better than a STM32. Any experience with Cypress product ?
    Now I can go to the engineering department (I work in a University) and look for the right collaborator.
    Thanks guys !

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Quote Originally Posted by MattH View Post
    Regardless, my question was more of a general one. What do you have to do programming-wise when you buy a chip directly
    from the manufacturer and you want to use it.
    As a general answer to your general question, generally you start first with a dev board like Teensy, or Arduino, or ST Discovery, or one of many others on the market. The path people generally follow first looks like "proof of concept" work, where you try to get the dev board to run some key part of your project. For example, if you're going to make a product involving a brushless motor, maybe you try using libraries and writing some code to make the motor spin at a certain speed. Generally this proof of concept work has little optimization. The general idea is to confirm whether you are able to get the key parts working, which involves the hardware capability, breadth of library support, and your own skill to fill in the needed pieces. This early work involves quite a bit of learning, both about the hardware and its software tools.

    Generally "proof of concept" prototypes are built on solderless breadboards or by soldering parts on stripboard or vectorboard.

    Generally speaking, what is *not* usually done is a custom circuit board as the very first step. In these modern times where chips have so many advanced features, and where software tools offer many powerful but complex features, starting "from scratch" before you even have a clear idea whether the hardware, its existing libraries, and dev tools will meet your needs is risky and usually wasteful. Generally you would get a "proof of concept" working first on an existing dev board. Then the next general step is to attempt your own custom board design, usually by copying some or all of the dev board's schematic and adding the parts you've used.

  8. #8
    Spot on !

    I owe you the success of my POC prototype Paul. Thanks a million !

  9. #9
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Given the open sentence of OP - it seemed that "have made a successful proof-of-concept prototype based on a Teensy3.2" already been done … and going forward was a done deal using T_3.2 as a baseline - thus post #2 about what the next step would generally look like.

  10. #10
    Senior Member crees's Avatar
    Join Date
    Dec 2016
    I suppose if you project is simple and can be adapted to another chip platform without significant coding then you can go with what makes sense. Personally I think so much foundational work has been done with teensy that allows quicker concepts to product . You may find that other chips do not have the libraries you need and requires you to write your own. If so how much time to you have to adapt or completely write a library? One example is that my product uses the teensy octows2811 platform. Its awesome use of DMA is a perfect match for what I need. Reinventing this method on another chip is possible but I do not have time to adapt and validate a DMA based driver code on another MCU.

    Here is an example of a prototype teensy based board that has turned out pretty successful.

    Click image for larger version. 

Name:	50DF91D5-2143-4301-AA86-15AD8F91EDD7.jpg 
Views:	56 
Size:	102.5 KB 
ID:	15852

  11. #11
    You're all making very good points.
    My project is rather simple. I did not make an extensive use of Teensy's libraries except for I2C and BLE which can be found for the vast majority of chips. I am definitely aware that writing a firmware/bootloader and libraries from scratch is a serious job even for something as simple as my little project. Cypress'PSoC creator and designer softwares seem to make that part a bit easier though (in expert hands).
    I won't underestimate the importance of pre-existing work.
    Thanks !

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts