Forums

You mentioned modifying simple_link.c.  What original software are you referencing, just so that it is clear what you are starting from.

More directly to your inquiry, I wouldn't try to change the type of the message from int8_t to int16_t, but rather make the message multiple bytes long.  Your application code can determine the order of the bytes, ie. which byte holds the upper 2 bits of the 10-bit value.

Hey thanks for replying ..

Let me be more specefic .I am compiling this modified simple_link.c using IAR workbench to be burnt into CC2510 based target board .I am inoutting 3 external analog inputs ,all to the ADC inputs . The results ,i have stored in adc_result[1],adc_result[2],adc_result[3] .If i choose a 10 bit resolution for ADC , i get the values for example 500,590,etc upto 1024 . The output of the ADCH and ADCL registers are put into an unsigned int16_t adc_result[].........Thus adc_result[] has the data ready in decimal format,and not the binary or the hex format .,,So when i try doing the following --

radioMsg[2]=1000;

radioMsg[3]=600;

radioMsg[4]=724;

I am not able to send it ,since radioMsg is declared as unsigned int8_t (max val=256). so wat exactly do u mean by making the message multiple bytes long in this context of integer numbers ranging from 0 to 1024 ..??

Niketh M G 

You can see in the code editor  I set adc_LOW = ADCL and adc_HIGH = ADCH From the watch box you can see they are unsigned char (8 bits) and could be sent as 2 separate 8 bit bytes via the radio and combined into a uint16 on the receiving end of the link. When combine they will be the same as adc_result. The radio's Tx and Rx buffers are only 8 bits so that is all they can send. Of course the OTA packet is longer but it is made up of streaming 8 bits chunks.

In the debugger  watch box I repeated the labels with both hex and decimal formats. I entered 29632 into the calculator as decimal and switched to binary to see the bit pattern. It is 16 bits but the first bit is 0 and does not display. Since it is a single ended measurement the first bit is 0 because it is a positive two's compliment number. There are a lot of zero to the right because it is a 10 bit measurement in a 16 bit memory allocation. With >>6 it could be push to the right so the zeros are to the left

As you can see I could not get all of the way to Vref due to my board design. I got to 463 decimal out of 511 which is 463/511 x 1.25vref = 1.13 or about .12v under.

Ps  The code should have been

adc_LOW =  ADCL  & 0xC0;  // 0xC0 is needed to mask the 6 undefined bits that are not used
adc_HIGH = ADCH;                // All 8 bits are used therefore no mask is required

Hey Thank you very much I got ur idea .and will implement that ..

I have another question..

I compiled the UART_......_ISR.c example code that TI has provided. It works this way,after transmission of a byte ,an interrupt is triggered off , which then takes the command to the TX_ISR service routine (the file and function names i have mentioned aren't matching with the real ones..i sort of dun remember the actual names )...

But on debugging ,i found no way to manually generate an interrupt so that i could go through the ISR function .... and it wasnt clear as to wat data format it was  transmitting ..

EXAMPLE : If i had to transmit 5 ,  As far as i think we need to input the ASCII of 5(0x35) to the TX buffer .since it works on ASCII coding technique .So my doubt is whether i have to do this conversion to ASCII manually or can we do it without that ,??

Say if i want to transmit 245 ,Thn without doing anything a value of 0xF5(245) goes into the U0DBUF ....Will i receive the same 245 on the receiving end ..??.

Or Do i need to convert each digit(2,4,5) to their ASCII equivalent in hex and then send each individually one after the other ???

When you write

U0DBUF = whatever;    "whatever"  is sent. You know U0DBUF is a 8 bit buffer so you are limited to 8 bits. There is not a automatic converter that converts anything to ASCII.

If you set 

uint8_t whatever;
whatever = 5;
U0DBUF = whatever;

then 00000101 will be sent because the compiler recognizes 5 as decimal and does the conversion to binary and from the uint8 knows to allocate 8 bits of storage.

If you set 

uint8_t whatever;
whatever = 0x05;
U0DBUF = whatever;

then 00000101 will still be sent because the compiler recognizes 0x05 as hex and does the conversion to binary and from the uint8 knows to allocate 8 bits of storage.

The following will get you a ASCII 5

#include <string.h>
char whatever;
whatever = '5';
U0DBUF = whatever;

then 00110101 will be sent because the compiler recognizes 5 as a ASCII and uses the a library to do the conversion  to binary and from the char knows to allocate 8 bits of storage.

Here is the code and watch box.  To handle long strings of alpha numeric's  really requires the #includes string.h and stdio.h With limits on code size with the free version of IAR and the limited memory of the Ti SOC it is sometimes easier to just look up and use the ascii value in hex if you only have a few alpha characters.