microcontroller
Assuming that we have an application which a lot of devices can connect and interact each other (like Internet of Things). Is there a way to identify the micro-controller that each connecting device contain inside? For example to identify if one device has a PIC or an Atmel or else? If not can at least identify if the micro-controller is 8bit vs 16bit or else?
edit: Can the firmware return the version of a microcontroller?
This answer is not STM32 specific but is based on experience and many such discussions over many (many) years. Others can add to this - it covers the main points (I think) but may not be complete.
It's encouraging to see someone asking these simple but fundamental questions and showing an awareness how such "little things" can 'gang aglae' in real life.
ie "If the micro does not initialise properly ..." really reads " ... when the micro does not initialise properly ..." :-) - and it's obvious that you realise this.
So:
Use of external pullup or pulldown is essential for those really keen on getting a well defined result. This is the single biggest must-do here. All the rest is a bonus. ie Setting to inputs with internal pullxxx is a compromise which will almost always work.
BUT if "almost always" is not good enough for your design then you need external pull xxxs.
Pullup or down does not seem to have an overwhelming better result. It may vary between ICs but can be determined from the data sheet. All things being equal (as they may be) I'd favour pull-down as there is a potential for lower leakage currents to device external circuitry - but this is liable to be minimal in a conformally coated PCB and/or a benign environment.
You may wish to look at startup action if you really care. eg a pulled up pin will start low and transit high at some stage. A pulled down pin will probably stay low throughout. This is probably not important but is mentioned for completeness.
ESD susceptibility will be device specific, quite likely symmetric and on average over many processors probably favours pull down as drivers tend to sink better than source if asymmetric. If you care a lot about ESD then you may wish to use low outputs with pull downs - as a a low impedance path will (probably) offer better ESD protection. But if you care a lot about ESD you will want to design for it in other ways and not rely on in-IC protection as your main protection.
Re question 3 - external pullxxxs is desirable but it seems safe to use values which are at the limiting high end of proper design and then use internal xxx's in parallel if desired. However, as internal pull xxxs often have a 2:1 Reffective you can get largest R and smallest current by using external only. What you of course want to avoid is external pull ups and internal pull downs or vice bersa - but that's unlikely to be an issue.
When I say " ... limiting high end of proper design ... " I mean just that and not "past the limiting ...". ie the pin will have a specified value of resistance which allows the worst case Vin spec to be met. A larger resistor may take less current in the resistor but may start to very slightly turn on the internal switch. ie it may be that there is an Rpulldown_current versus lowest overall current tradeoff as the internal driver starts to see leakage current (which will be extremely small) increasing the current to the dirver and whispering it on very slightly.
If you use eg pulldown you may then find it lower power to set the pin to output and drive it low, but this is an option that can be decided on in due course.
Almost an aside - NEVER allow protection diodes to handle "any significant currents" at any stage during operation. Allowing them to do so can lead to totally inexplicable processor action. The less the current the lower the chance of things gong wrong - and the harder to find it when they do.
I think it might be EM78P153A microcontroller or something from that family, at least the pinout seems to match. And yes, it has OTP ROM.
Manufacturer's page: http://www.emc.com.tw/eng/8bit_gpio_ds.asp
Best Answer
This answer is written on the basic assumption that the OP is choosing the devices and writing the firmware him/herself. The OP indicates this to be true in the comment discussion below the question.
Yes, you can certainly include functionality that will identify the device in use. Most (if not all) microcontrollers will have read-only memory that contains a device ID and a silicon revision number. The microcontroller will probably have the ability to read its own memory location in firmware so that it can report those values upon request. How you implement that functionality is entirely up to you.
If you're trying to prevent thieves from porting your firmware into other chips, this method will not prove to be very effective. It will be trivial for them to report dummy identification values when requested to make their chip look like another.