0

I have a function:

void Epd::SendData(unsigned char data) {
  digitalWrite(dc_pin, HIGH);
  SpiTransfer(data);
}

At the moment I am hardcoding data sent to it by calculating on paper and then writing the result as code, but I want to improve that. For example, I am calling:

SendData(0x03);
SendData(0x1f);

To get those two values (0x03 and 0x1f) I am converting the decimal value of 799 to binary: 1100011111 and then adding 0 at the beginning to make sure my binary result is 16 digits long: 0000 0011 0001 1111. After that, I convert every 4 bits to hexadecimal value and sending them as pairs using the SendData function.

I feel like I am almost there, but I don't know how to convert my result to proper type in order to send it to the SendData function:

void Epd::SendDecAsData(int dec) {
  int binary[16];
  for (int i = 0; i < 16; i++) {
    binary[i] = dec % 2;
    dec = dec / 2;
  }

  int dec1 = binary[15] * 8 + binary[14] * 4 + binary[13] * 2 + binary[12];
  int dec2 = binary[11] * 8 + binary[10] * 4 + binary[9] * 2 + binary[8];
  int dec3 = binary[7] * 8 + binary[6] * 4 + binary[5] * 2 + binary[4];
  int dec4 = binary[3] * 8 + binary[2] * 4 + binary[1] * 2 + binary[0];

  String val1 = "0x" + String(dec1, HEX) + String(dec2, HEX);
  String val2 = "0x" + String(dec3, HEX) + String(dec4, HEX);

  SendData(val1); // error because I'm sending `String` instead of `unsigned char`
  SendData(val2);
}

I need help converting those strings (val1, val2) to the right data type, or even better, optimizing this process to get the final result in the right type with less code/computation (probably avoiding conversion to String).

10
  • 3
    If I understand you correctly, you want to split a 16-bit int into two unsigned chars and send them. Why the convoluted conversion to hex? Why not use something like SendData(dec >> 8); SendData(dec & 0xff);. It's just binary data, no need to convert.
    – StarCat
    Nov 25 '20 at 17:32
  • @StarCat I just got the existing code (e-ink board) and I see they are sending hex value so I assumed I have to do the same. There is a ton of hardcoded SendData that is manually converted from dec to hex (for some reason as two SendData calls of 2 digit hex). So even when I just need to send 0 dec it is sent as SendData(0x00) called twice. I hope that explanation helps
    – pingDino
    Nov 25 '20 at 17:42
  • 3
    What you are sending with SendData(0x00) is not a hex value. It's just represented in your code text by a hexadecimal value but it is converted to an (unsigned char) binary value during compilation. You can replace all occurences of 0xNN with their decimal value (as long as they're not part of a string) and your program will work exactly the same. Just try it.
    – StarCat
    Nov 25 '20 at 17:49
  • 3
    799, 0x031f and B0000001100010111 are all stored as the same 16 bit binary number ... the differences are only in the source code for human reading .... compiled code always deals with 0000001100010111 ... your whole conversion program is a waste of resources ... do what @StarCat suggested in the first comment
    – jsotola
    Nov 25 '20 at 18:05
  • Thank you guys. I'll try as soon as I get to the office tomorrow
    – pingDino
    Nov 25 '20 at 18:07
1

As StarCat suggested, I can just send decimal values using the same function SendData I was provided with. Because the e-ink board can only communicate in 8-bit commands I still had to split my decimal value before sending it.

This is the function I used to send decimal data in 8-bit pairs:

void Epd::SendDecAsData(int dec) {
  if (dec == 0) {
    SendData(0);
    SendData(0);
  } else {
    SendData((dec-1) / 256);
    SendData((dec-1) % 256);
  }
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.