When to use int, const int, const byte and Define

I have visited that pool and discovered I don't really enjoy swimming there. I wasn't aware of the limitation between coding and electronics in the E14 Community. I assumed it was technology. Arduino technology such as coding was permissible.

I will never get to the level of professional coding. Mine is an interest (they did it because) and not a profession (it is important that do that because). Great resource I will try and use it. I like the reference to style in the appendix. I seem to recall I had a similar reference style-guide for Python in Visual Studio. At least my code looked I knew what I was doing:)

The last bullet point works if you have the knowledge to understand why they did what they did and not why they did something different. This whole thread was sparked from a tech tip I received in an email about using #define. 

May or may not help but Microchip published a couple of short courses on the fundamentals of embedded C, which might help with filling in some of the gaps.

https://mu.microchip.com/syntax-and-structure-of-c

https://mu.microchip.com/advanced-c-programming

int ledpin = 13; // The compiler will reserve 16-bits (assuming 16-bit processor) at an address in memory to store the number 13 0b0000000000001101.  that address will be used to retrieve the literal when used, every time, because the compiler has no knowledge if that value will change.

const byte ledpin = 13; // the compiler (if it is half decent) will almost certainly substitute the use of variable ledpin with an 8-bit literal value 0b00001101.

#define led_pin 13; // the pre-processor will text substitute, in source non-permanently, the word "led_pin" with the text "13" and then send the source to the compiler.  The compiler will then treat it as a literal integer (so like the const definition) but whether that would be as a 16-bit literal or an 8-bit literal would need to be researched because I don't actually know (it's an interesting thought actually and my first suspicion is that it would choose the most optimum bit size, 8 in this case!)

Any of these work but a ressurectionist will always struggle because they look radically different.  However, this stuff is as basic to programming as understanding Ohms law in electronics.  I'm an (ex-)developer, albeit one who hasn't had a professional development role for over 20 years, who had zero knowledge of C when I picked up an Arduino, so I actually spent some time understanding how the language dealt with types, working out the differences between const and #define, what happens if types are mixed in an expression (e.g int aVar = 12 / 7.1; ) and so on.  These things are so fundamental that even a resurrectionist should take the time to understand it if they intend to spend any time with microprocessors, including Arduino, because copy-and-paste will very often introduce strange errors into existing code (as, I think, you have found out on many occasions.)  I say this in the nicest possible way and not to criticise at all - I honestly believe it will increase your enjoyment of working with Arduinos if you understand a little more than you currently do.  It really will be worth the effort and we can help you clarify points of understanding.  

I still have a problem with C in that it would appear that many 'experienced' C programmers seem to go out of their way to write C code in as an obscure a manner as possible!  I also struggle with pointers despite reading umpteen articles about them and I have to revisit constantly.  

Jan, what do functions rdid() and rdsr() do?  Ditto set_nhold() and set_nwrite()?  I don't mean, the code, but what you would say in a function comment for them?  rdid() - is that reading an id for example?  What are the purposes of variables srwd, bp2?  

The snow storm here is almost over. Maybe next time:)

OMG  "colporteur "When to use int, const int, const byte and Define", I have been working with K&R and then ANSI C since the mid '70s.  Let me start at the top and work to the bottom;

• int ::= any time you want any sort of number (whole only)
• cont int        this is stupid lets me tell the compiler that I am not going to change its value; 
• const byte   "
• #define::=  This is a macro;  I use this to assign values for a named variable such as "#define FAIL -1;" or things that are not in the library like the value of pi. or a square "#define sqr(a)  ((a)*(a)",  

NOTE: error messages and I have quite a few some of my boxes will have 50+ error messages. here is the best way to handle them. The key is to standardize them. so lets build a structure of error messages:

typedef struct eMessages{
  int errorNumber;
  int equipment; 
  int formatType;     // this is info we send to the formatter
  char[200] error;    //message long
  char[20]  errorsh;  //short version
  } errorMessages;
  
  all error messages can now be unified
  
  void ErrorMessage(int errorNumber, int equipment, int formatType ){
  time_t current_raw_time = time(0); // System time:
   printf ( "%02d:%02d:%02d: #%10d -- #%u -- %s200 \n" errorMessages, int equipment, formatType);

Ok, I got your confusion. I created a simple function that prints pin number specified in different data types using Compiler Explorer (godbolt.org)
As you can see from the assembly language, compiler considers
#define and const declaration as same and directly copy the absolute value to register.
int as a 32bit value (double word).
byte as 8bit value, which compiler copies to lower byte and set 0 to rest of the higher order bytes.

Considering pin number won't change during compilation or run time and less amount of processing required pin definition can be made using const or #define types.

5 mins a day would soon get you through it. Time you are likely to get back starting from your next project.

When compiling, you have multiple steps, three of them being preprocessor, compiler and linker in that order

The preprocessor takes your source files, modifies them "in memory" and passes the result to the compiler

The compiler takes its input and generates machine code in the form of object files (.o)

The linker takes all object files and creates the final application file (.exe under Windows, .bin for firmware...)

#define NAME value tells the preprocessor to replace NAME by value wherever it sees it. It is just like copy/paste but done for you by the preprocessor, which means the compiler will never see the NAME item, only a repetition of value in lots of places

const int and int only differ in semantics, the "const" specifier telling the compiler that it should not allow any code to change the value. As this is seen by the compiler, you can "take" the address of the constant by using the ampersand (&) operator, which might be required by some libraries and is even more convenient when dealing with structures because all you deal with is a pointer (32 bits on 32 bits architecture) and not the entire structure itself (that can range in the dozen of bytes)

Finally, the linker can do some serious optimizations with constants when they have the same value by "merging" them together, meaning that 10 constants with the same value only occupy their size once in the final firmware. While this does not mean much under desktop OSes, it can be very important on embedded architectures.
One other benefit of "const" is that on architectures like the ESP32, the value is not placed in RAM but in Program memory. As RAM is very limited (120k contiguous at most), it is of the utmost importance to place as little things as possible in there.

> what do functions rdid() and rdsr() do?

That's the name of a function you can do with flash.

> Ditto set_nhold() and set_nwrite()?

set the IC's NHOLD and NWRITE pins

> What are the purposes of variables srwd, bp2?  

I did that deliberately - match the manufacturer's names.