On Fri, 19 Mar 2004 01:50:39 +1100, microbit wrote:

>> I would have loved to put the pain off into a
CPLD.  However at 250,000
>units
>> per year, the target cost for everything was $3 (USD).  Oh and did I
>forget
>> to mention the expected 10 year battery life....
>>
>>
>> -Bill

>It depends on app as usual of course.
>If you needed only one serial, and the Manchester didn't require a 2nd
UART
>(which it wouldn't)
>then it's OK.
>Otherwise a Coolrunner (64 Macrocell) is a surprisingly efficient way to
>address it if dealing
>with async data over RF.
>The cost of the CPLD is less than going eg. F13X -> F14X )(for the 2nd
>UART), and the current is lower !
>The way it was set up, the CoolRunner needed about 0.5 mA at 6.144 MHz, 8
>times oversampled,
>and that's much lower again than needing 2.5 mA with the MSP430 for
that
>function.
>It also means that the 0.5 mA only is needed while "hunting" for a
CRC
>checked and qualified
>packet, if no other things are needed the MSP430 can completely sleep,
>that's 0.5 mA instead
>of 2.5 mA, a significant saving.
>(A 16 bit MCU wouldn't be able to oversample 8 times, have a digital
PLL,
>and reliably decode
>Manchester at 1.5 MBps anyway, even an MSP430 :-(


I wouldn't want to do 1.5Mbps on an MSP.  Luckily our requirements were
slower.
We did however, sleep at 1.9uA for everything, including part of the RF front
end being active looking for entry into the read zone.

-Bill

> I would have loved to put the pain off into a CPLD.  However at
250,000
units
> per year, the target cost for everything was $3
(USD).  Oh and did I
forget
> to mention the expected 10 year battery life....
>
>
> -Bill

It depends on app as usual of course.
If you needed only one serial, and the Manchester didn't require a 2nd UART
(which it wouldn't)
then it's OK.
Otherwise a Coolrunner (64 Macrocell) is a surprisingly efficient way to
address it if dealing
with async data over RF.
The cost of the CPLD is less than going eg. F13X -> F14X )(for the 2nd
UART), and the current is lower !
The way it was set up, the CoolRunner needed about 0.5 mA at 6.144 MHz, 8
times oversampled,
and that's much lower again than needing 2.5 mA with the MSP430 for that
function.
It also means that the 0.5 mA only is needed while "hunting" for a CRC
checked and qualified
packet, if no other things are needed the MSP430 can completely sleep,
that's 0.5 mA instead
of 2.5 mA, a significant saving.
(A 16 bit MCU wouldn't be able to oversample 8 times, have a digital PLL,
and reliably decode
Manchester at 1.5 MBps anyway, even an MSP430 :-(

-- Kris

On Fri, 19 Mar 2004 01:13:35 +1100, microbit wrote:

>> Last things first.  At the time the project
was underway, IAR 1.2x was
>> the only comercial compiler available.  It did not have _SWPB.

>I see, Bill.
>I have been in that position myself. Thank God those days are gone :-)

>> The code that synchronized to, decoded, and
saved the downlink data
>> stream did so in 12 cycles per Manchester bit cell.  Even in assembly
>> it is a very tightly interwoven piece of code.  And yes, it saved all
>> used registers upon entry and restored them at exit.

>12 cycles / cell, that's pretty darn good
considering you were at 300 kBps.
>Last time I used BiPhase, I had 1.5 Mbps to deal with.
>I copped out and used a CPLD that handled all sync, filtering, oversampling,
>and packet sync/framing/network address recognition.
>Worked a treat with Coolrunner.

>-- Kris


I would have loved to put the pain off into a CPLD.  However at 250,000 units
per year, the target cost for everything was $3 (USD).  Oh and did I forget
to mention the expected 10 year battery life....


-Bill

> Last things first.  At the time the project was underway, IAR 1.2x was
> the only comercial compiler available.  It did not
have _SWPB.

I see, Bill.
I have been in that position myself. Thank God those days are gone :-)

> The code that synchronized to, decoded, and saved
the downlink data
> stream did so in 12 cycles per Manchester bit cell.  Even in assembly
> it is a very tightly interwoven piece of code.  And yes, it saved all
> used registers upon entry and restored them at exit.

12 cycles / cell, that's pretty darn good considering you were at 300 kBps.
Last time I used BiPhase, I had 1.5 Mbps to deal with.
I copped out and used a CPLD that handled all sync, filtering, oversampling,
and packet sync/framing/network address recognition.
Worked a treat with Coolrunner.

-- Kris

Hi Bill,

CrossWorks has an intrinsic unsigned _SWPB(unsigned), also _LSWPB and
_LSWPW.
As good as ASM.
There's actually stacks of intrinsics from _DADD16/32/64 to _DNEG and
_DSUB16/32/64.
and others, beyond scope I guess.

-- Kris

> On Thu, 18 Mar 2004 09:42:12 -0000, Paul Curtis
wrote:
>
> <snip>
>
> >We don't support inline assembler other than by using _OPC. 
I'm not
> >sure why people love inline assembler when we have a bunch of intrinsic
> >functions that do away with the need for it.  (I hope--but if you know
> >different, just drop me a line...)
>
>
> <snip>
>
> Paul
>   I'll jump in on that one.  A recent MSP project was to create a
> replacement California FasTrac (auto toll) tag.  The ASIC originally
> used had gone end-of-life and our customer was still selling almost
> 1/4 million tags per year.  Part of the requirements was the reception
> of a 300Kbps Manchester encoded message from the toll-booth.  And we
> found later in the project, the data rate could vary from booth to
> booth by a little over 1%.  The code to synchronize to and decode the
> data stream was written in assembly, however the code that called it
> and the code that used the results was written in C.  The abiltiy to
> have in-line assembly code which has access to C level data by name is
> a great benefit.  The assembly code in our case stored code in an
> array of uint8_t that was part of a union which allowed the C code to
> later parse the download packet.  It also updated the count field in
> the struct which held the union.
>
>   In another part of that same project had the need to very quickly
> swap the two bytes of a 16-bit word.  Yes, it would have been possible
> to either create an in-line C function or an assembly level routine to
> do it.  However, the C level function was bigger and slower, and the
> assembly language suffered from the overhead of the call/return.
> An in-line function containing only in-line assembly was ideal.
>
> Regards
> -Bill Knight
> R O SoftWare

On Thu, 18 Mar 2004 13:33:53 -0000, Paul Curtis wrote:

>Bill,

>> <snip>
>> 
>> >We don't support inline assembler other than by using _OPC. 
I'm not 
>> >sure why people love inline assembler when we have a bunch 
>> of intrinsic 
>> >functions that do away with the need for it.  (I hope--but 
>> if you know 
>> >different, just drop me a line...)
>> 
>> 
>> <snip>
>> 
>> Paul
>>   I'll jump in on that one.  A recent MSP project was to 
>> create a replacement California FasTrac (auto toll) tag.  The 
>> ASIC originally used had gone end-of-life and our customer 
>> was still selling almost 1/4 million tags per year.  Part of 
>> the requirements was the reception of a 300Kbps Manchester 
>> encoded message from the toll-booth.  And we found later in 
>> the project, the data rate could vary from booth to booth by 
>> a little over 1%.  The code to synchronize to and decode the 
>> data stream was written in assembly, however the code that 
>> called it and the code that used the results was written in 
>> C.  The abiltiy to have in-line assembly code which has 
>> access to C level data by name is a great benefit.  The 
>> assembly code in our case stored code in an array of uint8_t 
>> that was part of a union which allowed the C code to later 
>> parse the download packet.  It also updated the count field 
>> in the struct which held the union.

>I don't see why it can't just be an
assembly module that C has access
>to.  It's simple to do, to publicise an address in code that's
right in
>the middle of an assembly insert, or to move code form flash to RAM for
>execution.

>So, how did you manage the registers in use when
you coded inline?  Did
>you need to save them and restore them in the assembly code sequence?

>Again, I fail to see why you need a huge amount of
in-line assembly
>code.  You can easily modify C variables from assembly, just as you can
>modify assembly variables from C.

>>   In another part of that same project had the
need to very 
>> quickly swap the two bytes of a 16-bit word.  Yes, it would 
>> have been possible to either create an in-line C function or 
>> an assembly level routine to do it.  However, the C level 
>> function was bigger and slower, and the assembly language 
>> suffered from the overhead of the call/return. An in-line 
>> function containing only in-line assembly was ideal.

>What's wrong with _SWPB in every MSP430
compiler?  It's inline, comes in
>the package, and is documented in our compiler, and it's efficient.
>Same for every other byte/word swapping function in our compiler.  No
>need for inline code or assembler, so again, I fail to see why inline
>assembly code is the answer?


Last things first.  At the time the project was underway, IAR 1.2x was
the only comercial compiler available.  It did not have _SWPB.

The code that synchronized to, decoded, and saved the downlink data
stream did so in 12 cycles per Manchester bit cell.  Even in assembly
it is a very tightly interwoven piece of code.  And yes, it saved all
used registers upon entry and restored them at exit.  And yes, it is
possible to pass addresses and data into assembly routines.  It is
also nice to be able to reference them by name, without additional
declarations, while having to code in assembly.

-Bill

Bill,

> <snip>
> 
> >We don't support inline assembler other than by using _OPC. 
I'm not 
> >sure why people love inline assembler when we have a bunch 
> of intrinsic 
> >functions that do away with the need for it.  (I hope--but 
> if you know 
> >different, just drop me a line...)
> 
> 
> <snip>
> 
> Paul
>   I'll jump in on that one.  A recent MSP project was to 
> create a replacement California FasTrac (auto toll) tag.  The 
> ASIC originally used had gone end-of-life and our customer 
> was still selling almost 1/4 million tags per year.  Part of 
> the requirements was the reception of a 300Kbps Manchester 
> encoded message from the toll-booth.  And we found later in 
> the project, the data rate could vary from booth to booth by 
> a little over 1%.  The code to synchronize to and decode the 
> data stream was written in assembly, however the code that 
> called it and the code that used the results was written in 
> C.  The abiltiy to have in-line assembly code which has 
> access to C level data by name is a great benefit.  The 
> assembly code in our case stored code in an array of uint8_t 
> that was part of a union which allowed the C code to later 
> parse the download packet.  It also updated the count field 
> in the struct which held the union.

I don't see why it can't just be an assembly module that C has access
to.  It's simple to do, to publicise an address in code that's right
in
the middle of an assembly insert, or to move code form flash to RAM for
execution.

So, how did you manage the registers in use when you coded inline?  Did
you need to save them and restore them in the assembly code sequence?

Again, I fail to see why you need a huge amount of in-line assembly
code.  You can easily modify C variables from assembly, just as you can
modify assembly variables from C.

>   In another part of that same project had the
need to very 
> quickly swap the two bytes of a 16-bit word.  Yes, it would 
> have been possible to either create an in-line C function or 
> an assembly level routine to do it.  However, the C level 
> function was bigger and slower, and the assembly language 
> suffered from the overhead of the call/return. An in-line 
> function containing only in-line assembly was ideal.

What's wrong with _SWPB in every MSP430 compiler?  It's inline, comes
in
the package, and is documented in our compiler, and it's efficient.
Same for every other byte/word swapping function in our compiler.  No
need for inline code or assembler, so again, I fail to see why inline
assembly code is the answer?

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors 

On Thu, 18 Mar 2004 09:42:12 -0000, Paul Curtis wrote:

<snip>

>We don't support inline assembler other than
by using _OPC.  I'm not
>sure why people love inline assembler when we have a bunch of intrinsic
>functions that do away with the need for it.  (I hope--but if you know
>different, just drop me a line...)


<snip>

Paul
  I'll jump in on that one.  A recent MSP project was to create a
replacement California FasTrac (auto toll) tag.  The ASIC originally
used had gone end-of-life and our customer was still selling almost
1/4 million tags per year.  Part of the requirements was the reception
of a 300Kbps Manchester encoded message from the toll-booth.  And we
found later in the project, the data rate could vary from booth to
booth by a little over 1%.  The code to synchronize to and decode the
data stream was written in assembly, however the code that called it
and the code that used the results was written in C.  The abiltiy to
have in-line assembly code which has access to C level data by name is
a great benefit.  The assembly code in our case stored code in an
array of uint8_t that was part of a union which allowed the C code to
later parse the download packet.  It also updated the count field in
the struct which held the union.

  In another part of that same project had the need to very quickly
swap the two bytes of a 16-bit word.  Yes, it would have been possible
to either create an in-line C function or an assembly level routine to
do it.  However, the C level function was bigger and slower, and the
assembly language suffered from the overhead of the call/return.
An in-line function containing only in-line assembly was ideal.

Regards
-Bill Knight
R O SoftWare

Tim,

> Thanks for your help! I got it all going. I was
porting a 
> slab of code from GCC to CrossWorks. 
> 
> > if you go to : Tutorial -> MSP430 Samples -> .... in that
> > pretty HTML help, there are stacks and stacks of example 
> > projects where you can see the syntax for Interrupt handlers. 
> > I think you might have hit ARM examples because the context 
> > sensitive help took you to the CTL (CrossWorks Tasking 
> > Library), actually a ___fast__ and really nice RTOS !!!
> 
> Yes; it is a little confusing as I still haven't found any 
> explanation about interrupts in the IDE help files... Or 
> in-line assembler! I ended up reorganizing the code to remove 
> the two small inline bits of code...

We don't support inline assembler other than by using _OPC.  I'm not
sure why people love inline assembler when we have a bunch of intrinsic
functions that do away with the need for it.  (I hope--but if you know
different, just drop me a line...)

> One last question wrt to the __interrupt. On GCC
we use the 
> 'wakeup' flag on the interrupt service routine. Do Rowley 
> have anything similar?

I think you'll find the wakeup takes the CPU out of LPM on the RETI and
makes it go into active mode.  Thus, one of the LPMx_EXIT macros is
probably what you're wanting in the ISR.  Take a look at the contents of
<msp430x14x.h> and in the online help for _BIS_SR_IRQ and _BIC_SR_IRQ.

There are plenty of examples in the "samples" directory or, as Kris
points out, use the HTML-based help system and open up the samples
directly from inside the help system and start exploring.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors 

Hi Tim, Kris,

> > One last question wrt to the __interrupt. On
GCC we use the 
> 'wakeup' 
> > flag on the interrupt service routine. Do Rowley have anything 
> > similar?
> 
> I'm not familiar with GCC. I think Paul wil have to answer that.

I think you'll find the wakeup takes the CPU out of LPM on the RETI and
makes it go into active mode.  Thus, one of the LPMx_EXIT macros is
probably what you're wanting in the ISR.  Take a look at the contents of
<msp430x14x.h> and in the online help for _BIS_SR_IRQ and _BIC_SR_IRQ.

There are plenty of examples in the "samples" directory or, as Kris
points out, use the HTML-based help system and open up the samples
directly from inside the help system.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors