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

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.

Reply to
MC
Loading thread data ...

Yes... If it took $5k worth of time to get into a new platform, I would never have gotten into any platforms at all!

Reply to
MC

uChip was/is financially much better off than its technically superior competition.

Reply to
larwe

es,

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.

Reply to
larwe

And they do code-limited free versions (at least for AVR and ARM) that are entirely useable for smaller chips.

Reply to
Mike Harrison

Assuming the user is smart enough to understand that, and all the issues surrounding choice of vendor. I have frequently encountered customers who have gone with a particular chip on the basis of going to a seminar or being given a free eval board.

Reply to
Mike Harrison

They do. Problem is it is WAY below suboptimal.

Reply to
Mike Harrison

Yeah, right after I wrote the above I looked at the readme for the version of Hitech that MPLAB 8.33 dropped on my hard drive, and saw this.

Ironically, I have much less trouble spending $500 or $1000 on a tool for myself than I do when working in my day job. At home I decide: will this tool pay for itself over one or two projects? if the answer is yes, I pull out the checkbook. At work, it's much more complicated and painful.

I rarely do projects in pure asm any more. Occasionally I put in a little hand-optimized asm, but the vast majority of the code I write these days is in C. It's just so much faster to bring up and easier to maintain. So a good working C compiler is a must for me. No C compiler, and I don't use that micro.

Reply to
larwe

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.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

berichtnews: snipped-for-privacy@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

Reply to
Leon

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

Reply to
Walter Banks

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.

Reply to
David Brown

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

Reply to
OBones

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...
 Click to see the full signature
Reply to
Nico Coesel

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.

Reply to
larwe

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.

Reply to
nospam

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.

Reply to
MC

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.

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...
 Click to see the full signature
Reply to
Nico Coesel

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.

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

formatting link

Reply to
Vladimir Vassilevsky

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

Reply to
Joel Koltner

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.