Hi-Tech Software bought by Microchip - no more other compilers

Nico Coesel wrote:

> Walter Banks <walter@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..

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.

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.

larwe wrote:
> On Jul 9, 9:58 pm, "David L. Jones" <altz...@gmail.com> wrote:
> 
>> 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.

It's already the case and it's called Lite

Nobody <nobody@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.

-- 
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!"
--------------------------------------------------------------

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

David Brown <david.brown@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). 

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.


-- 

Rich Webb wrote:

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

larwe <zwsdotcom@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. 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!

-- 
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 wrote:
> larwe <zwsdotcom@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

"Walter Banks" <walter@bytecraft.com> wrote in message 
news:4A574681.1A6D66@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