Micah,

Yes.  Just define __putchar in your source code.

int __putchar(int ch)
{
   // do something...
}

The linker defines are something different...

-- Paul.

> -----Original Message-----
> From: Micah [mailto:micah@...]
> Sent: 31 March 2006 23:25
> To: msp430@yahoogroups.com
> Subject: [msp430] Okay, now crossworks question
>
> Thanks everyone for the feedback on the terminal programs.
>
> New problem with crossworks. I'm trying to redefine
> __putchar() to send out the SPI port, instead of to the
> virtual terminal. So according to the instructions, I should
> just be able to redirect the linker to use my function
> instead of the __putchar() function, right? I did this:
>
> -D___putchar=_my_putchar
>
> in the additional linker options. This should utilize
> my_putchar() instead of the standard one, right? However,
> when I compile, I get a duplicate __printchar error now.
>
> Any ideas? Is there a better way to do this?
>
> -Micah
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

You've probably left the linker definition of the symbol in the project,
so remove it!

-- Paul.

> -----Original Message-----
> From: Micah [mailto:micah@...]
> Sent: 01 April 2006 00:15
> To: msp430@yahoogroups.com
> Subject: Re: [msp430] Okay, now crossworks question
>
>
> Yep, in main.c and common.c.
>
>
> -Micah
>
> Microbit wrote:
>
> >Have you included the crossworks IO header file :
> >
> >#include <__cross_studio_io.h>
> >
> >???
> >
> >-- Kris
> >
> >
> >-----Original Message-----
> >From: msp430@yahoogroups.com [mailto:msp430@yahoogroups.com]
> On Behalf
> >Of Micah
> >Sent: Saturday, 1 April 2006 10:10 AM
> >To: msp430@yahoogroups.com
> >Subject: Re: [msp430] Okay, now crossworks question
> >
> >
> >Still not working.
> >
> >Okay, so I added this function to common.c:
> >
> >int __putchar (int spi_data)
> >{
> >    if (spi_data == '\n')
> >    spi_data = 0x0a;
> >  WRITE_TX_BUF2 (spi_data & 0xff);
> >  WAIT_SPI_FREE2;
> >
> > return (spi_data);
> >}
> >
> >And this to common.h:
> >
> >int __putchar (int);
> >
> >and included <stdio.h> in common.c and main.c. And I still get the
> >duplicate __putchar error.
> >
> >What's up?
> >
> >-Micah
> >
> >
> >Microbit wrote:
> >
> >
> >
> >>Hello Micah,
> >>
> >>Simply use the __putchar() function with the same prototype
> as in the
> >>library, and your own __putchar() code will be linked in,
> instead of the Library code.
> >>
> >>You _must_ use the same prototype to have your own function
> linked in ie.
> >>
> >>int __putchar (int);
> >>
> >>If you're using SPI, just return the parameter you were
> called with :
> >>
> >>int __putchar (int spi_data)
> >>{
> >> //.... do your SPI stuff
> >>return (spi_data);
> >>}
> >>
> >>If there's an error you can elect to return EOF or IOW (-1)
> >>
> >>
> >>B rgds
> >>Kris
> >>
> >>
> >>-----Original Message-----
> >>From: msp430@yahoogroups.com
> [mailto:msp430@yahoogroups.com] On Behalf
> >>Of Micah
> >>Sent: Saturday, 1 April 2006 9:25 AM
> >>To: msp430@yahoogroups.com
> >>Subject: [msp430] Okay, now crossworks question
> >>
> >>Thanks everyone for the feedback on the terminal programs.
> >>
> >>New problem with crossworks. I'm trying to redefine __putchar() to
> >>send out the SPI port, instead of to the virtual terminal. So
> >>according to the instructions, I should just be able to
> redirect the
> >>linker to use my function instead of the __putchar()
> function, right? I did this:
> >>
> >>-D___putchar=_my_putchar
> >>
> >>in the additional linker options. This should utilize my_putchar()
> >>instead of the standard one, right? However, when I
> compile, I get a
> >>duplicate __printchar error now.
> >>
> >>Any ideas? Is there a better way to do this?
> >>
> >>-Micah
> >>
> >>
> >>To unsubscribe from the msp430 group, send an email to:
> >>msp430-unsubscribe@egroups.com
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>To unsubscribe from the msp430 group, send an email to:
> >>msp430-unsubscribe@egroups.com
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >To unsubscribe from the msp430 group, send an email to:
> >msp430-unsubscribe@egroups.com
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >To unsubscribe from the msp430 group, send an email to:
> >msp430-unsubscribe@egroups.com
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hello BB,

> This is the frequecy recomendedd in the TI 430UM i.e 32 times
32.768KHz for the UART to be able to opperate on 19.200 Baud.


4.194MHz is what I have used in communication circuitry (non-MSP).
It's four times your frequency and is a standard crystal. Around 50c
at Digikey. You could probably even buy one of these at a local
electronics store.

Regards, Joerg

http://www.analogconsultants.com/

Just use a GPIO for the 4 wire CS pin. IF it's high, enable the SPI, if
it's low, disable it. Piece of cake.

If it helps, here's what I'm using and it works great, for SPI #2:

U1CTL = SWRST;    // put in reset for config
U1CTL = CHAR + SYNC + SWRST;         // 8-bit, SPI, slave
U1TCTL = TXEPT + SSEL1 + STC + CKPH;              // Polarity, ACLK, 3-wire
U1BR0 = 0x00;                                  // doesn't matter with slave
U1BR1 = 0x00;
U1MCTL = 0x00;            // nothing to control here
ME2 |= USPIE1;                            // Module enable SPI1
U1CTL &= ~SWRST;                          // take out of reset
IE2 |= URXIE1;      // enable RX interrupt

// Here's the interrupt (crossworks format)
void usart1_rx (void) __interrupt[UART1RX_VECTOR]
{
int input;
input = RXBUF1;                      // RXBUF1 to TXBUF0
// do your stuff here
}

-------------------

Make sure you check the polarity and phase settings, as mine will likely
be different than yours.

Hope that helps,
-Micah


iirojan wrote:
> Hi!
>
> I am having trouble configuring my MSP430F169 as a 4-wire slave to
> receive messages from a master device. The example codes by TI do not
> include such (just 3-wire). As there should be little difference, I
> have tried to modify the existing code made for UART1 to comply with
> using SPI1. The resulting init code is
>
> void spi1_init(void)
> {
>   _DINT();    // disable interrupts
>   U1CTL |= SWRST;   // set SWRST
>   UBR01 = 0x45;
>   UBR11 = 0x00;
>   U1CTL &= SWRST;         // unset all else than SWRST
>   U1CTL |= CHAR +  // 8-bit data
>            SYNC;   // SPI, slave mode
>   U1TCTL = SSEL0+SSEL1;   // SMCLK
>   ME2 |= USPIE1;          // Enable UART1 transmit/receive
>   U1CTL &= ~SWRST;        // clear SWRST
>   IE2 |= URXIE1; // Enable UART1 rx&tx interrupts
>   P5SEL |= BIT0;   // SS, 4-wire mode
>   P5SEL |= BIT1;   // SIMO
>   P5SEL |= BIT2;   // SOMI
>   P5SEL |= BIT3;   // UCLK
>   _EINT();           // enable interrupts
> }
>
> The interrupt function, which should fire if there is some incoming
> data, is as follows:
>
> #pragma vector=USART1RX_VECTOR
> __interrupt void SPI1_rx (void)
> {
>   unsigned char c;
>   while ((IFG2 & UTXIFG1) == 0); // USART1 TX buffer ready?
>
>   c = U1RXBUF;   // read USART1
>   receiv_char_process(c); // put receiver process
> }
>
> I have a debugger (IAR) breakpoint at the beginning of the interrupt
> function, but it never fires. Also the receiv_char_process function
> would output plenty to the computer terminal program. Nothing happens,
> the program runs as if there would be nothing coming over SPI.
> Surveillance with an oscilloscope shows, however, that all the SPI
> lines function as should: SS, MOSI and CLK, but nothing comes on MISO
> (out of my MSP).
>
> Where should I go to look for the problem? Anyone know how to use
> MSP430F169 as a SPI 4-wire slave to reveive and send unsigned char arrays?
>
> I'd be thankful for any hints what to do.
>
>

Thanks, I am considering this now. A pity that the ACLK dividers are not able to
divide more than by 8 :(
   BB


Joerg Schulze-Clewing <joergsch@...> wrote:
   Hello BB,

> This is the frequecy recomendedd in the TI 430UM i.e 32 times
32.768KHz for the UART to be able to opperate on 19.200 Baud.


4.194MHz is what I have used in communication circuitry (non-MSP).
It's four times your frequency and is a standard crystal. Around 50c
at Digikey. You could probably even buy one of these at a local
electronics store.

Regards, Joerg

http://www.analogconsultants.com/






To unsubscribe from the msp430 group, send an email to:
msp430-unsubscribe@egroups.com


Yahoo! Groups Links









---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.

[Non-text portions of this message have been removed]

Hi there,

I am trying to work with CPU pins as a single pins (bitwise
functions).
Is there a function to set and clear port pins independently?

e.g.

#define LCD_RW P4OUT;

set LCD_RW;
or
clear LCD_RW;

even I checked asm instructions and they are also byte and word
instructions.

For PIC micros after defining a CPU pin I could use output_high()
and output_low() functions to change cpu pin.

I'll really appreciate to have any comment.

Thanks

Amir

There's no intrinsic, but it's easy to write a #define for this, (thanks
to Kris for these functions)

/// Macro to set a bit y in variable x
#define SETB(x,y)       (x |= (y))
/// Macro to reset a bit y in variable x
#define CLRB(x,y)       (x &= ~(y))
/// Macro to toggle a bit y in variable x
#define INVB(x,y)       (x ^= (y))

So you can then use the BIT0...BIT16 defines in the MSP430.h header to
do things like:

SETB(P4OUT, BIT0);

or
CLRB(P1OUT, BIT4);

etc..

-Micah

Amir Ahmadi wrote:
> Hi there,
>
> I am trying to work with CPU pins as a single pins (bitwise
> functions).
> Is there a function to set and clear port pins independently?
>
> e.g.
>
> #define LCD_RW P4OUT;
>
> set LCD_RW;
> or
> clear LCD_RW;
>
> even I checked asm instructions and they are also byte and word
> instructions.
>
> For PIC micros after defining a CPU pin I could use output_high()
> and output_low() functions to change cpu pin.
>
> I'll really appreciate to have any comment.
>
> Thanks
>
> Amir
>
>
>
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

You could try the BIS/BIC instructions. Eg:



         bic.b   #0x40,&P5OUT              ;clears bit 6 of Port 5

or

         bis.b   #0x06,&P1OUT              ;sets bits 1 and 2 of Port 1





Rachel Adamec

Norristown, PA, USA







   _____

From: msp430@yahoogroups.com [mailto:msp430@yahoogroups.com] On Behalf Of
micah
Sent: Sunday, April 02, 2006 1:52 PM
To: msp430@yahoogroups.com
Subject: Re: [msp430] bitwise manipulating of pins




There's no intrinsic, but it's easy to write a #define for this, (thanks
to Kris for these functions)

/// Macro to set a bit y in variable x
#define SETB(x,y)       (x |= (y))
/// Macro to reset a bit y in variable x
#define CLRB(x,y)       (x &= ~(y))
/// Macro to toggle a bit y in variable x
#define INVB(x,y)       (x ^= (y))

So you can then use the BIT0...BIT16 defines in the MSP430.h header to
do things like:

SETB(P4OUT, BIT0);

or
CLRB(P1OUT, BIT4);

etc..

-Micah

Amir Ahmadi wrote:
> Hi there,
>
> I am trying to work with CPU pins as a single pins (bitwise
> functions).
> Is there a function to set and clear port pins independently?
>
> e.g.
>
> #define LCD_RW P4OUT;
>
> set LCD_RW;
> or
> clear LCD_RW;
>
> even I checked asm instructions and they are also byte and word
> instructions.
>
> For PIC micros after defining a CPU pin I could use output_high()
> and output_low() functions to change cpu pin.
>
> I'll really appreciate to have any comment.
>
> Thanks
>
> Amir
>





[Non-text portions of this message have been removed]

Many thanks for your reply.
Still I have to refer to ports when I want to change a pin.
in asm:
> bic.b   #0x40,&P5OUT              ;clears bit 6 of Port 5

and in C:
> SETB(P5OUT, BIT0);

Still I should use P5OUT

and later if I change a pin from one port to another port I should
check whole program and edit all.

Assume:
#define LCD_RW BIT0;
#define LCD_CNTL P5OUT;
#define SETB(x,y) (x |= (y))

SETB(LCD_CNTL, LCD_RW);

Do you think it will work?

BR

Amir

--- In msp430@yahoogroups.com, "Rachel Adamec" <adamec.rachel@...>
wrote:
>
> You could try the BIS/BIC instructions. Eg:
>
>
>
>         bic.b   #0x40,&P5OUT              ;clears bit 6 of Port 5
>
> or
>
>         bis.b   #0x06,&P1OUT              ;sets bits 1 and 2 of
Port 1
>
>
>
>
>
> Rachel Adamec
>
> Norristown, PA, USA
>
>
>
>
>
>
>
>   _____
>
> From: msp430@yahoogroups.com [mailto:msp430@yahoogroups.com] On
Behalf Of
> micah
> Sent: Sunday, April 02, 2006 1:52 PM
> To: msp430@yahoogroups.com
> Subject: Re: [msp430] bitwise manipulating of pins
>
>
>
>
> There's no intrinsic, but it's easy to write a #define for this,
(thanks
> to Kris for these functions)
>
> /// Macro to set a bit y in variable x
> #define SETB(x,y)       (x |= (y))
> /// Macro to reset a bit y in variable x
> #define CLRB(x,y)       (x &= ~(y))
> /// Macro to toggle a bit y in variable x
> #define INVB(x,y)       (x ^= (y))
>
> So you can then use the BIT0...BIT16 defines in the MSP430.h
header to
> do things like:
>
> SETB(P4OUT, BIT0);
>
> or
> CLRB(P1OUT, BIT4);
>
> etc..
>
> -Micah
>
> Amir Ahmadi wrote:
> > Hi there,
> >
> > I am trying to work with CPU pins as a single pins (bitwise
> > functions).
> > Is there a function to set and clear port pins independently?
> >
> > e.g.
> >
> > #define LCD_RW P4OUT;
> >
> > set LCD_RW;
> > or
> > clear LCD_RW;
> >
> > even I checked asm instructions and they are also byte and word
> > instructions.
> >
> > For PIC micros after defining a CPU pin I could use output_high
()
> > and output_low() functions to change cpu pin.
> >
> > I'll really appreciate to have any comment.
> >
> > Thanks
> >
> > Amir
> >
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

Amir,

| Many thanks for your reply.
| Still I have to refer to ports when I want to change a pin.
| in asm:
| > bic.b   #0x40,&P5OUT              ;clears bit 6 of Port 5
|
| and in C:
| > SETB(P5OUT, BIT0);
|
| Still I should use P5OUT
|
| and later if I change a pin from one port to another port I should
| check whole program and edit all.
|
| Assume:
| #define LCD_RW BIT0;
| #define LCD_CNTL P5OUT;

Remove the semicolon from the #define and it will work!

| #define SETB(x,y) (x |= (y))
|
| SETB(LCD_CNTL, LCD_RW);
|
| Do you think it will work?
|
| BR
|
| Amir

HTH.
KF

Hello List,

Target porcessor used : MSP430F1611
Tools Used : IAR embedded workbench Ver3.30A from IAR
systems.

My question is

1. Can I do 32 bit math(+,-,*,/) on MSP430F1611
processor just simillar to 16 bit math?

2. Does IAR support 32 bit data type?

3. Do I need to do any extra data manipulation for
portign the 32 bit programs to run on MSP430F1611 ?

Thanks in advance for your kind inputs

with regards
Raju K N N


Raju.K.N.N.
Bangalore

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

RAJU.K.N.N. RAJU.K.N.N wrote:
> Hello List,
>
> Target porcessor used : MSP430F1611
> Tools Used : IAR embedded workbench Ver3.30A from IAR
> systems.
>
> My question is
>
> 1. Can I do 32 bit math(+,-,*,/) on MSP430F1611
> processor just simillar to 16 bit math?

Yes we support 32 bit operations. You can even do 64 bit math using the
"long long" data type.


> 2. Does IAR support 32 bit data type?

Yes, both integers, "long", and floating-point, "float".


> 3. Do I need to do any extra data manipulation for
> portign the 32 bit programs to run on MSP430F1611 ?

If you have a program written for a 32 bit machine then you might need
to do some things. Mainly, the "int" data type for MSP430 is 16 bits.
This means that all variables that were declared as "int" but should be
able to take larger values have to be re-declared as "long".

I would recommend that you use the standard header file "stdint.h" and
use the types "int16_t", "uint32_t" etc.

      -- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Hi,

With the ever increasing push towards eco friendly systems, has anyone seen any
increasing demand for MSP430 or similar low power systems (perhaps powered by
solar cells) for use in eco-projects etc?

Should we expect an increased interest in our low-power technology skills?

Richard



[Non-text portions of this message have been removed]

Since we're already OT :)

I downloaded and read this book over the past week.
http://www.earth-policy.org/Books/PB2/index.htm
It's an interesting read. Anybody got any new ideas for efficient desalinization
plants?

Although we may get some interest in low power stuff that includes the MSP430 I
think it will be a much smaller issue than some of the others pointed out in the
book.

All the low power stuff I'm doing is still not quite low enough power use
(system wise) to be able to scavenge/harvest enough due to
application/size/weight constraints.

Alan
   ----- Original Message -----
   From: Richard (UK).
   To: msp430@yahoogroups.com
   Sent: Monday, April 03, 2006 10:58 AM
   Subject: [msp430] [OT] Solar powered systems?


   Hi,

   With the ever increasing push towards eco friendly systems, has anyone seen
any increasing demand for MSP430 or similar low power systems (perhaps powered
by solar cells) for use in eco-projects etc?

   Should we expect an increased interest in our low-power technology skills?

   Richard




[Non-text portions of this message have been removed]

As an aside, I did a major port recently from the PIC18LF452 to the MSP430F149.
One thing about the PIC18 which I recently noticed is that it does not have
what I consider to be a "true" single bit type in RAM memory, although it
claims to have such a beast. The MSP430 does not claim a single bit type. On
the MSP430, you can create and use a single bit by using atomic single-word
instructions, by which I mean they are instructions which are
non-interruptible. This can be done in both Assembler and C

eg.
MSP430:
=======
     typedef union
     {
     unsigned Semaphores;
     struct
         {
         blah blah
         unsigned CofferReadySemaphore: 1;
         unsigned OtherSemaphore: 1;
         blah blah up to 16 in all
         } Bits;
     } Semaphores_type;

     #define TRUE 1
     volatile Semaphores_type StarbucksSemaphores;
     StarbucksSemaphores.Bits.CoffeeReadySemaphore = TRUE;
  MSP430 Asm coding (from this above C code):
     BIS.W   #0x0100, &_StarbucksSemaphores

PIC18:
=====
     #define TRUE 1
     volatile bit MySemaphore;
     MySemaphore = TRUE;
  PIC18 Asm coding (from the above C code):
     bcf _MySemaphore/(0+8),_MySemaphore& (0+7),c
     ;volatile, position in byte allocated by linker

Both of these examples create a single-word non-interruptible instruction. The
non-interruptible instructions are important, since they require a
read-modify-write cycle, and if they were interruptible then they would be
unsafe without first disabling interrupts if an interrupt was able to modify
the same bit (or another bit within the same byte or word).

So where am I going with this? Well, the much-hyped bit variable on the PIC
turns out to be identical to the MSP implementation, the PIC18 using a bit
within 256 bytes of RAM whereas the MSP can use a bit anywhere within available
RAM. The bit-level instructions do the same on both processors, in that they do
a read-modify-write operation on the whole byte or word containing the bit of
interest. Huh, I thought. From what I remember, the 8051 (as a contrasting
example) has true bit instructions, which manipulate the bit and not the 7
adjacent bits as well. So the PIC18 code might look clearer to the MSP code,
but it ain't any different.

The real test is when these RAM areas are not RAM but instead a hardware
register; then the fact that we do a read-modify-write to a hardware register
(and not a true bit set or reset) might have unexpected side effects. Hmmm.

Hugh

--- Rachel Adamec <adamec.rachel@...> wrote:

> You could try the BIS/BIC instructions. Eg:
>
>
>
>         bic.b   #0x40,&P5OUT              ;clears bit 6 of Port 5
>
> or
>
>         bis.b   #0x06,&P1OUT              ;sets bits 1 and 2 of Port 1
>
>
>
>
>
> Rachel Adamec
>
> Norristown, PA, USA
>   _____
>
> From: msp430@yahoogroups.com [mailto:msp430@yahoogroups.com] On Behalf Of
> micah
> Sent: Sunday, April 02, 2006 1:52 PM
> To: msp430@yahoogroups.com
> Subject: Re: [msp430] bitwise manipulating of pins
>
>
>
>
> There's no intrinsic, but it's easy to write a #define for this, (thanks
> to Kris for these functions)
>
> /// Macro to set a bit y in variable x
> #define SETB(x,y)       (x |= (y))
> /// Macro to reset a bit y in variable x
> #define CLRB(x,y)       (x &= ~(y))
> /// Macro to toggle a bit y in variable x
> #define INVB(x,y)       (x ^= (y))
>
> So you can then use the BIT0...BIT16 defines in the MSP430.h header to
> do things like:
>
> SETB(P4OUT, BIT0);
>
> or
> CLRB(P1OUT, BIT4);
>
> etc..
>
> -Micah
>
> Amir Ahmadi wrote:
> > Hi there,
> >
> > I am trying to work with CPU pins as a single pins (bitwise
> > functions).
> > Is there a function to set and clear port pins independently?
> >
> > e.g.
> >
> > #define LCD_RW P4OUT;
> >
> > set LCD_RW;
> > or
> > clear LCD_RW;
> >
> > even I checked asm instructions and they are also byte and word
> > instructions.
> >
> > For PIC micros after defining a CPU pin I could use output_high()
> > and output_low() functions to change cpu pin.
> >
> > I'll really appreciate to have any comment.
> >
> > Thanks
> >
> > Amir
> >

Hugh wrote :

The real test is when these RAM areas are not RAM but instead a hardware
register; then the fact that we do a read-modify-write to a hardware register
(and not a true bit set or reset) might have unexpected side effects. Hmmm.

Hugh


It's even worse on AVR where you need to write "1" to clear a flag :
if you do a RMW on such a register, you're losing flags if you don't watch out !

In general I still allow for atomic (monitor) functions to set/clear bit state
variables, just
in case code is register based. Unlikely, but it helps portability a lot too.

Bit wise, that's been my only complaint over all on the MSP430 : the lack of a
1 cycle bit set/clear instruction. Would have made a big difference again.
I was told there's enough spare opcode space to do this, perhaps it was strictly
considered "reserved" for later more pressing opcodes ??? who knows ???

-- Kris

I have tried the one I purchased on three PC's. A laptop and desktop
running Windows XP Professional worked fine. A Windows XP Home fails
to work. I get a "failed to connect" in the IAR when trying to run the
compiled code.

Has anyone else had this problem? My interaction with TI ended up with
a suggestion to contact IAR - no response so far from IAR.

Jim

Hi,

We are planning to try Nordic's nRF24L01. Their preliminary product
specification document includes a application example with a reference
circuit and associated BOM list. In this example a 16Mhz crystal is
used with a load capacitance of 12pF. I was browsing Mouser and
Digikey for a suitable crystal but finding one with load capacitance
value below 18pF seems to be hard. Nordic people state following lines
about crystal selection and load capatitance:
"To achieve a crystal oscillator solution with low power consumption
and fast start-up time, it is recommended to specify the crystal with
a low value of crystal load
capacitance. Specifying CL=12pF is OK, but it is possible to use up to 16pF."

Does anyone have any previous experience with this part? Is it
possible to bend the xtal specs towards one with 18pF of load
capacitance?

Thanks in advance,
Onur Yildirim.

You can get suitable crystals from sparkfun.com in low quantities.
With a larger cap you are shifting the frequency which is the killer
for a 2401 application.

M.

On Mon, Apr 03, 2006 at 06:10:26PM +0300, Onur Yildirim wrote:
> Hi,
>
> We are planning to try Nordic's nRF24L01. Their preliminary product
> specification document includes a application example with a reference
> circuit and associated BOM list. In this example a 16Mhz crystal is
> used with a load capacitance of 12pF. I was browsing Mouser and
> Digikey for a suitable crystal but finding one with load capacitance
> value below 18pF seems to be hard. Nordic people state following lines
> about crystal selection and load capatitance:
> "To achieve a crystal oscillator solution with low power consumption
> and fast start-up time, it is recommended to specify the crystal with
> a low value of crystal load
> capacitance. Specifying CL=12pF is OK, but it is possible to use up to 16pF."
>
> Does anyone have any previous experience with this part? Is it
> possible to bend the xtal specs towards one with 18pF of load
> capacitance?
>
> Thanks in advance,
> Onur Yildirim.
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
         Matthias

----- Original Message -----
From: "Onur Yildirim" <onur.yildirim@...>
To: <msp430@yahoogroups.com>
Sent: Monday, April 03, 2006 4:10 PM
Subject: [msp430] OT: Nordic nRF24L01 crystal specs overrated?


> Hi,
>
> We are planning to try Nordic's nRF24L01. Their preliminary product
> specification document includes a application example with a reference
> circuit and associated BOM list. In this example a 16Mhz crystal is
> used with a load capacitance of 12pF. I was browsing Mouser and
> Digikey for a suitable crystal but finding one with load capacitance
> value below 18pF seems to be hard. Nordic people state following lines
> about crystal selection and load capatitance:
> "To achieve a crystal oscillator solution with low power consumption
> and fast start-up time, it is recommended to specify the crystal with
> a low value of crystal load
> capacitance. Specifying CL=12pF is OK, but it is possible to use up to
> 16pF."
>
> Does anyone have any previous experience with this part? Is it
> possible to bend the xtal specs towards one with 18pF of load
> capacitance?

As it's a prototype I'd just try it, it should work.

Leon

--- In msp430@yahoogroups.com, "jamie_risk" <jamie_risk@...> wrote:
>
> > We drew the line that we shouldn't do any data relocation what so
ever.
>
> I'm not disagreeing, it _is_ simply a line in the sand - my argument
> is that the line would be drawn based on ROM/RAM criteria, rather than
> a code/data criteria.
>

I'm still curious; Has anyone reading this found the line drawn by IAR
useful?

Giving up initialized data pointing to global variables but not
constant data (i.e. a string pointer) still seems less impactful than
giving up all initialized pointer data (constant or otherwise).

I'm trying to understand the business case for IAR's business decision
in their current compiler's PIC feature set.

- Jamie

On Mon, 03 Apr 2006 16:16:52 -0000, Jamie wrote:

>--- In msp430@yahoogroups.com, "jamie_risk" <jamie_risk@...> wrote:
>>
>> > We drew the line that we shouldn't do any data relocation what so
>ever.
>>
>> I'm not disagreeing, it _is_ simply a line in the sand - my argument
>> is that the line would be drawn based on ROM/RAM criteria, rather than
>> a code/data criteria.
>
>I'm still curious; Has anyone reading this found the line drawn by IAR
>useful?

I'm still unclear on the details.  But I gather that an argument is
hinted at which says that the current MSP430 mix of flash and RAM
doesn't make PC-relative references to static data all that useful,
anyway.  (A reference by Anders to a need for a "patcher" brings this
to my mind.)  However, I don't find that argument persuasive because
there are many very important cases where the static data is constant
(FIR filter constants, transcendental table values, etc., etc.) and
can move around in the flash along with the position independent
library code.  I could also, potentially, include the idea that a
position independent library module be built on the concept of
requiring a following block of flash for its saved static data and
that there needs to be a method to allow a block of flash code and an
associated block of flash data to move around.  Also, finally, code
doesn't only run in flash.  It is very possible to contain the idea in
an embedded product where code and its associated data is laid out
into the scarce RAM for execution and that the ability to allocate
small blocks for that purpose and to download code shouldn't require
the need for a "patcher", if the compiler supported the concept of PIC
fully.

>Giving up initialized data pointing to global variables but not
>constant data (i.e. a string pointer) still seems less impactful than
>giving up all initialized pointer data (constant or otherwise).
>
>I'm trying to understand the business case for IAR's business decision
>in their current compiler's PIC feature set.

My bitter side says:  Magazine articles, check-off boxes, a hack added
to provide a "differentiating point" in some write-up, words on paper,
not so carefully considered.  A hack designed to pit one product
against another in the check-off box wars and not about what real
programmers writing real libraries might care about.  Marketing, in
other words.  (Can you hear me spitting on the floor, now?)

My sweet side says:  It wasn't too hard to goose the compiler to emit
PIC code, but it was "too difficult" in the context of business
pressures to really think it out more carefully for the data side.  So
adding the feature might help _some_ folks on _certain_ tasks and,
what the heck, it's also a check-off box in the write-up wars.  "Let's
do it.  We can always argue that it helps at least some folks some of
the time.  And we get one more thing to club our competition with."

Anyway, if IAR has gone this far, perhaps they will take the next
logical step and clean up the details.  One can hope.

So far, Anders has said that he doesn't think the other vendors even
bothered to do it at all (this goes to my above point and doesn't
suggest crafted technical reasons were in play) and that "this is one
of those things that is difficult in C" (however that should be
taken.)  And although I love to speculate, I probably have no business
saying what his reasoning was, as he is here to say what it actually
was.  And hopefully, I'll learn something.

Jon

Hello,
     Thanks a lot for the immediate response.

with regards
Raju K N N


--- Anders Lindgren <Anders.lindgren@...> wrote:

> RAJU.K.N.N. RAJU.K.N.N wrote:
> > Hello List,
> >
> > Target porcessor used : MSP430F1611
> > Tools Used : IAR embedded workbench Ver3.30A from
> IAR
> > systems.
> >
> > My question is
> >
> > 1. Can I do 32 bit math(+,-,*,/) on MSP430F1611
> > processor just simillar to 16 bit math?
>
> Yes we support 32 bit operations. You can even do 64
> bit math using the
> "long long" data type.
>
>
> > 2. Does IAR support 32 bit data type?
>
> Yes, both integers, "long", and floating-point,
> "float".
>
>
> > 3. Do I need to do any extra data manipulation for
> > portign the 32 bit programs to run on MSP430F1611
> ?
>
> If you have a program written for a 32 bit machine
> then you might need
> to do some things. Mainly, the "int" data type for
> MSP430 is 16 bits.
> This means that all variables that were declared as
> "int" but should be
> able to take larger values have to be re-declared as
> "long".
>
> I would recommend that you use the standard header
> file "stdint.h" and
> use the types "int16_t", "uint32_t" etc.
>
>      -- Anders Lindgren, IAR Systems
> --
> Disclaimer: Opinions expressed in this posting are
> strictly my own and
> not necessarily those of my employer.
>
>
>
> To unsubscribe from the msp430 group, send an email
> to:
> msp430-unsubscribe@egroups.com
>
>
> Yahoo! Groups Links
>
>
>     msp430-unsubscribe@yahoogroups.com
>
>
>
>
>


Raju.K.N.N.
Bangalore

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Leon's right - for a prototype, a standard crystal will do the job.
Keep in mind though that you MUST load the crystal with the correct capacitance
to come up on the right frequency (else you will suffer massive BER).

If it's 18 pF Cl, then in theory you'd need 36 pF on either side of the crystal,
to come up within xx PPM of the spec of the crystal, then account for stray
capacitance.

However, for production you CANNOT do this.

> With a larger cap you are shifting the frequency which is the killer for a
2401 application.
> M.

This is not true.

You _can_ bring it up on the right frequency with Cl = 18 pF (as above).
However, because it is an oscillator designed for fast start-up at extremely low
current,
the drive is very, very little on the crystal.

Therefore, if you load the oscillator output with a capacitance that's too high
(practical will be
~ 33pF), you have a high production risk of :
- Unreliable start up -> resulting in complete RF link failure
- Instability/failure to maintain oscillation -> also resulting in complete RF
link failure.

You _could_ elect to load the output of the oscillator with a lower capacitance,
and then increase
the phase shift capacitor on the other side, and still come up on the right
frequency.
I've tested this on small runs of ~100 for a client, and this worked.
Nordic however does not endorse this method for production.

Bottom line is : get 12 pF Cl crystals for production, it's NOT worth the risk.
Hy-Q sells 12 pF SMT Xtals at 12 pF load.
Make sure their ESR is low enough, this is important.

B rgds
Kris


-----Original Message-----
From: msp430@yahoogroups.com [mailto:msp430@yahoogroups.com] On Behalf Of Leon
Heller
Sent: Tuesday, 4 April 2006 6:04 AM
To: msp430@yahoogroups.com
Subject: Re: [msp430] OT: Nordic nRF24L01 crystal specs overrated?

----- Original Message -----
From: "Onur Yildirim" <onur.yildirim@...>
To: <msp430@yahoogroups.com>
Sent: Monday, April 03, 2006 4:10 PM
Subject: [msp430] OT: Nordic nRF24L01 crystal specs overrated?


> Hi,
>
> We are planning to try Nordic's nRF24L01. Their preliminary product
> specification document includes a application example with a reference
> circuit and associated BOM list. In this example a 16Mhz crystal is
> used with a load capacitance of 12pF. I was browsing Mouser and
> Digikey for a suitable crystal but finding one with load capacitance
> value below 18pF seems to be hard. Nordic people state following lines
> about crystal selection and load capatitance:
> "To achieve a crystal oscillator solution with low power consumption
> and fast start-up time, it is recommended to specify the crystal with
> a low value of crystal load
> capacitance. Specifying CL=12pF is OK, but it is possible to use up to
> 16pF."
>
> Does anyone have any previous experience with this part? Is it
> possible to bend the xtal specs towards one with 18pF of load
> capacitance?

As it's a prototype I'd just try it, it should work.

Leon



To unsubscribe from the msp430 group, send an email to:
msp430-unsubscribe@egroups.com


Yahoo! Groups Links

Thanks for all the input folks. Let's see:

Try to get a good crystal within specs.. If not available, use 16Mhz
Abracon you already have.. Then while no production, look for a
vendor. If vendor found go produce.

This all computes very nicely,
Have a nice day.


On 4/4/06, Microbit <microbit@...> wrote:
> Leon's right - for a prototype, a standard crystal will do the job.
> Keep in mind though that you MUST load the crystal with the correct
> capacitance
> to come up on the right frequency (else you will suffer massive BER).
>
> If it's 18 pF Cl, then in theory you'd need 36 pF on either side of the
> crystal,
> to come up within xx PPM of the spec of the crystal, then account for stray
> capacitance.
>
> However, for production you CANNOT do this.
>
>
> > With a larger cap you are shifting the frequency which is the killer for a
> 2401 application.
> > M.
>
> This is not true.
>
> You _can_ bring it up on the right frequency with Cl = 18 pF (as above).
> However, because it is an oscillator designed for fast start-up at extremely
> low current,
> the drive is very, very little on the crystal.
>
> Therefore, if you load the oscillator output with a capacitance that's too
> high (practical will be
> ~ 33pF), you have a high production risk of :
> - Unreliable start up -> resulting in complete RF link failure
> - Instability/failure to maintain oscillation -> also resulting in complete
> RF link failure.
>
> You _could_ elect to load the output of the oscillator with a lower
> capacitance, and then increase
> the phase shift capacitor on the other side, and still come up on the right
> frequency.
> I've tested this on small runs of ~100 for a client, and this worked.
> Nordic however does not endorse this method for production.
>
> Bottom line is : get 12 pF Cl crystals for production, it's NOT worth the
> risk.
> Hy-Q sells 12 pF SMT Xtals at 12 pF load.
> Make sure their ESR is low enough, this is important.
>
> B rgds
> Kris
>

Hello

   I am running a code that uses mostly float variables and the map file gave the
following results:
   11 662 bytes of CODE  memory
   9 410 bytes of DATA  memory (+ 2 absolute )
   1 433 bytes of CONST memory
   Errors: none
Warnings: none

   As far as i know the msp430f1611 has 10240 bytes of memory, so how is this
code running using  this much bytes 11 662 and no error generated?

   The other thing i would like to ask, is on which basis do we choose the FET
debugger connection to be : LPT1, J-link or Ti USB FET

   Thanks in advance!


---------------------------------
Blab-away for as little as 1¢/min. Make  PC-to-Phone Calls using Yahoo!
Messenger with Voice.

[Non-text portions of this message have been removed]

CONST memory is in CODE space (flash).

M.

On Tue, Apr 04, 2006 at 12:55:59AM -0700, wish_akuze wish_akuze wrote:
> Hello
>
>   I am running a code that uses mostly float variables and the map file gave
the following results:
>   11 662 bytes of CODE  memory
>   9 410 bytes of DATA  memory (+ 2 absolute )
>   1 433 bytes of CONST memory
>   Errors: none
> Warnings: none
>
>   As far as i know the msp430f1611 has 10240 bytes of memory, so how is this
code running using  this much bytes 11 662 and no error generated?
>
>   The other thing i would like to ask, is on which basis do we choose the FET
debugger connection to be : LPT1, J-link or Ti USB FET
>
>   Thanks in advance!
>
>
> ---------------------------------
> Blab-away for as little as 1¢/min. Make  PC-to-Phone Calls using Yahoo!
Messenger with Voice.
>
> [Non-text portions of this message have been removed]
>
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
         Matthias

wish_akuze wish_akuze wrote:
> Hello
>
>   I am running a code that uses mostly float variables and the map file gave
the following results:
>   11 662 bytes of CODE  memory
>   9 410 bytes of DATA  memory (+ 2 absolute )
>   1 433 bytes of CONST memory
>   Errors: none
> Warnings: none
>
>   As far as i know the msp430f1611 has 10240 bytes of memory, so how is this
code running using  this much bytes 11 662 and no error generated?
>
>   The other thing i would like to ask, is on which basis do we choose the FET
debugger connection to be : LPT1, J-link or Ti USB FET
>
>   Thanks in advance!

It's got 10240 bytes of RAM memory and 48KB of ROM. Both CODE and CONST
are placed in ROM.

      -- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Jonathan Kirwan wrote:

>>>>We drew the line that we shouldn't do any data relocation what so
>>>>ever.

>>>I'm not disagreeing, it _is_ simply a line in the sand - my argument
>>>is that the line would be drawn based on ROM/RAM criteria, rather than
>>>a code/data criteria.

>>I'm still curious; Has anyone reading this found the line drawn by IAR
>>useful?

> I'm still unclear on the details.  But I gather that an argument is
> hinted at which says that the current MSP430 mix of flash and RAM
> doesn't make PC-relative references to static data all that useful,
> anyway.  (A reference by Anders to a need for a "patcher" brings this
> to my mind.)  However, I don't find that argument persuasive because
> there are many very important cases where the static data is constant
> (FIR filter constants, transcendental table values, etc., etc.) and
> can move around in the flash along with the position independent
> library code.  I could also, potentially, include the idea that a
> position independent library module be built on the concept of
> requiring a following block of flash for its saved static data and
> that there needs to be a method to allow a block of flash code and an
> associated block of flash data to move around.  Also, finally, code
> doesn't only run in flash.  It is very possible to contain the idea in
> an embedded product where code and its associated data is laid out
> into the scarce RAM for execution and that the ability to allocate
> small blocks for that purpose and to download code shouldn't require
> the need for a "patcher", if the compiler supported the concept of PIC
> fully.
>
>
>>Giving up initialized data pointing to global variables but not
>>constant data (i.e. a string pointer) still seems less impactful than
>>giving up all initialized pointer data (constant or otherwise).
>>
>>I'm trying to understand the business case for IAR's business decision
>>in their current compiler's PIC feature set.
>
>
> My bitter side says:  Magazine articles, check-off boxes, a hack added
> to provide a "differentiating point" in some write-up, words on paper,
> not so carefully considered.  A hack designed to pit one product
> against another in the check-off box wars and not about what real
> programmers writing real libraries might care about.  Marketing, in
> other words.  (Can you hear me spitting on the floor, now?)
>
> My sweet side says:  It wasn't too hard to goose the compiler to emit
> PIC code, but it was "too difficult" in the context of business
> pressures to really think it out more carefully for the data side.  So
> adding the feature might help _some_ folks on _certain_ tasks and,
> what the heck, it's also a check-off box in the write-up wars.  "Let's
> do it.  We can always argue that it helps at least some folks some of
> the time.  And we get one more thing to club our competition with."
>
> Anyway, if IAR has gone this far, perhaps they will take the next
> logical step and clean up the details.  One can hope.
>
> So far, Anders has said that he doesn't think the other vendors even
> bothered to do it at all (this goes to my above point and doesn't
> suggest crafted technical reasons were in play) and that "this is one
> of those things that is difficult in C" (however that should be
> taken.)  And although I love to speculate, I probably have no business
> saying what his reasoning was, as he is here to say what it actually
> was.  And hopefully, I'll learn something.

I'm interested to know myself ;)  This was added before I started
working on the compiler, which was when I wrote V2.xx, so from my point
of view it's spelled "backward compatibility".

I think that you have conviced me that this feature is of broader
interest that I've thought so far. Although I can't make any commitments
at this time, I will take a deep look into this and see if I can improve
the situation.

I'm a bit suprised that very few, if any, have contacted our support
orgianization concerning this...

      -- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

> I'm interested to know myself ;)  This was added before I started
> working on the compiler, which was when I wrote V2.xx, so from my point
> of view it's spelled "backward compatibility".

Ahh, the penny drops.

>
> I think that you have conviced me that this feature is of broader
> interest that I've thought so far. Although I can't make any
commitments
> at this time, I will take a deep look into this and see if I can
improve
> the situation.

A second check box to choose whether the constant data is code
relative or absolute would solve my trouble.

> I'm a bit suprised that very few, if any, have contacted our support
> orgianization concerning this...

REALLY!?  I came here expecting to read past articles and the subject.
  Your comment explains why I couldn't find any.