First of all I am new in this domain, so excuse me if I ask dumb questions. I have worked in the past with AVR microcontrollers and used arduino's bootloaders. Here I need to work with ATtiny16/17, and I don't know if I have to develop a bootloader or not ? Is it possible that the bootloader is already integrated in the µC ? And if I don't need one how will my programs run in this case ?
Thank you!
This is a primarily opinion based question, but I'll take a stab anyway. You generally do not need a bootloader for microcontrollers. Some have or still do come with a factory programmed bootloader, some you can change, some you can't. The primary goal IMO is in circuit programming. That has been solved in other ways over the years. The AVRs have historically, and now being under Microchip I hope that isn't destroyed, had simple, usable interfaces. The specific interface varies across the range from the tiny to the xmega, but I have used each and they work fine. I just took some other board and wrote a bit-banger that programs the part, can even take a $10 Raspberry Pi Zero and turn that into an AVR programmer with a small amount of programming. Or you can buy simple, inexpensive solutions.
Now there are some boot-loader-y kinds of things you want to think about, some mcus if you mess with the plls and get it wrong you can brick the part. The AVRs historically are nice in that you program them when the part is in reset, so you don't deal with the part hanging before you can get in and stop it and program it. Others like st tend to have a strap pin, the bootloader or logic in the part decides whether or not to boot your code or their burned in loader based on the strapping of an input pin. allowing you to mess up, and then recover the part. Not just PLLs other dumb things in general, and these happen. This is mostly research first, what in circuit programming interfaces does the part support, and what are you going to design into the board and maybe use. Do you have the tools or not, etc.
Many parts have only one flash bank, some have two so you can ping pong or have a bootloader and an application, so depending on the architecture, chip design, etc you might be able to load a bootloader into ram to get off the flash then in application program the flash.
You are resource limited as it is, and while you can buy the more expensive part to get the loader in there, it is "better" to put some debug pads down on the board and use an external programmer, the development/recovery cost is not forced on every board, it is off-board. The ARM cortex-m based parts are starting to abandon their factory bootloaders and go with SWD only, or some with usb are supporting dfu. The security fears of IoT are going to tie your hands as to what can be done anyway, so you need to research that for each part.
If you write perfect code for your application then there is no need to ever reprogram the part, one time program, done. Not realistic but something to think about we end up spending a lot of time and sadly a lot of code in planning for dealing with our bad code. Every line of code adds to the risk so the more code we write to plan for fixing bad code, creates more bad code that we have to fix.
You can design a development board and the a production board, ideally you want some pads for in circuit programming during production, the AVRs have been historically been just fine for that. But depending on how much you need to trim on the production version, you might want to build a development version that has more interfaces exposed, and the production version is one time programmed or has a way to be reprogrammed but doesn't have much more debug than that. Really depends on the part and board design how many pins for debug stuff and how many pins for the product, etc.
So research the (each possible) part, understand the debug and (re)programming interfaces, bricking possibilities if any (other than simply destroying the part due to letting smoke out) and have a plan for those. This means getting or making breakout boards, buying or building development tools to learn how the part really works and how good/bad these interfaces are.
How do you develop, do you need a debugger or just need something to reprogram firmware with and try again? What options if any does the part provide for debug, does that mesh with your development style/desire.
What would a bootloader give you that the part doesn't already have? Are you creating more work for no reason? (every line of code adds risk to the product/project) It can be as simple of an answer as we have always had a bootloader we have an in-house (let's say) serial protocol we always use and have all of our test fixtures are using that protocol. That is a very good reason to write one or port an existing one to every mcu you use. If you don't have those requirements, then what is it giving you, what are the pros cons.
I think you will find that the majority of the current products from the major vendors have in circuit solutions that use a small number of pins protocol, i2c, spi, jtag/swd, proprietary. And those are generally adequate for development purposes as well as production. Let's think of it this way, the millions of products that contains mcus from kitchen timers to TV remotes, toasters and on and on, are high volume production, all the pennies are cost reduced out of the product, probably use ICT (in circuit testing) to test the PCBs and the manufacturing but also can and do program the programmables on the board (or you buy/make pre-programmed parts using some other special fixture) which means there is an interface you can use too.
You know, the Arduino bootloader is nice; you don't need more than a usb/uart board that you probably wanted anyway for talking to the application. Same goes for st's bootloader and Atmel's sam-ba (although that is now history) (st's is by default turned off/disabled in the newer products except for virgin parts). But these appear to becoming a thing of the past, why burn ROM space on a chip when you can have some small logic in front of the flash? Or if you buy a core that has a solution just wire it up and call it done.
So a lot of text to say what the other answers/comments are saying. You don't NEED one, your choice if you want one. The hardware tools are in the ones or fives of dollars for good ones so if you want to seriously develop for these platforms, make the investment.
