Getting hex values for entering numeric values

[Nirupama]

Hi all, I'm working on nrf52832 in segger embedded studio. Using ble scanner app, I'm entering some random values. So when i enter a value, I'm adding them to watch and checking out the value. I entered an integer value of 10, i'm expecting the same value to come in watch, but I'm getting the value as hex. For example if i enter 10, I'm getting it as 0x10.

[awneil]

Have you checked out the documentation for Segger Embedded Studio (SES), and this "ble scanner app" ?

It's not entirely clear what you're doing here.

Remember that we can't see what you're doing, we don't know what "ble scanner app" you're using, etc, etc.

Please provide detailed descriptions of exactly what you are doing, where you are doing it, what equipment & tools you are using, etc.

You can insert screenshots & pictures using the 'Insert' menu ... 

[Nirupama]

In segger embedded studio, i'm working on an application where it has this structure and the members of this structure are updated from ble scanner app. First i run the application in segger and search for that application in ble scanner app. once i connect to this application from mobile app, i will start writing some values.

So, i entered 20 from ble app, this is reflected as 0x20 in the application, i indicated it.  Why am i getting such value?

[Einar Thorsrud]

Can you show us your firmware code, how do you handle the data starting with when you receive it until you print it? Do you make sure to only print the correct length, and is it null-terminated?

[Nirupama]

7888.ble_peripheral.zip

Hi, Yes, Please find the zip file attached.

Thanks,

Nirupama.T

[cbd]

Most apps it will use a C type null terminated string and they will not overwrite old data in the characteristic beyond the string termination point.

Remember that the minimum characteristic size if 20 bytes of data.

In all cases the full amount of data will be transmitted for a characteristic.

This means that if you send "hello" as ASCII in your 10 byte characteristic you will find 10 bytes of junk data tagged on the end even if you send 5 null bytes after the 'o'.

If you wish to ensure that your characteristic always has null characters beyond the end of your string then you will need to ensure that you treat all data written to the characteristic as a binary array of the full characteristic size.

The onus is on you to know how to interpret your characteristic data when read. If it is always a null terminated string then just read back the data until the null character is found.

As a final point are no power savings to be made by sending null characters.

[cbd]

I don't see an issue here.

In the picture you've entered either a space character " " which has an ASCII value of 0x20 when writing the characteristic as a string or as it's a custom characteristic more likely you  entered a byte value of 0x20.

You're app debug watch point on PDT clearly shows a null terminated string with the same data e.g. two bytes being 0x20 followed by 0x00.

If you want the ASCII characters "20" then you will need to send 0x3230

[Nirupama]

Before entering the value, i am doing a memset of 0 to that characteristics.  So, when i try to read the data, it should return the value i entered with rest of the bytes as 0.