| Newsgroups |
gmane.comp.hardware.texas-instruments.msp430.discuss |
| Message-ID |
<[email protected]> |
--------------040709040705090701020505
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
I think my favourite program of all time was one I encountered about 20
years ago. It was written in assembler for a 6809. The program was
thousands of instructions long, and all but a few of these sat inside a
single massive interrupt handler. The guy read the PIC status byte, into
the ACC, shifted it (without saving it) jumped off within the same ISR
if the bit was set, else continued to the next bit. Then on return (by a
jump, no less not a call) he shifted the acc for the next bit, having
corrupted it in the function he jumped to. Needless to say the program
crashed frequently, but he had a unique way of dealing with this too.
One of the program functions was to handle a packet modem, so he
monitored the modem status led with a wire onto a hardware timer, and if
the led stayed on too long the timer triggered a relay, and shut power
off to the system for 5 seconds, then turned the relay back on again.
This same guy told me that good programmers never used bit instructions,
ie bit tests or set/clear. I think he must have been a refugee from the
Montreal Comedy Festival, but somehow he'd convinced somebody to pay him
thousands a week for over a year.
I think it's probably easier to make a simple mistake with profound
consequences in assembler, more so than C, but I've also seen some
almost as good in C, C++ and C#. Perhaps the most memorable was nothing
to do with language at all. A team of supposedly crack internet experts,
who just happened to use C# were supposed to write a simple serial
routine to recieve data from a wireless network I'd designed. It didn't
work, but, of course the fault was mine, i couldn't be transmitting the
data correctly. So I added in a CRC. they didn't know what a CRC was,
they didn't know what data whitening was, or FEC, so I gave them a C
function to handle it. They then insisted that my system was still
faulty, because when they parsed it they only ever got garbage, however
I tried to point out that the CRC calculation was correct every time,
and, since there was no physical link this was pretty much proof that my
data was being received cleanly. they didn't understand the CRC, so i
started trying to explain to them. i made the mistake of suggesting that
the internet, which they were experts on, used similar data recovery
tools to work, b ut no, I was totally wrong, apparently aaccording to
them every time there is an error in receiving a packet the originating
station has to start sending the whole thing over again. Funnily I lost
that contract because I didn't understand data transmission apparently.
The bugger still owes me over $50k, but no way to get that back.
Sometimes the language doesn't matter, you just aren't designed to be a
programmer, no matter how many times you tell people you are the 'god of
internet programming'.
Life has certainly been fun, but I avoid all the excitement now by only
doing stuff for me.
Al
On 13/01/2016 7:39 PM, David Brown [email protected] [msp430] wrote:
> On 13/01/16 05:34, Onestone [email protected] [msp430] wrote:
>>
>>
>> I do so want to go for six shooters at sunset, but mostly you are right,
>> however this presupposes the C writer is able to write efficient code,
>> because without that the compiler, no matter how efficient, is of
>> limited help. The number of times I see people do something that needs a
>> division, lets say an average, and they pick some arbitrary value such
>> as 11, when 8 or 16 makes more sense and codes cleanly. No compiler can
>> make up for dumb thought processes, whereas assembler tends to make you
>> think more in line with how the CPU hardware works, at least when I
>> write software that's how I think, basically track the operands through
>> the hardware in my thoughts. Similarly C programmers tend to be in love
>> with floating point, when integer is more accurate, and faster. In 40+
>> years I've very rarely had the need to revert to floating point, yet
>> most of the C programs I see for micros use it whenever the program has
>> to handles numbers.
> That's a good point, and you are absolutely right. I think that the
> best way to learn to write good C code for embedded systems (actually,
> good C code in general) is to do some assembly programming first.
> People who come to embedded C programming from assembly upwards write
> more efficient code than people who get there from Java, C#, Python down.
>
> But there is also a similar effect the other way. While those with a
> background in PC programming will divide by 11 or use floating point
> without thought of the consequences, people with an assembly background
> (and even more so, people programming in assembly) will avoid these even
> if they are actually the best way to handle the problem. Sometimes
> floating point is the most convenient way to get correct code, and it
> doesn't matter if the operation takes 1 ms instead of 10 microseconds
> using scaled integers. An assembly programmer, or a C programmer who
> thinks in assembly, would avoid the floating point even though it means
> a good deal of unnecessary work.
>
> It is not easy to get the right balance here - but if this job were too
> easy, it would be no fun! On the whole, people who have done /some/
> assembly programming are better qualified to write embedded C than
> people who have not done so, but /any/ programmer of /any/ type of
> system will benefit from working on a variety of programs on a variety
> of systems using a variety of languages.
>
>> So while I agree that in the hands of a good programmer C should be
>> quite fast and compact, I suspect that the number of C programmers out
>> there who are capable of making use of these features are as few and far
>> between as assembler programmers of any ilk.
> This is all gut feeling rather than evidence based, but I think the
> percentage of good, mediocre and bad programmers for any given language
> is fairly independent of the language. I would rather have a mediocre C
> programmer, or even a bad C programmer, than a a mediocre assembly
> programmer - because a non-expert C programmer might write inefficient
> code, but he is less likely to write /incorrect/ code. And correctness
> trumps efficiency every time. (And non-expert assembly programmers
> write inefficient code - at least as badly as non-expert C programmers.
> I have seen plenty of astoundingly bad assembly code.)
>
> When working in teams, it is also much easier for one expert C
> programmer to guide and help a number of mediocre C programmers - code
> reviews to weed out particularly bad code, help on the "difficult bits",
> etc. This is a lot harder if everyone is doing assembly - it is far
> harder to understand most people's assembly code than their C code when
> doing reviews, and there are many more "difficult bits". (Again, this
> is gut feeling without proof.)
>
>
>> However a good compiler can
>> make an average C programmer look a lot better than they really are.
> If the resultant program is good enough for the job, does it matter if
> the programmer did a good job, or if the compiler did a good job? When
> doing professional work - someone is paying for your time and effort -
> then "good enough" is good enough. Perfection is a waste of somebody's
> money. If the motor has to turn at 1000 rpm, then hiring a better (and
> more expensive) C programmer, or letting an assembler programmer spend
> four times the development time in order to get 2000 rpm out of the same
> chip is a waste of money. It means you have done a /worse/ job, not a
> better one.
>
>> I
>> truly believe that the higher level language you program in the lazier,
>> sloppier and less efficient most people get because they can, without
>> much fear of being found out, and if it doesn't work just throw a bigger
>> faster processor at it.
> Absolutely true - but lazy and sloppy are /good/ in the right context.
> When I write PC code, most of it is in Python. It is far cheaper for
> the customer to buy a faster processor than to pay me to write tens of
> thousands of lines of efficient C code rather than a few hundred lines
> of quick-and-dirty Python code. High level languages exist to insulate
> you from the low-level details, giving a different balance between
> development time and run time.
>
> I believe that working with a variety of languages at different levels
> (both higher and lower level than their main language) makes a
> programmer more aware of this, and better able to choose the right
> balance for the task in hand.
>
>> I get it, but don't want to be a part of it, and don't have to be so I
>> shall plod along with the rest of the dinosaurs waiting for the next
>> major extinction event to come along.
> In all discussions about what is the best language or development
> methodology, it is important not to forget the developers' preferences -
> a happy assembly programmer is more use than an unhappy C programmer!
>
> mvh.,
>
> David
>
>
>> Cheers
>>
>> Al
>>
>> On 13/01/2016 9:48 AM, David Brown [email protected] [msp430] wrote:
>>> On 12/01/16 22:28, Jon Kirwan [email protected] [msp430] wrote:
>>>> On Tue, 12 Jan 2016 10:04:54 +0100, David wrote:
>>>>
>>>> ><snip>
>>>> >gcc will generate better
>>>> >code than most assembler programmers in many circumstances - assuming
>>>> >the code has to be written in a clear, understandable, safe,
>>>> >maintainable manner.
>>>> ><snip>
>>>>
>>>> Although we've discussed the subject in the long past here,
>>>> this really has very little to do with the current thread
>>>> started by Craig. Craig was interested in "sample code in
>>>> Asm."
>>>>
>>>> While I do think there are a number of related topics to the
>>>> question of sample assembly code (for example, which
>>>> assembler tool is in use so that the appropriate sample
>>>> source can be suggested -- gas assembler is quite different
>>>> from IAR, as we both know), I don't for a second imagine that
>>>> his question should instill a response saying that gcc
>>>> generates better code than "most assembler programers," which
>>>> seems more about uncovering some old sore point than anything
>>>> else. (Besides, there are a few folks here who are definitely
>>>> better than "most assembler programmers.")
>>>>
>>> When I see someone looking for help with assembly, I think it is
>>> perfectly reasonable to point out the options with compilers. You have
>>> to ask yourself /why/ that person is asking about assembly, and think
>>> can you be more helpful by pointing them in a different direction.
>>>
>>> Let's consider the reasons why a person might want to start working on
>>> an msp430 in assembly. (Note that I don't know to what extent the OP is
>>> /starting/ with assembly, but the discussion on choice of assembler
>>> tools suggest he might be.)
>>>
>>> 1. They want to learn about the cpu, and see exactly how it works.
>>> That's great!
>>>
>>> 2. It's for fun - also great.
>>>
>>> 3. They want to do something that cannot be done using C. There are
>>> /very/ few cases where this is realistic - in most cases, the person is
>>> mistaken.
>>>
>>> 4. They want to write the most efficient possible code, and think that
>>> means assembly. In most cases, they are mistaken.
>>>
>>> 5. Assembly is all they know, and they don't want to learn C. If this
>>> is for a hobby project, then that's fair enough - but if it is in a
>>> professional context, then they are not doing a good job. Writing
>>> maintainable code in a language that many people understand, and using
>>> tools that give much greater developer efficiency, means C trumps
>>> assembly in almost all cases for professional development. There are
>>> always exceptions, of course, but exceptions are rare.
>>>
>>> 6. They think C compilers for small microcontrollers are inefficient or
>>> limited. That may be true on some cores, but not on the msp430.
>>>
>>> 7. They think that C compilers are expensive. Again, that is true for
>>> some cores, and it used to be true for the msp430, but it is not true now.
>>>
>>>
>>> My experience is that most people who choose to work in assembler these
>>> days, do so for invalid or inappropriate reasons. This certainly does
>>> not apply to /all/ people who pick assembler - but it applies to many.
>>> So in the interest of helping the original poster, it makes sense to
>>> bring up C as an alternative. It would be unreasonable to try to push
>>> it on him if he has good reason to use assembler, but it is a good think
>>> to suggest it.
>>>
>>> So when the OP was asking about different sized multiply and divide
>>> routines in msp430 assembly, my first thought is /why/ bother? Write "x
>>> = y * z;" and "x = y / z;" and let the compiler generate the code. It
>>> will make code that is at least as small and efficient as you can do by
>>> hand - and if it can figure out some of the values at compile time, it
>>> will do far better than the assembly programmer. And it will do so as
>>> fast as you can type a couple of lines of code, and will do so correctly
>>> - no need to search for sample code, figure out how to integrate it,
>>> worry about possible mismatches of register uses, and so on.
>>>
>>> David
>>>
>
>
> ------------------------------------
> Posted by: David Brown <[email protected]>
> ------------------------------------
>
> To unsubscribe from the msp430 group, send an email to:
> [email protected]
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>
--------------040709040705090701020505
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<!-- |**|begin egp html banner|**| -->
<br><br>
<!-- |**|end egp html banner|**| -->
<font size="-1">I think my favourite program of all time was one I
encountered about 20 years ago. It was written in assembler for a
6809. The program was thousands of instructions long, and all but
a few of these sat inside a single massive interrupt handler. The
guy read the PIC status byte, into the ACC, shifted it (without
saving it) jumped off within the same ISR if the bit was set, else
continued to the next bit. Then on return (by a jump, no less not
a call) he shifted the acc for the next bit, having corrupted it
in the function he jumped to. Needless to say the program crashed
frequently, but he had a unique way of dealing with this too. One
of the program functions was to handle a packet modem, so he
monitored the modem status led with a wire onto a hardware timer,
and if the led stayed on too long the timer triggered a relay, and
shut power off to the system for 5 seconds, then turned the relay
back on again. This same guy told me that good programmers never
used bit instructions, ie bit tests or set/clear. I think he must
have been a refugee from the Montreal Comedy Festival, but somehow
he'd convinced somebody to pay him thousands a week for over a
year.<br>
<br>
I think it's probably easier to make a simple mistake with
profound consequences in assembler, more so than C, but I've also
seen some almost as good in C, C++ and C#. Perhaps the most
memorable was nothing to do with language at all. A team of
supposedly crack internet experts, who just happened to use C#
were supposed to write a simple serial routine to recieve data
from a wireless network I'd designed. It didn't work, but, of
course the fault was mine, i couldn't be transmitting the data
correctly. So I added in a CRC. they didn't know what a CRC was,
they didn't know what data whitening was, or FEC, so I gave them a
C function to handle it. They then insisted that my system was
still faulty, because when they parsed it they only ever got
garbage, however I tried to point out that the CRC calculation was
correct every time, and, since there was no physical link this was
pretty much proof that my data was being received cleanly. they
didn't understand the CRC, so i started trying to explain to them.
i made the mistake of suggesting that the internet, which they
were experts on, used similar data recovery tools to work, b ut
no, I was totally wrong, apparently aaccording to them every time
there is an error in receiving a packet the originating station
has to start sending the whole thing over again. Funnily I lost
that contract because I didn't understand data transmission
apparently. The bugger still owes me over $50k, but no way to get
that back. Sometimes the language doesn't matter, you just aren't
designed to be a programmer, no matter how many times you tell
people you are the 'god of internet programming'.<br>
<br>
Life has certainly been fun, but I avoid all the excitement now by
only doing stuff for me.<br>
<br>
Al<br>
<br>
</font>
<div class="moz-cite-prefix">On 13/01/2016 7:39 PM, David Brown
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:<br>
</div>
<blockquote cite="mid:[email protected]" type="cite">
<pre wrap="">On 13/01/16 05:34, Onestone <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
I do so want to go for six shooters at sunset, but mostly you are right,
however this presupposes the C writer is able to write efficient code,
because without that the compiler, no matter how efficient, is of
limited help. The number of times I see people do something that needs a
division, lets say an average, and they pick some arbitrary value such
as 11, when 8 or 16 makes more sense and codes cleanly. No compiler can
make up for dumb thought processes, whereas assembler tends to make you
think more in line with how the CPU hardware works, at least when I
write software that's how I think, basically track the operands through
the hardware in my thoughts. Similarly C programmers tend to be in love
with floating point, when integer is more accurate, and faster. In 40+
years I've very rarely had the need to revert to floating point, yet
most of the C programs I see for micros use it whenever the program has
to handles numbers.
</pre>
</blockquote>
<pre wrap="">
That's a good point, and you are absolutely right. I think that the
best way to learn to write good C code for embedded systems (actually,
good C code in general) is to do some assembly programming first.
People who come to embedded C programming from assembly upwards write
more efficient code than people who get there from Java, C#, Python down.
But there is also a similar effect the other way. While those with a
background in PC programming will divide by 11 or use floating point
without thought of the consequences, people with an assembly background
(and even more so, people programming in assembly) will avoid these even
if they are actually the best way to handle the problem. Sometimes
floating point is the most convenient way to get correct code, and it
doesn't matter if the operation takes 1 ms instead of 10 microseconds
using scaled integers. An assembly programmer, or a C programmer who
thinks in assembly, would avoid the floating point even though it means
a good deal of unnecessary work.
It is not easy to get the right balance here - but if this job were too
easy, it would be no fun! On the whole, people who have done /some/
assembly programming are better qualified to write embedded C than
people who have not done so, but /any/ programmer of /any/ type of
system will benefit from working on a variety of programs on a variety
of systems using a variety of languages.
</pre>
<blockquote type="cite">
<pre wrap="">
So while I agree that in the hands of a good programmer C should be
quite fast and compact, I suspect that the number of C programmers out
there who are capable of making use of these features are as few and far
between as assembler programmers of any ilk.
</pre>
</blockquote>
<pre wrap="">
This is all gut feeling rather than evidence based, but I think the
percentage of good, mediocre and bad programmers for any given language
is fairly independent of the language. I would rather have a mediocre C
programmer, or even a bad C programmer, than a a mediocre assembly
programmer - because a non-expert C programmer might write inefficient
code, but he is less likely to write /incorrect/ code. And correctness
trumps efficiency every time. (And non-expert assembly programmers
write inefficient code - at least as badly as non-expert C programmers.
I have seen plenty of astoundingly bad assembly code.)
When working in teams, it is also much easier for one expert C
programmer to guide and help a number of mediocre C programmers - code
reviews to weed out particularly bad code, help on the "difficult bits",
etc. This is a lot harder if everyone is doing assembly - it is far
harder to understand most people's assembly code than their C code when
doing reviews, and there are many more "difficult bits". (Again, this
is gut feeling without proof.)
</pre>
<blockquote type="cite">
<pre wrap="">However a good compiler can
make an average C programmer look a lot better than they really are.
</pre>
</blockquote>
<pre wrap="">
If the resultant program is good enough for the job, does it matter if
the programmer did a good job, or if the compiler did a good job? When
doing professional work - someone is paying for your time and effort -
then "good enough" is good enough. Perfection is a waste of somebody's
money. If the motor has to turn at 1000 rpm, then hiring a better (and
more expensive) C programmer, or letting an assembler programmer spend
four times the development time in order to get 2000 rpm out of the same
chip is a waste of money. It means you have done a /worse/ job, not a
better one.
</pre>
<blockquote type="cite">
<pre wrap="">I
truly believe that the higher level language you program in the lazier,
sloppier and less efficient most people get because they can, without
much fear of being found out, and if it doesn't work just throw a bigger
faster processor at it.
</pre>
</blockquote>
<pre wrap="">
Absolutely true - but lazy and sloppy are /good/ in the right context.
When I write PC code, most of it is in Python. It is far cheaper for
the customer to buy a faster processor than to pay me to write tens of
thousands of lines of efficient C code rather than a few hundred lines
of quick-and-dirty Python code. High level languages exist to insulate
you from the low-level details, giving a different balance between
development time and run time.
I believe that working with a variety of languages at different levels
(both higher and lower level than their main language) makes a
programmer more aware of this, and better able to choose the right
balance for the task in hand.
</pre>
<blockquote type="cite">
<pre wrap="">
I get it, but don't want to be a part of it, and don't have to be so I
shall plod along with the rest of the dinosaurs waiting for the next
major extinction event to come along.
</pre>
</blockquote>
<pre wrap="">
In all discussions about what is the best language or development
methodology, it is important not to forget the developers' preferences -
a happy assembly programmer is more use than an unhappy C programmer!
mvh.,
David
</pre>
<blockquote type="cite">
<pre wrap="">
Cheers
Al
On 13/01/2016 9:48 AM, David Brown <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 12/01/16 22:28, Jon Kirwan <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 12 Jan 2016 10:04:54 +0100, David wrote:
><snip>
>gcc will generate better
>code than most assembler programmers in many circumstances - assuming
>the code has to be written in a clear, understandable, safe,
>maintainable manner.
><snip>
Although we've discussed the subject in the long past here,
this really has very little to do with the current thread
started by Craig. Craig was interested in "sample code in
Asm."
While I do think there are a number of related topics to the
question of sample assembly code (for example, which
assembler tool is in use so that the appropriate sample
source can be suggested -- gas assembler is quite different
from IAR, as we both know), I don't for a second imagine that
his question should instill a response saying that gcc
generates better code than "most assembler programers," which
seems more about uncovering some old sore point than anything
else. (Besides, there are a few folks here who are definitely
better than "most assembler programmers.")
</pre>
</blockquote>
<pre wrap="">When I see someone looking for help with assembly, I think it is
perfectly reasonable to point out the options with compilers. You have
to ask yourself /why/ that person is asking about assembly, and think
can you be more helpful by pointing them in a different direction.
Let's consider the reasons why a person might want to start working on
an msp430 in assembly. (Note that I don't know to what extent the OP is
/starting/ with assembly, but the discussion on choice of assembler
tools suggest he might be.)
1. They want to learn about the cpu, and see exactly how it works.
That's great!
2. It's for fun - also great.
3. They want to do something that cannot be done using C. There are
/very/ few cases where this is realistic - in most cases, the person is
mistaken.
4. They want to write the most efficient possible code, and think that
means assembly. In most cases, they are mistaken.
5. Assembly is all they know, and they don't want to learn C. If this
is for a hobby project, then that's fair enough - but if it is in a
professional context, then they are not doing a good job. Writing
maintainable code in a language that many people understand, and using
tools that give much greater developer efficiency, means C trumps
assembly in almost all cases for professional development. There are
always exceptions, of course, but exceptions are rare.
6. They think C compilers for small microcontrollers are inefficient or
limited. That may be true on some cores, but not on the msp430.
7. They think that C compilers are expensive. Again, that is true for
some cores, and it used to be true for the msp430, but it is not true now.
My experience is that most people who choose to work in assembler these
days, do so for invalid or inappropriate reasons. This certainly does
not apply to /all/ people who pick assembler - but it applies to many.
So in the interest of helping the original poster, it makes sense to
bring up C as an alternative. It would be unreasonable to try to push
it on him if he has good reason to use assembler, but it is a good think
to suggest it.
So when the OP was asking about different sized multiply and divide
routines in msp430 assembly, my first thought is /why/ bother? Write "x
= y * z;" and "x = y / z;" and let the compiler generate the code. It
will make code that is at least as small and efficient as you can do by
hand - and if it can figure out some of the values at compile time, it
will do far better than the assembly programmer. And it will do so as
fast as you can type a couple of lines of code, and will do so correctly
- no need to search for sample code, figure out how to integrate it,
worry about possible mismatches of register uses, and so on.
David
</pre>
</blockquote>
</blockquote>
<pre wrap="">
------------------------------------
Posted by: David Brown <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>
------------------------------------
To unsubscribe from the msp430 group, send an email to:
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
------------------------------------
Yahoo Groups Links
<*> To visit your group on the web, go to:
<a class="moz-txt-link-freetext" href="http://groups.yahoo.com/group/msp430/">http://groups.yahoo.com/group/msp430/</a>
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
<a class="moz-txt-link-freetext" href="http://groups.yahoo.com/group/msp430/join">http://groups.yahoo.com/group/msp430/join</a>
(Yahoo! ID required)
<*> To change settings via email:
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<*> To unsubscribe from this group, send an email to:
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<*> Your use of Yahoo Groups is subject to:
<a class="moz-txt-link-freetext" href="https://info.yahoo.com/legal/us/yahoo/utos/terms/">https://info.yahoo.com/legal/us/yahoo/utos/terms/</a>
</pre>
</blockquote>
<br>
<!-- |**|begin egp html banner|**| -->
<br>
<br>
<!-- |**|end egp html banner|**| -->
<div width="1" style="color: white; clear: both;"/>__._,_.___</div>
<div id="fromDMARC" style="clear:both; margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: Onestone <[email protected]> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- |**|begin egp html banner|**| -->
<br><br>
<tt>
To unsubscribe from the msp430 group, send an email to:<BR>
[email protected]<BR>
<BR>
</tt>
<br><br>
<!-- |**|end egp html banner|**| -->
<!-- |**|begin egp html banner|**| -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=2342629/grpspId=1705005378/msgId=52502/stime=1452693341" width="1" height="1"> <br>
<!-- |**|end egp html banner|**| -->
<!-- |**|begin egp html banner|**| -->
<br>
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">
<span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/msp430/info;_ylc=X3oDMTJlMGNxcjEzBF9TAzk3MzU5NzE0BGdycElkAzIzNDI2MjkEZ3Jwc3BJZAMxNzA1MDA1Mzc4BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQ1MjY5MzM0MQ--" style="text-decoration: none;">Visit Your Group</a></span>
<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
<li style="border-right: 1px solid #000; font-weight: 700; display: inline; padding: 0 5px; margin-left: 0;">
<span class="cat"><a href="https://groups.yahoo.com/neo/groups/msp430/members/all;_ylc=X3oDMTJmcHJjbWJlBF9TAzk3MzU5NzE0BGdycElkAzIzNDI2MjkEZ3Jwc3BJZAMxNzA1MDA1Mzc4BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0NTI2OTMzNDE-" style="text-decoration: none;">New Members</a></span>
<span class="ct" style="color: #ff7900;">1</span>
</li>
</ul>
</div>
<div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;">
<a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJkcWY2MW1lBF9TAzk3NDc2NTkwBGdycElkAzIzNDI2MjkEZ3Jwc3BJZAMxNzA1MDA1Mzc4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDUyNjkzMzQx" style="float: left;"><img src="http://l.yimg.com/ru/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a>
<div style="color: #747575; float: right;"> • <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> • <a href="mailto:[email protected]?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> • <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div>
</div>
<!-- |**|end egp html banner|**| -->
</div> <!-- ygrp-msg -->
<br>
<!-- |**|end egp html banner|**| -->
<div style="color: white; clear: both;"/>__,_._,___</div>
</body>
</html>
--------------040709040705090701020505--