Forums

PIC/dsPIC development

Started by bitrex November 4, 2018
On 4.11.18 22:12, bitrex wrote:
> I might have to work on a project involving dsPIC code which I don't > have a lot of experience with, I'm primarily an AVR and ARM guy. > > What's the hip current toolchains/dev boards y'all like to use for PIC > development on Linux or Windows desktops nowatimes?
dsPIC is a chip which is different from ARM, AVR and other PIC's. If ouy're not yet stuck with it, I'd recommend a Cortex-M3 or Cortex-M4 instead. There are as many DSP porperties, and the non-DSP side is much less unfriendly to program. I've done one project with a dsPIC, where we used the XC-16 compiler, which is a special version of GCC. I'd rather use a Cortex instead. -- -TV
On 04/11/2018 22:45, speff wrote:
> On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex wrote: >> I might have to work on a project involving dsPIC code which I don't >> have a lot of experience with, I'm primarily an AVR and ARM guy. >> >> What's the hip current toolchains/dev boards y'all like to use for PIC >> development on Linux or Windows desktops nowatimes? > > MPLAB-X with their compiler XC-16. It's a bit greedy with resources but okay on a modern machine. There is a free version with no optimization. I am not sure how well the DSP functionality is supported by the compiler, we just used it as a relatively fast 16-bit micro.
I've used the old MPLAB with C30 compiler on dsPICs extensively, though my DSP code is in assembler. The optimisers don't seem to do very much, Maybe because of the way I write C - certainly code size hardly varies between the four levels of optimisation and even goes the wrong way between two adjacent levels. Even with full optimisation, / 2 on an unsigned integer gets compiled as an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking pathetic. I've used MPLAB-X with XC-16 too because some newer dsPICs aren't supported by the old version. It's very slow to start up, no idea why except that so much modern software is shite. IIRC it does have one level of optimisation on the free version. I'd like to know exactly what the optimisers do.
> > The compiler is $995 but there is a 50% off discount coupon good to the end of this month. Use Coupon Code : TP1932 > > This family is a bit long in the tooth, but if your customer wants it.. > > --Spehro Pefhany >
Cheers -- Clive
On 05/11/2018 08:05, David Brown wrote:

<snipped>

> PIC microcontrollers are horrible to use and program, but their > long-term availability is unrivalled. They are also incredibly robust. > (We once had a customer who wanted help improving the temperature range > of their board. It ran fine up to 135 C, but they wanted to get to 150 > C. It turned out that the board had an 85 C qualified PIC on board - > but that was not the problem, and was quite happy at 150 C.)
I suspect there's just one version made, they're not graded or anything, and the temperature ratings are just marketing. Cheers -- Clive
On 11/05/2018 03:23 AM, 698839253X6D445TD@nospam.org wrote:
> bitrex wrote >> My time >>from concept to working prototype on breadboard is astonishingly low, >> sometimes just tens of minutes. > > Just lighting a LED can be done with one resistor too. >
Yeah anything more complex would be a big job to code if I had to punch in all the ones and zeros by hand, surely!
On 11/05/2018 06:01 AM, Clive Arthur wrote:
> On 04/11/2018 22:45, speff wrote: >> On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex&nbsp; wrote: >>> I might have to work on a project involving dsPIC code which I don't >>> have a lot of experience with, I'm primarily an AVR and ARM guy. >>> >>> What's the hip current toolchains/dev boards y'all like to use for PIC >>> development on Linux or Windows desktops nowatimes? >> >> MPLAB-X with their compiler XC-16. It's a bit greedy with resources >> but okay on a modern machine. There is a free version with no >> optimization. I am not sure how well the DSP functionality is >> supported by the compiler, we just used it as a relatively fast 16-bit >> micro. > > I've used the old MPLAB with C30 compiler on dsPICs extensively, though > my DSP code is in assembler.&nbsp; The optimisers don't seem to do very much, > Maybe because of the way I write C - certainly code size hardly varies > between the four levels of optimisation and even goes the wrong way > between two adjacent levels. > > Even with full optimisation, / 2 on an unsigned integer gets compiled as > an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking > pathetic. > > I've used MPLAB-X with XC-16 too because some newer dsPICs aren't > supported by the old version.&nbsp; It's very slow to start up, no idea why > except that so much modern software is shite.&nbsp; IIRC it does have one > level of optimisation on the free version. > > I'd like to know exactly what the optimisers do.
Try https://godbolt.org/ you can drop some of your C or C++ code into the box and see the asm output for many different compilers for many different targets at whatever optimization level, PIC is not one of them but it includes ARM, MIPS, AVR and MSP430 compilers. Sometimes on uP C or C++ compilers -Os (optimize size) can in fact produce larger binary size than some of the higher speed-optimization levels depending on the particulars, it happens. GCC has "#pragma optimize" switches that can be turned on and off inline to select different optimization levels for different blocks of code which can be handy sometimes (though non-portable.) On microcontrollers the binary size generally does not change that much between optimization levels it's true, the goal of the flags -O1, -O2, -O3 is to increase execution speed in whatever way that can be accomplished mostly irrespective of binary size, but it will usually reduce bianry size significantly as compared to -O0 (non optimization) simply cuz it aggressively removes non-reachable/superfluous code
On 11/05/2018 09:28 AM, bitrex wrote:
> On 11/05/2018 06:01 AM, Clive Arthur wrote: >> On 04/11/2018 22:45, speff wrote: >>> On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex&nbsp; wrote: >>>> I might have to work on a project involving dsPIC code which I don't >>>> have a lot of experience with, I'm primarily an AVR and ARM guy. >>>> >>>> What's the hip current toolchains/dev boards y'all like to use for PIC >>>> development on Linux or Windows desktops nowatimes? >>> >>> MPLAB-X with their compiler XC-16. It's a bit greedy with resources >>> but okay on a modern machine. There is a free version with no >>> optimization. I am not sure how well the DSP functionality is >>> supported by the compiler, we just used it as a relatively fast >>> 16-bit micro. >> >> I've used the old MPLAB with C30 compiler on dsPICs extensively, >> though my DSP code is in assembler.&nbsp; The optimisers don't seem to do >> very much, Maybe because of the way I write C - certainly code size >> hardly varies between the four levels of optimisation and even goes >> the wrong way between two adjacent levels. >> >> Even with full optimisation, / 2 on an unsigned integer gets compiled >> as an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking >> pathetic. >> >> I've used MPLAB-X with XC-16 too because some newer dsPICs aren't >> supported by the old version.&nbsp; It's very slow to start up, no idea why >> except that so much modern software is shite.&nbsp; IIRC it does have one >> level of optimisation on the free version. >> >> I'd like to know exactly what the optimisers do. > > Try https://godbolt.org/ you can drop some of your C or C++ code into > the box and see the asm output for many different compilers for many > different targets at whatever optimization level, PIC is not one of them > but it includes ARM, MIPS, AVR and MSP430 compilers.
It also shows a record of the compiler's passes and steps in the process of compiling the code, as it breaks the code down from high level to asm over many passes you can see how it examines and tags the structure of the code, organizes things into functional blocks, and then attempts to optimize them
On 11/05/2018 06:01 AM, Clive Arthur wrote:
> On 04/11/2018 22:45, speff wrote: >> On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex&nbsp; wrote: >>> I might have to work on a project involving dsPIC code which I don't >>> have a lot of experience with, I'm primarily an AVR and ARM guy. >>> >>> What's the hip current toolchains/dev boards y'all like to use for PIC >>> development on Linux or Windows desktops nowatimes? >> >> MPLAB-X with their compiler XC-16. It's a bit greedy with resources >> but okay on a modern machine. There is a free version with no >> optimization. I am not sure how well the DSP functionality is >> supported by the compiler, we just used it as a relatively fast 16-bit >> micro. > > I've used the old MPLAB with C30 compiler on dsPICs extensively, though > my DSP code is in assembler.&nbsp; The optimisers don't seem to do very much, > Maybe because of the way I write C - certainly code size hardly varies > between the four levels of optimisation and even goes the wrong way > between two adjacent levels. > > Even with full optimisation, / 2 on an unsigned integer gets compiled as > an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking > pathetic. > > I've used MPLAB-X with XC-16 too because some newer dsPICs aren't > supported by the old version.&nbsp; It's very slow to start up
the IDE is probably based on Microsoft Visual Studio sooooo that's par for the course there.
On 05/11/18 15:36, bitrex wrote:
> On 11/05/2018 06:01 AM, Clive Arthur wrote: >> On 04/11/2018 22:45, speff wrote: >>> On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex wrote: >>>> I might have to work on a project involving dsPIC code which I don't >>>> have a lot of experience with, I'm primarily an AVR and ARM guy. >>>> >>>> What's the hip current toolchains/dev boards y'all like to use for PIC >>>> development on Linux or Windows desktops nowatimes? >>> >>> MPLAB-X with their compiler XC-16. It's a bit greedy with resources >>> but okay on a modern machine. There is a free version with no >>> optimization. I am not sure how well the DSP functionality is >>> supported by the compiler, we just used it as a relatively fast >>> 16-bit micro. >> >> I've used the old MPLAB with C30 compiler on dsPICs extensively, >> though my DSP code is in assembler. The optimisers don't seem to do >> very much, Maybe because of the way I write C - certainly code size >> hardly varies between the four levels of optimisation and even goes >> the wrong way between two adjacent levels. >> >> Even with full optimisation, / 2 on an unsigned integer gets compiled >> as an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking >> pathetic. >> >> I've used MPLAB-X with XC-16 too because some newer dsPICs aren't >> supported by the old version. It's very slow to start up > > the IDE is probably based on Microsoft Visual Studio sooooo that's par > for the course there. >
Microchip's IDE is based on NetBeans, which is Java (quite similar to Eclipse). I haven't used it myself.
On Monday, 5 November 2018 06:01:16 UTC-5, Clive Arthur  wrote:
> On 04/11/2018 22:45, speff wrote: > > On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex wrote: > >> I might have to work on a project involving dsPIC code which I don't > >> have a lot of experience with, I'm primarily an AVR and ARM guy. > >> > >> What's the hip current toolchains/dev boards y'all like to use for PIC > >> development on Linux or Windows desktops nowatimes? > > > > MPLAB-X with their compiler XC-16. It's a bit greedy with resources but okay on a modern machine. There is a free version with no optimization. I am not sure how well the DSP functionality is supported by the compiler, we just used it as a relatively fast 16-bit micro. > > I've used the old MPLAB with C30 compiler on dsPICs extensively, though > my DSP code is in assembler. The optimisers don't seem to do very much, > Maybe because of the way I write C - certainly code size hardly varies > between the four levels of optimisation and even goes the wrong way > between two adjacent levels. > > Even with full optimisation, / 2 on an unsigned integer gets compiled as > an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking > pathetic. > > I've used MPLAB-X with XC-16 too because some newer dsPICs aren't > supported by the old version. It's very slow to start up, no idea why > except that so much modern software is shite. IIRC it does have one > level of optimisation on the free version. > > I'd like to know exactly what the optimisers do. >
I vaguely recall someone analyzing the code and it was "almost" as if they were deliberately making it use more instructions in the non-optimized version. --sp
On 11/05/2018 12:03 PM, speff wrote:
> On Monday, 5 November 2018 06:01:16 UTC-5, Clive Arthur wrote: >> On 04/11/2018 22:45, speff wrote: >>> On Sunday, 4 November 2018 15:12:28 UTC-5, bitrex wrote: >>>> I might have to work on a project involving dsPIC code which I don't >>>> have a lot of experience with, I'm primarily an AVR and ARM guy. >>>> >>>> What's the hip current toolchains/dev boards y'all like to use for PIC >>>> development on Linux or Windows desktops nowatimes? >>> >>> MPLAB-X with their compiler XC-16. It's a bit greedy with resources but okay on a modern machine. There is a free version with no optimization. I am not sure how well the DSP functionality is supported by the compiler, we just used it as a relatively fast 16-bit micro. >> >> I've used the old MPLAB with C30 compiler on dsPICs extensively, though >> my DSP code is in assembler. The optimisers don't seem to do very much, >> Maybe because of the way I write C - certainly code size hardly varies >> between the four levels of optimisation and even goes the wrong way >> between two adjacent levels. >> >> Even with full optimisation, / 2 on an unsigned integer gets compiled as >> an 18 cycle divide instead of a 1 cycle shift, which is IMO fucking >> pathetic. >> >> I've used MPLAB-X with XC-16 too because some newer dsPICs aren't >> supported by the old version. It's very slow to start up, no idea why >> except that so much modern software is shite. IIRC it does have one >> level of optimisation on the free version. >> >> I'd like to know exactly what the optimisers do. >> > I vaguely recall someone analyzing the code and it was "almost" as if they > were deliberately making it use more instructions in the non-optimized version. > > --sp >
I don't think e.g. -O0 actually adds anything superfluous it's just super dumb and does everything the dumbest by-the-book way possible to accomplish the task. It usually doesn't even remove dead/non-reachable code or perform calculations which can clearly be done at compile-time as with e.g. const variables. It's not uncommon with C++ code studying the output of https://godbolt.org/ for an unoptimized program consisting of 100 lines of source to compile to 100 lines or more of asm. Hit -O1 or -Os and not unusual for it to reduce to like, fifteen instructions.