> thanks for this explanation. The reason I'm asking such questions is, I want > to find out wether there are cases where SystemInit() is unavoidable. I take > your answer as a "no", because constructors usually go, well, into the > constructor of a class. I have to admit I use C++ very rarely, though, > preferring either plain C or Objective-C.
Using the initX/finiX functions effect act like constructor/destructors for plain C, as long as you understand their limitations and differences from the real ones in C++. SystemInit is a convenience function supplied by device manufactures as part of CMSIS. Its use is not required directly. The device still needs to be inilized somehow. I've never really found these type of 'magical' functions of value other than as an example of device initialization, as they rarely do what I need. >arm-libc. Because everything is custom, custom ... and you have to port over >and over again for each new chip. I support the goal of arm-libc. Not really seeing how that prevents having to port new devices? arm-libc itself would need updated for each new device would it not? Something I'm not understanding here. > I try to put no emphasis on what helps exactly me in exactly this case. IMO, > code which helps everybody, everywhere matters. I was referring to helping the arm-libc project, not you personally, sorry that I was not clear. atomic.h is useful for any device when dealing with C in embedded systems. > Sorry for such unpleasant words as an answer to your help attempt. It's the > fourth time now people seem to assume I'm incapable to solve my particular > task currently at hand, which bugs me a bit. I I address my point of confusion above. Which is probably why this has happened. I know you from other lists and know you are quite capable of addressing your own issues. _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
