How can I print these two sentences as a compound sentence in serial print?
1.sentence = 0x
2.sentence = F740BF
Serial.println("0x"+F740BF); I tried this but it didn't work
Serial.print("0x");
Serial.println("F740BF");
hi, i need the join code as i will put it in a variable
sample
veri = 0x+F740BF;
Try then
unsigned long veri = 0xF740BF;
Serial.print("0x");
Serial.println(veri, HEX);
code= irsend.sendNEC(0xF740BF, 32); i am using this code. I'm sending the data to the part that says 0xF740BF, but it should be 0x at the beginning
Do you have a number or a string?
I don’t understand what irsend.sendNEC() has to do with your printing question. Can you clarify exactly the need and context?
Incoming data in ir receiver =F740BF this data irsend.sendNEC(HERE,32); I'm posting it here, but there should be a 0x at the beginning, is there a code that can combine the two sentences?
Why do you think this? The "0x" is indicating that what follows is a number expressed as a hexadecimal value.
this is ir send code. should be 0x at the beginning
Post your current sketch to see how we can help.
My crystalball is in the dishwasher.
If variable veri holds your number you do
unsigned long veri = 0xF740BF;
Serial.print("0x");
Serial.println(veri, HEX);
irsend.sendNEC(veri, 32);
The 0x is just a notation to say that the number literal that follows is expressed in hexadecimal. You probably misunderstand this. When the number is in a variable, then you don’t worry about the base (it’s in binary in memory).
Try this:
Serial.begin(9600);
String myString = "0x";
Serial.println(myString+"F740BF"); ///shows: 0xF740BF
What a waste of resources 
but it does the job !
That is your code, which is compiled on a PC. It has nothing at all to do with the serial port.
no, you don't need any 0x at the beginning for IR sending. You are confusing text and numeric representation of a variable
1 Like
Codes of post #12 could be inefficient, but it does not cause wastage of resources as these codes require some storage area.
?
Codes of post #12 could be inefficient, but it does not cause wastage of resources as these codes require some storage area
I let you judge the compared costs and you then come back with your opinion
When I do
Serial.println("F(F740BF"));
The compiler allocates the cStrng in flash memory (guaranteed to have room or the compilation would fail) and at run time this flash memory address (pointer) is passed to the println() method which goes and reads bytes one by one from flash memory and write() them out. 1 copy of the text in flash is used and a 2 bytes pointer on the stack for the println() call.
Compare now with your code
When you do this
It goes somewhat like this:
You have flash storage for the 2 string literals then at run time stack memory is used to instantiate myString and heap memory is allocated for the 3 bytes of "0x" then “0x" is copied over from flash to the heap location.
Then you perform a concatenation with + for the cString "F740BF" which is copied over from flash to the stack and promoted to a String instance so stack and heap memory allocated again for "F740BF" which is copied over from the stack to the heap in this transitory String. Then this transitory instance is passed as parameter to the overloaded + operator which is called and it starts by calculating the length of that string (a call to the length method) then a new transitory String is allocated on the stack and the heap , large enough to fit the concatenated Strings (some maths done to find that size) and "0x" is copied over to this new location and the "F740BF" is also copied over. Note that all these heap allocations are run time decisions that are costly operation as the heap needs to maintains the list of free blocks.
At that point we have a copy of "F740BF" in Flash, on the stack, in the first transitory String heap memory and in the new concatenation transitory String… 4 copies of the same bytes…
Then, if all the calls for memory allocation did not silently fail because you were running out of space - which can happen and Murphy says it will - the println method is called on that transitory String which extracts the pointer to the storage of the cString on the heap and the println() method goes and reads bytes one by one from SRAM memory and write() them out.
But wait that’s not all… now the 2 temporary Strings need clean up and the destructor method is called which returns memory to the heap - again a costly operation as the heap needs to maintains the list of free blocks.
As your function exits myString will also need to be destructed and so another call to heap functions will happen…
——
Now that you might have a better understanding of what is at play when you abuse the String class and use the + operator, what do you think? Does my claim that this is a waste of resources makes more sense??
(Was the same reason I told @Best_codes it was not so good)
Edit/ I see you removed your comment. I keep that answer as it might help newcomers understand the hidden cost of this String class and concatenation..
I have worked with an Oil Company (Schlumberger) who recruits both Geologists and Engineers; where, a Geologist interprets log data in the Computer Center by virtue of his academic excellence and an Engineer interprets log data (for real time quality control) in the Oil Field by virtue of his training excellence. It is the Geologist whose interpretation is always better.
Myself, being an Electrical Engineer who has learnt programming mainly through training/practice while testing the target hardware, does feel proud of reading the details of ("what is being happened in the background when String data type is used") offered by a Software Engineer/Programmer who is seasoned by virtue of his academic excellence.
I have put back my comments of post #29.
1 Like
I think that code kindof defeats the purpose of what this guy wants, @J-M-L .
Yes, that’s why the right answer with a variable is
unsigned long veri = 0xF740BF;
Serial.printF(("0x"));
Serial.println(veri, HEX);
And not the “waste” suggested by @GolamMostafa that OP seems to like… but hey, it is his program;)
Note that it turned out as well that the whole thing was a total misunderstanding of the difference between the value in memory and it’s screen representation in a given base…