Chipcon CC2510 on Keil

Hi Andy,

The library functions are downloadable in the
form of source code. But since there are written
for IAR compiler, none of the functions works because
they require a "different header file (CC2510.h)+ Startup files which are DIFFERENT from the header file posted on KEIL website.
This is one of the different I can think of, and I
am sure they are more ...

JIMMY

Hi Andy,

The library functions are downloadable in the
form of source code. But since there are written
for IAR compiler, none of the functions works because
they require a "different header file (CC2510.h)+ Startup files which are DIFFERENT from the header file posted on KEIL website.
This is one of the different I can think of, and I
am sure they are more ...

JIMMY

You didn't answer what these "libraries" actually do?

Have you asked chipcon if they have Keil equivalents available?

If the files are available as source, then you can change all the IAR-Specific usage to the corresponding Keil usage.

Of course, this applies to the complete file set - including the headers.

Keil will automatically use its own startup files - you can customise these to your own requirements as you would for any other Keil project:

http://www.keil.com/support/man/docs/c51/c51_ap_customfiles.htm

The Chipcon CC1010 library was written for the Keil C compiler 2-3 years ago. I'm not sure why the newer chips have libraries for different compilers. In my opinion, that's kinda of a migration killer for the chip vendor. Maybe there is some common functionality between the two libraries that would make porting easier.

In general, there is not so much that's different between the source code that the two compilers can digest. I think the main difference is in how SFRs are declared.

Nonetheless, I would contact Chipcon directly and see if they have a library that works with the Keil tools. I'm sure they have heard this question before.

Jon

I contacted Chipcom which is owned by TI, I received
the replied e-mail below:

Hello, Jimmy:

Our Chipcon application engineer replied:

I'm afraid we haven't ported the CC2510 sourcefiles to Keil, but since the original CC2510 sourcefiles

are well structured, porting shouldn't pose a big problem/task for a skilled programmer. Anyway, we

do have a debugger plug-in available for Keil, because our sw designer actually managed to complete

a stable debugger plug-in for Keil before the switch to IAR was done :) So, I recommend that the

customer associates with skilled programmers to do the sourcefile porting from IAR to Keil, and then

use the attached plug-in to perform Keil debugging of CC2510.

Regards,

Joey Grasty (grasty@ti.com)
Analog Field Applications Engineer
Texas Instruments
Dallas Field Sales Office
Phone: 972-917-1706 Fax: 972-917-1210

in other words, they sent you the source?

Erik

Yes they did. when I tried to compile using KEIL, I ran into some error, I think it has something to
do with compiler difference. Here is the section
of code where the error occurred:
The hal.h is the header file I downloaded.

////// hal.h  ///// header file
// Where _source_ is one of
#define CRYSTAL 0x00
#define RC      0x01

// Macro for setting the main clock oscillator source,
//turns off the clock source not used
//changing to XOSC will take approx 150 us


#define SET_MAIN_CLOCK_SOURCE(source) \ 
   do {                               \ 
      if(source) {                    \ 
        CLKCON |= 0x40;               \ 
        while(!HIGH_FREQUENCY_RC_OSC_STABLE); \ 
        SLEEP |= 0x04;                \ 
      }                               \ 
      else {                          \ 
        SLEEP &= ~0x04;               \ 
        while(!XOSC_STABLE);          \ 
        asm("NOP");                   \ 
        CLKCON &= ~0x47;              \ 
        SLEEP |= 0x04;                \ 
      }                               \ 
   }while (0)

The function below also downloaded from their website:

// See hal.h for a description of this function.
//-----------------------------------------------------------------------------
BOOL halRfConfig(UINT32 frequency)
{
   BOOL status;

   //Turning on crystal oscillator
    SET_MAIN_CLOCK_SOURCE(CRYSTAL);  ///<<< error !!! here


   // Setting the frequency
   halRfSetRadioFrequency(frequency);


   if (frequency > 2400000)
   {
// 250kbps FSK setup (for other data rates or modulation formats, please see SmartRF Studio).
      // Dynamic packet length and append status
      PKTLEN = 0xFF;
      PKTCTRL0 = 0x05;
      PKTCTRL1 = 0x04;

      // IF frequency
      FSCTRL1 = 0x0A;
      FSCTRL0 = 0x00;

      // filter BW, data rate,
      MDMCFG4 = 0x2D;
      MDMCFG3 = 0x3B;

      // Modulation format, detection level
      MDMCFG2 = 0x73;
      MDMCFG1 = 0x22;
      MDMCFG0 = 0xF8;

      // Deviation setting
      DEVIATN = 0x00;

      // Calibration synth
      MCSM2 = 0x07;
      MCSM1 = 0x30;
      MCSM0 = 0x10;

      // Frequency offset compensation configuration
      FOCCFG = 0x1D;

      // Bit synchronization
      BSCFG = 0x1C;

      // AGC settings
      AGCCTRL2  = 0xC7;
      AGCCTRL1  = 0x00;
      AGCCTRL0  = 0xB2;

      // Front end settings (from SmartRf04)
      FREND1 = 0xB6;
      FREND0 = 0x10;

      // Synth calibration
      FSCAL3 = 0xEA;
      FSCAL2 = 0x0A;
      FSCAL1 = 0x00;
      FSCAL0 = 0x11;

      // From Smart RF Studio
      FOCCFG = 0x1D;
      BSCFG = 0x1C;
      FSTEST = 0x59;
      PTEST = 0x7F;
      AGCTEST = 0x3F;
      TEST2 = 0x88;
      TEST1 = 0x31;
      TEST0 = 0x0B;


      // Output power
      PA_TABLE0 = 0xFF;

      // Calibrating synth.
      SIDLE();
      SCAL();
      while(MARCSTATE != 0x01);

      INT_SETFLAG(INUM_RFTXRX,INT_CLR);


      status = TRUE;
   }
   else {
      status = FALSE;
   }

   return status;
}

THE ERROR MESSAGE pointed to "SET_MAIN_CLOCK_SOURCE(CRYSTAL) line.

   SOURCE\RFCONFIG.C(41): warning C206: 'asm': missing function-prototype
SOURCE\RFCONFIG.C(41): error C267: 'asm': requires ANSI-style prototype

"porting shouldn't pose a big problem/task for a skilled programmer"

The error functions you are getting are due to an inline asm() function, invoked in the function-like macro, that is being used to force the inclusion of a NOP in the code.

In Keil, you have the intrinsic function _nop_(), that does the same thing.

It is in the Cx51 Compiler MANUAL, at chapter 8.

But be aware that the ported code will probably need careful analysis of such timing loops that use NOPs, since the new compiler may generate quite different machine code than the original compiler.

Got it, thak you