mikroElekronika vs microchip

I assume you're talking about C-language programming.

I worked with the Mikroelektronika tools, briefly, for a customer who just had to use a PIC processor. We changed over to the Hi-Tech tool chain, and while it is still severely limited by the processor, I could at least promise to get the work done. I've also used the Microchip compiler.

Here are my impressions:

The Mikroelektronika tool chain is -- or at least was in 2008 -- a toy, or a marketing gimmick for Mikroelektronika hardware. Yes, it's great for casual stuff using all-Mikroelektronika hardware. But you're not going to make real production code with it.

Both the Hi-Tech compiler and the Microchip compiler (I can't even remember if they're two different things or if the Microchip compiler is just a free come-on for the Hi-Tech) are much better than he Mikroelektronika, but they allow themselves to be shaped by the limitations of the PIC hardware to a much greater degree than they commit to being ANSI-C compatible. This is most visible when you start (properly) declaring things as const: both of these compilers (quite properly) put 'const' variables into read-only program space and mutable variables into data space; but both of them (quite improperly) make a pointer to 'const' disjoint from a pointer to data -- so you cannot, for instance, do the following:

const int default_value; int running_value;

tune(&default_value); tune(&running_value);

You can't do this because your 'tune' function would need to take a pointer to const int, but _quite unlike ANSI-C_, the compiler barfs when you try to pass it a pointer to 'regular old' mutable data.

I have not used it, but sdcc (Small Device C Compiler) explicitly takes care of this problem, at the cost of using 24-bit pointers (two bytes for the address, and one byte for a tag that says it's ROM or RAM). Unfortunately, the last time I looked it still didn't look 'real' for PIC processors.

So, my personal bias is:

1: When confronted with a proposed PIC-processored project, try to talk the customer into a better processor unless volumes are high or there is some other compelling reason.

2: If the design decision to use a PIC survives step 1, see if the application is small enough to just use assembly, and stick to it if so.

3: If the design decision survives steps 1 & 2, check up on the SDCC project and see if they've made it beyond 'hobbyist' stage -- then estimate the software effort in light of the fact that I will be unable to reuse _any_ of my home-grown library code, and use the Microchip or Hi- Tech tool chains.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

They are different, as long as "if picXX >=3D 24".

Not a problem "if picXX >=3D 24).

Yes, good choice "if picXX >=3D 24".

-

"if picXX >=3D 24, cc =3D gcc"

Did i make it clear to stay away from anything less than PIC24?

In think they are the same. IIRC Microchip acquired Hi-tech.

Which is why Harvard based processors are such a pain in the ass and make code unportable.

At the cost of overhead because each pointer needs to be evaluated first.

I totally agree. Choosing a PIC is choosing for a world of pain if you take a design beyond hobby level. MSP430 and ARM Cortex-M0 devices are a much better choice for the same price. Even better: the tools are free for both MSP430 and ARM. The only reason to use a PIC would be the DIP package.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Ditto a pain, but consider Atmel AVRs... free dev tools and simulators, but stick with AVR Studio 4.xx, not 5.xx

s

ut

AVR8 has the same PROG/DATA pointer issue. AVR32, PIC32 and ARM32 don't.

But at least AVR8 is less painful to use than PIC8.

I just got bitten badly by Atmel. I'll pass.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

Well, yes, but the OP did specifically mention the PIC18.

If you're going to go away from the PIC18, I would suggest that you use a PIC ARM Cortex M3, and subtract the "PIC".

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Il giorno luned=EC 12 marzo 2012 17:48:42 UTC+1, Tim Wescott ha scritto:

CUT thanks for your answer, I really appreciated it!

=20

the "limit" is our past experience not the customer preferences... in this = case customer doesn't require a specific microcontroller but requires fast = time-to-market; my expercience with pic is enough to start the new project just tomorrow; s= witching to different processor like arm may requires some extra-time; and = directly start to program arm (or any other uC) in C I think is not the bes= t way to go

is not small enough, eth is requested

thanks

-ice-

What do you mean by "real ICE"? If you mean a JTAG debugging chain that's as least as capable as the proprietary serial one used by Microchip, then they all come with it.

And tools can be free.

Switching to an ARM from a PIC with Elektronika tools should take about the same amount of rewriting as switching to a decent compiler on a PIC, and when you're done you'll be a lot better off.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Il giorno marted=EC 13 marzo 2012 04:02:47 UTC+1, Tim Wescott ha scritto:

this one:

-ice-

That name is so far from reality that it just about constitutes an outright lie.

"ICE" stands for In Circuit Emulator, which is a gizmo that you plug into a board in place of a (socketed) processor; that "Real" ICE is just a fancier box for connecting to a processor's serial debugging port.

You can get fancy boxes to plug into ARM processor JTAG ports that are undoubtedly faster than the $50 dongles you can get from Sparkfun (when the bugs don't get into the way). If you just can't survive unless they're named "Real" then you'll have to get out your markers.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

You might want to check out what's available from IAR. They do a good job of hand-holding with their IDE; if you just want to write code and go with a simple app that'll do you.

Of course, I've never met a proprietary IDE & tool set that didn't try to "help" you by hiding "messy" details that get in the way of making the lights blink, but that you absolutely have to deal with in the long run. It's why I prefer the Gnu tool chain and makefiles.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

There are a lot of us satisfied MikroElectronica Customers out here. It is unusual to see any of their hardware on ebay. I don't know of any shortcomings in any of the compilers. The IDEs work as advertised. They are very prompt to respond to all questions with tech's that know what they need to!

I th>hi all!

microcontroller, professional use;

but I've no experience with microchip toolchain nor mikroe one (always used ccs in the past)

John Ferrell W8CCW