There are four steps/zones to this process - preheating, soaking, reflow and cooling.įor the traditional trapezoidal type profile base on lead free solder paste that Bittele uses for SMT assembly process: Reflow soldering is a process by which the solder paste is heated and changes to a molten state in order to connect components pins and PCB pads together permanently. This can be good and can be bad - among other things, you can use macros in ways you could never use variables or functions (you can pass a parameter to a macro too.Lead-free Reflow Profile: Soaking type vs.
Other preprocessor directives like #ifdef and such behave similarly.
Define reflow code#
Macro substitution is a lot like running find/replace on your code immediately prior to each time you compile it. The compiler is pretty clever about optimizing). It's not done at runtime (this is also true of const variables, as noted above. The macro substitution happens by the preprocessor, before the preprocessed source is passed to the compiler. In a few cases, it can be possible to generate code that doesn't have a separate place where the number in question is stored (there are several instructions where small operands are stuffed into the opcode) - but again, whether it's a constant variable or macro or numeric literal doesn't change this. The compiler is smart enough to use similar optimization techniques on globally scoped const variables and numeric literals - though I'm sure that someone sitting there changing little things about a sketch could find cases where the behavior wasn't the same. Whether it's macro substitution, or a const globally scoped variable, the data still has to be in the compiled binary. I'd really like to learn the proper use of pointer variables, and that is my next priority this winter once everything is shut down. I'm new enough at this programming thing to want to keep things as simple and obvious as possible, even at a slight performance hit. I'm still working on that, and have made all the original globals that are only used in one function locals, but that is another topic. The reason I like #defines is that I can group all the related definitions together at the top of the page, making them easy to find and modify as the situation calls for, whereas if I lump them under the global variables section, it gets messy, and seems to go against the custom of keeping global variables as few as possible.
a const value, although at 16 million instructions per second, the real world difference is probably not that great. If that is correct, it would seem to indicate a clear advantage to a #defined value vs. If I understand correctly, to use an example: #define REFLOW_HEATER_1 12Īt compile-time, the compiler will not allocate any specific memory to reflow heater 1, but simply substitute the value 12 for every instance of REFLOW_HEATER_1 in the sketch, whereas if I do: const int REFLOW_HEATER_1 = 12 Īs a global variable, the compiler causes the sketch to allocate 2 bytes of memory at run-time, and at every instance REFLOW_HEATER_1 is called, it has to read those 2 bytes, and write their value to another memory location. A recurring problem I have is that every time I think I understand how something works and start counting on what I think I know, it turns out that either I am mistaken, or there is more to the story, LOL Thanks guys! It doesn't seem like a clear advantage either way, performance-wise, and is more of a personal preference. One final 'behind the green door' difference is that you can actually change the value of a const. This dictates the use of #define as the compiler does not recognize a value stored in SRAM to be constant, despite it's naming. Tou can see however, that if your #define'd value were a byte, your code would compile smaller and then larger if it were a long.Īnother issue that comes into play is that some library functions require constant parameters so addresses can be assigned at the time of compilation. As pointers on a machine that has 16-bit addressing will be 2 bytes wide, the differences by using #define and const int are negligible, just in access time (SRAM is faster). The const int will find a home in SRAM and during compilation will have it's identifier replaced by a pointer to the address. During compilation, the pre-processor replaces each instance of the identifier with the value. #define'd values are embedded in the program and stored in FLASH. The reality is one of which memory is used. The use of memory is a confused issue as if no memory was used, the value could not exist.
0 kommentar(er)
