| Newsgroups |
gmane.comp.hardware.texas-instruments.msp430.discuss |
| Message-ID |
<[email protected]> |
--------------000604080306080409010001
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi David, I've ridden that old saw horse so many times! Frankly I
understand why a lot of people would use and prefer C, but personally I
started out coding straight into binary, so have always been more than
comfortable with assembler. I find the instruction set is more like a
language that is easy to learn and understand than C or especially C++
with all it's crytpic forms. Not that I don't understand C or C++, and
I've written a lot in C, but disliked C++ immensely. I know it's strange
to dislike what is simply a tool, but then I prefer ring spanners to
open ended spanners, am useless with routers, but great with hammers.
Yes it takes a a lot more instructions to, say, display a short text,
but a lot of other things are easier, and I have a vast library of plug
in functions for different displays, and most things I might want to
hang off a micro.
I think the worst tool I ever bought was an ICE for the Motorola G5
micro or the PH8, I can't remember which now, as I used both at
different times, but anyway whichever part I bought it for the flat
ribbon cable was wired for a similar but slightly different type, and as
soon as I plugged the cable into the ICE it turned into a $10,000 space
heater. Killed that contract totally since it took me months to get Moto
to accept that their tools were faulty. It was the last time I used a
moto processor. I still even have some windowed UVEPROM parts around for
both parts, along with E9's, windowed E9's etc.
Cheers
Al
On 12/01/2016 10:47 PM, David Brown [email protected] [msp430] wrote:
> On 12/01/16 11:49, Onestone [email protected] [msp430] wrote:
>>
>>
>> Of course I disagree regarding many things , but won't get into the old
>> argument of C vs assembler. i write in assembler, I have done for tens
>> of years. i've also written in most other languages at various times,
>> but generally come back to assembler for embedded systems for many reasons.
> That's fair enough. I'm sure we could have a lively debate about the
> pros and cons of assembly and C, and where one is more appropriate than
> the other. But I think that would be for another day, in another
> thread. If you feel like it, start the thread and I'll join in.
>
>> regarding IAR's tools, I think they are excellent for a free tool that
>> is used for assembler. I haven't tried them on C for the MSP430 since
>> probably 1999. I'm not looking for anything fancy in an assembler, one
>> reason I like assembler is that it's clean, simple and efficient. The
>> debugger isn't bad, but here I compare it to stuff like the old HC11 ICE
>> tools, or the ADSP ICE tools, thousands of dollars and often barely
>> functional. Then, I'm probably strange. I once used a lot of PIC micros
>> and actually liked MPLAB. I have no doubt that modern compilers are
>> quite efficient, but I would still rather trust my own coding abilities
>> than rely on more layer(s) of potential bugs and/or inefficiency.
> I can certainly agree that there are worse tools than IAR's - and AD's
> would be high amongst them, as would TI's older tools. Sometimes I
> think there is a clear negative correlation between tool price and tool
> quality.
>
>> Finally I was not always a big fan of IAR, in fact for a long time I
>> used to give them hell in this group, but I think they finally got a lot
>> of things squared away, and deserve a little praise for still supporting
>> a free tool that must have a negative return for them. I dislike CCS
>> intensely (or did last time I tried it) and see no point paying a chunk
>> of money for an assembler when I can get one for free.
>>
>> Al
> As I noted a few times, it is a long time since I used IAR's tools - and
> if you say they have improved, then I'll take your word for it. On the
> same note, TI's tools have improved greatly (especially their newer
> eclipse tools) and are free, at least when using gcc rather than their
> own propriety (and much weaker) toolchain.
>
> mvh.,
>
> David
>
>
>> On 12/01/2016 7:34 PM, David Brown [email protected] [msp430] wrote:
>>> It's a long time since I have posted in this group, and I know I am at
>>> odds with other opinions here - but it is perhaps good to have a balance
>>> to the endless praise of IAR.
>>>
>>> When I started using msp430's, IAR was the only option. Other tool
>>> vendors (free, cheap or expense) had to fight with TI to get any
>>> information or support. So like everyone else who didn't want to pay
>>> huge prices for IAR's C compiler, I used IAR's assembler and IDE.
>>>
>>> It is perhaps a decade since I have used this combination, so things may
>>> have changed - but I doubt if they have changed significantly for a free
>>> tool from IAR that is little used, and where the market for the paid
>>> version (their C compiler) of this target is very much on the decline.
>>>
>>>
>>> The assembler is okay. It is not "excellent", it's just okay. It is
>>> fairly simple, and does not have particularly advanced features - it is
>>> simply a straightforward assembler. Often that is all you want from an
>>> assembler - it was certainly enough for me to write my code. But it is
>>> nothing special, and has no outstanding or exciting additional features.
>>> I have used worse, and used better, but usually assembly code has a
>>> simple structure and the IAR assembler handled that fine.
>>>
>>> I did not like the IDE (note again that it is something around a decade
>>> since I used it - the IDE may have changed since then). I used my own
>>> makefiles, and a different editor. I used the debugger sometimes, but
>>> always felt it was awkward and that assembly was very much a
>>> second-class citizen to the debugger. In fact, I felt that some aspects
>>> of the debugger (especially trying to view registers and expressions)
>>> were intentionally bad - almost to the point of trying to persuade
>>> people to buy the C compiler just to get decent debugging. In practice,
>>> most of my work was done without using the IDE or debugger at all.
>>>
>>>
>>> When the early gcc port for msp430 stabilised, I moved to using it, and
>>> have used a few generations of that compiler over the years. I used
>>> eclipse as the editor, and gdb (with eclipse's gui) for debugging - it
>>> is a joy in comparison to IAR's tools. The compiler has way more
>>> features, generates good code, and you don't have to fight anyone (IAR,
>>> company purchasing, etc.) about licenses, upgrades, etc. - install the
>>> tools on as many systems as you want, regardless of OS, archive them
>>> (when you have to resurrect a 10-year old project and re-compile with
>>> the original tools, you will seriously regret ever buying locked
>>> commercial tools).
>>>
>>> For doing a new msp430 project (I rarely use them now), there would be
>>> no doubt in my mind as to the tools. It would be TI's eclipse IDE,
>>> combined with the new gcc port that is fully supported by TI and Red
>>> Hat. I can't imagine why someone would want to work on an assembly-only
>>> project these days, except perhaps for fun. 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. There can be occasions when a particular small
>>> snippet is best written in assembly - the inline assembler is usually
>>> the best answer, but of course it is possible to write external assembly
>>> functions if you really must.
>>>
>>>
>>> David
>>>
>>>
>>>
>>> On 12/01/16 03:24, 'Peter Grey' [email protected] [msp430] wrote:
>>>>
>>>>
>>>> Hi Jon, Al
>>>>
>>>> I may be a little off topic here. Like yourselves I have used IAR and
>>>> assembler for many years. I like the thought of using both assembler and C
>>>> so I can use existing software and also use some of the advantages of C. I
>>>> started to have a look at CCS6 as I thought I would have to buy a copy of
>>>> IAR for the use of C. I only see one document on the TI website that refers
>>>> to mixing C and assembler and it is quite old. Do you have any references to
>>>> any other documentation on mixing the 2 and using IAR?
>>>>
>>>> Thanks
>>>>
>>>> Peter
>>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:[email protected]]
>>>> Sent: Tuesday, 12 January 2016 5:29 AM
>>>> To: MSP430 List
>>>> Subject: Re: [msp430] Asm source code page?
>>>>
>>>> On Mon, 11 Jan 2016 19:33:47 +1030, Al wrote:
>>>>
>>>>> I Totally agree with Jon.
>>>> :)
>>>>
>>>>> IAR's assembler is excellent, does everything I want, is unlimited, is
>>>>> free, and since I don't use any libraries from third parties there are
>>>>> no royalty issues.
>>>> That assembler and linker tool-pair is good. I've used a LOT of assemblers
>>>> in my life and have written a few, as well.
>>>> This one from IAR is about as good as assemblers for micros usually get. The
>>>> abstract segmentation model is great. The macro facility could be better,
>>>> but I consider it "good enough for most things." (I can also use M4 or some
>>>> other tool on the source where I feel there are some limitations.
>>>> Such tools won't be fluent with the semantics but they may be fruitfully
>>>> used. I just haven't felt enough of a need yet, since IAR's capabilities are
>>>> good enough for now.)
>>>>
>>>>> The IDE is straightforward, and quite good.
>>>> It's remarkably easy to get started using and remains very capable as you
>>>> advance further over time. It just wears well over time. They've done a very
>>>> good job on its design. And, fortunately for some of us, have decided to
>>>> offer a fully functional toolset for assembler programmers at no charge.
>>>> I'm in debt to them for this fact.
>>>>
>>>> (I'm also in debt for another reason -- I've never needed more than an
>>>> additional 4k of C generated code for an MSP430 project, so the KickStart
>>>> has been "good enough" for all my project uses so far.)
>>>>
>>>>> It used to do some strange things, but they seem to have been cleaned
>>>>> up over the years, either that or I subconsciously avoid them!
>>>> I haven't found anything that was "strange." I have found things that took a
>>>> moment to consider before I fully understood them. But once I gathered up
>>>> the conceptual model they made good sense to me.
>>>>
>>>> The only "strange" things are things I've done myself with their toolset.
>>>> For example, I needed a way to find the largest common divisor for a pair of
>>>> configuration parameters to help me set up a clocking system that would
>>>> serve two purposes at once with only integer multiplier differences in their
>>>> operation. I hacked up a MACRO tool to do exactly that, too. Worked
>>>> perfectly. Now, someone looking at it would see "strange" there, I suppose.
>>>> But that's my fault, not IARs!
>>>>
>>>>> I find the syntax is more in line with the vast majority of assemblers
>>>>> I've used over the last too many years, no strange things.
>>>> That's pretty much my feeling, too.
>>>>
>>>>> Their header files for each processor are also quite good, but large
>>>>> because they are general use for C, c++ and assembler, so I personally
>>>>> always clean out all the stuff I am unlikely to use, add some stuff
>>>>> that I personally like to use, and rename the file, so I have an
>>>>> original version incase I ever decide to mix assembly and C for example.
>>>> Hmm. So far, I've not bothered with that. In part, perhaps, because I
>>>> haven't done as much as you have and haven't reached a situation where the
>>>> trouble would have been worth it. In part, perhaps, because I tend not to
>>>> change standard facilities unless I can clearly justify the change. I'd
>>>> rather use an additional file I create and add it to the inclusion list. But
>>>> again, you probably have a wider array of usages than I do and I may very
>>>> well have made similar choices if I had faced similar situations, too.
>>>>
>>>> Jon
>>>>
>>>>> Cheers
>>>>>
>>>>> Al
>>>>>
>>>>> On 11/01/2016 6:15 AM, Jon Kirwan [email protected] [msp430] wrote:
>>>>>> On Sat, 9 Jan 2016 22:47:23 -0800, Craig Carmichael wrote:
>>>>>>
>>>>>>> ... ideas for web pages of sample code in Asm?
>>>>>> Just as an additional note...
>>>>>>
>>>>>> If you are interested in writing assembly-only projects for the
>>>>>> MSP430 and MSP430X families, I'd recommend using IAR's Kickstart
>>>>>> tools. Their assembler is quite general-purpose and does NOT have any
>>>>>> code size limitations at all. See:
>>>>>>
>>>>>> http://supp.iar.com/FilesPublic/UPDINFO/004578/infocenter/product_pac
>>>>>> kages.html
>>>>>>
>>>>>> where the 2nd bullet under the Kickstart heading says, "The IAR
>>>>>> Assembler delivered is the full version without any restrictions" and
>>>>>> the 3rd bullet expands, "The IAR XLINK Linker will link ... an
>>>>>> unlimited amount of code originating from assembly code." (The 4th
>>>>>> bullet adds, "The IAR KickStart C-SPY Simulator ... is unlimited in
>>>>>> the amount of assembly code read.") This pretty much means you get an
>>>>>> excellent assembler/linker toolset, plus a very nice IDE and debugger
>>>>>> for coding purposes and ZERO cost to you. I've used IAR for assembly
>>>>>> coding development and I really like the tools a lot, as they present
>>>>>> a very clean, orthogonal design with all the features you need. Other
>>>>>> assembler tools I've used, off and on, tend to have odd "limitations"
>>>>>> which are frustrating at times. IAR's tools "just work well." Never
>>>>>> wished for a feature that I couldn't already find in IAR's assembler
>>>>>> + linker toolset.
>>>>>>
>>>>>> You can also explore C/C++ with IAR's tools, but the free Kickstart
>>>>>> version does limit your final application size.
>>>>>> IAR asks a "fairly high price" for unlimited C/C++ code sizes. If you
>>>>>> do plan on mixing C and assembly and plan on developing larger
>>>>>> applications then you should consider other tools for a cost/benefit
>>>>>> analysis. A starting point might be TI's page here:
>>>>>>
>>>>>> http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/tools_so
>>>>>> ftware.page
>>>>>>
>>>>>> However, be aware that this page in no way provides all your options.
>>>>>> Rowley and ImageCraft are just two such examples that you don't see
>>>>>> there:
>>>>>>
>>>>>> http://www.rowley.co.uk/msp430/
>>>>>> https://www.imagecraft.com/devtools_MSP430.html
>>>>>>
>>>>>> I'm sure there are others, as well, that aren't included in the TI
>>>>>> page.
>>>>>>
>>>>>> If you are doing this all as a hobby, then you are free to make your
>>>>>> own choices about assembly-only or mixed coding styles. Whatever
>>>>>> makes you happy works just fine.
>>>>>>
>>>>>> If you have your own product/product-line in mind, then you need to
>>>>>> be aware of licensing issues (libraries used, as well as compiler
>>>>>> generated output) for the tools you apply. I believe you can use the
>>>>>> IAR assembler/linker toolchain for commercial products without paying
>>>>>> them a fee, so long as you are careful about library use (not using
>>>>>> any library other than public domain would be safer.) It sounds like
>>>>>> you might be in this frame of mind, but it is hard to tell.
>>>>>>
>>>>>> For professional contract work, you will want to be able to support
>>>>>> mixed assembly and C/C++. Clients deserve to have the widest range of
>>>>>> options available for their project development so that the overall
>>>>>> development process can be optimized for them, weighing all
>>>>>> conditions appropriate to their circumstances. You should then
>>>>>> carefully study the various commercial options. But you should ALSO
>>>>>> contact the vendors, too, and speak or write to a human there and get
>>>>>> a feel for what contact and support will be like after you buy their
>>>>>> tools. Most MSP430 vendors should be pretty good, I think. But it
>>>>>> helps to make contact and see how things play out before making a
>>>>>> final decision and spending your money.
>>>>>>
>>>>>> As an employee in an organization with more than one programmer,
>>>>>> which does NOT sound like your situation, you do what has been
>>>>>> established by careful consideration of your team members. If you are
>>>>>> a sole employee, then I suppose you get to make your own choices but
>>>>>> you need to make them well for those depending on you.
>>>>>>
>>>>>> Jon
>
>
> ------------------------------------
> Posted by: David Brown <[email protected]>
> ------------------------------------
>
> To unsubscribe from the msp430 group, send an email to:
> [email protected]
>
>
> ------------------------------------
>
> Yahoo Groups Links
>
>
>
>
--------------000604080306080409010001
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">Hi David, I've ridden that old saw horse so many
times! Frankly I understand why a lot of people would use and
prefer C, but personally I started out coding straight into
binary, so have always been more than comfortable with assembler.
I find the instruction set is more like a language that is easy to
learn and understand than C or especially C++ with all it's
crytpic forms. Not that I don't understand C or C++, and I've
written a lot in C, but disliked C++ immensely. I know it's
strange to dislike what is simply a tool, but then I prefer ring
spanners to open ended spanners, am useless with routers, but
great with hammers. Yes it takes a a lot more instructions to,
say, display a short text, but a lot of other things are easier,
and I have a vast library of plug in functions for different
displays, and most things I might want to hang off a micro.<br>
<br>
I think the worst tool I ever bought was an ICE for the Motorola
G5 micro or the PH8, I can't remember which now, as I used both at
different times, but anyway whichever part I bought it for the
flat ribbon cable was wired for a similar but slightly different
type, and as soon as I plugged the cable into the ICE it turned
into a $10,000 space heater. Killed that contract totally since it
took me months to get Moto to accept that their tools were faulty.
It was the last time I used a moto processor. I still even have
some windowed UVEPROM parts around for both parts, along with
E9's, windowed E9's etc.<br>
<br>
Cheers<br>
<br>
Al<br>
</font><br>
<div class="moz-cite-prefix">On 12/01/2016 10:47 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 12/01/16 11:49, Onestone <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Of course I disagree regarding many things , but won't get into the old
argument of C vs assembler. i write in assembler, I have done for tens
of years. i've also written in most other languages at various times,
but generally come back to assembler for embedded systems for many reasons.
</pre>
</blockquote>
<pre wrap="">
That's fair enough. I'm sure we could have a lively debate about the
pros and cons of assembly and C, and where one is more appropriate than
the other. But I think that would be for another day, in another
thread. If you feel like it, start the thread and I'll join in.
</pre>
<blockquote type="cite">
<pre wrap="">
regarding IAR's tools, I think they are excellent for a free tool that
is used for assembler. I haven't tried them on C for the MSP430 since
probably 1999. I'm not looking for anything fancy in an assembler, one
reason I like assembler is that it's clean, simple and efficient. The
debugger isn't bad, but here I compare it to stuff like the old HC11 ICE
tools, or the ADSP ICE tools, thousands of dollars and often barely
functional. Then, I'm probably strange. I once used a lot of PIC micros
and actually liked MPLAB. I have no doubt that modern compilers are
quite efficient, but I would still rather trust my own coding abilities
than rely on more layer(s) of potential bugs and/or inefficiency.
</pre>
</blockquote>
<pre wrap="">
I can certainly agree that there are worse tools than IAR's - and AD's
would be high amongst them, as would TI's older tools. Sometimes I
think there is a clear negative correlation between tool price and tool
quality.
</pre>
<blockquote type="cite">
<pre wrap="">
Finally I was not always a big fan of IAR, in fact for a long time I
used to give them hell in this group, but I think they finally got a lot
of things squared away, and deserve a little praise for still supporting
a free tool that must have a negative return for them. I dislike CCS
intensely (or did last time I tried it) and see no point paying a chunk
of money for an assembler when I can get one for free.
Al
</pre>
</blockquote>
<pre wrap="">
As I noted a few times, it is a long time since I used IAR's tools - and
if you say they have improved, then I'll take your word for it. On the
same note, TI's tools have improved greatly (especially their newer
eclipse tools) and are free, at least when using gcc rather than their
own propriety (and much weaker) toolchain.
mvh.,
David
</pre>
<blockquote type="cite">
<pre wrap="">
On 12/01/2016 7:34 PM, David Brown <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:
</pre>
<blockquote type="cite">
<pre wrap="">It's a long time since I have posted in this group, and I know I am at
odds with other opinions here - but it is perhaps good to have a balance
to the endless praise of IAR.
When I started using msp430's, IAR was the only option. Other tool
vendors (free, cheap or expense) had to fight with TI to get any
information or support. So like everyone else who didn't want to pay
huge prices for IAR's C compiler, I used IAR's assembler and IDE.
It is perhaps a decade since I have used this combination, so things may
have changed - but I doubt if they have changed significantly for a free
tool from IAR that is little used, and where the market for the paid
version (their C compiler) of this target is very much on the decline.
The assembler is okay. It is not "excellent", it's just okay. It is
fairly simple, and does not have particularly advanced features - it is
simply a straightforward assembler. Often that is all you want from an
assembler - it was certainly enough for me to write my code. But it is
nothing special, and has no outstanding or exciting additional features.
I have used worse, and used better, but usually assembly code has a
simple structure and the IAR assembler handled that fine.
I did not like the IDE (note again that it is something around a decade
since I used it - the IDE may have changed since then). I used my own
makefiles, and a different editor. I used the debugger sometimes, but
always felt it was awkward and that assembly was very much a
second-class citizen to the debugger. In fact, I felt that some aspects
of the debugger (especially trying to view registers and expressions)
were intentionally bad - almost to the point of trying to persuade
people to buy the C compiler just to get decent debugging. In practice,
most of my work was done without using the IDE or debugger at all.
When the early gcc port for msp430 stabilised, I moved to using it, and
have used a few generations of that compiler over the years. I used
eclipse as the editor, and gdb (with eclipse's gui) for debugging - it
is a joy in comparison to IAR's tools. The compiler has way more
features, generates good code, and you don't have to fight anyone (IAR,
company purchasing, etc.) about licenses, upgrades, etc. - install the
tools on as many systems as you want, regardless of OS, archive them
(when you have to resurrect a 10-year old project and re-compile with
the original tools, you will seriously regret ever buying locked
commercial tools).
For doing a new msp430 project (I rarely use them now), there would be
no doubt in my mind as to the tools. It would be TI's eclipse IDE,
combined with the new gcc port that is fully supported by TI and Red
Hat. I can't imagine why someone would want to work on an assembly-only
project these days, except perhaps for fun. 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. There can be occasions when a particular small
snippet is best written in assembly - the inline assembler is usually
the best answer, but of course it is possible to write external assembly
functions if you really must.
David
On 12/01/16 03:24, 'Peter Grey' <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hi Jon, Al
I may be a little off topic here. Like yourselves I have used IAR and
assembler for many years. I like the thought of using both assembler and C
so I can use existing software and also use some of the advantages of C. I
started to have a look at CCS6 as I thought I would have to buy a copy of
IAR for the use of C. I only see one document on the TI website that refers
to mixing C and assembler and it is quite old. Do you have any references to
any other documentation on mixing the 2 and using IAR?
Thanks
Peter
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>]
Sent: Tuesday, 12 January 2016 5:29 AM
To: MSP430 List
Subject: Re: [msp430] Asm source code page?
On Mon, 11 Jan 2016 19:33:47 +1030, Al wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I Totally agree with Jon.
</pre>
</blockquote>
<pre wrap="">:)
</pre>
<blockquote type="cite">
<pre wrap="">IAR's assembler is excellent, does everything I want, is unlimited, is
free, and since I don't use any libraries from third parties there are
no royalty issues.
</pre>
</blockquote>
<pre wrap="">That assembler and linker tool-pair is good. I've used a LOT of assemblers
in my life and have written a few, as well.
This one from IAR is about as good as assemblers for micros usually get. The
abstract segmentation model is great. The macro facility could be better,
but I consider it "good enough for most things." (I can also use M4 or some
other tool on the source where I feel there are some limitations.
Such tools won't be fluent with the semantics but they may be fruitfully
used. I just haven't felt enough of a need yet, since IAR's capabilities are
good enough for now.)
</pre>
<blockquote type="cite">
<pre wrap="">The IDE is straightforward, and quite good.
</pre>
</blockquote>
<pre wrap="">It's remarkably easy to get started using and remains very capable as you
advance further over time. It just wears well over time. They've done a very
good job on its design. And, fortunately for some of us, have decided to
offer a fully functional toolset for assembler programmers at no charge.
I'm in debt to them for this fact.
(I'm also in debt for another reason -- I've never needed more than an
additional 4k of C generated code for an MSP430 project, so the KickStart
has been "good enough" for all my project uses so far.)
</pre>
<blockquote type="cite">
<pre wrap="">It used to do some strange things, but they seem to have been cleaned
up over the years, either that or I subconsciously avoid them!
</pre>
</blockquote>
<pre wrap="">I haven't found anything that was "strange." I have found things that took a
moment to consider before I fully understood them. But once I gathered up
the conceptual model they made good sense to me.
The only "strange" things are things I've done myself with their toolset.
For example, I needed a way to find the largest common divisor for a pair of
configuration parameters to help me set up a clocking system that would
serve two purposes at once with only integer multiplier differences in their
operation. I hacked up a MACRO tool to do exactly that, too. Worked
perfectly. Now, someone looking at it would see "strange" there, I suppose.
But that's my fault, not IARs!
</pre>
<blockquote type="cite">
<pre wrap="">I find the syntax is more in line with the vast majority of assemblers
I've used over the last too many years, no strange things.
</pre>
</blockquote>
<pre wrap="">That's pretty much my feeling, too.
</pre>
<blockquote type="cite">
<pre wrap="">Their header files for each processor are also quite good, but large
because they are general use for C, c++ and assembler, so I personally
always clean out all the stuff I am unlikely to use, add some stuff
that I personally like to use, and rename the file, so I have an
original version incase I ever decide to mix assembly and C for example.
</pre>
</blockquote>
<pre wrap="">Hmm. So far, I've not bothered with that. In part, perhaps, because I
haven't done as much as you have and haven't reached a situation where the
trouble would have been worth it. In part, perhaps, because I tend not to
change standard facilities unless I can clearly justify the change. I'd
rather use an additional file I create and add it to the inclusion list. But
again, you probably have a wider array of usages than I do and I may very
well have made similar choices if I had faced similar situations, too.
Jon
</pre>
<blockquote type="cite">
<pre wrap="">Cheers
Al
On 11/01/2016 6:15 AM, Jon Kirwan <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> [msp430] wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Sat, 9 Jan 2016 22:47:23 -0800, Craig Carmichael wrote:
</pre>
<blockquote type="cite">
<pre wrap="">... ideas for web pages of sample code in Asm?
</pre>
</blockquote>
<pre wrap="">Just as an additional note...
If you are interested in writing assembly-only projects for the
MSP430 and MSP430X families, I'd recommend using IAR's Kickstart
tools. Their assembler is quite general-purpose and does NOT have any
code size limitations at all. See:
<a class="moz-txt-link-freetext" href="http://supp.iar.com/FilesPublic/UPDINFO/004578/infocenter/product_pac">http://supp.iar.com/FilesPublic/UPDINFO/004578/infocenter/product_pac</a>
kages.html
where the 2nd bullet under the Kickstart heading says, "The IAR
Assembler delivered is the full version without any restrictions" and
the 3rd bullet expands, "The IAR XLINK Linker will link ... an
unlimited amount of code originating from assembly code." (The 4th
bullet adds, "The IAR KickStart C-SPY Simulator ... is unlimited in
the amount of assembly code read.") This pretty much means you get an
excellent assembler/linker toolset, plus a very nice IDE and debugger
for coding purposes and ZERO cost to you. I've used IAR for assembly
coding development and I really like the tools a lot, as they present
a very clean, orthogonal design with all the features you need. Other
assembler tools I've used, off and on, tend to have odd "limitations"
which are frustrating at times. IAR's tools "just work well." Never
wished for a feature that I couldn't already find in IAR's assembler
+ linker toolset.
You can also explore C/C++ with IAR's tools, but the free Kickstart
version does limit your final application size.
IAR asks a "fairly high price" for unlimited C/C++ code sizes. If you
do plan on mixing C and assembly and plan on developing larger
applications then you should consider other tools for a cost/benefit
analysis. A starting point might be TI's page here:
<a class="moz-txt-link-freetext" href="http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/tools_so">http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/tools_so</a>
ftware.page
However, be aware that this page in no way provides all your options.
Rowley and ImageCraft are just two such examples that you don't see
there:
<a class="moz-txt-link-freetext" href="http://www.rowley.co.uk/msp430/">http://www.rowley.co.uk/msp430/</a>
<a class="moz-txt-link-freetext" href="https://www.imagecraft.com/devtools_MSP430.html">https://www.imagecraft.com/devtools_MSP430.html</a>
I'm sure there are others, as well, that aren't included in the TI
page.
If you are doing this all as a hobby, then you are free to make your
own choices about assembly-only or mixed coding styles. Whatever
makes you happy works just fine.
If you have your own product/product-line in mind, then you need to
be aware of licensing issues (libraries used, as well as compiler
generated output) for the tools you apply. I believe you can use the
IAR assembler/linker toolchain for commercial products without paying
them a fee, so long as you are careful about library use (not using
any library other than public domain would be safer.) It sounds like
you might be in this frame of mind, but it is hard to tell.
For professional contract work, you will want to be able to support
mixed assembly and C/C++. Clients deserve to have the widest range of
options available for their project development so that the overall
development process can be optimized for them, weighing all
conditions appropriate to their circumstances. You should then
carefully study the various commercial options. But you should ALSO
contact the vendors, too, and speak or write to a human there and get
a feel for what contact and support will be like after you buy their
tools. Most MSP430 vendors should be pretty good, I think. But it
helps to make contact and see how things play out before making a
final decision and spending your money.
As an employee in an organization with more than one programmer,
which does NOT sound like your situation, you do what has been
established by careful consideration of your team members. If you are
a sole employee, then I suppose you get to make your own choices but
you need to make them well for those depending on you.
Jon
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</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=52493/stime=1452606320" 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=X3oDMTJlczlybWVwBF9TAzk3MzU5NzE0BGdycElkAzIzNDI2MjkEZ3Jwc3BJZAMxNzA1MDA1Mzc4BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQ1MjYwNjMyMA--" 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=X3oDMTJmMmMzYXRrBF9TAzk3MzU5NzE0BGdycElkAzIzNDI2MjkEZ3Jwc3BJZAMxNzA1MDA1Mzc4BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0NTI2MDYzMjA-" 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=X3oDMTJkYjJzcGtkBF9TAzk3NDc2NTkwBGdycElkAzIzNDI2MjkEZ3Jwc3BJZAMxNzA1MDA1Mzc4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDUyNjA2MzIw" 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>
--------------000604080306080409010001--