Forums

mikroElekronika vs microchip

Started by ice March 12, 2012
hi all!
I need a complete toolchain (ide, compiler, hardware debugger, ...) for pic18 microcontroller, professional use;
I only know that mikroelektronika is a bit cheaper for the complete hw/sw tools but I've no experience with microchip toolchain nor mikroe one (always used ccs in the past)
budget up to 750/800 usd

thanks in advance for any suggestion coming from pratical experince
-ice-
On Mon, 12 Mar 2012 04:44:17 -0700, ice wrote:

> hi all! > I need a complete toolchain (ide, compiler, hardware debugger, ...) for > pic18 microcontroller, professional use; I only know that > mikroelektronika is a bit cheaper for the complete hw/sw tools but I've > no experience with microchip toolchain nor mikroe one (always used ccs > in the past) budget up to 750/800 usd
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
On Mar 12, 9:48=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> On Mon, 12 Mar 2012 04:44:17 -0700, ice wrote: > > hi all! > > I need a complete toolchain (ide, compiler, hardware debugger, ...) for > > pic18 microcontroller, professional use; I only know that > > mikroelektronika is a bit cheaper for the complete hw/sw tools but I've > > no experience with microchip toolchain nor mikroe one (always used ccs > > in the past) budget up to 750/800 usd > > I assume you're talking about C-language programming. > > ... > > 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)
They are different, as long as "if picXX >=3D 24".
> 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. =A0This 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);
Not a problem "if picXX >=3D 24).
> > 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.
Yes, good choice "if picXX >=3D 24".
> > 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. >
"if picXX >=3D 24, cc =3D gcc" Did i make it clear to stay away from anything less than PIC24?
Tim Wescott <tim@seemywebsite.com> wrote:

>On Mon, 12 Mar 2012 04:44:17 -0700, ice wrote: > >> hi all! >> I need a complete toolchain (ide, compiler, hardware debugger, ...) for >> pic18 microcontroller, professional use; I only know that >> mikroelektronika is a bit cheaper for the complete hw/sw tools but I've >> no experience with microchip toolchain nor mikroe one (always used ccs >> in the past) budget up to 750/800 usd > >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: > >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
In think they are the same. IIRC Microchip acquired Hi-tech.
>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.
Which is why Harvard based processors are such a pain in the ass and make code unportable.
>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).
At the cost of overhead because each pointer needs to be evaluated first.
>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.
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=.) --------------------------------------------------------------
>> >>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. > > 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. > > --
Ditto a pain, but consider Atmel AVRs... free dev tools and simulators, but stick with AVR Studio 4.xx, not 5.xx
On Mar 12, 11:22=A0am, "TTman" <pcw1....@ntlworld.com> wrote:
> >>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 i=
s
> >>some other compelling reason. > > > 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. > > > -- > > Ditto a pain, but consider Atmel AVRs... free dev tools and simulators, b=
ut
> stick with AVR Studio 4.xx, not 5.xx
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.
"TTman" <pcw1.cad@ntlworld.com> wrote:

>>> >>>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. >> >> 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. >> >> -- > >Ditto a pain, but consider Atmel AVRs... free dev tools and simulators, but >stick with AVR Studio 4.xx, not 5.xx
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=.) --------------------------------------------------------------
On Mon, 12 Mar 2012 11:15:37 -0700, linnix wrote:

> On Mar 12, 9:48&nbsp;am, Tim Wescott <t...@seemywebsite.com> wrote: >> On Mon, 12 Mar 2012 04:44:17 -0700, ice wrote: >> > hi all! >> > I need a complete toolchain (ide, compiler, hardware debugger, ...) >> > for pic18 microcontroller, professional use; I only know that >> > mikroelektronika is a bit cheaper for the complete hw/sw tools but >> > I've no experience with microchip toolchain nor mikroe one (always >> > used ccs in the past) budget up to 750/800 usd >> >> I assume you're talking about C-language programming. >> >> ... >> >> 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) > > They are different, as long as "if picXX >= 24". > >> 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. &nbsp;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); > > Not a problem "if picXX >= 24). > > >> 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. > > Yes, good choice "if picXX >= 24". > > >> 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. >> >> > "if picXX >= 24, cc = gcc" > > Did i make it clear to stay away from anything less than PIC24?
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!


> 1: When confronted with a proposed PIC-processored project, try to talk=
=20
> the customer into a better processor
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
> 2: If the design decision to use a PIC survives step 1, see if the=20 > application is small enough to just use assembly, and stick to it if so.
is not small enough, eth is requested thanks -ice-
Il giorno luned=EC 12 marzo 2012 19:15:37 UTC+1, linnix ha scritto:

> Did i make it clear to stay away from anything less than PIC24?
yes :) -ice-