After some tinkering, I figured out a formula that will work for those numbers WITHOUT a remainder of 10-15 (A thru F). It works with those having a remainder of 9 or less. I need help for representing the higher remainders as letters, not numbers.
SendInt[1] = (SendInt[1] / 16) * 10 + (SendInt[1] % 16); <EDIT> Realized I forgot to put the * 10
// Results if I enter :
SendInt[1] = 83, I get 53
SendInt[1] = 23, I get 17
SendInt[1] = 99, I get 60
Unfortunately, '95' gives me '65', not the desired '5F' since it's adding the remainder 15 to 50.
I've got no clue how to do this and haven't found it on Google.
{
Serial.print("In decimal: ");
Serial.print(value, DEC); // DEC is the default if not specified
Serial.print("\tIn hexadecimal: 0x");
Serial.println(value, HEX);
}
void setup()
{
Serial.begin(115200);
int intA = 123;
int intB = 23;
int intC = 0x83;
ShowValue(intA);
ShowValue(intB);
ShowValue(intC);
In decimal: 123 In hexadecimal: 0x7B
In decimal: 23 In hexadecimal: 0x17
In decimal: 131 In hexadecimal: 0x83
In decimal: 123 In hexadecimal: 0x7B
In decimal: 23 In hexadecimal: 0x17
In decimal: 131 In hexadecimal: 0x83
This would work if I was putting the result to the Serial Monitor. I need the result in a variable for further use.
When duplicating the procedure is when I discovered the correct values needed weren't being produced by sprintf(), but work for outputting to the Serial Monitor. It was marked [solved] prematurely, marked off my checklist of problems, and thought it was working until I had to call it up again. To which I found that plan didn't work and I'm back trying again.
To which I found that plan didn't work and I'm back trying again.
You will need to be more explicit about what "didn't work".
sprintf can give a null terminated hex character array in the form you appear to want to send.
There are several other ways to achieve the same end, but unless you are more specific about what you want, we are going in circles, perhaps around some axle
cattledog:
You will need to be more explicit about what "didn't work".
sprintf can give a null terminated hex character array in the form you appear to want to send.
There are several other ways to achieve the same end, but unless you are more specific about what you want, we are going in circles, perhaps around some axle
"Didn't work" as in no function or desirable results when it was transmitted in the format with sprintf().
I discovered this issue when I did a Serial.print for a byte with the value of 0x83. The result was a decimal with the value of 131, and not the value of 83, or even 0x83. I knew then the sprintf() was not what I needed to work.
I need to find the hexadecimal value of an integer (or decimal). The hexadecimal result will always be for a integer (or decimal) with a value of 99 or less, or a hex value of 01-63. When I calculate this hexadecimal number, it then gets placed in a byte to transmit.
For example, int SentInt[0] with a value of 90 must be converted so the byte SendByte[0] has a value of 5F, or 0x5F, by however means. I've figured out the formula for those integers (or decimals) that have a remainder of 9 or less. Currently, I do not know how to convert those remainders of 10-15 into the corresponding letters for hex (A - F). The formula so far: SentInt[0] = (SentInt[0] / 16) * 10 + (SentInt[0] % 16).
Currently, I do not know how to convert those remainders of 10-15 into the corresponding letters for hex (A - F).
value - 10 + 'A' is one conversion often used for ASCII representation of hex, but the talk of "90" as "5F" has made me kinda lose the plot here, and I'm too lazy to go back and read through this again.
peasoup:
I discovered this issue when I did a Serial.print for a byte with the value of 0x83. The result was a decimal with the value of 131, and not the value of 83, or even 0x83. I knew then the sprintf() was not what I needed to work.
I've tried to explain multiple times in this thread that a value within the processor is just a value. There's no such thing as a 'hex value' or 'decimal value', it's just a value.
It's almost like looking at two side by side buildings and saying one is 100 feet high and the other is 30.48 meters high. THE ARE THE SAME HEIGHT.
Now, when you start talking about "decimal representation" or "hex representation", then you're talking about a human-readable representation of the value. That means ASCII characters. They need to be stored in a null-terminated char array. Then they can be printed on the Serial Monitor, Displayed on an LCD, sent via wire over an RS232 interface, etc.
Regardless, please stop talking about "decimal integers" and "hex integers".
I'm not trying to be mean. But, I simply don't know how to explain it more clearly. Perhaps someone else can. But, at this point, all I can do is sit back and watch this Train Wreck unfold in slow motion.
gfvalvo:
I'm not trying to be mean. But, I simply don't know how to explain it more clearly. Perhaps someone else can. But, at this point, all I can do is sit back and watch this Train Wreck unfold in slow motion.
I didn't think you were. I see the terminology as one way (which is wrong, I know) and try to be as clear to explain myself. You see the terminology correctly (which I lack). Some people like myself, just needed it worded a certain way to grasp.
If I'm understanding you correctly and I hope I am, if I use the following I should be able to get the same results?
int SendInt[1] = 95; <-- For lack of better terms, the 'numeric representation' of 0x5F
byte SendByte[1] = 0x5F; <-- and the 'hexadecimal representation' of 95.
Serial1.write(SendInt[1]);
and
Serial1.write(SendByte[1]);
These are the same and both will work? If so, maybe it was the wall explanation that I had to hit my head with and I was obviously wwaaaayyyyy overthinking my problem. I'm really not an idiot, sometimes I miss the point and believe the problem lies deeper into the how/why part.
Well, you're getting closer. One trouble with what you posted is that 'int' and 'byte' are two different datatypes. On an 8-bit AVR (like Arduino Uno or Mega), an 'int' is 16 bits and occupies 2 bytes of memory. A 'byte', obviously, occupies one byte of memory.
But, since 'byte' is a non-standard, Arduino-specific type, I'd advise against using it. Instead, learn to use Standard Integer Types. A 'uint8_t' is an '8-bit, unsigned integer'. So, it's equivalent to a 'byte' but has a standard name.
The two assignment statements in the setup() function are 100% identical. Also note, as @TheMemberFormerlyKnownAsAWOL has been trying to beat into you, array element indices start at 0. So, a one-element array only has an element at index 0.
peasoup:
These are the same and both will work?
As I said, the two assignment statements above are identical. The other is question is difficult to answer because you haven't told us what "work" means. What are you going to do with this array? And, if you only need 1 element, why are you using an array at all?
It works. I had another situation in my code for the slot machine that used the so called byte, "3D", I changed the value to be sent to the slot machine to a value of "61". And it printed the cashout voucher and reported it back to the Arduino with no lockup. Yaayy for me.
Now that I'm publicly humiliated, by my own doing, I've learned a valuable lesson here. And I thank you for that. I'm sorry that it took 3 pages of posts to get it through my thick skull. I'm sure I've pissed off a few along the way as well.
Next time you see me trying to do something stupid and my issue isn't as in-depth as I'm describing, do me a favor and just tell me "dude, you're overthinking it again."
