RF with char* issues

I am trying to send a message over RF, but I got some issues.

The problem is that I can send something like random(500) but the | is giving me some problems.

RF_S:20: error: invalid operands of types ‘char*’ and ‘const char [2]’ to binary ‘operator+’

The final output is something that should have value|value|value so it is easy for my c# app for the receiver to read and process, but how do I do it?

#include <VirtualWire.h>
#undef int
#undef abs
#undef double
#undef float
#undef round

void setup()
{
  // Initialise the IO and ISR
  vw_set_ptt_inverted(true);               // Required for RF Link module
  vw_setup(2000);                          // Bits per sec
  vw_set_tx_pin(3);                        // pin 3 is used as the transmit data out into the TX Link module, change this to suit your needs.
}

void loop()
{
  char *msg ;

  msg += random(500);
  msg += "|";

  vw_send((uint8_t *)msg, strlen(msg));
  vw_wait_tx();
  delay(200);
}

A char* is just a memory pointer - it's not an object with operations like += defined. To perform these sorts of operations you need to use something like the String library.

Cheers, G.

Your thread title is confusing - this has nothing to do with RF, and it is in the wrong section - it is not a hardware problem.

A char* is just a memory pointer - it's not an object with operations like += defined. To perform these sorts of operations you need to use something like the String library.

Just tried that, but that gives me another problem

    String msg = sensTemperature;
    msg = msg + "|";
    msg = msg + sensHumidity;
    msg = msg + "|";
    msg = msg + rpm;
    
    char *output;
    
    msg.toCharArray(output, msg.length());
    
    vw_send((uint8_t *)output, strlen(output));
    vw_wait_tx();                          // Wait for message to finish

This does not return any error, but does not work either, if I put a output="ok"; in, the reciever will print the ok, but without nothing happens. I suspect the toCharArray, but by the use of it I have seen, I seems to do it right, or am I actually doing it wrong?


Your thread title is confusing

No one forces you to look at it

this has nothing to do with RF

Your post has nothing to do with what I wrote, but the code is actually used to talk to a RF module...

and it is in the wrong section - it is not a hardware problem.

Yes, I hit the wrong group. But now after pointing out all I do wrong, I wonder why you didn't actually write something useful, instead of replying to a question, without replying to the actual question. So unless you got something that would help with the actual topic, I would prefer if you just stayed out of it.

    char *output;

Declare output to be an array that is at least as large as the longest possible String variable (plus 1) that you are going to use it with.

Maybe something like

    char output[100];
.
. // Build up the msg String
.
     msg.toCharArray(output, 100);
.
.
.

Or some such thing.

Here's the deal: In C and C++, the name of an array of chars is a pointer whose value is the address of the first character of the array. The toCharArray function will copy from the String object to the array. If the String length is larger than 99, it will be truncated. There is nothing "magic" about 100. Use an estimate of the largest String that you want to work with. Whatever value you use in the declaration statement should also be used in the function call.

If I were going to use String objects, I would probably do it like this:

    char output[100]; // Change the size to what is appropriate for your app
.
. // Build up the msg String
.
     msg.toCharArray(output, sizeof(output));
.
.
.

Regards,

Dave

aaaah, I see! And I got it working! :)

Final code will be a part of this http://bld.is-a-geek.com/2010/12/12/from-drawing-to-reality/ :)

@bld: Learn from the experience; the compiler knows nothing about RF, so clearly the problem is not an RF one. Conversely, RF knows nothing about 'char' or 'char*'. Similarly, since the problem relates to a compiler error, it also quite clearly isn't a hardware issue. After 700+ posts, I would expect you to set a better example.