Microchip buys Hi-Tech Software

formatting link

and of course, Hi-Tech will no longer supply compilers for competing processors:

formatting link

Dave.

Reply to
David L. Jones
Loading thread data ...

When I used it last (about 2001) Microchip's C compiler was about as bug-free as summer in Rimouski (or in Blue Bayou, for all the non-Canucks out there). Switching to Hi-Tech saved my project, but the libraries were different enough that that wasn't a trivial job.

I gather that Microchip is quietly deep-sixing its own compilers?

Cheers

Phil Hobbs

Reply to
Phil Hobbs

Yes, the Microchip compilers are notoriously bad and inefficient. Hi-Tech have always made excellent stable compilers that produce very tight and fast code, even on the smallest PIC's.

I hope so. Although I also hope they don't remove the "free" versions. It's nice having free (albeit performance crippled) C compilers that everyone can use. At present (or last I looked) the free versions of Hi-Tech compilers only supported a very restricted number of devices.

I can only presume that the Hi-Tech programmers will still be based in Australia?

Dave.

Reply to
David L. Jones

Do you have any reference, that Hi-Tech doesn't support competing processors? It sounds like a natural consequence, but I didn't found it in your links.

Would be bad, because then the free version of the Cypress PSoC C compiler would be not available any more.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

I sure like the philosophy of the SPCC, but it sure didn't seem to take off.

All of the available compilers for the PIC line drive me up the wall with their non-ANSI-ness. I'm too pedantic, I guess.

--
http://www.wescottdesign.com
Reply to
Tim Wescott

Dave.

Reply to
David L. Jones

Couldn't agree more. I started off with the Microchip compiler about

10 years ago. It drove me mad so I tried CC5X and then CC8E from Knudsen and I haven't looked back. They simply work and generate tight code.

I'm thinking of using their Leanslice multisker for the next project. Has anybody tried it?

Richard

Reply to
reswaby

Go to their web site and try to buy one....

Reply to
nospam

Me too. I have become a real believer in the preprocessor. I like to hide as much of the strangeness as possible. That and the use of int8, int16, and int32 and so on instead of char, int, and long that might not have lengths you expect.

Reply to
WangoTango

Hi-Tech just sold out, and they make really GOOD compilers.

I guess Microchip had plenty of money on hand after the Atmel deal fell through, a drop of which could buy out Hi-Tech 10 times over, or perhaps Hi-Tech weren't in the best of shape?, or perhaps the owners were tired and just wanted to get out? Anyone know what went down?

Dave.

Reply to
David L. Jones

Yes, but that was the 2nd time around. 20/20 hindsight ;-)

It was mostly just Clyde, so I wouldn't be surprised if he got jack of it and grabbed a sweet offer to retire.

Reply to
Clifford Heath

Good question. The traditional PIC is soon to be overtaken by the ARM derivatives. The hobby scene worked very well for Microchip, but they are quickly losing ground.

An excellent version of GCC is available for the PIC32 (MIPS based) platform. So why bother buying a compiler manufacturor?

--
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!"
--------------------------------------------------------------
Reply to
Nico Coesel

For some markets, sure... but in many commodity items like remote controls it doesn't make sense to use a $1 32-bit ARM when a $0.10 8-bit PIC still works just fine.

GCC for microcontrollers has never been as good as the best commercial compilers in code size or performance... and typically "customer support," although I'd grant that's a very difficult quantity to define. (E.g., there's no guarantee anyone will answer your GCC questions, but on the other hand, there's at least a chance the guy answering them is the guy who wrote the code in question, whereas that's almost never the case with commercial vendors.)

Reply to
Joel Koltner

Ah, but we are now in an era where the "microcontrollers" of today have the cores of the 32 bit processors that GCC was written for.

I would certainly trust GCC on a 32 bit machine, over something derived from, say, some line of "PIC compilers"!

--

John Devereux
Reply to
John Devereux

Well, they are already looking for new staff in Australia:

formatting link

I'll put my money on Clyde getting an offer he couldn't refuse. :-)

You get to a certain age, where your get up and go, has gone and went.

Don...

--
Don McKenzie

Site Map:            http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
No More Damn Spam:   http://www.wizard-of-oz.com

http://www.dontronics-shop.com/super4-usb-relay-module.html
Reply to
Don McKenzie

Good point. I also meant to point out that typically the "GCC penalty" on

8-bit CPUs is often not more than 10% or so in code space requirements and execution speed, and for many, many products that's just fine.

Plus the interface between C and assembly is pretty darned cool.

Reply to
Joel Koltner

Yes, but you'll need to sell quite a few units to make up for the price difference between free GCC and a $$$ toolkit. For high volume stuff, you're better off slapping an Asic together with some uC core inside. The 8051 core is probably even cheaper (almost free).

GCC for ARM and MIPS platforms is pretty darn good. Most commercial compilers will perform less. Just look at some independant comparisons. The problem with compiler manufacturor's benchmarks is that they usually compare their product with full optimisations on against GCC with all optimisations off.

GCC also works fine with most 16 bit controllers (like the Renesas H8 and the TI MSP430 series). Its the oddball controllers like the 8051 and PIC that require a more specific approach towards converting C into machine language.

Another advantage of using GCC is that you'll have one dialect and one development environment (for example Eclipse) for all your platforms. This makes changing to/porting to other/using multiple platforms a lot easier since you don't have to invest time in learning new tools.

--
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!"
--------------------------------------------------------------
Reply to
Nico Coesel

I would factor it into NRE -- when you have, say, 2 programmers spending 3 months developing some widget, that's probably $100k on salaries, do whether you choose a free tool or one for, e.g., $3k is pretty much irrelevant.

Granted, if GCC can do the job for you, by all means use it.

Agreed, GCC is quite competitive on 32-bit CPUs.

Heck, many commercial compilers are just GCC with proprietary support libraries for the hardware in question. :-)

Yeah, there's something to that, but of the various programmers I've known, only a small percentage actually used the more sophisticated features of the tools provided. I once had to explain to a programmer that there is more to the default "DEBUG" vs. "RELEASE" profiles than just "whether of not it #defines DEBUG". :-( You might be surprised at how many people ship DEBUG builds with zero optimizations, symbol tables included, etc. -- I even once had a programmer tell me that, "[he] ships DEBUG build executesbles because you should ship what you test, and since all testing is done with a DEBUG build, that's what we should ship." Wow. Although I suppose there is a certain perverse logic there that's true...

IAR likes to use this line of reasoning to promote their tools too -- their one IDE covers both 8- and 32-bit compilers.

Last time I used GCC my "IDE" was a command line and make files...

---Joel

Reply to
Joel Koltner

Do you think that 8-bit uCs are about to disappear?

Reply to
Nobody

Don McKenzie wrote: ...

I guess they need new staff after getting rid of some recently.

Tom

Reply to
Tom

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.