How to map CC-codes into ASCII-codes?

I have a left-shifting 5-digit cc-type 7-segment display sub unit (Price Field of Fig-1) being driven by MAX7219 chips, which holds price of goods in the range: 00000 - 99999 (000.00 - 999.99). The cc-codes of the digits being shown on the display sub unit are available to me via byte type 5 variables. I would like to map these cc-codes (0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70, 0x7F, 0x7B for 0, 1, ..., 9) into ASCII codes (0x30, 0x31, ..., 0x39 for 0, 1, ..., 9) in order to use the atol() function to get the price in integer form which will be used to compute the cost of the goods. Currently, I have solved the issue using switch-case structure (display-circuit/codes are given below); alternative idea/algorithm is being longed to enrich my collection.

A: Schematic of the Display Unit


Figure-1: Display unit of a UNO-MAX7219 based Digital Weighing Machine (DWM)

B: Pictorial View of the Prototype Digital Weighing of which the Price Field is a Sub Unit

Figure-2: Pictorial view of the prototype DWM

C: Partial Codes for Price Entry, Weight Acquisition, Cost Computation, and Display Update.

byte lupTable[] = {0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70, 0x7F, 0x7B, 0x77, 0x1F, 0x4E, 0x3D, 0x4F, 0x47}; 
//0, 1, ...., E, F (p, a, b, c, d, e, f g)

byte ccCode[16] = {0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E, 0x7E};
 //ccCode0-ccCode4(wt) ; ccCode5-ccCode9(price); ccCode10-ccCode15(cost)

char keyAscii[6] = "";

void loop()
{
  byte customKey = customKeypad.getKey();
  if (customKey)
  {
     i++;
    ccKey = lupTable[(customKey & 0x0F)]; //cc-code is saved
    //------------------------------------------------------
    ccCode[5] = ccCode[6];
    ccCode[6] = ccCode[7];
    ccCode[7] = ccCode[8];
    ccCode[8] = ccCode[9];
    ccCode[9] = ccKey;
    displayPrice();
    //-----------------------------------------
    zero = caseSwitch(ccCode[5]); // 0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70,0x7F, 0x7B
    one  = caseSwitch(ccCode[6]);
    two = caseSwitch(ccCode[7]);
    three = caseSwitch(ccCode[8]);
    four = caseSwitch(ccCode[9]);
   
    if (flag2 == LOW)
    {
      caseSwitchA(i);
    }
    else
    {
      caseSwitchA(5);
    }

     price = atol(keyAscii); //0.00 - 999.99
   }

 else
 {
   weight();  //returns tWt as integer
   cost = tWt * price; //12375 * rate; //tWt * price; //as integer
   binToBcdCost();  //updates ccCode[] Table
   showDisplay();
 }   

}
 //-------------------------------------------------
byte caseSwitch(byte x) //0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70,0x7F, 0x7B
{
  switch (x)
  {
    case  0x7E: return 0x30;
    case  0x30: return 0x31;
    case  0x6D: return 0x32;
    case  0x79: return 0x33;
    case  0x33: return 0x34;
    case  0x5B: return 0x35;
    case  0x5F: return 0x36;
    case  0x70: return 0x37;
    case  0x7F: return 0x38;
    case  0x7B: return 0x39;
  }
}

//----------------------------------
byte caseSwitchA(byte x)
{
  switch (x)
  {
    case 1:
      {
        keyAscii[0] = four;
        keyAscii[1] = 0x00;//three;
        keyAscii[2] = 0x00;//two
        keyAscii[3] = 0x00;//one;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 2:
      {
        keyAscii[0] = three;
        keyAscii[1] = four;
        keyAscii[2] = 0x00;//two;
        keyAscii[3] = 0x00;//one;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 3:
      {
        keyAscii[0] = two;
        keyAscii[1] = three;
        keyAscii[2] = four;
        keyAscii[3] = 0x00;//one;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 4:
      {
        keyAscii[0] = one;
        keyAscii[1] = two;
        keyAscii[2] = three;
        keyAscii[3] = four;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 5:
      {
        keyAscii[0] = zero;
        keyAscii[1] = one;
        keyAscii[2] = two;
        keyAscii[3] = three;
        keyAscii[4] = four;
        flag2 = HIGH;
      }
      break;
  }
}

You could use a lookup table, which would probably be slighly slower and somewhat smaller, depending on what else is already in your program...

Generally, if it's a 1-to-1 mapping you could done something shorter like this:

byte mapAlpha2Num(byte alpha)
{
   static byte alp[] = {'A', 'B', 'C', 'D'};
   static byte num[] = {'1', '2', '3', '4'};
   int i;
   for (int i=0; i <4; i++) {
      if (alp[i] == alpha)
         break;
   }
   return num[i];
}

westfw:
You could use a lookup table, which would probably be slighly slower and somewhat smaller, depending on what else is already in your program...

I thought about it but could not figure out the way of realizing it using C's pointers. In assembly programming, it so easy to use pointers to collect source codes (the cc-codes) from one set of known memory locations and then collect the corresponding target codes (the ASCII codes) from another set of known memory locations. In C, I can create two look up Tables -- lupTableCC[10] = {0x7E, ..., 0x7B} containing cc-codes for the digits 0 to 9 and lupTableAs[10] = {0x30, ..., 0x39} containing ASCII codes for the digits 0 to 9. Now, how to use C to map 0x7E into 0x30 or 0x7B into 0x39 given that every digit position of the 5-digit price field can assume any digit from 0 to 9.

Thanks for the interest and guidance.

Im not at a keyboard at the moment, but... something like:

ascii = ‘0’ + ( strchr(lupTable, cccode) - lupTable );

(Put a null at the end of lupTable!)

Hell, you could brute force it with two 256 byte arrays as lookup tables... Is there some complication I'm missing here?

Why are you saving the cc-codes in the first place? Just save the chars, converting from char to cc-code using a LUT is less expensive than the other way around.

Pieter

PieterP:
Why are you saving the cc-codes in the first place? Just save the chars, converting from char to cc-code using a LUT is less expensive than the other way around.

That's what was done at the beginning, and it was fine if the price was taken after the entry of all 5 digits of the price and using the atol() function. Rather than waiting for all the 5 digit entry during which there happened no activity on the display, it had been decided to compute/show the cost of the goods for the current partial/final price seen on the Price Field due to left-shifting digit entry from the ASCII keypad. The price could be computed from the saved ASCII codes of the keyAscii[] array, but it was soon discovered that whatever were being seen on the Price Field (up to 5 digit entry) did do 1-to-1 correspondence (position-wise) with the contents of keyAscii[] array. After 5 digit entry, the digits were shifting left on the Price Field, but the keyAscii[] array was not tracking the digit positions. This disparity required a lot of manipulation to align the data of keyAscii[] array so that the atol() function could be applied to get the price in integer form.

As the vision varies person to person, it has been decided to avoid the manipulation (shifting and shifting) of the contents of the keyAscii[] array and to using 'what is being seen on the Price Field (the cc-codes)' to find the price through the use of atol() function and here comes the need of mapping cc-codes into ASCII codes. The solution that has been devised using switch-case works fine; yet, there could be other better means to solve the issue and these are being poured by the enthusiastic Forum Members.

Thank you for the interest and guidance. I will re-check/re-test your proposal.

arduino_new:
Generally, if it's a 1-to-1 mapping you could done something shorter like this:

byte mapAlpha2Num(byte alpha)

{
  static byte alp[] = {'A', 'B', 'C', 'D'};
  static byte num[] = {'1', '2', '3', '4'};
  int i;
  for (int i=0; i <4; i++) {
     if (alp[i] == alpha)
        break;
  }
  return num[i];
}

1. Your codes have worked well, but I have to delete the keyword int from the for() loop. When I have executed the following version of your codes, I have received correct response (1, 12, 123, 1234, 12345) for the price entry of 12345 (123.45) or any other combination.

byte caseSwitch(byte alpha)
{
  //static byte alp[] = {'A', 'B', 'C', 'D'};
  // static byte num[] = {'1', '2', '3', '4'};
  //int i;
  for (i = 0; i < 16; i++)
  {
    if (lupTable[i] == alpha)
      break;
  }
  return codeAscii[i];
}

2. Your codes have not worked with the keyword int in the for() loop. When I have executed the following version of your codes, I have received wrong response (1, 22, 33, 44, 55555) for the price entry of 12345 (123.45) or any other combination. I have successfully hooked up your program with the Parent Control Program of the DWM (Digital Weighing Machine) and everything works fine.

byte caseSwitch(byte alpha)
{
  //static byte alp[] = {'A', 'B', 'C', 'D'};
  // static byte num[] = {'1', '2', '3', '4'};
  //int i;
  for (int i = 0; i < 16; i++)
  {
    if (lupTable[i] == alpha)
      break;
  }
  return codeAscii[i];
}

3. Your 9-line program has produced the same result which the following 16-line program was producing.

byte caseSwitch(byte x) 
{
  switch (x)
  {
    case  0x7E: return 0x30;
    case  0x30: return 0x31;
    case  0x6D: return 0x32;
    case  0x79: return 0x33;
    case  0x33: return 0x34;
    case  0x5B: return 0x35;
    case  0x5F: return 0x36;
    case  0x70: return 0x37;
    case  0x7F: return 0x38;
    case  0x7B: return 0x39;
  }
}

Congratulation with karma for the contribution!

GolamMostafa:
1. Your codes have worked well, but I have to delete the keyword int from the for() loop. When I have executed the following version of your codes, I have received correct response (1, 12, 123, 1234, 12345) for the price entry of 12345 (123.45) or any other combination.

byte caseSwitch(byte alpha)

{
  //static byte alp[] = {'A', 'B', 'C', 'D'};
  // static byte num[] = {'1', '2', '3', '4'};
  //int i;
  for (i = 0; i < 16; i++)
  {
    if (lupTable[i] == alpha)
      break;
  }
  return codeAscii[i];
}




**2.** Your codes have not worked with the keyword **int** in the for() loop. When I have executed the following version of your codes, I have received wrong response (1, 22, 33, 44, 55555) for the price entry of 12345 (123.45) or any other combination.


byte caseSwitch(byte alpha)
{
  //static byte alp[] = {'A', 'B', 'C', 'D'};
  // static byte num[] = {'1', '2', '3', '4'};
  //int i;
  for (int i = 0; i < 16; i++)
  {
    if (lupTable[i] == alpha)
      break;
  }
  return codeAscii[i];
}




**3.** Your 9-line program has produced the same result which the following 16-line program was producing.


byte caseSwitch(byte x)
{
  switch (x)
  {
    case  0x7E: return 0x30;
    case  0x30: return 0x31;
    case  0x6D: return 0x32;
    case  0x79: return 0x33;
    case  0x33: return 0x34;
    case  0x5B: return 0x35;
    case  0x5F: return 0x36;
    case  0x70: return 0x37;
    case  0x7F: return 0x38;
    case  0x7B: return 0x39;
  }
}





Congratulation with p... for the contribution!

Yeah I was meant to delete that re-declaration.

If you make the 2 tables global, you can map the other way too, and it still looks prettier than switch-cases.

westfw:
Im not at a keyboard at the moment, but... something like:

ascii = ‘0’ + ( strchr(lupTable, cccode) - lupTable );

(Put a null at the end of lupTable!)

1. Your single line program has fantastically worked. When I have executed the following version of your program, I have received right response (1, 12, 123, 1234, 12345) for the price entry of 12345 (123.45) or any other combination. I have successfully hooked up your program with the Parent Control Program of the DWM (Digital Weighing Machine) and everything works fine.

byte caseSwitch(byte x)
{
  return '0' + ( strchr(lupTable, x) - lupTable );
}
  1. Your 4-line program has produced the same result which the following 16-line program was producing.
byte caseSwitch(byte x) 
{
  switch (x)
  {
    case  0x7E: return 0x30;
    case  0x30: return 0x31;
    case  0x6D: return 0x32;
    case  0x79: return 0x33;
    case  0x33: return 0x34;
    case  0x5B: return 0x35;
    case  0x5F: return 0x36;
    case  0x70: return 0x37;
    case  0x7F: return 0x38;
    case  0x7B: return 0x39;
  }
}

Thank you with karma for the contribution!

If you can afford 265 bytes of memory, just allocate a static array of 256 bytes and put the values for the corresponding cc codes into it.

No need use atoi and ascii.

int value = 0;
for(int digit = 0; digit < 6; digit++) {
  value = 10*value + translate_cc[mydisplay[digit]];
}

PaulMurrayCbr:
If you can afford 265 bytes of memory, just allocate a static array of 256 bytes and put the values for the corresponding cc codes into it.

No need use atoi and ascii.

int value = 0;

for(int digit = 0; digit < 6; digit++) {
 value = 10*value + translate_cc[mydisplay[digit]];
}

1. Congratulation with karma for the above program/contribution which works well. When I have executed the following version of your program, it has provided the correct response (1, 12, 123, 1234, 12345) for the price entry of 12345 (123.45) or any other combination. I have successfully hooked up your program with the Parent Control Program of the DWM (Digital Weighing Machine) and everything works fine.

static byte translate_cc[] = {     //global declaration
  //00  01  02  03  04  05  06  07  08  09  0A  0B  0C  0D  0E  0F
  //10  11  12  13  14  15  16  17  18  19  1A  1B  1C  1D  1E  1F
  00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
  00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,

  //20  21  22  23  24  25  26  27  28  29  2A  2B  2C  2D  2E  2F
  //30  31  32  33  34  35  36  37  38  39  3A  3B  3C  3D  3E  3F
  00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
  0x1, 00, 00, 0x4, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,

  //40  41  42  43  44  45  46  47  48  49  4A  4B  4C  4D  4E  4F
  //50  51  52  53  54  55  56  57  58  59  5A  5B  5C  5D  5E  5F
  00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
  00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 0x5, 00, 00, 00, 0x6,

  //60  61  62  63  64  65  66  67  68  69  6A  6B  6C  6D  6E  6F
  //70  71  72  73  74  75  76  77  78  79  7A  7B  7C  7D  7E  7F
  00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 0x2, 00, 00,
  0x7, 00, 00, 00, 00, 00, 00, 00, 00, 03, 00, 0x9, 00, 00, 00, 0x8
};

/*-- The above array can also be created executing the following codes;-----------
*---------byte numericValue[128];

  for (int i = 0; i < 0x80; i++)
  {
    if (i == 0x30 | 0x33 | 0x5B | 0x5F | 0x6D | 0x70 | 0x79 | 0x7B | 0x7E | 0x7F)
    {
      numericValue [i] = putValue(i);
    }
    else
    {
      numericValue[i] = 0x00;
    }
  }

Serial.println(numericValue[0x7B], HEX);   //testing 9
}

byte putValue(byte x)
{
  switch (x)
  {
    case 0x30: return 0x01;
    case 0x33: return 0x04;
    case 0x5B: return 0x05;
    case 0x5F: return 0x06;
    case 0x6D: return 0x02;
    case 0x70: return 0x07;
    case 0x79: return 0x03;
    case 0x7B: return 0x09;
    case 0x7E: return 0x00;
    case 0x7F: return 0x08;
  }
}

----------------------------------------------------------------*/

unsigned long priceX=0; //global declrartion
int digit; //global declaration

for (digit = 5; digit < 10; digit++)
{
   priceX = 10 * priceX + translate_cc[ccCode[digit]];
     // price = atol(keyAscii); //0.00 - 999.99
}
digit = 5;
price = priceX;   //price is used to compute cost of the goods
priceX = 0;

2. Your 4-line program along with a 128-byte Look-up Table has produced the same result which the following 80-line program was producing.

zero = caseSwitch(ccCode[5]); // 0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70,0x7F, 0x7B
one  = caseSwitch(ccCode[6]);
two = caseSwitch(ccCode[7]);
three = caseSwitch(ccCode[8]);
four = caseSwitch(ccCode[9]);

if (flag2 == LOW)
{
   caseSwitchA(i);
}
else
{
   caseSwitchA(5);
}
price = atol(keyAscii); //0.00 - 999.99 
//------------------------------------------------

 byte caseSwitch(byte x) //0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70,0x7F, 0x7B
{
  switch (x)
  {
    case  0x7E: return 0x30;
    case  0x30: return 0x31;
    case  0x6D: return 0x32;
    case  0x79: return 0x33;
    case  0x33: return 0x34;
    case  0x5B: return 0x35;
    case  0x5F: return 0x36;
    case  0x70: return 0x37;
    case  0x7F: return 0x38;
    case  0x7B: return 0x39;
  }
}

byte caseSwitchA(byte x)
{
  switch (x)
  {
    case 1:
      {
        keyAscii[0] = four;
        keyAscii[1] = 0x00;//three;
        keyAscii[2] = 0x00;//two
        keyAscii[3] = 0x00;//one;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 2:
      {
        keyAscii[0] = three;
        keyAscii[1] = four;
        keyAscii[2] = 0x00;//two;
        keyAscii[3] = 0x00;//one;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 3:
      {
        keyAscii[0] = two;
        keyAscii[1] = three;
        keyAscii[2] = four;
        keyAscii[3] = 0x00;//one;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 4:
      {
        keyAscii[0] = one;
        keyAscii[1] = two;
        keyAscii[2] = three;
        keyAscii[3] = four;
        keyAscii[4] = 0x00;//zero;
      }
      break;
    case 5:
      {
        keyAscii[0] = zero;
        keyAscii[1] = one;
        keyAscii[2] = two;
        keyAscii[3] = three;
        keyAscii[4] = four;
        flag2 = HIGH;
      }
      break;
  }
}

DrAzzy:
Hell, you could brute force it with two 256 byte arrays as lookup tables... Is there some complication I'm missing here?

You have provided solution clue in a symbolic way that I have understood now. I think that you have told to follow these steps:

1. Create an array to hold cc-codes for the digits 0, 1, ..., 9 where the digits are the sequential indices for the array elements. Now, I can create the following array:

byte ccCode[] = {0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70, 0x7F, 0x7B};
//0, 1, 2, 3, 4, 5, 6, 7, 8, 9

2. Create an array to hold numerical values (0x01 or 0x02, 0r 0x03, 0r 0x03, ..., or 0x09 whatever is required/exits) for the cc-codes of: 0x00, 0x01, ..., 0x7E, 0x7F where the cc-codes are the sequential indices for the numerical values. Now, I can create this array executing the following codes:

void setup()
{
  Serial.begin(9600);
  byte numericValue[128];

  for (int i = 0; i < 0x80; i++)
  {
    if (i == 0x30 | 0x33 | 0x5B | 0x5F | 0x6D | 0x70 | 0x79 | 0x7B | 0x7E | 0x7F)
    {
      numericValue [i] = putValue(i);
    }
    else
    {
      numericValue[i] = 0x00;
    }
  }

Serial.println(numericValue[0x7B], HEX);
}

void loop() 
{

}

byte putValue(byte x)
{
  switch (x)
  {
    case 0x30: return 0x01;
    case 0x33: return 0x04;
    case 0x5B: return 0x05;
    case 0x5F: return 0x06;
    case 0x6D: return 0x02;
    case 0x70: return 0x07;
    case 0x79: return 0x03;
    case 0x7B: return 0x09;
    case 0x7E: return 0x00;
    case 0x7F: return 0x08;
  }
}

3. Now, I can use the following algorithm (taken from Post#11) to get the price without knowing the ASCII codes for the corresponding cc-codes of the Price Field and also without using the atol() function.

int value = 0;
for(int digit = 0; digit < 6; digit++) 
{
  value = 10*value + translate_cc[mydisplay[digit]];
}

Thanks with karma for the contribution!

  ascii = '0' + ( strchr(lupTable, cccode) - lupTable );
  1. Your single line program has fantastically worked.

Oh good; often my first attempts have bugs and syntax errors; after all - you can let the compiler do SOME of your debugging for you...
Here's a more detailed description of how it works...

byte lupTable[] = {0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70, 0x7F, 0x7B, 0};

lupTable already maps an integer 0..9 to the segment Codes that we're looking for.
We can also search through the table for the Code, and get an index back.
You could do this with a loop, but the standard C library already has a function to look for a particular character in an array of characters (strchr()) that is probably more optimized than anything we could write.
However, strchr() returns a pointer to the matching byte, rather than an index. Subtracting two pointers gives you the 'distance' between them, so we can get the index by subracting the base address of the array from the results of the strchr() operation:

resultPtr = strchr(lupTable, cccode);
index = resultPtr - lupTable;

(the behavior of subtracted pointers may be new to many people.)

To convert the index to some other code, we COULD use a second lookup table:

finalResult = index2result[index];

But in this particular case, the desired results are sequential and we want ascii, so we can just add the index to the character value for zero ('0'). If we wanted to translate the full hex range, we might want something like:

 ascii = "01234567890ABCDEF"[( strchr(lupTable, cccode) - lupTable )];

Of course, as others have pointed out, if your final goal is a decimal number, you don't really need to convert to ascii first; you can just use the derived index (essentially your old friend BCD) in the usual decimal conversion routine.

westfw:
However, strchr() returns a pointer to the matching byte, rather than an index. Subtracting two pointers gives you the 'distance' between them, so we can get the index by subracting the base address of the array from the results of the strchr() operation:

resultPtr = strchr(lupTable, cccode);

index = resultPtr - lupTable;




(the behavior of subtracted pointers may be new to many people.)

I have some interest to study the working principle of the strchr() function based on your quoted description. Comments would be highly appreciated.

char lupTable[] = {0x7E, 0x30, 0x6D, 0x79, 0x33, 0x5B, 0x5F, 0x70, 0x7F, 0x7B, 0};

void setup() 
{
  Serial.begin(9600);
  char *resultPtr = strchr(lupTable, 0x5B);
  int pointerCode = resultPtr;
  Serial.println(pointerCode, HEX);  //shows : 0x0105 = address of storage area for target ccCode (0x5B)

  int pointerTable = lupTable;
  Serial.println(pointerTable, HEX);  //shows : 0x0100 = base address of storage space of lupTable
  byte indexCode = pointerCode - pointerTable;
  Serial.println(indexCode, HEX);   //shows: 0x05 = the sequential index of the target ccCode (0x5B)

  byte ascii = '0' + indexCode;
  Serial.println(ascii, HEX); //shows 0x35; the ASCII code for the digit 5 for which the MAX7219-based ccCode is 0x5B 
}

void loop() 
{
 
}

Yes, that looks fine. Do you really get 0x100 ? That's the very first possible address of RAM on an ATmega328/etc, and I would have expected it to have internal variables from the core, rather than user variables (but maybe not.)

Thank you for reviewing my post and the subsequent certification. This is the screenshot of the Serial Monitor which shows the addresses, index, and ASCII Code.

strchr.png

ram.png

strchr.png

ram.png

  char *resultPtr = strchr(lupTable, 0x5B);
  int pointerCode = resultPtr;

This certainly should product semantic error like so: error: invalid conversion from 'char*' to 'int'. I don't know why it didn't report it as error, maybe you found a bug.

I don't know if Serial.print() supports printing address but you can workaround like so:

    char buf[100];
    char *c = new char('c'); //address of something somewhere.

    sprintf(buf, "%p", c); //%p to print the address.
    Serial.println(buff);

arduino_new:

  char *resultPtr = strchr(lupTable, 0x5B);

int pointerCode = resultPtr;




This certainly should product semantic error like so: __error: invalid conversion from 'char*' to 'int'__. I don't know why it didn't report it as error, maybe you found a bug.

1. Why should it produce error for ambiguity in meaning? The following prototype of the strchr() function clearly leads to the declaration/definition of char *resultPtr = strschr(lupTable, 0x5B); where resultPtr is a pointer variable which holds the address of the matching byte found in the string/array named lupTable.

char *_CType  strchr(const char *_s, int_c);

2. resultPtr is a pointer variable, and it holds a numerical value. In order to print the numerical value on the Serial Monitor, we must transfer the content of the variable resultPtr into an integer type variable. This is to say --

int pointerCode = resultPtr;
Serial.println(pointerCode, HEX);