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

> 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

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

> 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: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