PIC/dsPIC development

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

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

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.