On 07/02/13 17:30, Paul Curtis wrote:
>>> TI let the MSP430 compiler market blossom,
and actively
>>> encouraged independent 3P compilers.
>>
>> That is not quite how I remember things. I am not a compiler
>> developer, so obviously I don't have the "insider" views
like you -
>> but we were
> early
>> users of the msp430, and I have followed mailing lists had contact
>> with compiler developers over the years. And of course I may be
>> misremembering things, or have misunderstood things at the time -
>> so apologies if anyone feels I am being unfair to them.
>>
>> When the msp430 came out, TI's attitude was that there was an
>> msp430 compiler - IAR made it.
>
> This may well have been before the flash variants of the MSP430.
>
>> They had no interest in any other vendors or toolchain developers,
>> whether they were high priced (like IAR), low
> priced
>> (like ImageCraft), or free (mspgcc). TI seemed totally incapable
>> of understanding why msp430 customers might want an alternative to
>> IAR
> tools.
>
> TI had a small set of customers at that point.
>
>> I know that the msp430 gcc developers had enormous trouble trying
>> to get anyone at TI even to acknowledge their existence, never mind
>> give
> them any
>> help or information - and I believe that also applied to other
>> commercial toolchain developers. It took a good while before TI
>> came round to the idea that a choice of development tools was a
>> good idea.
>
> That isn't how it was. RAL were regularly visiting Freising,
meeting
> with TI, and were even invited for a few days at TI's expense to
come
> and see if the proposed MSP430X instruction set would cause great
> problems in the existing tools. This was when TI in Germany was
> driving the MSP430 forward. So, we had a great relationship with TI
> and TI gave us anything we needed thanks to some very, very committed
> individuals within the organization (isn't it always the way?)
Chris
> Speck should have an award for his dedication.
>
> The ATCs were fantastic, from the first few that were attended by
> perhaps 40-50 individuals and organized by committed MSP430ites in
> TI, to the final hurrah in the larger hotels. Walking back to the
> hotel after a great night with the MSP430 folk, after beer and music
> provided by TI employees, with torches aflame and blowing in the dark
> night was fantastic.
>
> However, when things were driven more state-side, things
> deteriorated. :-(
I only started using the msp430 with the early flash versions, but maybe
the problems I had heard about were from earlier times. I don't know
how the timing fits with when the msp430 "moved" from Germany to the
USA
- I did not even know it had roots in Germany. At what point did the
plans for the MSP430X start? I though it was relatively recently -
certainly long after CCS was available.
My information is only second-hand, while you have first-hand experience
from working with TI on compilers, so I happy to learn here.
>
>> I am sure you already know this, but you've got another
challenge
>> coming...
>>
>> TI have engaged Red Hat to produce a gcc toolchain for the msp430.
>
> I don't care one bit about what TI do with MSP430 and GCC. Donning
> the Open Source garb now to get down with the new-age hippies
doesn't
> really do much for me. ;-)
>
>> There has been a working gcc toolchain and library for the msp430
>> for
> many
>> years, and it has always produced excellent code (and being gcc, it
>> has lots of useful features - I much prefer it to Code Composter).
>> But it is a bit rough around the edges, lacks debugger support for
>> the 20-bit devices (though the compiler supports them fine now),
>> and for many
> reasons
>> was never part of the mainline gcc tree - and that means it takes
>> longer time and more work to get the benefits of later gcc
>> versions. Now Red Hat is in the process of completing these missing
>> parts, and presumably also packaging it with an IDE (perhaps CCE).
>
> You know, I really don't give two hoots about TI + GCC + MSP430. It
> is what it is.
>
Well, for your sake I hope it doesn't affect your sales. But for the
sake of users, including me, I am glad that Red Hat is adding polish to
msp430 gcc. It is an excellent compiler - as I said, I much prefer it
to CCS, though I haven't tried your tools for comparison. Certainly if
Red Hat can get the debugger working well with the latest version of the
compiler, I would be very happy. In many ways, my ideal would be the
CCS IDE and debugger but with gcc as the toolchain - I think CCS has got
quite good as an IDE now with a modern version of Eclipse (not everyone
likes Eclipse, of course, but I think recent versions have become a lot
smoother and more usable).
And I don't consider myself a "new-age hippie" for using gcc on a
dozen
target architectures (though I might accept that title as a fan of
command-line gdb). I'm sure most of your ARM toolchain users also view
themselves as professional developers rather than "hippies".
mvh.,
David
What's the best MSP430 Development Enviroment?
Started by ●February 6, 2013
Reply by ●February 7, 20132013-02-07
Reply by ●February 7, 20132013-02-07
On Thu, 7 Feb 2013 19:24:11 -0000, you wrote:
>Jon,
>
>> I've a lot of mixed feelings from this discussion and I can't place them
>> into any kind of final form. Obviously, I'm an end user of compilers, not
>> a vendor. So interests are different, too.
>>
>> The only comment I have is to the above where you pan down parts because
>> of their proprietary nature. Yet the MSP430 itself is proprietary and no
>> one else makes chips based on that core (that I know of.)
>
>It is true nobody else makes it, but competitors to it will arrive with ARM
>at the core. And if I had my time again, I would not do MSP430, I would not
>do AVR, I would not do MAXQ20, and I would not do MAXQ30. We learn from our
>mistakes.
>
>> The MIPS m4k, at least, is an IP that other vendors _might_ select and
>> build, in addition to Microchip. MIPS is in the business of selling that
>> kind of IP, I think. (If not, let me know.)
>
>ARM and Imagination picked over MIPS's bones:
>
><http://www.electronicsweekly.com/blogs/x86-processor-endgame/2012/11/imagin
>ation-arm-buy-mips.html>ARM and Imagination were buddies, possibly less so now.
Very interesting business news I wasn't aware of. It also
mentions the number of chips and the number of licensees.
Thanks!
>> ARM has achieved something with its critical mass starting (memory
>> serving) with the ARM7 that no other IP-only company has achieved. If to
>> be interesting to you, a company has to sport an ARM core, then I suppose
>> that is that. But m4k is a very interesting core and Microchip has good
>> customer support (if not compiler vendor support.)
>
>Whatever MIPS licenses, it's not been successful in licensing to the general
>purpose microcontroller crowd. It might do great in set-top boxes and so
>on, and had a fist at trying to make phones by having official Android
>support (IIRC), but really, where is it in the mainstream media?
I already gathered this much before. I've pretty much ignored
MIPS after the R2000 (when it really was novel and impressive
and remarkable at the time.) It wasn't until Microchip
decided to roll something out (and buy the m14k rights) that
I revisited their core. I still like it. But I already took
your point above, too.
>> So I guess your response here confuses me a little (I'm NOT confused about
>> your discussion of TI here, though; just in general when you say that a
>> core is proprietary which doesn't seem to me to be a problem if you want
>> to be in business anywhere else than ARM.)
>
>Like I said, if I had my time again I would not do MSP430 as a
>single-sourced architecture -- you're just too exposed to the silicon vendor
>deciding to throw you under a bus.
Yes, that's a clear message.
>The world is moving to having free dev tools, huggy-huggy socialized
>community support +1 tweeeet, and less-than-cost-price evaluation kits.
I wouldn't have expected to hear this answer in public. But I
also see the growing critical mass here, as well.
>In the past you've wanted me to put non-standard features into the compiler
>and improve its code generation. I know that will win me nothing in the
>end: nobody wants that any longer. They want something "cheap" and
>"adequate" not "professional" and "robust" with zero-cost libraries. Most
>Si vendors libraries are really not that brilliant, but they are "adequate"
>for a chuck-it-together-and-pray product.
The whole market has evolved (devolved) and that includes the
"pyramid" of programmers and designers. That pyramid is MUCH
larger than before, with people coming in at the base of the
pyramid from as diverse backgrounds as accounting, marketing,
and road construction, I suppose. When I started, most of
those I learned from were Ph.D. physicists who designed and
built the industry and the number of tiers in the pyramid was
small, with the "bottom" being essentially engineering types
and the top being exceptional folks like von Neumann.
Now, you find students who are debating between "Hmm, should
I go into accounting or ... software? Which pays better for
less stress?" The pyramid has dozens of tiers and the bulk of
tool consumers are from very diverse (read: less technical)
backgrounds.
That's the major part of your market now.
As far as my interests in seeing lambdas (wow, have I gone
crazy in love with those and delivered my first
professionally completed project using them in a beautiful
way on May of last year -- what a fantastic simplification
they yielded me for a multi-tiered B* tree implementation), I
could only hope that it might serve to differentiate but I
was never was under any serious misapprehensions.
(By the way, the project I completed using lambdas was
shipped to thousands of customers last year and has been
exposed to extensive testing without a single error report so
far. I subjected things to a lot of testing before delivery
and did code reviews, as well, though. It is solid.) to
greatly simplify the resulting code
It was more about making a point. I'd rather see your kind of
talent spent on compilers, linkers, and debuggers, than on
IDE text fonts, colors, smart editors, and print preview
code. That point may have skipped over your head, but that
was the purpose at the time. The rest was more about teasing
that expectation.
>Customers can endure unending pain when the price point is $0.
Well, there is more to it than that. One is the ability to
completely freeze all of the source code into a repository,
including that of the operating system it runs on, so that if
and when an embedded project needs to be unearthed (as has
happened to me many times) the tools are there and the
documents about them remain accurate and able to be followed.
I still have Lattice C, for example, because it is used in an
old project that is STILL BEING MADE and SOLD even as we
speak!
There is pain. There are advantages. It's all a bunch of
tradeoffs. The critical mass is moving things in a direction
which in many sad ways means that people who develop and then
retain serious expertise will no longer have the continuing
revenue to support that. New people will have to relearn what
others learned when things break, or else not tackle it at
all. I suppose this means new business models all around?
Thanks, Paul.
Jon
>Jon,
>
>> I've a lot of mixed feelings from this discussion and I can't place them
>> into any kind of final form. Obviously, I'm an end user of compilers, not
>> a vendor. So interests are different, too.
>>
>> The only comment I have is to the above where you pan down parts because
>> of their proprietary nature. Yet the MSP430 itself is proprietary and no
>> one else makes chips based on that core (that I know of.)
>
>It is true nobody else makes it, but competitors to it will arrive with ARM
>at the core. And if I had my time again, I would not do MSP430, I would not
>do AVR, I would not do MAXQ20, and I would not do MAXQ30. We learn from our
>mistakes.
>
>> The MIPS m4k, at least, is an IP that other vendors _might_ select and
>> build, in addition to Microchip. MIPS is in the business of selling that
>> kind of IP, I think. (If not, let me know.)
>
>ARM and Imagination picked over MIPS's bones:
>
><http://www.electronicsweekly.com/blogs/x86-processor-endgame/2012/11/imagin
>ation-arm-buy-mips.html>ARM and Imagination were buddies, possibly less so now.
Very interesting business news I wasn't aware of. It also
mentions the number of chips and the number of licensees.
Thanks!
>> ARM has achieved something with its critical mass starting (memory
>> serving) with the ARM7 that no other IP-only company has achieved. If to
>> be interesting to you, a company has to sport an ARM core, then I suppose
>> that is that. But m4k is a very interesting core and Microchip has good
>> customer support (if not compiler vendor support.)
>
>Whatever MIPS licenses, it's not been successful in licensing to the general
>purpose microcontroller crowd. It might do great in set-top boxes and so
>on, and had a fist at trying to make phones by having official Android
>support (IIRC), but really, where is it in the mainstream media?
I already gathered this much before. I've pretty much ignored
MIPS after the R2000 (when it really was novel and impressive
and remarkable at the time.) It wasn't until Microchip
decided to roll something out (and buy the m14k rights) that
I revisited their core. I still like it. But I already took
your point above, too.
>> So I guess your response here confuses me a little (I'm NOT confused about
>> your discussion of TI here, though; just in general when you say that a
>> core is proprietary which doesn't seem to me to be a problem if you want
>> to be in business anywhere else than ARM.)
>
>Like I said, if I had my time again I would not do MSP430 as a
>single-sourced architecture -- you're just too exposed to the silicon vendor
>deciding to throw you under a bus.
Yes, that's a clear message.
>The world is moving to having free dev tools, huggy-huggy socialized
>community support +1 tweeeet, and less-than-cost-price evaluation kits.
I wouldn't have expected to hear this answer in public. But I
also see the growing critical mass here, as well.
>In the past you've wanted me to put non-standard features into the compiler
>and improve its code generation. I know that will win me nothing in the
>end: nobody wants that any longer. They want something "cheap" and
>"adequate" not "professional" and "robust" with zero-cost libraries. Most
>Si vendors libraries are really not that brilliant, but they are "adequate"
>for a chuck-it-together-and-pray product.
The whole market has evolved (devolved) and that includes the
"pyramid" of programmers and designers. That pyramid is MUCH
larger than before, with people coming in at the base of the
pyramid from as diverse backgrounds as accounting, marketing,
and road construction, I suppose. When I started, most of
those I learned from were Ph.D. physicists who designed and
built the industry and the number of tiers in the pyramid was
small, with the "bottom" being essentially engineering types
and the top being exceptional folks like von Neumann.
Now, you find students who are debating between "Hmm, should
I go into accounting or ... software? Which pays better for
less stress?" The pyramid has dozens of tiers and the bulk of
tool consumers are from very diverse (read: less technical)
backgrounds.
That's the major part of your market now.
As far as my interests in seeing lambdas (wow, have I gone
crazy in love with those and delivered my first
professionally completed project using them in a beautiful
way on May of last year -- what a fantastic simplification
they yielded me for a multi-tiered B* tree implementation), I
could only hope that it might serve to differentiate but I
was never was under any serious misapprehensions.
(By the way, the project I completed using lambdas was
shipped to thousands of customers last year and has been
exposed to extensive testing without a single error report so
far. I subjected things to a lot of testing before delivery
and did code reviews, as well, though. It is solid.) to
greatly simplify the resulting code
It was more about making a point. I'd rather see your kind of
talent spent on compilers, linkers, and debuggers, than on
IDE text fonts, colors, smart editors, and print preview
code. That point may have skipped over your head, but that
was the purpose at the time. The rest was more about teasing
that expectation.
>Customers can endure unending pain when the price point is $0.
Well, there is more to it than that. One is the ability to
completely freeze all of the source code into a repository,
including that of the operating system it runs on, so that if
and when an embedded project needs to be unearthed (as has
happened to me many times) the tools are there and the
documents about them remain accurate and able to be followed.
I still have Lattice C, for example, because it is used in an
old project that is STILL BEING MADE and SOLD even as we
speak!
There is pain. There are advantages. It's all a bunch of
tradeoffs. The critical mass is moving things in a direction
which in many sad ways means that people who develop and then
retain serious expertise will no longer have the continuing
revenue to support that. New people will have to relearn what
others learned when things break, or else not tackle it at
all. I suppose this means new business models all around?
Thanks, Paul.
Jon
Reply by ●February 7, 20132013-02-07
The big difference is that Microchip came out with MPLAB at the same
time it came out with its early cheap ICSP tools, very early in the
birth of the company from IIRC GE, unlike Ti who from my perspective, as
a user, largely relied on third parties to support their products until
very late in the piece.
Al
On 8/02/2013 2:53 AM, Peter Johansson wrote:
> My understanding here is that this is merely an announcement of an
> Eclipse-based IDE wrapped around existing command-line
> compiler/assembler/linker tools. I recall stumbling across some
> *very* old manuals for these tools at one point, but I cannot recall
> the exact dates on these documents. Does anyone happen to know the
> early history of these tools (if, in fact, there is one) prior to this
> 2004 announcement?
>
> In my opinion, TI has *still* not released a usable IDE nearly 10
> years later. And while I cannot comment on the state of their paid
> support, everything I have seen on their E2E site is just abysmal.
> Honestly, I am not sure if TI is even a viable competitor in this
> market.
>
> I should also note that while I am rather new to embedded development,
> I have been programming in C since 1987. I learned C using the GNU
> toolchain, and that has been my toolchain of choice when it is an
> option. In that respect I was rather lucky to have come upon the
> msp430 shortly after Peter Bigot resumed development. I have been
> exceptionally pleased with msp430-gcc and mspdebug. Support from
> Peter and Daniel has been as good (if not better) than anything I have
> seen commercially.
>
> Finally, I am not sure how any of this is any different than MicroChip
> which also offers its own compilers and support. Or have you decided
> not to compete with MicroChip as well?
>
> -p.
>
time it came out with its early cheap ICSP tools, very early in the
birth of the company from IIRC GE, unlike Ti who from my perspective, as
a user, largely relied on third parties to support their products until
very late in the piece.
Al
On 8/02/2013 2:53 AM, Peter Johansson wrote:
> My understanding here is that this is merely an announcement of an
> Eclipse-based IDE wrapped around existing command-line
> compiler/assembler/linker tools. I recall stumbling across some
> *very* old manuals for these tools at one point, but I cannot recall
> the exact dates on these documents. Does anyone happen to know the
> early history of these tools (if, in fact, there is one) prior to this
> 2004 announcement?
>
> In my opinion, TI has *still* not released a usable IDE nearly 10
> years later. And while I cannot comment on the state of their paid
> support, everything I have seen on their E2E site is just abysmal.
> Honestly, I am not sure if TI is even a viable competitor in this
> market.
>
> I should also note that while I am rather new to embedded development,
> I have been programming in C since 1987. I learned C using the GNU
> toolchain, and that has been my toolchain of choice when it is an
> option. In that respect I was rather lucky to have come upon the
> msp430 shortly after Peter Bigot resumed development. I have been
> exceptionally pleased with msp430-gcc and mspdebug. Support from
> Peter and Daniel has been as good (if not better) than anything I have
> seen commercially.
>
> Finally, I am not sure how any of this is any different than MicroChip
> which also offers its own compilers and support. Or have you decided
> not to compete with MicroChip as well?
>
> -p.
>
Reply by ●February 7, 20132013-02-07
> Whatever MIPS licenses, it's not been
successful in licensing to the
> general purpose microcontroller crowd. It might do great in set-top
> boxes and so on, and had a fist at trying to make phones by having
> official Android support (IIRC), but really, where is it in the
> mainstream media?
MIPS had/has a fair number of licensees, and they produced vast numbers
of chips. The key areas are set-top boxes (as you mentioned) and
related devices such as bluray players, network devices (most small
router/firewalls have a MIPS core, as do a very large proportion of
"intelligent" network infrastructure devices), and as a core in ASICs.
They also used to be big in mobile telephones, printers, and other such
systems. Before that, of course, they were popular for graphics
workstations.
A common feature for all of these is that there are very few developers
per unit sold - thus the market for development tools is tiny. To my
knowledge, there are only two major toolchains for MIPS - Green Hills
(who do not target the small developer - they don't even bother to
support the PIC32) and gcc. I certainly cannot see any realistic way to
market another MIPS toolchain - the only conceivable path is gcc + own
library and IDE, and it would be very difficult since that is exactly
what Microchip is offering.
What will happen to the MIPS architecture now, I do not know. I would
hate to see it go away - it's top-end cores are (apparently) much better
than ARMs for networking applications, with mature 64-bit and SMP
support, and it's new small cores are clear competitors to Cortex
devices. But I guess these new cores came out too late.
> general purpose microcontroller crowd. It might do great in set-top
> boxes and so on, and had a fist at trying to make phones by having
> official Android support (IIRC), but really, where is it in the
> mainstream media?
MIPS had/has a fair number of licensees, and they produced vast numbers
of chips. The key areas are set-top boxes (as you mentioned) and
related devices such as bluray players, network devices (most small
router/firewalls have a MIPS core, as do a very large proportion of
"intelligent" network infrastructure devices), and as a core in ASICs.
They also used to be big in mobile telephones, printers, and other such
systems. Before that, of course, they were popular for graphics
workstations.
A common feature for all of these is that there are very few developers
per unit sold - thus the market for development tools is tiny. To my
knowledge, there are only two major toolchains for MIPS - Green Hills
(who do not target the small developer - they don't even bother to
support the PIC32) and gcc. I certainly cannot see any realistic way to
market another MIPS toolchain - the only conceivable path is gcc + own
library and IDE, and it would be very difficult since that is exactly
what Microchip is offering.
What will happen to the MIPS architecture now, I do not know. I would
hate to see it go away - it's top-end cores are (apparently) much better
than ARMs for networking applications, with mature 64-bit and SMP
support, and it's new small cores are clear competitors to Cortex
devices. But I guess these new cores came out too late.
Reply by ●February 7, 20132013-02-07
Such an active thread :-)
First: TI hardware still actively support 3P vendors, as far as I know.
They keep sending me their microcontroller kits, even when I told not to
:-)
IAR seems to have wrangled starter kit packaging deals with just about
everybody, especially in the early days. So AVR and MSP430 both had IAR
KIckstart to begin with.
Quadravox and us released our compilers within months of each other. We
were getting a lot of verbal encouragement from TI but they never let us
know anything - from new devices that were coming, or heck, even hinted
that other companies may be joining the party.
As for my recollection of CCS, I don't have much to add to what Paul said.
--
// richard m: richard @imagecraft.com
http://imagecraft.com
First: TI hardware still actively support 3P vendors, as far as I know.
They keep sending me their microcontroller kits, even when I told not to
:-)
IAR seems to have wrangled starter kit packaging deals with just about
everybody, especially in the early days. So AVR and MSP430 both had IAR
KIckstart to begin with.
Quadravox and us released our compilers within months of each other. We
were getting a lot of verbal encouragement from TI but they never let us
know anything - from new devices that were coming, or heck, even hinted
that other companies may be joining the party.
As for my recollection of CCS, I don't have much to add to what Paul said.
--
// richard m: richard @imagecraft.com
http://imagecraft.com
Reply by ●February 7, 20132013-02-07
On Thu, 07 Feb 2013 12:25:03 -0800, I wrote:
> to greatly simplify the resulting code
Well, that was abrupt from me. Sorry. What I meant to write
was:
The use of lambdas in this case greatly simplified the final,
resulting code. I know, because it started out much more
complex in handling the communication of keys between tiers
and involved a number of explicit classes to get the work
done. Five modules were cut down to two, as a result of using
lambdas, and the overall code was far, far easier to explain
in a code review I did with the customer's programming team.
It was better in every conceivable way.
Jon
> to greatly simplify the resulting code
Well, that was abrupt from me. Sorry. What I meant to write
was:
The use of lambdas in this case greatly simplified the final,
resulting code. I know, because it started out much more
complex in handling the communication of keys between tiers
and involved a number of explicit classes to get the work
done. Five modules were cut down to two, as a result of using
lambdas, and the overall code was far, far easier to explain
in a code review I did with the customer's programming team.
It was better in every conceivable way.
Jon
Reply by ●February 7, 20132013-02-07
>> Whatever MIPS licenses, it's not been
successful in licensing to the
>> general purpose microcontroller crowd. It might do great in set-top
>> boxes and so on, and had a fist at trying to make phones by having
>> official Android support (IIRC), but really, where is it in the
>> mainstream media?
>> MIPS had/has a fair number of licensees, and they produced vast numbers
> of chips.
Of course. That is not my point. ARM licenses its core, and many of those licenses don't make it to commodity parts either. But a lot do, as you can see by the plethora of parts that feature ARM cores. If anything, the rate of ARM core and device introduction is accelerating.
> The key areas are set-top boxes (as you mentioned) and
> related devices such as bluray players, network devices (most small
> router/firewalls have a MIPS core, as do a very large proportion of
> "intelligent" network infrastructure devices), and as a core in ASICs.
> They also used to be big in mobile telephones, printers, and other such
> systems. Before that, of course, they were popular for graphics
> workstations.
Yes, Philips, Boradcom, all the usual suspects took licenses...
>
> A common feature for all of these is that there are very few developers
> per unit sold - thus the market for development tools is tiny. To my
> knowledge, there are only two major toolchains for MIPS - Green Hills
> (who do not target the small developer - they don't even bother to
> support the PIC32) and gcc. I certainly cannot see any realistic way to
> market another MIPS toolchain - the only conceivable path is gcc + own
> library and IDE, and it would be very difficult since that is exactly
> what Microchip is offering.
The thing that started the ARM snowballing was the LPC2000: A fast ARM7 with integrated flash and a lot of RAM with some nice, but relatively primitive, peripherals. MIPS didn't have anybody to do the same until Microchip popped up and took a license. I don't think MIPS were daunted by the fact that they were not taking an ARM license: I suspect they rather liked being different from everybody else simply because they already had a gaggle of architectures in their stable anyway! One more would hardly make a difference. They all add and jump, don't they?
>
> What will happen to the MIPS architecture now, I do not know. I would
> hate to see it go away - it's top-end cores are (apparently) much better
> than ARMs for networking applications, with mature 64-bit and SMP
> support, and it's new small cores are clear competitors to Cortex
> devices. But I guess these new cores came out too late.
>
Consigned to obscurity?
-- Paul.
>> general purpose microcontroller crowd. It might do great in set-top
>> boxes and so on, and had a fist at trying to make phones by having
>> official Android support (IIRC), but really, where is it in the
>> mainstream media?
>> MIPS had/has a fair number of licensees, and they produced vast numbers
> of chips.
Of course. That is not my point. ARM licenses its core, and many of those licenses don't make it to commodity parts either. But a lot do, as you can see by the plethora of parts that feature ARM cores. If anything, the rate of ARM core and device introduction is accelerating.
> The key areas are set-top boxes (as you mentioned) and
> related devices such as bluray players, network devices (most small
> router/firewalls have a MIPS core, as do a very large proportion of
> "intelligent" network infrastructure devices), and as a core in ASICs.
> They also used to be big in mobile telephones, printers, and other such
> systems. Before that, of course, they were popular for graphics
> workstations.
Yes, Philips, Boradcom, all the usual suspects took licenses...
>
> A common feature for all of these is that there are very few developers
> per unit sold - thus the market for development tools is tiny. To my
> knowledge, there are only two major toolchains for MIPS - Green Hills
> (who do not target the small developer - they don't even bother to
> support the PIC32) and gcc. I certainly cannot see any realistic way to
> market another MIPS toolchain - the only conceivable path is gcc + own
> library and IDE, and it would be very difficult since that is exactly
> what Microchip is offering.
The thing that started the ARM snowballing was the LPC2000: A fast ARM7 with integrated flash and a lot of RAM with some nice, but relatively primitive, peripherals. MIPS didn't have anybody to do the same until Microchip popped up and took a license. I don't think MIPS were daunted by the fact that they were not taking an ARM license: I suspect they rather liked being different from everybody else simply because they already had a gaggle of architectures in their stable anyway! One more would hardly make a difference. They all add and jump, don't they?
>
> What will happen to the MIPS architecture now, I do not know. I would
> hate to see it go away - it's top-end cores are (apparently) much better
> than ARMs for networking applications, with mature 64-bit and SMP
> support, and it's new small cores are clear competitors to Cortex
> devices. But I guess these new cores came out too late.
>
Consigned to obscurity?
-- Paul.
Reply by ●February 7, 20132013-02-07
On 7 Feb 2013, at 21:46, Jon Kirwan wrote:
> On Thu, 07 Feb 2013 12:25:03 -0800, I wrote:
>
>> to greatly simplify the resulting code
>
> Well, that was abrupt from me. Sorry. What I meant to write
> was:
>
> The use of lambdas in this case greatly simplified the final,
> resulting code. I know, because it started out much more
> complex in handling the communication of keys between tiers
> and involved a number of explicit classes to get the work
> done. Five modules were cut down to two, as a result of using
> lambdas, and the overall code was far, far easier to explain
> in a code review I did with the customer's programming team.
> It was better in every conceivable way.
>
1960s technology to the rescue! Now, how many times have I said that my favourite language happens to come from the Lisp branch of the Language Tree? I love T; I like Common Lisp.
I'm not sure you really appreciate a language until you write a compiler or interpreter for it. And I'm not sure I will ever appreciate the finer details of C++ because I have no intention of writing a compiler for it.
-- Paul.
> On Thu, 07 Feb 2013 12:25:03 -0800, I wrote:
>
>> to greatly simplify the resulting code
>
> Well, that was abrupt from me. Sorry. What I meant to write
> was:
>
> The use of lambdas in this case greatly simplified the final,
> resulting code. I know, because it started out much more
> complex in handling the communication of keys between tiers
> and involved a number of explicit classes to get the work
> done. Five modules were cut down to two, as a result of using
> lambdas, and the overall code was far, far easier to explain
> in a code review I did with the customer's programming team.
> It was better in every conceivable way.
>
1960s technology to the rescue! Now, how many times have I said that my favourite language happens to come from the Lisp branch of the Language Tree? I love T; I like Common Lisp.
I'm not sure you really appreciate a language until you write a compiler or interpreter for it. And I'm not sure I will ever appreciate the finer details of C++ because I have no intention of writing a compiler for it.
-- Paul.
Reply by ●February 7, 20132013-02-07
>> However, when things were driven more
state-side, things
>> deteriorated. :-(
>
> I only started using the msp430 with the early flash versions, but maybe
> the problems I had heard about were from earlier times. I don't know
> how the timing fits with when the msp430 "moved" from Germany to the USA
> - I did not even know it had roots in Germany.
Eek!
> At what point did the plans for the MSP430X start? I though it was relatively recently -
> certainly long after CCS was available.
Oh dear. No. Long before CCS was available, in fact.
>> You know, I really don't give two hoots about TI + GCC + MSP430. It
>> is what it is.
>> Well, for your sake I hope it doesn't affect your sales. But for the
> sake of users, including me, I am glad that Red Hat is adding polish to
> msp430 gcc. It is an excellent compiler - as I said, I much prefer it
> to CCS, though I haven't tried your tools for comparison. Certainly if
> Red Hat can get the debugger working well with the latest version of the
> compiler, I would be very happy. In many ways, my ideal would be the
> CCS IDE and debugger but with gcc as the toolchain - I think CCS has got
> quite good as an IDE now with a modern version of Eclipse (not everyone
> likes Eclipse, of course, but I think recent versions have become a lot
> smoother and more usable).
Look, another TI-supported compiler in the world is going to make zero difference to our MSP430 business. As Richard says, we're fighting over the scraps left over from IAR and CCS. The reason we maintain our compiler and bring out new versions is to support existing customers and, if new business comes along, that is a nice bonus. That's the way it is.
GCC can do some wonderful things, for sure. Heck, even clang and LLVM are sprouting MSP430 support, and that is a lot easier to maintain than GCC. Having written our MSP430 compiler and tools, I know what we excel at, and GCC won't do what our tools can do at the link stage. But GCC can do some neat tricks when compiling. We don't go in for that -- we generate straight-forward code with a fast code generation algorithm that has excellent local code generation and a good register allocator.
>
> And I don't consider myself a "new-age hippie" for using gcc on a dozen
> target architectures (though I might accept that title as a fan of
> command-line gdb). I'm sure most of your ARM toolchain users also view
> themselves as professional developers rather than "hippies".
>
The new-age hippie jibe was at the nouveau "engineers" that are now being churned out using "compile in the cloud" tools, or whatever is in vogue these days. You know, #include <some-free-library-I-stmbled-apon-and-have-no-idea-how-it-works-but-I-have-a-job-to-do-with-it.h>
At least I know how my compiler actually works. All of it. You can't say that about GCC or LLVM or clang.
I've rambled enough now. I'm firmly in the Wirth camp when it comes to compilers.
-- Paul.
>> deteriorated. :-(
>
> I only started using the msp430 with the early flash versions, but maybe
> the problems I had heard about were from earlier times. I don't know
> how the timing fits with when the msp430 "moved" from Germany to the USA
> - I did not even know it had roots in Germany.
Eek!
> At what point did the plans for the MSP430X start? I though it was relatively recently -
> certainly long after CCS was available.
Oh dear. No. Long before CCS was available, in fact.
>> You know, I really don't give two hoots about TI + GCC + MSP430. It
>> is what it is.
>> Well, for your sake I hope it doesn't affect your sales. But for the
> sake of users, including me, I am glad that Red Hat is adding polish to
> msp430 gcc. It is an excellent compiler - as I said, I much prefer it
> to CCS, though I haven't tried your tools for comparison. Certainly if
> Red Hat can get the debugger working well with the latest version of the
> compiler, I would be very happy. In many ways, my ideal would be the
> CCS IDE and debugger but with gcc as the toolchain - I think CCS has got
> quite good as an IDE now with a modern version of Eclipse (not everyone
> likes Eclipse, of course, but I think recent versions have become a lot
> smoother and more usable).
Look, another TI-supported compiler in the world is going to make zero difference to our MSP430 business. As Richard says, we're fighting over the scraps left over from IAR and CCS. The reason we maintain our compiler and bring out new versions is to support existing customers and, if new business comes along, that is a nice bonus. That's the way it is.
GCC can do some wonderful things, for sure. Heck, even clang and LLVM are sprouting MSP430 support, and that is a lot easier to maintain than GCC. Having written our MSP430 compiler and tools, I know what we excel at, and GCC won't do what our tools can do at the link stage. But GCC can do some neat tricks when compiling. We don't go in for that -- we generate straight-forward code with a fast code generation algorithm that has excellent local code generation and a good register allocator.
>
> And I don't consider myself a "new-age hippie" for using gcc on a dozen
> target architectures (though I might accept that title as a fan of
> command-line gdb). I'm sure most of your ARM toolchain users also view
> themselves as professional developers rather than "hippies".
>
The new-age hippie jibe was at the nouveau "engineers" that are now being churned out using "compile in the cloud" tools, or whatever is in vogue these days. You know, #include <some-free-library-I-stmbled-apon-and-have-no-idea-how-it-works-but-I-have-a-job-to-do-with-it.h>
At least I know how my compiler actually works. All of it. You can't say that about GCC or LLVM or clang.
I've rambled enough now. I'm firmly in the Wirth camp when it comes to compilers.
-- Paul.
Reply by ●February 7, 20132013-02-07
>
>> Customers can endure unending pain when the price point is $0.
>
> Well, there is more to it than that. One is the ability to
> completely freeze all of the source code into a repository,
> including that of the operating system it runs on, so that if
> and when an embedded project needs to be unearthed (as has
> happened to me many times) the tools are there and the
> documents about them remain accurate and able to be followed.
You just get yourself a virtual machine We use VMs all the time in our rack of servers, and I use a VM to run multiple operating systems. It's great.
I still maintain that a price of $0 is hard to beat, and bean counters can easily impose that purchase on an engineering team, I guess.
-- Paul.
>> Customers can endure unending pain when the price point is $0.
>
> Well, there is more to it than that. One is the ability to
> completely freeze all of the source code into a repository,
> including that of the operating system it runs on, so that if
> and when an embedded project needs to be unearthed (as has
> happened to me many times) the tools are there and the
> documents about them remain accurate and able to be followed.
You just get yourself a virtual machine We use VMs all the time in our rack of servers, and I use a VM to run multiple operating systems. It's great.
I still maintain that a price of $0 is hard to beat, and bean counters can easily impose that purchase on an engineering team, I guess.
-- Paul.
