I'm trying to pass a String to BLEDevice::init(str);
I createad function set deviceName which returns C char* String and i need to convert it to arduino String , no success ... no matter what i tried, new to Arduino , thanks
Welcome to the forum
Please post a sketch that illustrates the problem that you are trying to solve, using code tags when you post it
Does the function just return the pointer ? Anyway as Bob says, post the non-working / compiling example
For practical purposes, refer to String with the capital S, Being the object of the String class, which should be used with care since it may fragment the heap if used incorrectly. And refer to c-string / char array / char * with the lower cap 's'
There are standard ways to convert one into the other, but with functions returning char * (or pointers to a char array) another little thing shows it head.
try
char* test ="Hello world";
String s=String(test);
for further details have a look at stringObject
if you are using a low powered microcontroller (e.g. classic UNO, Mega, etc) avoid using String
use can fragment the memory and cause program crashes etc
C function setDeviceName returns a pointer the whole idea is to use any string that BLEDeviceinit() a cepts it doesn't have to be String i'm coming from C Java world
As previously requested, please post a sketch showing the problem. This will make it clear whether you are referring to Strings or C style strings and which libraries you are using
You have some learning curve that is worth the climb and fortunately it takes you into simpler C.
Text is 8 bit ASCII code values in a char (can be byte) array that ends with a 0. Look up ASCII table and find one you can grab and open any time.
The compiler will turn single quotes with a character between into the ASCII value of that character, you don't have to look them up.
byte zero = '0'; // zero = 48 now
Serial.write( zero + 7 ); // prints 7
chars are basic data that you can store in flash, EEPROM and RAM. Most Arduinos have way more flash than RAM.
C++ String can't be stored in flash or EEPROM. They keep their own protected copy of the text and if you let them they can turn your RAM space into a mess and eat processor cycles as result of adding text. Yeah you don't have to manage memory at that high cost. They are great for use in Large RAM Environments but they suck badly in small systems.
C strings, I can make buffer space in RAM to hold and work from, I can keep in flash and print from there, ditto EEPROM, I write text functions with char pointers and they work on every C string and when reading Serial, every char one at a time since an Uno is so much faster than Serial even > 115200 baud. There is a library, #include <string.h> to get a whole suite including strcat(), short for string concatenate to add one string to another. The names are cryptic till you learn the syllables and they DO take lots of practice to get much goof with. Often it is easier to manipulate the chars directly. With C strings you do have to manage text memory.
Wrong not so much, but the extended table shows 8-bit
For 28 years you didn't know that ASCII had been extended 45 years ago?
The Extended ASCII Table from 1981.
"In 1981, IBM developed an extension of 8-bit ASCII code, called "code page 437", in this version were replaced some obsolete control characters for graphic characters. Also 128 characters were added , with new symbols, signs, graphics and latin letters, all punctuation signs and characters needed to write texts in other languages, such as Spanish.
In this way was added the ASCII characters ranging from 128 to 255."
Extended ASCII lets you do text graphics like boxes and orthagonal POV maze views.
But the data variable needs to be declared globally (or at least not locally within the function that returns the pointer) or the data will not be there anymore once the function is exited.
char * thisFunc() {
char data[] = "Now It exists\0";
char * ptr = &data[0];
return ptr;
}
if you call the function from the pointer is returned, but the data no longer has space reserved in memory and may be overwritten.
A better solution would be to declare the array, pass the pointer to the array to the function and in that way provide access to the data within the function
Without seeing the code from @yosikiss we are working in the dark
That is not true! The table in post #8 has been with me for many, many years, and it carries the line "extra bit (b7) for the second set of characters." So, I know that an extended set of characters exists though I have not explored them. I have thought about:
- (Standard) 7-bit ASCII
- (Extended) 8-bit ASCII
so now you have your answer and your students might not.
It seems that when the most significant bit is HIGH, the characters may change according to the country in which the code is used. Some LCD displays show different characters than that extended table shows.
Correct. He shows the USASCII extended code. Other languages use different characters for each of the extended codes. First were the Japanese dot matrix printers from the 1970's.
C and C++ define three flavors of character:
- "just plain"
char, which can be either signed or unsigned signed charunsigned char
Therefore char only guarantees the 7-bit values, which match "just plain" ASCII. Everything else -- "extended", "ANSI", code pages -- is a can of worms: UTF-8, anyone? That's what the IDE uses. But with some care, you can certainly get things to work.
Be thankful the winner was not EBCDIC.
That looks like Code Page 850, which specifies an extended set of characters above ASCII. There are several other popular 8-bit sets.
AFAIK, this never officially became part of the actual "ASCII standard", and the extra 128 characters vary significantly from vendor to vendor and country to country. The most standardized version (ISO 8859-) adds mainly international characters, rather than the pseudo-graphical codes IBM shipped on the original PC.
Where did you come up with this?
char is signed 8 bit integer, int8_t by a different name.
Do math with chars and find out that char range is -128 to 127.
unsigned 8 bit integer is byte
But you can specify unsigned char or uint8_t for the same thing.
char c = 0xFF;
print( c, DEC ); // it won't sometimes print differently