On 12/01/16 11:49, Onestone o...@bigpond.net.au [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 d...@westcontrol.com [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' m...@ozemail.com.au [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: m... [mailto:m...]
>>> 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 j...@infinitefactors.org [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




Start a New Thread

Whoops, I should have written TimerAx_0 and then TimerAx_(1-4)

Al

On 12/01/2016 9:26 PM, Onestone o...@bigpond.net.au [msp430] wrote:
> Depending on the micro TIMER A has between 2 and 5 channels and the
> following interrupts available:_
>
> overflow interrupt
> TimerA0 interrupt
> Generic interrupt for remaining 1-4 channels
>
> Interrupt addresses may vary slightly between micros
>
> Al
>
> On 12/01/2016 8:08 PM, Craig Carmichael c...@saers.com [msp430] wrote:
>> Wow, Thanks for all the replies!
>>
>> I ended up with NakenAsm because it was the first one I tried that
>> worked for me on Ubuntu. Just run from a terminal.
>>
>> Back in the 'old days' I wrote two structured assemblers myself, for
>> 6809 and 680x0. Among other features, branches could be structured to
>> eliminate most labels, and you could group instructions on a line
>> (separated by ";") to improve readability. Quick example, self
>> explanatory I hope:
>>
>> test D1; SkipCS |BCS to end brace (BCS on 68K = JCS on MSP)
>> {
>> whatever
>> whatever more
>> dec D0; loopNE |BNE to start brace
>> }
>>
>> There were some other features too. Eg:
>>
>> move.w Table(A6),A0
>>
>> could also be written as:
>>
>> A0.w = Table(A6)
>>
>> I have too many things to do to duplicate this work for MSP, but it
>> made writing in Asm far easier.
>>
>> ---
>>
>> Originally the Easter Egg I was looking for was TimerA examples to
>> generate 3 different frequencies of varying pulse widths, reloading
>> the next ON or OFF time period for each in an ISR. The TAIV
>> "interrupt vector" register seemed to only have TACCR1 and TACCR2 but
>> not TACCR0. Now I think I see how that works - there seems to be a
>> whole separate interrupt vector for TACCR0, at FFF2 (TA0) or FFFA
>> (TA1) instead of FFF0 or FFF8 for all other timer interrupts.
>>
>> So theoretically now all I really need is to find the time to write
>> several routines and hook up the hardware! It would still be nice to
>> find that page, but you've given me some starting points, thanks.
>>
>> Craig
>>
>> ====>>
>>> I have a very old document from 2001 with various notes and examples
>>> in assembler, called APP_14306. there are loads of other app notes
>>> (mostly older) that are in assembler, there are alos lots of files
>>> posted on the yahoo group in assembler. What specifically are you
>>> looking for? To learn assembler, a specific app note etc. I write
>>> almost exclusively in assembler for most micros, including the
>>> MSP430, but that seems to be rare enough for most manuafacturers,
>>> including Ti to have stopped supporting the use of assembler in
>>> their app notes.
>>>
>>> Al
>>>
>>> On 10/01/2016 5:17 PM, Craig Carmichael
>>> c...@saers.com [msp430] wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> In summer 2013 I found a web page full of what I remember as being
>>>> dozens of MSP430 assembly source code files, probably all open
>>>> source. I believe it was on a TI page. I downloaded and used the
>>>> 16x16->32 bit multiply and 32/16 bit divide routines, and I thought I
>>>> had carefully bookmarked this very special page. Now I can't find the
>>>> bookmark, or the page in hours of searching. Anybody know where it
>>>> is, or have any other ideas for web pages of sample code in Asm?
>>>>
>>>>
>>>> Thanks,
>>>> Craig
>>>> http://www.TurquoiseEnergy.com/
>>>>
>>>>
>>>> http://www.saers.com/recorder/craig/TENewsV2/ - Radiant energy
>>>> project with MSP430G2553, issues #94, #95 (#96 next).
>> ====>>
>> Posted by: Craig Carmichael
>>
>>
>>
>> Yahoo Groups Links Start a New Thread

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 d...@westcontrol.com [msp430] wrote:
> On 12/01/16 11:49, Onestone o...@bigpond.net.au [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 d...@westcontrol.com [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' m...@ozemail.com.au [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: m... [mailto:m...]
>>>> 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 j...@infinitefactors.org [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
>
>
>
> Yahoo Groups Links Start a New Thread

I have to agree with David here... By all means, use IAR, as it's assembler is "better" than the one is CCS (uses a more traditional syntax). But if you have problems with the debugger, don't assume that it's the chips fault, or TI's fault... because the debugger in CCS works MUCH better. And the IDE is better. And the assembler works... you just have to translate everything.

Having worked with PICs for years, I can tell you that the IAR assembly language sucks in comparison. It's "ok"... it "works"... it could be much better.

You can do a LOT with a good macro assembler.
http://techref.massmind.org/techref/new/letter/news0403.htm http://techref.massmind.org/techref/new/letter/news0403.htm
(not for the MSP430, but it's gives a good idea of what you can twist out of a good asm)

---In m..., 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.

(don't you wish more people would snip off long trails of prior emails?) Start a New Thread

On Tue, 12 Jan 2016 10:04:54 +0100, David wrote:

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

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.")

Jon

P.S. I'm currently engaged in writing scalable software under
Windows, where there may be server boards with 4 CPUs, each
with 16 available cores on them (perhaps more, soon.) This
means 64 parallel threads. In this venue, with extremely high
bandwidth and loading, I'm finding the need to use specific
data structures as well as software transactional memory in
order to greatly reduce the need for synchronization
(avoidable serialization is bad) or even low level memory
barriers or acquire/release semantics. The compilers are good
and functional programming approaches really start to blossom
well here. Functional programming, with appropriate data
structure arrangements, really achieves a lot for
applications (without having to delve into assembly.) So this
area probably makes me very much aware of certain areas where
assembly coding for application programmers (as opposed to
assembly coding for operating system programmers) makes less
sense than before. We're talking multi-core and sophisticated
server applications, so the focus has to be elsewhere. But I
still wouldn't go around trying to stimulate yet another
debate about some compiler vs some hypothesized assembler
programmer. The debate is especially pointless as Craig was
asking specifically about sample assembly code, unless your
whole focus in life is about convincing people they should
not be doing what they are already doing.

Posted by: Jon Kirwan




Start a New Thread

Better is subjective, of course, what some like others don't. Find the
tool that works for you, but if you're paying for it that makes it
difficult to analyse the offerings without some kind of free trial.

Craig seemed to be an experienced guy looking for a few pointers I think
that absolute code answers. There is quite a bit of assembler posted on
this group and I'm usually happy to send examples of my code if I'm
asked for a specific solution. Not that I'm claiming anything other than
it works for what I want!

Al

On 13/01/2016 2:54 AM, j...@massmind.org [msp430] wrote:
> I have to agree with David here... By all means, use IAR, as it's
> assembler is "better" than the one is CCS (uses a more traditional
> syntax). But if you have problems with the debugger, don't assume that
> it's the chips fault, or TI's fault... because the debugger in CCS
> works MUCH better. And the IDE is better. And the assembler works...
> you just have to translate everything.
>
> Having worked with PICs for years, I can tell you that the IAR
> assembly language sucks in comparison. It's "ok"... it "works"... it
> could be much better.
>
> You can do a LOT with a good macro assembler.
> http://techref.massmind.org/techref/new/letter/news0403.htm
> (not for the MSP430, but it's gives a good idea of what you can twist
> out of a good asm)
> ---In m..., 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.
>
> (don't you wish more people would snip off long trails of prior emails?)
> Start a New Thread

On 12/01/16 22:28, Jon Kirwan j...@infinitefactors.org [msp430] wrote:
> On Tue, 12 Jan 2016 10:04:54 +0100, David wrote:
>
> >
> >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.
> > 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




Start a New Thread

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.

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. However a good compiler can
make an average C programmer look a lot better than they really are. 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.

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.

Cheers

Al

On 13/01/2016 9:48 AM, David Brown d...@westcontrol.com [msp430] wrote:
> On 12/01/16 22:28, Jon Kirwan j...@infinitefactors.org [msp430] wrote:
>> On Tue, 12 Jan 2016 10:04:54 +0100, David wrote:
>>
>> >
>> >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.
>> >
>>
>> 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
>
>
>
> Yahoo Groups Links Start a New Thread

On Jan 12, 2016 1:05 AM, "David Brown d...@westcontrol.com [msp430]" <
m...> wrote:
>

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

Mythical Man Month addressed this 40 years ago.

>
> David
> On 12/01/16 03:24, 'Peter Grey' m...@ozemail.com.au [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: m... [mailto:m...]
> > 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 j...@infinitefactors.org [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
> > Start a New Thread

Wow, what a discussion I've sparked!

>5. Assembly is all they know, and they don't want to learn C.

Bingo! I learned the bare essentials of assembler taking electronics
(digital specialty) at BCIT in 1974/1975. I started by building
microcomputers, which were hardly available at the time, from the
chips. Never took programming per se, but the computers were only
useful with software, so I developed my 6809 structured assembler and
a crude text editor for my 6809 based computer. And a 4800 baud
cassette interface for data storage - 4 times faster than any
commercial ones and more reliable.

I wrote among other things the first "Paint" program ever sold to the
public, "TV Graphics Editor" (1982) for Radio Shack Color Computer
(MC6809), and the world's first graphic adventure/role playing game,
"Viking Raider" (1984) for the Commodore 64. (Not a single untouched
256 byte block of memory remained, but I got everything in! About 150
screens of RLE map/scenery. Oh yah, the 6502 cross assembler that ran
on the Radio Shack CoCo for that project was another stuctured
assembler I wrote. I recall it only took 5 days to write, but it was
essentially just an adaptation of the 6809 version.)

When I saw "Mac Paint" on the first Macintoshes, I thought they had
copied my "TV Graphics Editor", but there were enough differences
that I cancelled that thought, and I found out later that there was
an even earlier "Paint" program that had circulated in university
circles, on which Mac Paint was based.

When I got into the 68K I started writing AKO really sophisticated
stuff, but I never got it to market.

I dislike C. I have the hubris to think I (and I speak only for
myself) can do anything better and faster in assembler. ...with a
processor having a nice architecture and instruction set. From the
68K stuff on I've always tried to document and comment what I do very
fully. That's what will make the code easier for others to deal with
it later more than what language it's written in. I often find C very
hard to figure out just because it is so often sparcely commented -
also because the source is so often split into several or even many
files, which is of course a reflection of author philosophy or 'C
traditions' more than of the language itself.

I'm not sure why I've typed all this. Now it's past bedtime and I
haven't done the work I meant to!

--Mr. Prejudiced

PS: Hey, who swiped all my indents and spacings? (Rhetorical question) Grr!

>test D1; SkipCS |BCS to end brace (BCS on 68K = JCS on MSP)
>{
>whatever
>whatever more
>dec D0; loopNE |BNE to start brace
>}

Posted by: Craig Carmichael




Start a New Thread