Re: Hi-Tech Software bought by Microchip - no more other compilers
Boudewijn Dijkstra
> Does anybody know what has happened to their old compilers e.g. H8/300
> or Z180?
>
> Is somebody buying the rights to these products?
Very small market I guess. IAR has EOLed H8/300 two years ago, and even
then they never released a GUI version for it.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
David L. Jones
> Does anybody know what has happened to their old compilers e.g. H8/300
> or Z180?
They binned them, as to be expected.
> Is somebody buying the rights to these products?
Unlikely, as they would probably include common code that is part of the PIC
compiler which Microchip want to keep for themselves.
Dave.
--
---------------------------------------------
Check out my Electronics Engineering Video Blog & Podcast:
http://www.alternatezone.com/eevblog/
The Real Andy
<alt...@gmail.com> wrote:
>nob...@nowhere.com wrote:
>> Does anybody know what has happened to their old compilers e.g. H8/300
>> or Z180?
>
>They binned them, as to be expected.
>
>> Is somebody buying the rights to these products?
>
>Unlikely, as they would probably include common code that is part of the PIC
>compiler which Microchip want to keep for themselves.
>
>Dave.
Its interesting this. Is microchip going to release the compiler free
of charge? Atmel uses gcc, so it must be getting some good market
share on that aspect alone. I recently did some work on the AP7000
running linux, and whilst I hate linux its clear that Atmel has done a
lot of work to make it all free. Gcc is pretty good, can microchip
beat it?
Dimiter Popoff
> ...
> Its interesting this. Is microchip going to release the compiler free
> of charge? Atmel uses gcc, so it must be getting some good market
> share on that aspect alone. I recently did some work on the AP7000
> running linux, and whilst I hate linux its clear that Atmel has done a
> lot of work to make it all free. Gcc is pretty good, can microchip
> beat it?
Their 32-bit parts are MIPS based, which should be GNU covered
OK - so I guess they won't try to beat it. My guess is they will
want to make some "point and click" kind of thing for those who
find "normal" programming as we know it (command line, text
editing etc. "very difficult" things) too complex a task...
The bad news is if they do so they will likely get hugely
popular (being already more popular than they should be to my
taste, many people nowadays thing "PIC" is just a synonym of
"MCU" ).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
larwe
> popular (being already more popular than they should be to my
> taste, many people nowadays thing "PIC" is just a synonym of
> "MCU" ).
Microchip's compiler support is terribly fragmented though now.
- PIC10/12/14/16 covered by third-party compilers only. Since uChip
now owns Hitech, I guess this has changed, technically.
- PIC18 is covered Microchip C18 (proprietary?). Free non-optimizing
version.
- PIC24/dsPIC is covered by Microchip C30 (gcc based). Free non-
optimizing version.
- PIC32 is MIPS, so gcc.
Last week I did a quick-n-dirty consulting job for which I chose a PIC
as it was the only micro with USB and sufficient I/O AND DIP package
that I had on hand; rapid hand prototyping was the key here. In the
process I got reacquainted with MPLAB and the horrible ergonomics of
Microchip's tools... argh! And the fun stuff in the architecture, like
ROM tables (const rom char [] = { x,y,...} ) that can't exceed a
certain size but don't generate any compiler warnings or errors....
yuck.
Grant Edwards
> The GNU tools have been around for years for the H8/300 too,
> but were pretty rough - as one would expect for a) a generic
> compiler without many or any CPU specific optimisations and b)
> a tool used only by a relatively small number of people and
> "supported" (not) by that arrogant company called Hitachi. The
> IAR compiler was a lot better (I used it for the H8/500
> series) and the Hitech one was at least as good.
>
> How good is the GNU compiler these days? I see the last
> updates were about 2002, and there is even a windoze build of
> it somewhere.
The last update to the H8 toolchain was June 10, 2009:
http://www.kpitgnutools.com/releaseNotes.php
I've never tried the KPIT Gnu Eclipse IDE, but the toolchain
sources maintained by KPIT have always been very solid and
current.
--
Grant Edwards grante Yow! I want the presidency
at so bad I can already taste
visi.com the hors d'oeuvres.
MC
> On Mon, 6 Jul 2009 22:01:49 +1000, "David L. Jones"
> Its interesting this. Is microchip going to release the compiler free
> of charge?
They release the "demo" version of the compiler free, without a time
limit or (as I recall) any limits except that optimizations are turned off.
Having optimizations turned off is pretty bad -- the code frequently
bank-switches to the memory bank it is already in, for instance. So the
un-optimized compiler is good for learning C and testing algorithms, but
its output is rather bloated.
I seem to recall they want over $1000 for the optimizing version of the
compiler. I wish they would get it down to much less, or even give it
away free as they do their other tools.
Dave Nadler
Regarding the PIC32MX: Microchip's GCC-based offering is
C-only, with a bunch of proprietary extensions... meaning 3rd
party GCC products cannot compile Microchip's libraries or
examples without hackery. Microchip also does not provide
complete library sources which scares us. If you can tolerate
MPLAB, C only, and incomplete library sources, Microchip's
offering is passable, but really weak for non-trivial projects.
We adapted CodeSourcery's G++ GCC-based offering, using
Eclipse for development. If anyone's interested contact me;
I'll finish the web page describing this Real Soon Now.
Hope that helps,
Best Regards, Dave
Boudewijn Dijkstra
<for.addr...@www.ai.uga.edu.slash.mc>:
> The Real Andy wrote:
>> On Mon, 6 Jul 2009 22:01:49 +1000, "David L. Jones"
>
>> Its interesting this. Is microchip going to release the compiler free
>> of charge?
>
> They release the "demo" version of the compiler free, without a time
> limit or (as I recall) any limits except that optimizations are turned
> off.
That like a car dealer not allowing test drivers to go beyond first gear.
It's a great way to ensure that people continue to have no idea about the
quality of the product.
> Having optimizations turned off is pretty bad -- the code frequently
> bank-switches to the memory bank it is already in, for instance. So the
> un-optimized compiler is good for learning C and testing algorithms, but
> its output is rather bloated.
As is any compiler's unoptimized output.
larwe
> We adapted CodeSourcery's G++ GCC-based offering, using
> Eclipse for development. If anyone's interested contact me;
> I'll finish the web page describing this Real Soon Now.
Oh no! :) Please don't do anything to encourage people to use
Microchip's parts!
Nobody
>>> Is somebody buying the rights to these products?
>>
>>Unlikely, as they would probably include common code that is part of the PIC
>>compiler which Microchip want to keep for themselves.
>>
>>Dave.
>
> Its interesting this. Is microchip going to release the compiler free
> of charge? Atmel uses gcc, so it must be getting some good market
> share on that aspect alone. I recently did some work on the AP7000
> running linux, and whilst I hate linux its clear that Atmel has done a
> lot of work to make it all free. Gcc is pretty good, can microchip
> beat it?
Microchip uses gcc for their higher-end products, but modifying gcc for
an 8-bit target isn't realistic.
I'm not expecting them to give away the Hi-Tech product for free.
Microchip's C18 compiler is $500; you can get a demo version, but it
disables some optimisations after 60 days, and you have to register to get
it (and provide offline contact details; OTOH, at least they don't require
your phone number, like Hi-Tech did for their free version).
Nobody
> - PIC24/dsPIC is covered by Microchip C30 (gcc based). Free non-
> optimizing version.
Does anyone know what the deal is with the restrictions of C30?
It's derived from gcc, so they have to provide the complete source for any
derivative works. So either the restricted optimisations are performed by
a separate program, or they're only restricted in the pre-compiled binary
packages but not the source code, or they're making a dubious
interpretation of what constitues a derivative work.
DJ Delorie
nob...@nowhere.com writes:
> How good is the GNU compiler these days? I see the last updates were
> about 2002, and there is even a windoze build of it somewhere.
Where are you getting this info? The last change to the H8/300 GCC
backend was June 4th. Red Hat has been selling an H8/300 toolchain
(with varying levels of support) for as long as I can remember, and a
windows build has always been available. How do I know? I'm the one
responsible for the H8/300 within our group! I even recall doing my
first H8/300 to DJGPP port in 1992...
(as for the PIC compiler, the PIC24 Microchip compiler *is* gcc, and
is available - with sources - free of charge already)
DJ Delorie
Nobody <nob...@nowhere.com> writes:
> Does anyone know what the deal is with the restrictions of C30?
If you don't have a valid license, it forces you to -O0.
> It's derived from gcc, so they have to provide the complete source
> for any derivative works. So either the restricted optimisations are
> performed by a separate program, or they're only restricted in the
> pre-compiled binary packages but not the source code, or they're
> making a dubious interpretation of what constitues a derivative
> work.
Get the source code from their web site, comment out that code (a
single #define controls it), and rebuild. It just works, and has all
the optimizations enabled that way.
However, by doing that, you no longer have a license to use their
libraries.
larwe
> it (and provide offline contact details; OTOH, at least they don't require
> your phone number, like Hi-Tech did for their free version).
Oddly enough when faced with this question I encounter a mental block
that turns my number into 617-861-3962.
Nobody
>>> Its interesting this. Is microchip going to release the compiler free
>>> of charge?
>>
>> They release the "demo" version of the compiler free, without a time
>> limit or (as I recall) any limits except that optimizations are turned
>> off.
>
> That like a car dealer not allowing test drivers to go beyond first gear.
> It's a great way to ensure that people continue to have no idea about the
> quality of the product.
The approach used with C18 is that some optimisations are disabled after
60 days. This allows it to be used both as a time-limited evaluation copy
of the complete product and as a feature-limited freeware version.
The problem here is that it's bound to involve some kind of malware
behaviour, otherwise the user could just re-install it every 60 days.
Nobody
>> it (and provide offline contact details; OTOH, at least they don't require
>> your phone number, like Hi-Tech did for their free version).
>
> Oddly enough when faced with this question I encounter a mental block
> that turns my number into 617-861-3962.
It's possible that providing false information could count as
"obtaining goods or services dishonestly"[1].
[1] Formerly known as "obtaining goods or services by deception"; it was
changed because it didn't apply when the entire process is automated, as
it isn't possible to "deceive" a computer.
larwe
> > Oddly enough when faced with this question I encounter a mental block
> > that turns my number into 617-861-3962.
>
> It's possible that providing false information could count as
> "obtaining goods or services dishonestly"[1].
No leg to stand on - I honestly don't want to give them my contact
details so they can harass me. This issue has, in any case, been
litigated and killed aeons ago in cases revolving around people who
enter inaccurate profile information for (e.g.) free email services.
Leon
> On Mon, 6 Jul 2009 22:01:49 +1000, "David L. Jones"
>
Microchip makes the source code for their C30 and C32 compilers
available, they are based on gcc. They supply free versions of those
compilers as well, with some features disabled.
Leon
who where
>On Wed, 08 Jul 2009 19:32:25 +1000, The Real Andy wrote:
>
>>>> Is somebody buying the rights to these products?
>>>
>>>Unlikely, as they would probably include common code that is part of the PIC
>>>compiler which Microchip want to keep for themselves.
>>>
>>>Dave.
>>
>> Its interesting this. Is microchip going to release the compiler free
>> of charge? Atmel uses gcc, so it must be getting some good market
>> share on that aspect alone. I recently did some work on the AP7000
>> running linux, and whilst I hate linux its clear that Atmel has done a
>> lot of work to make it all free. Gcc is pretty good, can microchip
>> beat it?
>
>Microchip uses gcc for their higher-end products, but modifying gcc for
>an 8-bit target isn't realistic.
>
>I'm not expecting them to give away the Hi-Tech product for free.
(snip)
Why not? That surely is the optimum business model. Let's face it, their core
business is selling silicon. If giving away the tools (which cost them
incrementally nothing per copy) gains/retains buyers and user base, they are in
front. At the moment users are migrating away from Microchip in numbers,
contributed to by the tools situation.
Nobody
>>I'm not expecting them to give away the Hi-Tech product for free.
>
> (snip)
>
> Why not?
Because they charge $500 for C18, and the Hi-Tech compiler is supposedly a
better product (why else would they have bought it?)
> That surely is the optimum business model. Let's face it, their core
> business is selling silicon. If giving away the tools (which cost them
> incrementally nothing per copy) gains/retains buyers and user base, they
> are in front. At the moment users are migrating away from Microchip in
> numbers, contributed to by the tools situation.
I can't see the cost of tools being a significant factor for major
customers. Even if they charge nothing for the software, the time it
takes for an engineer to get up to speed on the platform will equate to a
few grand in salary.
OTOH, I wouldn't expect that Microchip earns a significant proportion of
their revenue from tools. I'm wondering if they do it to maintain some
modest barriers to entry, to give their more valuable customers some
advantage over the mom-&-pop outfits.
Arlet
> I can't see the cost of tools being a significant factor for major
> customers. Even if they charge nothing for the software, the time it
> takes for an engineer to get up to speed on the platform will equate to a
> few grand in salary.
Sure, but cost of tools is a serious issue for hobbyists and small
companies. Experience acquired as a result of hobby projects could
later influence some big purchasing decisions.
Leon
Evidence?
Leon
Robert Roland
>I can't see the cost of tools being a significant factor for major
>customers.
Not to existing and short term new customers. But gaining new
customers in the long term is important too.
>Even if they charge nothing for the software, the time it
>takes for an engineer to get up to speed on the platform will equate to a
>few grand in salary.
Exactly. By giving away good tools, they will attract young hobbyists
and students who don't have a lot of money. Years later, some of these
people will inevitably end up in jobs in large companies.
Imagine a situation where the new employee tells his boss: "I can do
it. If we use an Atmel chip, I'll have it done by Friday, but if we
use a Microchip chip, I'll need a few weeks to learn.".
--
RoRo
nospam
>At the moment users are migrating away from Microchip in numbers,
>contributed to by the tools situation.
If a $1000 tool cost is enough to swing a user between one or another
processor supplier that user isn't buying enough processors for either
supplier to care.
--
David Brown
> On Thu, 09 Jul 2009 09:57:45 +0800, who where wrote:
>
>>> I'm not expecting them to give away the Hi-Tech product for free.
>> (snip)
>>
>> Why not?
>
> Because they charge $500 for C18, and the Hi-Tech compiler is supposedly a
> better product (why else would they have bought it?)
>
>> That surely is the optimum business model. Let's face it, their core
>> business is selling silicon. If giving away the tools (which cost them
>> incrementally nothing per copy) gains/retains buyers and user base, they
>> are in front. At the moment users are migrating away from Microchip in
>> numbers, contributed to by the tools situation.
>
> I can't see the cost of tools being a significant factor for major
> customers. Even if they charge nothing for the software, the time it
> takes for an engineer to get up to speed on the platform will equate to a
> few grand in salary.
>
Even for commercial companies, the monetary cost of getting started with
a new device is important. New architectures are often introduced in
small projects, for prototypes, or as part of training periods for new
employees. While it's true that the biggest true cost is normally in
time (and salaries), the cost of development tools has a big
psychological influence, disproportional to the final costs. When
considering a choice between different architectures for a project, if
one has free tools and the other has tools costing a few thousand, you
can be sure that the free tool device will be tested first "because it
costs nothing to try it out".
Then there are the other benefits of having zero cost tools. Typically
you can download them and start working immediately - there are no
purchase orders to deal with, no waiting for dongles in the post, no
contracts to sign. You can install them on multiple computers or at
home offices without worrying about licenses. You never have to make
decisions like "it would be useful to have this running on the laptop as
well - but is it worth x thousand dollars?".
I don't mean to say that all tools should be free - just that
microcontroller manufacturers would do well to make good free tools
easily available, even within professional markets. They (or third
parties) can profit from charging for /better/ tools - but only
providing bad tools for free is, IMHO, a silly strategy.
Michael A. Terrell
And if that company's next product needs $100,000,000 worth of
processors, who are they going to give the first choice to supply the
silicon?
--
You can't have a sense of humor, if you have no sense!
Walter Banks
Robert Roland wrote:
> >Even if they charge nothing for the software, the time it
> >takes for an engineer to get up to speed on the platform will equate to a
> >few grand in salary.
>
> Exactly. By giving away good tools, they will attract young hobbyists
> and students who don't have a lot of money. Years later, some of these
> people will inevitably end up in jobs in large companies.
>
> Imagine a situation where the new employee tells his boss: "I can do
> it. If we use an Atmel chip, I'll have it done by Friday, but if we
> use a Microchip chip, I'll need a few weeks to learn.".
It is an obvious conclusion that is not supported by our marketing studies.
Microchip's customer support has been a effective part of their business
promotion.
Tool cost is small part (~2 man days cost) of overall project cost.
Accompanying tools support (about 40% of our support calls are
application more than tool related) makes tools very low cost overall.
Regards,
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
Walter Banks
David Brown wrote:
> I don't mean to say that all tools should be free - just that
> microcontroller manufacturers would do well to make good free tools
> easily available, even within professional markets.
The chip companies that provide a core of free tools for casual
use and small projects that leave the door open for other tools
generally do well. Third parties bring new ideas and approaches to
problem solving. Application area's evolve and third party have
the advantage of developing application support for several
targets.
Chip companies that try to dominate the tools used for their
products for free or otherwise fail over time to have competitive
tools. Chip companies often buy tool companies and find that
within a few years the tool support no longer is competitive.
> They (or third parties) can profit from charging for /better/ tools - but only
> providing bad tools for free is, IMHO, a silly strategy.
Wounding tools especially code generation is a waste of time
and resources for a tool company. Costs sales, is demoralizing
for the tool company.
Walter Banks
"Michael A. Terrell" wrote:
> > If a $1000 tool cost is enough to swing a user between one or another
> > processor supplier that user isn't buying enough processors for either
> > supplier to care.
>
> And if that company's next product needs $100,000,000 worth of
> processors, who are they going to give the first choice to supply the
> silicon?
The lowest cost silicon that can be delivered that meets the application
functional requirements. The code will be ported as part of production
engineering.
We regularly see prototypes done on silicon with far more capabilities
than production parts.
Michael A. Terrell
Walter Banks wrote:
>
> "Michael A. Terrell" wrote:
>
> > > If a $1000 tool cost is enough to swing a user between one or another
> > > processor supplier that user isn't buying enough processors for either
> > > supplier to care.
> >
> > And if that company's next product needs $100,000,000 worth of
> > processors, who are they going to give the first choice to supply the
> > silicon?
>
> The lowest cost silicon that can be delivered that meets the application
> functional requirements. The code will be ported as part of production
> engineering.
>
> We regularly see prototypes done on silicon with far more capabilities
> than production parts.
That isn't always a bad thing. It allows changes to the design
without a complete redesign. Would you try to save a penny per chip by
dealing with a company that you don't trust?
larwe
wrote:
> easily available, even within professional markets. They (or third
> parties) can profit from charging for /better/ tools - but only
> providing bad tools for free is, IMHO, a silly strategy.
Really, you're ignoring a 500-pound gorilla. The reason there is such
a wide performance gap between "unoptimized" and "payware" is because
the PIC ISAs are horrendous (at least up to PIC18, I have no real
experience with PIC24 and dsPIC). Ceteris paribus there is no good
reason to choose a PIC over an AVR or MSP430.
larwe
> If a $1000 tool cost is enough to swing a user between one or another
> processor supplier that user isn't buying enough processors for either
Buying a $1000 tool at my (multibillion dollar, millions-of-units EAU)
employer involves a capital appropriations request process that can
take six months and needs to go up and down the management chain,
across a minimum of three countries (US, Switzerland and Mexico -
possibly also India), through accounting, up and down and round the
mulberry bush, worse than any Vogon bureaucracy you can imagine. Time
is money. If I can download vendor A's tool free, or wait six months
and endure agonizing paperwork to get authorization to buy vendor B's
tool, I'm damn unlikely to go route B.
(Sometimes vendor B will give us free licenses to use while the CAR is
in progress, but not always, and it's still painful).
MC
>> I'm not expecting them to give away the Hi-Tech product for free.
>
> Why not? That surely is the optimum business model. Let's face it, their core
> business is selling silicon. If giving away the tools (which cost them
> incrementally nothing per copy) gains/retains buyers and user base, they are in
> front. At the moment users are migrating away from Microchip in numbers,
> contributed to by the tools situation.
Hear, hear!
petrus bitbyter
"Walter Banks" <wal...@bytecraft.com> schreef in bericht
news:4A55EF75...@bytecraft.com...
Nevertheless I know at least one small company that moved from PIC to Atmel
because of the good, free GNU compiler.
petrus bitbyter
petrus bitbyter
"Leon" <leo...@btinternet.com> schreef in bericht
news:eabcb5ad-c626-48fc...@h11g2000yqb.googlegroups.com...
Only a little bit: Myself. I've done some small PIC projects lately using
PICs that can (best) be programmed in assembler. Microchips tools for this
are good. Good enough for me that is. The last larger project that required
a C-compiler I used HI-tech. But the next larger project I'll go Atmel. I
know, nobody will care or even notice. But what if some thousends of others
will do the same?
petrus bitbyter
Raveninghorde
I normally design using PICs, I've been using them since at least
1990. I've had the Byte Craft compiler and now use the Hi-Tech
compilers and the cost has not been an issue until recently.
One of my customers wants to take over updating the code for his
products. The free complier is no good because the PIC size has been
chosen for the pro compiler. He is not keen to buy the compilers for
the volume he uses. Currently I'm disabling the compiler my end so he
can activate a copy at his end and then he disables so I can
reactivate to use it here.
Atmel with free software is looking good for new designs.
Walter Banks
"Michael A. Terrell" wrote:
> > We regularly see prototypes done on silicon with far more capabilities
> > than production parts.
>
> That isn't always a bad thing. It allows changes to the design
> without a complete redesign. Would you try to save a penny per chip by
> dealing with a company that you don't trust?
I think that it is a good thing as well. Get the technology right then do a clean
implementation. The chip companies don't have a significant advantage
by being used in high volume prototypes
w..
Rich Webb
One possible advantage to PICs is the availability of (most? all?) parts
with OTP PROM instead of flash (the "C" parts versus the "F" series).
For something that may need to just work, for decades, in high ambient
conditions such as the controller on an outside plant HVAC unit, that
could be desirable insurance.
--
Rich Webb Norfolk, VA
-jg
<pieterkraltlaatdit...@enditookhccnet.nl> wrote:
>
> Nevertheless I know at least one small company that moved from PIC to Atmel
> because of the good, free GNU compiler.
It is not JUST the compiler that designers look at, it is the whole
development and debug flow as well.
The fastest way to get a (new) device onto a designers desk, is to
offer a USB-Stick
(or slightly larger) type very low cost, ie a 'Slicon datasheet' with
USB debug.
If that toolkit also has a nice set of hackable examples, then that
helps as well.
Microcontroller silicon is getting cheaper so quickly, that details
like compiler differences will be lost in the timelines.
Most of our recent device-selections were driven by peripherals, not
by tools,
(and not by core).
example: in one selection, Microchip PIC32 actually made the
shortlist, (surprised me ;) until the fine print revealed that TxCK
was only available on the bigger package. Bummer...
Pity, as their EVK was affordable, _and_ had a proper debug pathway.
Some more expensive systems are only partial, and beware lines like
this in the Guides :
["Optionally, if you have a SAM-ICE™, instructions are also given
about
how to debug the code."] - and that Sam-ice is twice the price of the
whole
PIC32 evk !? (and the SAM3U EVK is way more complex than we need too,
which bumps the price to $200+$100 vs $55...)
NXP parts DO have the right peripherals in the right package mix, so
now we
trawl this :
http://www.standardics.nxp.com/literature/other/microcontrollers/pdf/arm.mcu.tools.pdf
nospam
>Only a little bit: Myself. I've done some small PIC projects lately using
>PICs that can (best) be programmed in assembler. Microchips tools for this
>are good. Good enough for me that is. The last larger project that required
>a C-compiler I used HI-tech. But the next larger project I'll go Atmel. I
>know, nobody will care or even notice. But what if some thousends of others
>will do the same?
One reason people will not go Atmel is the relatively low probability of
being able to buy the same chip in two years time (especially with them
looking financially weak at the moment).
Microchip still sell chips for designs I did 15 years ago.
Atmel's 'Not recommended for new designs' means go redesign your product
because we are not making them anymore.
--
Nico Coesel
>On Thu, 09 Jul 2009 09:57:45 +0800, who where wrote:
>
>>>I'm not expecting them to give away the Hi-Tech product for free.
>>
>> (snip)
>>
>> Why not?
>
>Because they charge $500 for C18, and the Hi-Tech compiler is supposedly a
>better product (why else would they have bought it?)
>
>> That surely is the optimum business model. Let's face it, their core
>> business is selling silicon. If giving away the tools (which cost them
>> incrementally nothing per copy) gains/retains buyers and user base, they
>> are in front. At the moment users are migrating away from Microchip in
>> numbers, contributed to by the tools situation.
>
>I can't see the cost of tools being a significant factor for major
>customers. Even if they charge nothing for the software, the time it
>takes for an engineer to get up to speed on the platform will equate to a
>few grand in salary.
Are you grazy? It takes me a day to get into a new platform and start
working with it. Period. Last time I had to do a PIC design. The days
work included writing a wrapper so PICC could be invoked like it is
GCC from Eclipse.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Nico Coesel
The problem with commercial tools is that each MCU has a different
crappy IDE and a different toolchain. That is why the combination
Eclipse, GCC en GDB is so powerful. You learn the tools once and can
apply that knowledge to any target. Besides, Eclipse beats most IDEs
hands down.
krw
<wal...@bytecraft.com> wrote:
>
>
>Robert Roland wrote:
>
>> >Even if they charge nothing for the software, the time it
>> >takes for an engineer to get up to speed on the platform will equate to a
>> >few grand in salary.
>>
>> Exactly. By giving away good tools, they will attract young hobbyists
>> and students who don't have a lot of money. Years later, some of these
>> people will inevitably end up in jobs in large companies.
>>
>> Imagine a situation where the new employee tells his boss: "I can do
>> it. If we use an Atmel chip, I'll have it done by Friday, but if we
>> use a Microchip chip, I'll need a few weeks to learn.".
>
>It is an obvious conclusion that is not supported by our marketing studies.
>
>Microchip's customer support has been a effective part of their business
>promotion.
>
>Tool cost is small part (~2 man days cost) of overall project cost.
Not all $$ are created equal.
>Accompanying tools support (about 40% of our support calls are
>application more than tool related) makes tools very low cost overall.
Cost and price being completely different things, of course.
krw
Ten years back, I justified a laptop based on the node-locked tools I
had to run. I needed to work in the lab as well as my office and a
laptop was a lot cheaper than another $80K for another seat (high end
FPGA stuff). Now I wouldn't consider buying any node-locked software.
Indeed I won't buy any FPGA development software, because I don't need
to.
>I don't mean to say that all tools should be free - just that
>microcontroller manufacturers would do well to make good free tools
>easily available, even within professional markets. They (or third
>parties) can profit from charging for /better/ tools - but only
>providing bad tools for free is, IMHO, a silly strategy.
Having bad tools is a silly strategy.
krw
<wal...@bytecraft.com> wrote:
>
>
>David Brown wrote:
>
>> I don't mean to say that all tools should be free - just that
>> microcontroller manufacturers would do well to make good free tools
>> easily available, even within professional markets.
>
>The chip companies that provide a core of free tools for casual
>use and small projects that leave the door open for other tools
>generally do well. Third parties bring new ideas and approaches to
>problem solving. Application area's evolve and third party have
>the advantage of developing application support for several
>targets.
>
>Chip companies that try to dominate the tools used for their
>products for free or otherwise fail over time to have competitive
>tools. Chip companies often buy tool companies and find that
>within a few years the tool support no longer is competitive.
Because they refuse to adequately fund something that doesn't generate
profit/revenue. The counters of beans refuse to see that you have to
give bait away to catch fish.
>> They (or third parties) can profit from charging for /better/ tools - but only
>> providing bad tools for free is, IMHO, a silly strategy.
>
>Wounding tools especially code generation is a waste of time
>and resources for a tool company. Costs sales, is demoralizing
>for the tool company.
Yet it's SOP.
krw
wrote:
Classic attitude of a company just about to go bust.
Mark Borgerson
says...
> Walter Banks <wal...@bytecraft.com> wrote:
>
> >
> >
> >Robert Roland wrote:
> >
> >> >Even if they charge nothing for the software, the time it
> >> >takes for an engineer to get up to speed on the platform will equate to a
> >> >few grand in salary.
> >>
> >> Exactly. By giving away good tools, they will attract young hobbyists
> >> and students who don't have a lot of money. Years later, some of these
> >> people will inevitably end up in jobs in large companies.
> >>
> >> Imagine a situation where the new employee tells his boss: "I can do
> >> it. If we use an Atmel chip, I'll have it done by Friday, but if we
> >> use a Microchip chip, I'll need a few weeks to learn.".
> >
> >It is an obvious conclusion that is not supported by our marketing studies.
> >
> >Microchip's customer support has been a effective part of their business
> >promotion.
> >
> >Tool cost is small part (~2 man days cost) of overall project cost.
> >Accompanying tools support (about 40% of our support calls are
> >application more than tool related) makes tools very low cost overall.
>
> The problem with commercial tools is that each MCU has a different
> crappy IDE and a different toolchain. That is why the combination
> Eclipse, GCC en GDB is so powerful. You learn the tools once and can
> apply that knowledge to any target. Besides, Eclipse beats most IDEs
> hands down.
>
>
same IDE. I've only used it for the ARM, but the IDE and debugging
facilities seem OK to me. YMMV.
Mark Borgerson
larwe
> >If a $1000 tool cost is enough to swing a user between one or another
> >processor supplier that user isn't buying enough processors for either
> >supplier to care.
>
> Classic attitude of a company just about to go bust.
Eh... You do know that in the very recent past it looked as if
Microchip was going to buy Atmel, right?
David L. Jones
> On Mon, 6 Jul 2009 22:01:49 +1000, "David L. Jones"
> <alt...@gmail.com> wrote:
>
>> nob...@nowhere.com wrote:
>>> Does anybody know what has happened to their old compilers e.g.
>>> H8/300 or Z180?
>>
>> They binned them, as to be expected.
>>
>>> Is somebody buying the rights to these products?
>>
>> Unlikely, as they would probably include common code that is part of
>> the PIC compiler which Microchip want to keep for themselves.
>>
>> Dave.
>
> Its interesting this. Is microchip going to release the compiler free
> of charge? Atmel uses gcc, so it must be getting some good market
> share on that aspect alone. I recently did some work on the AP7000
> running linux, and whilst I hate linux its clear that Atmel has done a
> lot of work to make it all free. Gcc is pretty good, can microchip
> beat it?
Microchips own branded compiled is based on GCC and is free for most series,
e.g 18, 24, 32
Some speed/size optimisation limits may apply on the free student version,
but no code size limits etc, so close enough to free for many uses.
Dave.
--
================================================
Check out my Electronics Engineering Video Blog & Podcast:
http://www.alternatezone.com/eevblog/
Nobody
>>I can't see the cost of tools being a significant factor for major
>>customers. Even if they charge nothing for the software, the time it
>>takes for an engineer to get up to speed on the platform will equate to a
>>few grand in salary.
>
> Are you grazy? It takes me a day to get into a new platform and start
> working with it. Period. Last time I had to do a PIC design. The days
> work included writing a wrapper so PICC could be invoked like it is
> GCC from Eclipse.
There's a difference between "start working with" and "up to speed". A big
difference.
krw
Nobody
>> Its interesting this. Is microchip going to release the compiler free
>> of charge? Atmel uses gcc, so it must be getting some good market
>> share on that aspect alone. I recently did some work on the AP7000
>> running linux, and whilst I hate linux its clear that Atmel has done a
>> lot of work to make it all free. Gcc is pretty good, can microchip
>> beat it?
>
> Microchips own branded compiled is based on GCC and is free for most series,
> e.g 18, 24, 32
Only the 16-bit (PIC24/30/33) and 32-bit (PIC32) compilers are gcc-based.
It wouldn't be practical to port gcc to the 8-bit families (10/12/16/18),
they're just too far from the kind of architecture for which gcc was
designed.
MC
> who where <no...@home.net> wrote:
>
>> At the moment users are migrating away from Microchip in numbers,
>> contributed to by the tools situation.
>
> processor supplier that user isn't buying enough processors for either
> supplier to care.
But small jobs lead to big jobs. Hobbies lead to small jobs. If you
really want to sell chips, win the hearts and minds of the hobbyists and
students.
MC
> Then there are the other benefits of having zero cost tools. Typically
> you can download them and start working immediately - there are no
> purchase orders to deal with, no waiting for dongles in the post, no
> contracts to sign. You can install them on multiple computers or at
> home offices without worrying about licenses. You never have to make
> decisions like "it would be useful to have this running on the laptop as
> well - but is it worth x thousand dollars?".
>
> I don't mean to say that all tools should be free - just that
> microcontroller manufacturers would do well to make good free tools
> easily available, even within professional markets. They (or third
> parties) can profit from charging for /better/ tools - but only
> providing bad tools for free is, IMHO, a silly strategy.
Well said!
The same goes for operating systems. Remember OS/2? If I had been IBM
management, I would have paid Borland to port Delphi to it. There would
then have been a flurry of reasonably good GUI software for OS/2. As it
was, hardly any application software was ever developed for OS/2, and it
died out as soon as its half-brother Windows 95 came along.
MC
>> customers. Even if they charge nothing for the software, the time it
>> takes for an engineer to get up to speed on the platform will equate to a
>> few grand in salary.
>
> Are you grazy? It takes me a day to get into a new platform and start
> working with it. Period.
Yes... If it took $5k worth of time to get into a new platform, I would
never have gotten into any platforms at all!
larwe
> >> Classic attitude of a company just about to go bust.
>
> >Eh... You do know that in the very recent past it looked as if
> >Microchip was going to buy Atmel, right?
>
> And this is relevent how?
uChip was/is financially much better off than its technically superior
competition.
larwe
> Microchips own branded compiled is based on GCC and is free for most series,
> e.g 18, 24, 32
It is free for the minority of series - 10/12/14/16 are [right now]
not free. I suspect that they'll start offering a free suboptimal
Hitech now though.
Rich Webb
And also the hearts and minds of professionals who, if they have fun
with what they're doing (and if not, perhaps should change careers), may
want to "play" with a new chip or architecture. If the entry barrier to
get set up is too high for an out of pocket expense, that chip may be
bypassed and won't be designed-in.
Leon
<pieterkraltlaatdit...@enditookhccnet.nl> wrote:
> "Leon" <leon...@btinternet.com> schreef in berichtnews:eabcb5ad-c626-48fc...@h11g2000yqb.googlegroups.com...
That's not particularly significant! Microchip has a far larger market
share than Atmel, and makes a profit, so they must be doing something
right.
Leon
Walter Banks
Nico Coesel wrote:
> Walter Banks <wal...@bytecraft.com> wrote:
>
> >
> >
> >Robert Roland wrote:
> >
> >> >Even if they charge nothing for the software, the time it
> >> >takes for an engineer to get up to speed on the platform will equate to a
> >> >few grand in salary.
> >>
> >> Exactly. By giving away good tools, they will attract young hobbyists
> >> and students who don't have a lot of money. Years later, some of these
> >> people will inevitably end up in jobs in large companies.
> >>
> >> Imagine a situation where the new employee tells his boss: "I can do
> >> it. If we use an Atmel chip, I'll have it done by Friday, but if we
> >> use a Microchip chip, I'll need a few weeks to learn.".
> >
> >It is an obvious conclusion that is not supported by our marketing studies.
> >
> >Microchip's customer support has been a effective part of their business
> >promotion.
> >
> >Tool cost is small part (~2 man days cost) of overall project cost.
> >Accompanying tools support (about 40% of our support calls are
> >application more than tool related) makes tools very low cost overall.
>
> The problem with commercial tools is that each MCU has a different
> crappy IDE and a different toolchain. That is why the combination
> Eclipse, GCC en GDB is so powerful. You learn the tools once and can
> apply that knowledge to any target. Besides, Eclipse beats most IDEs
> hands down.
There are a lot of tool interface standards that make IDE's essentially a
non issue. Everyone uses the same error return standards and error
reporting file syntax. Makes work with most compilers and linkers
We encourage and support our customers to use the IDE they are familiar
with (most have company standards on IDE's).
w..
David Brown
Actually, there was a surprisingly large amount of software for OS/2.
In particular, there was a totally disproportional amount of freeware,
shareware, and open source software for it when considering the number
of users compared to Windows. This was at least partly because it was
so much easier for developers than Windows, so people who had a choice
(such as freeware developers) chose OS/2.
Of course, I have to agree that porting Delphi (and other Borland tools)
would have been a big help too.
But the death of OS/2 had little to do with lack of software (almost all
DOS/Windows software at the time ran fine on OS/2, and often far better
than it did on DOS or Windows). It was all to do with MS's strategies,
and IBM's lack of commitment and understanding. Together they figured
out that it was cheaper to sell IBM PC's with Windows than with their
own OS/2, added to the fact that their own PC's were not entirely
compatible with their own OS/2. If IBM was not willing to sell PC's
with OS/2, it was hard for anyone else to do it.
OBones
It's already the case and it's called Lite
Nico Coesel
Nope. A microcontroller always has memory (ram/rom), a cpu and
peripherals. If you've seen one, you've seen them all. Ofcourse there
are people that like to toy around and try to get every peripheral
working without looking at the examples. Those people need a month to
get started... I'd fire them asap.
larwe
> Nope. A microcontroller always has memory (ram/rom), a cpu and
> peripherals. If you've seen one, you've seen them all. Ofcourse there
> are people that like to toy around and try to get every peripheral
That's absolutely untrue, starting with the difference between double-
and single-buffered UARTs, buffered vs. non-buffered PWM peripherals,
special caveats and magic not often found in application notes. Yes
you can compile an app note's sourcecode in a day. No, you cannot
learn to use a new microcontroller _effectively_ and _optimally_ in
such a short time. No god of embedded engineering can do it,
especially for larger chips (I'd like to see you try this on something
like an i.MX21).
Just compare the difference between a TI datasheet and a PIC
datasheet. TI has a family datasheet for the chip and a user manual
for the core and peripheral set. Extensive cross-referencing is
required to understand how any particular peripheral works. Microchip
has all the data, even down to the ISA document, in a single datasheet
for the part family.
nospam
>Of course, I have to agree that porting Delphi (and other Borland tools)
>would have been a big help too.
>
>But the death of OS/2 had little to do with lack of software (almost all
>DOS/Windows software at the time ran fine on OS/2,
OS/2 was a dead man walking long before it could run DOS/Windows software
fine.
I died because of IBM's insistence it ran on brain dead 286s (to satisfy
their hardware customers who had purchased lots of expensive PS/2 boxes
with brain dead processors).
At the time Microsoft embraced the 386 which really could run Windows and
DOS programs fine.
IBM chose hardware backward compatibility over software backward
compatibility - very very dumb.
--
MC
>> But small jobs lead to big jobs. Hobbies lead to small jobs. If you
>> really want to sell chips, win the hearts and minds of the hobbyists and
>> students.
>
> And also the hearts and minds of professionals who, if they have fun
> with what they're doing (and if not, perhaps should change careers), may
> want to "play" with a new chip or architecture. If the entry barrier to
> get set up is too high for an out of pocket expense, that chip may be
> bypassed and won't be designed-in.
Agreed! And there are plenty of professionals for whom a particular
project is more like a hobby project. It's small, it's easy, and you
want to use it to try out a new processor or toolset.
Nico Coesel
>On Jul 10, 11:35=A0am, n...@puntnl.niks (Nico Coesel) wrote:
>
>> Nope. A microcontroller always has memory (ram/rom), a cpu and
>> peripherals. If you've seen one, you've seen them all. Ofcourse there
>> are people that like to toy around and try to get every peripheral
>
>That's absolutely untrue, starting with the difference between double-
>and single-buffered UARTs, buffered vs. non-buffered PWM peripherals,
Perhaps but -for instance- all UARTs work the same. Provide some
settings, create an interrupt routine and ready to go. Timers ditto. I
use -more or less- the same set of routines on 8051 derivatives, H8/3x
and several ARM based controllers. Ofcourse there are microcontrollers
that are crappy at some point but most modern stuff is quite
straightforward. It only takes a few reads from specific sections from
the user manual to get a peripheral going.
>learn to use a new microcontroller _effectively_ and _optimally_ in
>such a short time. No god of embedded engineering can do it,
>especially for larger chips (I'd like to see you try this on something
>like an i.MX21).
An i.MX21 is a SOC, not a microcontroller!
Vladimir Vassilevsky
Nico Coesel wrote:
> larwe <zwsd...@gmail.com> wrote:
>
>
>>On Jul 10, 11:35=A0am, n...@puntnl.niks (Nico Coesel) wrote:
>>
>>
>>>Nope. A microcontroller always has memory (ram/rom), a cpu and
>>>peripherals. If you've seen one, you've seen them all. Ofcourse there
>>>are people that like to toy around and try to get every peripheral
>>That's absolutely untrue, starting with the difference between double-
>>and single-buffered UARTs, buffered vs. non-buffered PWM peripherals,
>
>
> Perhaps but -for instance- all UARTs work the same.
Nope. The UARTs can be very different and proper setup could be quite
sophisticated. Look at the TMS 28xx UART, for example. Or UART DMA
configuration for BlackFin.
> Provide some
> settings, create an interrupt routine and ready to go. Timers ditto. I
> use -more or less- the same set of routines on 8051 derivatives, H8/3x
> and several ARM based controllers. Ofcourse there are microcontrollers
> that are crappy at some point but most modern stuff is quite
> straightforward. It only takes a few reads from specific sections from
> the user manual to get a peripheral going.
This assumption could be very misleading and dangerous. There are subtle
differences here and there, and this can result in the erratic operation
in some special cases. Being burned with that, I prefer to read the
manuals and the errata sheets rather then making assumptions.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Joel Koltner
news:4A57468...@bytecraft.com...
> We encourage and support our customers to use the IDE they are familiar
> with (most have company standards on IDE's).
Really? I've yet to work at any company that standardized on a particular
IDE -- they are just too many bits and pieces that don't typically interface
"nicely" to a generic IDE. I mean, can you actually debug PICs or AVRs or
MSP430s using Eclipse with a standard interface that gives you source code,
diassembly, breakpoints, watch windows, registers, etc.?
The vast majority of microcontroller programmers I've met just use the IDE
that comes with the tools. I'd even go so far as to say that no more than 1
user in 50 uses the more advanced features of any given IDE such as scripting.
---Joel
larwe
> >That's absolutely untrue, starting with the difference between double-
> >and single-buffered UARTs, buffered vs. non-buffered PWM peripherals,
>
> Perhaps but -for instance- all UARTs work the same. Provide some
Hardly! And in any case, few UARTs are pure UARTs, most are USARTs
with other functionality bolted on; I2C, SPI, CAN, LIN, ... ...
> straightforward. It only takes a few reads from specific sections from
> the user manual to get a peripheral going.
I wish I lived in your world, it must be a very simple and stress-free
place.
> >especially for larger chips (I'd like to see you try this on something
> >like an i.MX21).
>
> An i.MX21 is a SOC, not a microcontroller!
Nitpicking. You could call an 8051 with onboard LCD controller and
keyboard muxer an SoC too.
Mel
> Perhaps but -for instance- all UARTs work the same. Provide some
> settings, create an interrupt routine and ready to go
Heh. The UART came up pretty fast, but getting the clock generator to
generate the right assortment of clocks is not something a Z180 ever needed
done. Nor PIC.
And not enabling the /Reset pin too soon because the power-up sequence
assumes that the firmware is *using* it to control startup of outside
peripherals.
I like this chip, but getting really familiar with it did take some time.
Mel.
George Neuner
wrote:
>The problem with commercial tools is that each MCU has a different
>crappy IDE and a different toolchain. That is why the combination
>Eclipse, GCC en GDB is so powerful. You learn the tools once and can
>apply that knowledge to any target. Besides, Eclipse beats most IDEs
>hands down.
Eclipse is still far from the best IDEs, but it has potential ...
somebody with a lot more time than me could potentially develop an
Eclispse based code browser as useful as Smalltalks or a debugger as
good as Wind Rivers.
BTW: GDB sucks and GCC is just a decent compiler - not a really good
one.
Apart from these points, I agree that some kind of a standard tool
chain is desirable. Or at least a plug and play tool chain with
standardized intermediate formats so you can choose compiler, linker,
debugger, etc. and they all interoperate.
George
David Brown
Debugging and simulation are often difficult to integrate with IDEs (the
only standard is gdb, but even there you can often have to do some work
to get things like proxies or hardware interfaces to start up nicely
with the IDE's gdb front end). And if you want thinks like gui boxes
for picking compiler options, rather than using makefiles, then you need
extra integration. But for the basic work of editing, searching,
project management, and often running makefiles and interpreting the
errors and warnings, then you can mix and match programmer's editors or
IDEs and compiler tools.
Nico Coesel
Well, I use Eclipse for almost everything except 8051. But I never use
debugging except for Windows and Linux (which I also use to debug
software that goes into embedded platforms). There is not much use in
debugging a microcontroller. The non-realtime stuff is easier & faster
to debug when run on Windows or Linux. The realtime stuff can't be
debugged because the moment you halt there is no more realtime...
David Brown
> David Brown <david...@hesbynett.removethisbit.no> wrote:
>
>> Of course, I have to agree that porting Delphi (and other Borland tools)
>> would have been a big help too.
>>
>> But the death of OS/2 had little to do with lack of software (almost all
>> DOS/Windows software at the time ran fine on OS/2,
>
> OS/2 was a dead man walking long before it could run DOS/Windows software
> fine.
>
> I died because of IBM's insistence it ran on brain dead 286s (to satisfy
> their hardware customers who had purchased lots of expensive PS/2 boxes
> with brain dead processors).
>
My experience with OS/2 began with Warp (OS/2 3.0), which was a very
different OS than OS/2 2 (which again was very different from version
1). It was only with Warp that OS/2 gained significant followers, and
it needed a 386 or better.
> At the time Microsoft embraced the 386 which really could run Windows and
> DOS programs fine.
>
At the time of Warp, Windows was at 3.11 (or the very rare NT 3.51), and
could run many DOS programs reasonably (and obviously current windows
programs). However, Windows was in reality single-tasking (since it was
a co-operative multi-tasking system, and windows programs were not
co-operative), although it could do some limited DOS multi-tasking.
OS/2 was vastly better, and could properly multi-task windows software
and DOS software. In particular, it was much better for DOS since it
allowed more flexible graphics and significantly better memory management.
> IBM chose hardware backward compatibility over software backward
> compatibility - very very dumb.
>
The main cause of death was that that MS told IBM that if it wanted OEM
discounts on its windows PCs, it had to install windows on *all* its
machines. If it shipped PCs with OS/2 pre-installed, they would have to
pay full customer prices for every PC it shipped with windows. IBM said
"fair enough", and installed windows on all its PCs.
George Neuner
wrote:
>[OS2/] died because of IBM's insistence it ran on brain dead 286s (to
>satisfy their hardware customers who had purchased lots of expensive PS/2
>boxes with brain dead processors).
>
>At the time Microsoft embraced the 386 which really could run Windows and
>DOS programs fine.
And then, for years, gave us a shared memory process model with
cooperative multitasking.
Windows, too, was originally designed for the 286, and it retained
that unfortunate legacy for nearly 10 years. Windows 1.0 was
introduced in 1985. Windows/386 in 1989 was the first to use the 386
in 32-bit protected mode. Windows 3.0 was the first version that was
actually useful - it used 32-bit mode internally but only drivers
could use it that way - all GUI programs shared a single 16-bit VM. It
wasn't until 1993 with the introduction of NT and Win32 on Windows
that the average programmer could write real 32-bit software.
OS/2 was better than Windows until NT4 appeared.
George
Leon
> On Thu, 09 Jul 2009 23:07:18 GMT, n...@puntnl.niks (Nico Coesel)
The XMOS tools use Eclipse (they can also be used from the command
line). I've always disliked Eclipse but the XMOS implementation is
very good.
Leon
nospam
>> I died because of IBM's insistence it ran on brain dead 286s (to satisfy
>> their hardware customers who had purchased lots of expensive PS/2 boxes
>> with brain dead processors).
>>
>
>My experience with OS/2 began with Warp (OS/2 3.0),
When Windows had already won.
>The main cause of death was that that MS told IBM that if it wanted OEM
>discounts on its windows PCs, it had to install windows on *all* its
>machines. If it shipped PCs with OS/2 pre-installed, they would have to
>pay full customer prices for every PC it shipped with windows. IBM said
>"fair enough", and installed windows on all its PCs.
If OS/2 was any good (having enough 3rd party application and hardware
support to compete) then IBM would not have needed to ship Windows on any
PCs would they? OS/2 was already dead, what you suggest might just have
been the last nail in its coffin.
--
nospam
>On Fri, 10 Jul 2009 16:50:57 +0100, nospam <nos...@please.invalid>
>wrote:
>
>>[OS2/] died because of IBM's insistence it ran on brain dead 286s (to
>>satisfy their hardware customers who had purchased lots of expensive PS/2
>>boxes with brain dead processors).
>>
>>At the time Microsoft embraced the 386 which really could run Windows and
>>DOS programs fine.
>OS/2 was better than Windows until NT4 appeared.
And Betamax was better than VHS. Windows 3 was worth buying just to run DOS
programs 'better', at the time OS/2 was worse at running DOS programs than
DOS. That's when the battle was lost.
--
Nobody
>>>>I can't see the cost of tools being a significant factor for major
>>>>customers. Even if they charge nothing for the software, the time it
>>>>takes for an engineer to get up to speed on the platform will equate to a
>>>>few grand in salary.
>>>
>>> Are you grazy? It takes me a day to get into a new platform and start
>>> working with it. Period. Last time I had to do a PIC design. The days
>>> work included writing a wrapper so PICC could be invoked like it is
>>> GCC from Eclipse.
>>
>>There's a difference between "start working with" and "up to speed". A big
>>difference.
>
> Nope.
Yep.
> A microcontroller always has memory (ram/rom), a cpu and
> peripherals.
And there the similarity ends. Even that's overstating the case; whether
RAM and ROM share the same address space makes quite a difference.
> If you've seen one, you've seen them all.
Far from true. The term "microcontroller" covers everything from a 32-bit
ARM/MIPS/AVR32 RISC chip down to a PIC10. Programming the former is
closer to programming a PC than to programming a PIC10.
It's not even as if PICs are all the same; "PIC" just means "one of
Microchip's 5 substantially different architectures".
It's not even as if the 8-bit PICs are all the same; there's a lot of
difference between the the low-end (banked, 2-level stack, no interrupts,
unable to read program memory), mid-range (8-level stack, has interrupts,
able to read program memory) and high-end (access bank, flat indirect
addressing, 31-level stack, byte-addressed program memory, multiple
FSR/INDF sets, high/low priority interrupts, separate PORTx/LATx
registers, built-in multiply, ...).
If you think that using C makes the low-level details irrelevant, expect
to end up with code which is 3x larger and 3x slower than if it had been
written with the details in mind.
krw
wrote:
>"Joel Koltner" <zapwireD...@yahoo.com> wrote:
>
>>"Walter Banks" <wal...@bytecraft.com> wrote in message
>>news:4A57468...@bytecraft.com...
>>> We encourage and support our customers to use the IDE they are familiar
>>> with (most have company standards on IDE's).
>>
>>Really? I've yet to work at any company that standardized on a particular
>>IDE -- they are just too many bits and pieces that don't typically interface
>>"nicely" to a generic IDE. I mean, can you actually debug PICs or AVRs or
>>MSP430s using Eclipse with a standard interface that gives you source code,
>>diassembly, breakpoints, watch windows, registers, etc.?
>>
>>The vast majority of microcontroller programmers I've met just use the IDE
>>that comes with the tools. I'd even go so far as to say that no more than 1
>>user in 50 uses the more advanced features of any given IDE such as scripting.
>
>Well, I use Eclipse for almost everything except 8051. But I never use
>debugging except for Windows and Linux (which I also use to debug
>software that goes into embedded platforms). There is not much use in
>debugging a microcontroller. The non-realtime stuff is easier & faster
>to debug when run on Windows or Linux. The realtime stuff can't be
>debugged because the moment you halt there is no more realtime...
You're sure showing your (lack of) debugging skills. If the bug can't
be found single stepping, you simply halt *after* (or on) the failure,
then track backwards to it.
krw
<for.addr...@www.ai.uga.edu.slash.mc> wrote:
>David Brown wrote:
>
>> Then there are the other benefits of having zero cost tools. Typically
>> you can download them and start working immediately - there are no
>> purchase orders to deal with, no waiting for dongles in the post, no
>> contracts to sign. You can install them on multiple computers or at
>> home offices without worrying about licenses. You never have to make
>> decisions like "it would be useful to have this running on the laptop as
>> well - but is it worth x thousand dollars?".
>>
>> I don't mean to say that all tools should be free - just that
>> microcontroller manufacturers would do well to make good free tools
>> easily available, even within professional markets. They (or third
>> parties) can profit from charging for /better/ tools - but only
>> providing bad tools for free is, IMHO, a silly strategy.
>
>Well said!
>
>The same goes for operating systems. Remember OS/2? If I had been IBM
>management, I would have paid Borland to port Delphi to it. There would
>then have been a flurry of reasonably good GUI software for OS/2. As it
>was, hardly any application software was ever developed for OS/2, and it
>died out as soon as its half-brother Windows 95 came along.
IBM paid a *ton* of software developers to port their wares to OS/2.
They took the money and didn't come across.
krw
<david...@hesbynett.removethisbit.no> wrote:
>nospam wrote:
>> David Brown <david...@hesbynett.removethisbit.no> wrote:
>>
>>> Of course, I have to agree that porting Delphi (and other Borland tools)
>>> would have been a big help too.
>>>
>>> But the death of OS/2 had little to do with lack of software (almost all
>>> DOS/Windows software at the time ran fine on OS/2,
>>
>> OS/2 was a dead man walking long before it could run DOS/Windows software
>> fine.
>>
>> I died because of IBM's insistence it ran on brain dead 286s (to satisfy
>> their hardware customers who had purchased lots of expensive PS/2 boxes
>> with brain dead processors).
>>
>
>My experience with OS/2 began with Warp (OS/2 3.0), which was a very
>different OS than OS/2 2 (which again was very different from version
>1). It was only with Warp that OS/2 gained significant followers, and
>it needed a 386 or better.
I used 1.0, 1.1, 1.3 (skipped M$' 1.2), and 2.0. All but 1.0 were far
better DOS than DOS. V1.3 was particularly good, but still only
allowed one DOS box.
>> At the time Microsoft embraced the 386 which really could run Windows and
>> DOS programs fine.
>>
>
>At the time of Warp, Windows was at 3.11 (or the very rare NT 3.51), and
>could run many DOS programs reasonably (and obviously current windows
>programs). However, Windows was in reality single-tasking (since it was
>a co-operative multi-tasking system, and windows programs were not
>co-operative), although it could do some limited DOS multi-tasking.
>OS/2 was vastly better, and could properly multi-task windows software
>and DOS software. In particular, it was much better for DOS since it
>allowed more flexible graphics and significantly better memory management.
Yep, until M$ started crippling WinOS2.
>> IBM chose hardware backward compatibility over software backward
>> compatibility - very very dumb.
>>
>
>The main cause of death was that that MS told IBM that if it wanted OEM
>discounts on its windows PCs, it had to install windows on *all* its
>machines. If it shipped PCs with OS/2 pre-installed, they would have to
>pay full customer prices for every PC it shipped with windows. IBM said
>"fair enough", and installed windows on all its PCs.
That's not 100% true. IBM, and all other box makers, had to buy a Win
license for every box built ("simplified accounting") to get the best
OEM price. OS/2 was then an additional cost. M$ wasn't *that*
stupid.
krw
wrote:
>George Neuner <gneu...@comcast.net> wrote:
>
>>On Fri, 10 Jul 2009 16:50:57 +0100, nospam <nos...@please.invalid>
>>wrote:
>>
>>>[OS2/] died because of IBM's insistence it ran on brain dead 286s (to
>>>satisfy their hardware customers who had purchased lots of expensive PS/2
>>>boxes with brain dead processors).
>>>
>>>At the time Microsoft embraced the 386 which really could run Windows and
>>>DOS programs fine.
>
>>OS/2 was better than Windows until NT4 appeared.
>
>And Betamax was better than VHS.
False analogy. Betamax was *not* better than VHS, where it counted.
>Windows 3 was worth buying just to run DOS
>programs 'better', at the time OS/2 was worse at running DOS programs than
>DOS. That's when the battle was lost.
Absolute nonsense. Even OS/2 V1.1 was a better DOS than DOS.
krw
wrote:
>Nobody <nob...@nowhere.com> wrote:
>
>>On Thu, 09 Jul 2009 23:02:33 +0000, Nico Coesel wrote:
>>
>>>>I can't see the cost of tools being a significant factor for major
>>>>customers. Even if they charge nothing for the software, the time it
>>>>takes for an engineer to get up to speed on the platform will equate to a
>>>>few grand in salary.
>>>
>>> Are you grazy? It takes me a day to get into a new platform and start
>>> working with it. Period. Last time I had to do a PIC design. The days
>>> work included writing a wrapper so PICC could be invoked like it is
>>> GCC from Eclipse.
>>
>>There's a difference between "start working with" and "up to speed". A big
>>difference.
>
>Nope. A microcontroller always has memory (ram/rom), a cpu and
>peripherals. If you've seen one, you've seen them all. Ofcourse there
>are people that like to toy around and try to get every peripheral
>working without looking at the examples. Those people need a month to
>get started... I'd fire them asap.
You've *got* to be kidding! I've never seen two interrupt controllers
that work the same way. It takes some time to even get GPIO bits
sorted out. Timer/counters? You _must_ be a C hack.
krw
<for.addr...@www.ai.uga.edu.slash.mc> wrote:
>Nico Coesel wrote:
>
>>> customers. Even if they charge nothing for the software, the time it
>>> takes for an engineer to get up to speed on the platform will equate to a
>>> few grand in salary.
>>
>> Are you grazy? It takes me a day to get into a new platform and start
>> working with it. Period.
>
>Yes... If it took $5k worth of time to get into a new platform, I would
>never have gotten into any platforms at all!
$5K is only a week or two.
krw
wrote:
>On Jul 9, 11:20�pm, krw <k...@att.bizzzzzzzzzzz> wrote:
>
>> >> Classic attitude of a company just about to go bust.
>>
>> >Eh... You do know that in the very recent past it looked as if
>> >Microchip was going to buy Atmel, right?
>>
>> And this is relevent how?
>
>uChip was/is financially much better off than its technically superior
>competition.
That may well be, but totally irrelevant to anything I've said.
larwe
> On Fri, 10 Jul 2009 01:52:43 -0700 (PDT), larwe <zwsdot...@gmail.com>
> wrote:
>
> >On Jul 9, 11:20 pm, krw <k...@att.bizzzzzzzzzzz> wrote:
>
> >> >> Classic attitude of a company just about to go bust.
>
> >> >Eh... You do know that in the very recent past it looked as if
> >> >Microchip was going to buy Atmel, right?
>
> >> And this is relevent how?
>
> >uChip was/is financially much better off than its technically superior
> >competition.
>
> That may well be, but totally irrelevant to anything I've said.
Look at the requotes above, and reconcile "about to go bust" with
"financially good enough to buy its competition".
JosephKK
Goodness, so many claims. Does any of you have any backup?
krw
wrote:
>On Jul 10, 8:39�pm, krw <k...@att.bizzzzzzzzzzz> wrote:
Try a remedial reading class. This time, stay awake.
Nico Coesel
That still needs something to trigger when the failure occurs. If you
do that manually you'll be too late to get a proper stack trace.
Nico Coesel
So interrupt controller A makes eggs and interrupt controller B makes
bacon? Come on, put the bits in the right place and every interrupt
controller gets you an interrupt.
Nico Coesel
>On Fri, 10 Jul 2009 15:35:55 +0000, Nico Coesel wrote:
>
>>>>>I can't see the cost of tools being a significant factor for major
>>>>>customers. Even if they charge nothing for the software, the time it
>>>>>takes for an engineer to get up to speed on the platform will equate to a
>>>>>few grand in salary.
>>>>
>>>> Are you grazy? It takes me a day to get into a new platform and start
>>>> working with it. Period. Last time I had to do a PIC design. The days
>>>> work included writing a wrapper so PICC could be invoked like it is
>>>> GCC from Eclipse.
>>>
>>>There's a difference between "start working with" and "up to speed". A big
>>>difference.
>>
>> Nope.
>
>Yep.
>
>> A microcontroller always has memory (ram/rom), a cpu and
>> peripherals.
>
>And there the similarity ends. Even that's overstating the case; whether
>RAM and ROM share the same address space makes quite a difference.
>
>> If you've seen one, you've seen them all.
>
>Far from true. The term "microcontroller" covers everything from a 32-bit
>ARM/MIPS/AVR32 RISC chip down to a PIC10. Programming the former is
>closer to programming a PC than to programming a PIC10.
If you program an ARM like a PC then you'll run into trouble with the
amount of memory. I did manage to get an SSL stack intended for a PC
environment to run on an ARM controller but not without writing a
managed malloc implementation first.
>It's not even as if PICs are all the same; "PIC" just means "one of
>Microchip's 5 substantially different architectures".
>
>It's not even as if the 8-bit PICs are all the same; there's a lot of
>difference between the the low-end (banked, 2-level stack, no interrupts,
>unable to read program memory), mid-range (8-level stack, has interrupts,
>able to read program memory) and high-end (access bank, flat indirect
>addressing, 31-level stack, byte-addressed program memory, multiple
>FSR/INDF sets, high/low priority interrupts, separate PORTx/LATx
>registers, built-in multiply, ...).
IOW PIC Is Crap (at least the 8 bit ones). One of the very few
architectures that doesn't port C very well. A current project I'm
working on involves a PIC16 and an ARM. Because of the crappy PIC16
architecture I have two different implementations of the same code for
a communication protocol.
>If you think that using C makes the low-level details irrelevant, expect
>to end up with code which is 3x larger and 3x slower than if it had been
>written with the details in mind.
I never said C makes the low level details irrelevant. Don't put words
into my 'mouth'! I don't think I even mentioned C before.
Anyway, IMHO getting a microcontroller going is a matter of figuring
out how to program the damn thing (get your code in the flash),
getting the toolchain setup, getting a port-pin to toggle from
software. From this point you know the hardware is working at a basic
level. From there you can start to setup the rest of the peripherals
you need. I like to keep a positive perspective knowing that it is a
process that can be applied to any microcontroller because they
basically all do the same. Why should that be difficult? Or am I
working with too many platforms?
Dombo
> On Fri, 10 Jul 2009 16:50:57 +0100, nospam <nos...@please.invalid>
> wrote:
>
>> [OS2/] died because of IBM's insistence it ran on brain dead 286s (to
>> satisfy their hardware customers who had purchased lots of expensive PS/2
>> boxes with brain dead processors).
>>
>> At the time Microsoft embraced the 386 which really could run Windows and
>> DOS programs fine.
>
> And then, for years, gave us a shared memory process model with
> cooperative multitasking.
>
> Windows, too, was originally designed for the 286, and it retained
> that unfortunate legacy for nearly 10 years.
Actually Windows 1.0 was designed for the 8086. Some remnants of that
legacy you can still find in the API today. For example the
GlobalLock()/GlobalUnlock() functions were originally to have a sort of
virtual memory on a processor that didn't have the features to support
virtual memory transparently to the application programs.
David Brown
> David Brown <david...@hesbynett.removethisbit.no> wrote:
>
>>> I died because of IBM's insistence it ran on brain dead 286s (to satisfy
>>> their hardware customers who had purchased lots of expensive PS/2 boxes
>>> with brain dead processors).
>>>
>> My experience with OS/2 began with Warp (OS/2 3.0),
>
> When Windows had already won.
>
Windows was most certainly dominant, but it was not yet a given that it
had "won". Warp could do everything that current windows could do, and
do it much better. It could do everything Win95 could do even though it
was out a year before Win95 came out. And it was easier to use, and
nicer to look at, as well as having more functionality, and being more
secure (DOS and Windows viruses came on disks rather than email in those
days, but were still prevalent).
There were some limitations on hardware compatibility and drivers, but
these were fairly small and of little effect in the target group
(business users). OS/2 did have greater memory requirements to run
smoothly - preferably 16 MB, which was a lot at the time (NT 3.51 was
similar).
The key was software compatibility. As I said, OS/2 was much better for
running Win16 and DOS programs than any other system. It could not run
Win32 software (the NT 3.51 api), because MS wouldn't give out the
details. But MS and IBM had agreements on the Win32s API (32-bit data
and flat memory addresses, but missing things like multi-threading)
which was becoming popular for larger programs on Win3.1. Win32s
programs ran fine on NT 3.51, at least as well on OS/2, and acceptably
on Win3.1 (if you didn't need to do anything else at the same time).
There were hopes and plans from both MS and IBM (and others, including
*nix vendors) that the software industry would solidify around a few
standardised APIs (Win32 and posix in particular) so that any modern
operating system would have an implementation or translation layer for
all these APIs and be able to software written for any API. That way
people could pick the OS based on things like hardware support, easy of
use, and OS-level features without having to worry about software
compatibility. Applications might look a little out-of-place if they
were not native, but they would run. As an example, NT has limited
posix support, and can also run OS/2 16-bit command line binaries (I
don't know if that support still exists in NT's descendants).
When MS saw that OS/2 was actually gaining noticeable market share (even
though almost no one sold pre-installed machines), they changed tactics
and killed it off. I believe their insistence that manufacturers (IBM
included) paid for Windows licenses for each machine made, regardless of
whether or not Windows was installed, was later condemned in court -
long after the damage was done to consumers, suppliers, and the
industry. PC manufacturers had to choose between selling only Windows
machines, or selling no windows machines - guess which they choose?
Major software developers were put under similar pressure.
Then there were tricks with software compatibility. I can't remember
off-hand what version of Win32s OS/2 supported, but shortly after it was
released, MS made a new version - the only difference was that the
initialisation routine checked for OS/2 and gave a error message about
requiring a newer version of Win32s. Thus any new software built with
the latest Win32s would not run on OS/2.
Of course, MS didn't have to work /too/ hard to cripple OS/2. IBM's
PHBs were doing a fine job themselves in various ways, and MS's
marketing people could easily make the Win95 vapourware sound far more
attractive than Warp.
In a sense you are right that windows had already won - history has
shown repeatedly that those who partner with MS or trust in their
promises and commitments will lose out sooner or later.
David Brown
> On Fri, 10 Jul 2009 22:09:25 +0200, David Brown
> <david...@hesbynett.removethisbit.no> wrote:
>
>> nospam wrote:
>>> David Brown <david...@hesbynett.removethisbit.no> wrote:
>>>
>>>> Of course, I have to agree that porting Delphi (and other Borland tools)
>>>> would have been a big help too.
>>>>
>>>> But the death of OS/2 had little to do with lack of software (almost all
>>>> DOS/Windows software at the time ran fine on OS/2,
>>> OS/2 was a dead man walking long before it could run DOS/Windows software
>>> fine.
>>>
>>> I died because of IBM's insistence it ran on brain dead 286s (to satisfy
>>> their hardware customers who had purchased lots of expensive PS/2 boxes
>>> with brain dead processors).
>>>
>> My experience with OS/2 began with Warp (OS/2 3.0), which was a very
>> different OS than OS/2 2 (which again was very different from version
>> 1). It was only with Warp that OS/2 gained significant followers, and
>> it needed a 386 or better.
>
> I used 1.0, 1.1, 1.3 (skipped M$' 1.2), and 2.0. All but 1.0 were far
> better DOS than DOS. V1.3 was particularly good, but still only
> allowed one DOS box.
>
I didn't use OS/2 until Warp 3.0, and it allowed multiple DOS boxes. A
particularly nice feature was that programs could get something like
720K conventional memory - much higher than with "real" DOS.
>>> At the time Microsoft embraced the 386 which really could run Windows and
>>> DOS programs fine.
>>>
>> At the time of Warp, Windows was at 3.11 (or the very rare NT 3.51), and
>> could run many DOS programs reasonably (and obviously current windows
>> programs). However, Windows was in reality single-tasking (since it was
>> a co-operative multi-tasking system, and windows programs were not
>> co-operative), although it could do some limited DOS multi-tasking.
>> OS/2 was vastly better, and could properly multi-task windows software
>> and DOS software. In particular, it was much better for DOS since it
>> allowed more flexible graphics and significantly better memory management.
>
> Yep, until M$ started crippling WinOS2.
>
>>> IBM chose hardware backward compatibility over software backward
>>> compatibility - very very dumb.
>>>
>> The main cause of death was that that MS told IBM that if it wanted OEM
>> discounts on its windows PCs, it had to install windows on *all* its
>> machines. If it shipped PCs with OS/2 pre-installed, they would have to
>> pay full customer prices for every PC it shipped with windows. IBM said
>> "fair enough", and installed windows on all its PCs.
>
> That's not 100% true. IBM, and all other box makers, had to buy a Win
> license for every box built ("simplified accounting") to get the best
> OEM price. OS/2 was then an additional cost. M$ wasn't *that*
> stupid.
>
All manufacturers had to use "simplified accounting" (or pay a huge
extra cost), which meant that if they wanted to ship windows on more
than a few machines, they had to buy windows for all their machines.
This was enough to stop OS/2 being shipped by non-IBM manufacturers
because, as you say, it was an additional cost. But for IBM the cost of
installing OS/2 would have been minimal since it was their system -
there were extra clauses in the MS license deal with IBM to specifically
exclude OS/2 pre-installs beyond the usual "simplified accounting". I
don't remember the details at all, but I believe IBM got an even greater
windows discount for installing windows on 100% of their machines - MS
practically gave away windows licenses to IBM to avoid any competition.
The Real Andy
<d...@tgi-sci.com> wrote:
>On Jul 8, 12:32�pm, The Real Andy <thereala...@nospam.com> wrote:
>> ...
>> Its interesting this. Is microchip going to release the compiler free
>> of charge? Atmel uses gcc, so it must be getting some good market
>> share on that aspect alone. I recently did some work on the AP7000
>> running linux, and whilst I hate linux its clear that Atmel has done a
>> lot of work to make it all free. Gcc is pretty good, can microchip
>> beat it?
>
>Their 32-bit parts are MIPS based, which should be GNU covered
>OK - so I guess they won't try to beat it. My guess is they will
>want to make some "point and click" kind of thing for those who
>find "normal" programming as we know it (command line, text
>editing etc. "very difficult" things) too complex a task...
Well they way I see it is you can do it the hard way or the easy way.
I like the easy way. Means I can get something to market quickly, and
more time for me or more time to develop new stuff for my customer.
Yup, I can do the command line stuff, but if they take care of it for
me its one less thing i need to do and the happier I am. Bring it on I
say.
> The bad news is if they do so they will likely get hugely
>popular (being already more popular than they should be to my
>taste, many people nowadays thing "PIC" is just a synonym of
>"MCU" ).
Popular is not all bad. Popular means they can throw more money at it
and make it easier. Always a good thing. If you use the argument that
idiots can do it, well true, but idiots cant make a good product and
will always fail.
>
>Dimiter
>
>------------------------------------------------------
>Dimiter Popoff Transgalactic Instruments
>
>http://www.tgi-sci.com
>------------------------------------------------------
>http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/