Searching \ for '[PIC] dsPIC toolchain (GNU/Linux)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=spi
Search entire site for: 'dsPIC toolchain (GNU/Linux)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] dsPIC toolchain (GNU/Linux)'
2009\05\02@161323 by Peter Restall

flavicon
face

Evening All,

Forgive me if I miss anything out (or am asking an obvious question), but it's
been a long day - pretty much 12 hours straight trying to get the C30 sources
(v3.12) built and working under Ubuntu (8.04 Hardy Heron - kernel 2.6.24).
I've patched and hacked (just slightly :) the Debian templates from

http://www.nabble.com/Debian-templates-for-dsPIC-build-toolchain-3.01-td12265748.html

to get the system to build 3.12 rather than 3.01.  I've downloaded the eval
version of 3.12 from Microchip too so I have the libraries to link against.

I thought I'd pretty much got it - but I'm tearing my hair out trying to get
even a simple program to work.  My very simple, quick-n-dirty-first-attempt
program is below; intended just to flash an LED on/off on RB0.  I don't know
if it works or will work, so don't worry if the logic looks wrong (although
anything you spot I'd like to know - it might save me some time).

#include <p30f2010.h>

_FOSC(LPRC & CSW_FSCM_ON)
_FWDT(WDT_OFF)
_FBORPOR(MCLR_DIS & RST_IOPIN & PBOR_ON & BORV_45 & PWRT_64)
_FGS(CODE_PROT_OFF)
_FICD(ICS_NONE)

#ifndef _NOAUTOPSV
#define _NOAUTOPSV __attribute__((interrupt, no_auto_psv))
#endif

void _ISR _NOAUTOPSV _T1Interrupt(void)
{
       PORTBbits.RB0 ^= 0x01;
       IFS0bits.T1IF  = 0;
}

int main(int argc, char *argv[])
{
       /* Tri-state everything except RB0 */

       TRISBbits.TRISB0 = 0;


       /* Flash on for 1/2 second (256 period counter @ 500Hz increments) */

       TMR1 = 0;
       PR1  = 250;                     /* Period of 250 (half full ticks) */

       T1CONbits.TCKPS = 0x03;         /* Timer pre-scaler to 500Hz */

       T1CONbits.TON = 1;


       /* Never end... */

       while (1);

       return(0);
}

The bit I've labelled 'Never end' is the bit that's causing me grief.  My
makefile is:

MAP_OUT=blink.map
EXE_OUT=blink.out

CC=pic30-elf-gcc
CC_FLAGS=-mcpu=30f2010 -ansi -Wall -pedantic -c

LD=pic30-elf-ld
LD_SCRIPT=-T/usr/share/pic30-support/dsPIC30F/gld/p30f2010.gld
LD_LIB_PATH=-L/usr/pic30-elf/lib/ -L/usr/pic30-elf/lib/dsPIC30F
LD_LIBS=-lc -lpic30
LD_FLAGS=--heap=0 --no-data-init -Map=$(MAP_OUT) $(LD_SCRIPT) $(LD_LIB_PATH) -o

BIN2HEX=pic30-elf-bin2hex
BIN2HEX_FLAGS=-v

OBJS=blink.o

main:   $(OBJS)
       $(LD) $(LD_FLAGS) $(EXE_OUT) $(OBJS) $(LD_LIBS)
       $(BIN2HEX) $(EXE_OUT) $(BIN2HEX_FLAGS)

%.o: %.c
       $(CC) $(CC_FLAGS) -o $@ $<

Note that I need the --no-data-init for the linker otherwise I get tons of
similar errors as below (anybody know how I can get around that ?)  The error
I'm struggling with (the 'while (1);') is:

blink.o(.text+0x44): In function `.L4':
: Link Error: PC Relative branch to '.L4' is out of range. Suggest large-code
model.

An object dump on the gcc output file (blink.o) reveals this (part)
disassembly:

00000026 <_main>:
 26:   04 00 fa        lnk       #0x4
 28:   00 0f 78        mov.w     w0, [w14]
 2a:   11 07 98        mov.w     w1, [w14+2]
 2c:   00 00 a9        bclr.b    0x0, #0x0
 2e:   00 00 eb        clr.w     w0
 30:   00 00 88        mov.w     w0, 0x0
 32:   a0 0f 20        mov.w     #0xfa, w0
 34:   00 00 88        mov.w     w0, 0x0
 36:   01 00 20        mov.w     #0x0, w1
 38:   91 40 78        mov.b     [w1], w1
 3a:   00 c3 b3        mov.b     #0x30, w0
 3c:   00 c0 70        ior.b     w1, w0, w0
 3e:   00 e0 b7        mov.b     WREG, 0x0
 40:   01 e0 a8        bset.b    0x1, #0x7

00000042 <.L4>:
 42:   00 00 37        bra       0x44

It might be my head spinning but that bra disassembly doesn't look quite
right; I need to inspect the DS70157 instruction reference a bit more
closely I think.

I've tried adding nops in the loop, changing the loop to a do { } while (1) and
a for (;;) but they all produce the same linker error.  The linker error
disappears if I remove the loop.

Anybody got any ideas/managed to get v3.12 running under GNU/Linux ?  I
hope this isn't something obvious, but I really am cross-eyed now - apologies
if this is a little muddled, but please ask if I've missed anything/you need
clarification.  I think I'll have a dram and pack up for the night methinks.

Many thanks.

Regards,

Pete Restall

2009\05\02@174943 by olin piclist

face picon face
Peter Restall wrote:
> pretty much 12 hours straight trying to get
> the C30 sources (v3.12) built and working under Ubuntu
> <blah, blah, blah>
>
> I thought I'd pretty much got it - but I'm tearing my hair out trying
> to get even a simple program to work.  My very simple,
> quick-n-dirty-first-attempt program is below; intended just to flash an
> LED on/off on RB0.

Decide what the purpose of your post is and make it clear.

If it's a Linux question, then ask that (of course not under PIC).  If it's
a PIC question, then I don't see what Ubuntu has to do with it.  In either
case, you haven't asked a question so there is nothing to answer.  I can't
find a purpose to your post unless you think we'd all be enthralled by your
solution to the Grand Challange of blinking a LED.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\02@190313 by Herbert Graf

picon face
On Sat, 2009-05-02 at 17:49 -0400, Olin Lathrop wrote:
> Peter Restall wrote:
> > pretty much 12 hours straight trying to get
> > the C30 sources (v3.12) built and working under Ubuntu
> > <blah, blah, blah>
> >
> > I thought I'd pretty much got it - but I'm tearing my hair out trying
> > to get even a simple program to work.  My very simple,
> > quick-n-dirty-first-attempt program is below; intended just to flash an
> > LED on/off on RB0.
>
> Decide what the purpose of your post is and make it clear.
>
> If it's a Linux question, then ask that (of course not under PIC).  If it's
> a PIC question, then I don't see what Ubuntu has to do with it.  In either
> case, you haven't asked a question so there is nothing to answer.  I can't
> find a purpose to your post unless you think we'd all be enthralled by your
> solution to the Grand Challange of blinking a LED.

You're in an oddly crabby mood, and even more odd you don't seem to read
posts before responding.

It's rather clear to me that the OP is trying to build the C30 compiler
(under Ubuntu, which IS relavent) and is having problems with seemingly
normal code getting through without errors.

This is clearly PIC (getting PIC compilers operating on other OSs is
appropriate for the PIC tag).

It seems the word "Linux" threw you into some mode, next time please
don't bother wasting the list's time with it.

TTYL

2009\05\02@193756 by olin piclist

face picon face
Herbert Graf wrote:
> It's rather clear to me that the OP is trying to build the C30
> compiler (under Ubuntu, which IS relavent) and is having problems
> with seemingly normal code getting through without errors.

I'm not sure how you got that from the post, but it certainly wasn't clear.
There was some blah blah at top, no question, and then a bunch of source
code.

> next time please don't bother wasting the list's time with it.

My telling the OP I didn't understand him is a waste of time, but you
telling me that's a waste of time isn't?  It doesn't work that way.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\02@204405 by Xiaofan Chen

face picon face
On Sun, May 3, 2009 at 4:07 AM, Peter Restall <spam_OUTpeteTakeThisOuTspamrestall.net> wrote:
> Forgive me if I miss anything out (or am asking an obvious question), but it's
> been a long day - pretty much 12 hours straight trying to get the C30 sources
> (v3.12) built and working under Ubuntu (8.04 Hardy Heron - kernel 2.6.24).
> I've patched and hacked (just slightly :) the Debian templates from
>
> http://www.nabble.com/Debian-templates-for-dsPIC-build-toolchain-3.01-td12265748.html
>
> to get the system to build 3.12 rather than 3.01.  I've downloaded the eval
> version of 3.12 from Microchip too so I have the libraries to link against.
>
> Anybody got any ideas/managed to get v3.12 running under GNU/Linux ?  I
> hope this isn't something obvious, but I really am cross-eyed now - apologies
> if this is a little muddled, but please ask if I've missed anything/you need
> clarification.  I think I'll have a dram and pack up for the night methinks.
>

I would solve the problems in a different way. Now you have serveral
unknowns. Your program may be wrong, your hacked compiler may
be wrong. So you want to remove one unknown first.

For example, you can try the original V3.12 compiler (under Linux with Wine
or under Windows) and see if that works. If it works with your program,
then you know your modification is not correct. If it does not work with
the known-good compiler, then debug your program until it works.
After that, try your own compiler.

--
Xiaofan http://mcuee.blogspot.com

2009\05\02@205239 by Xiaofan Chen

face picon face
On Sun, May 3, 2009 at 4:07 AM, Peter Restall <.....peteKILLspamspam@spam@restall.net> wrote:
>
> Anybody got any ideas/managed to get v3.12 running under GNU/Linux ?  I
> hope this isn't something obvious, but I really am cross-eyed now - apologies
> if this is a little muddled, but please ask if I've missed anything/you need
> clarification.  I think I'll have a dram and pack up for the night methinks.
>

I just saw a comment in my blog. Apparently mhel has already got it
working.
http://mcuee.blogspot.com/2007/11/debian-template-to-build-gcc-for.html

Last time, there is a patch for V3.10 but it did not work.
http://www.microchip.com/forums/tm.aspx?m=342218

--
Xiaofan http://mcuee.blogspot.com

2009\05\03@104237 by Peter Restall

flavicon
face

On May 03, 2009; 01:44am, Xiaofan Chen wrote:

> I would solve the problems in a different way. Now you have serveral
> unknowns. Your program may be wrong, your hacked compiler may
> be wrong. So you want to remove one unknown first.
>
> For example, you can try the original V3.12 compiler (under Linux with Wine
> or under Windows) and see if that works. If it works with your program,
> then you know your modification is not correct. If it does not work with
> the known-good compiler, then debug your program until it works.
> After that, try your own compiler.

Xiaofan,

Thanks for the suggestions; I had aleady seen all of your links though - I did
wonder if you were the same Xiaofan !

As for your other suggestion, I have compiled blink.c via the same commands
under Windows, using the C30 eval version from Microchip, and it compiles/links
fine.  However, I am struggling to reconcile this result with the changes I
have made to the packages in order to get it to work on my Ubuntu installation.

I did not have to change any source files (in binutils, gcc or pic30-support),
only the Debian template build scripts and the path names in a few header files
(v3.12 has path names in a c30_flag_definitions.h header, so the changes are
very localised).

After putting some debug printf's in the binutils linker, I have discovered
that the problem is PC-relative relocations, or at least that's a symptom
that is manifesting itself and ultimately stopping the linker.  For some
reason, the linker is performing some right-shifts and causing back-references
(negative PC offsets) to turn into very large numbers.  These very large
numbers are then seen as addresses outside of the PIC's range.  It's almost as
if it should be shifting using the sign bit rather than zeroes - that would
make sense.  Alas, I'm not an expert with binutils, so I'd rather not try and
change any behaviour for fear of producing broken object code - that would be
even worse to troubleshoot.  Microchip have added some extra checks since the
last version of the source (to prevent segfaults), but they have not changed
the relocation logic itself.

I initially tried to use v3.01, which you and others have reported as working
under Ubuntu, but I get segfaults during the build process, which is why I
thought it better to try using a newer version.  I am running a 64-bit AMD
Turion, so I wonder if that could be the cause at all ?

I tend not to use Windows very often, so I would like to get this working if
possible - do you think Microchip would be interested in a dialogue or have I
got no chance ?  I doubt the binutils maintainers would help either since
they're Microchip enhancements and not core binutils.

Any suggestions on how to progress would be appreciated.

Regards,

Pete Restall

2009\05\03@105511 by Xiaofan Chen

face picon face
On Sun, May 3, 2009 at 10:37 PM, Peter Restall <petespamKILLspamrestall.net> wrote:
> I initially tried to use v3.01, which you and others have reported as working
> under Ubuntu, but I get segfaults during the build process, which is why I
> thought it better to try using a newer version.  I am running a 64-bit AMD
> Turion, so I wonder if that could be the cause at all ?

Are you using 64bit Linux? In that case, it may be the issue. I do not
see any benefits to run 64bit Linux (or Windows Vista 64) with PIC
development. It only causes problems...

> I tend not to use Windows very often, so I would like to get this working if
> possible - do you think Microchip would be interested in a dialogue or have I
> got no chance ?  I doubt the binutils maintainers would help either since
> they're Microchip enhancements and not core binutils.
>

I will say try 32bit Linux first and 3.01 first.

--
Xiaofan http://mcuee.blogspot.com

2009\05\03@110412 by Xiaofan Chen

face picon face
On Sun, May 3, 2009 at 10:55 PM, Xiaofan Chen <.....xiaofancKILLspamspam.....gmail.com> wrote:
> On Sun, May 3, 2009 at 10:37 PM, Peter Restall <EraseMEpetespam_OUTspamTakeThisOuTrestall.net> wrote:
>> I tend not to use Windows very often, so I would like to get this working if
>> possible - do you think Microchip would be interested in a dialogue or have I
>> got no chance ?  I doubt the binutils maintainers would help either since
>> they're Microchip enhancements and not core binutils.
>>
>
> I will say try 32bit Linux first and 3.01 first.
>

But I will send you the other person's V3.12 patch to see if that helps.
I have not tested it yet but I will do it within a week.

--
Xiaofan http://mcuee.blogspot.com

2009\05\03@111826 by Xiaofan Chen

face picon face
On Sun, May 3, 2009 at 11:04 PM, Xiaofan Chen <xiaofancspamspam_OUTgmail.com> wrote:
> On Sun, May 3, 2009 at 10:55 PM, Xiaofan Chen <@spam@xiaofancKILLspamspamgmail.com> wrote:
>> On Sun, May 3, 2009 at 10:37 PM, Peter Restall <KILLspampeteKILLspamspamrestall.net> wrote:
>>> I tend not to use Windows very often, so I would like to get this working if
>>> possible - do you think Microchip would be interested in a dialogue or have I
>>> got no chance ?  I doubt the binutils maintainers would help either since
>>> they're Microchip enhancements and not core binutils.
>>>
>>
>> I will say try 32bit Linux first and 3.01 first.
>>
>
> But I will send you the other person's V3.12 patch to see if that helps.
> I have not tested it yet but I will do it within a week.
>

Hopefully the patches I sent to you in private email work for you. If not,
try 32bit Linux.

If that still does not work, you can try Microchip support. You can
also give GNUPIC mailing list a shot. John Steele Scott was in
that list and he is the original author of the patches. I did some
testing last time.

--
Xiaofan http://mcuee.blogspot.com

2009\05\03@122359 by Peter Restall

flavicon
face

On May 03, 2009; 03:55pm, Xiaofan Chen wrote:

> Are you using 64bit Linux? In that case, it may be the issue. I do not
> see any benefits to run 64bit Linux (or Windows Vista 64) with PIC
> development. It only causes problems...

Xiaofan,

Thanks for your help with this.  I am indeed running a 64-bit Ubuntu install;
kernel and packages.  I've had no problems so far other than with proprietry
stuff without source (ie. Flash plugins, ATI drivers, that sort of thing).
Interestingly though, the C30 I successfully tested with is a 32-bit XP
installation (dual boot on this same Ubuntu box), so you might be onto
something there.

I have just removed all my pic30 installation attempts and tried the build
scripts/instructions you sent.  Unfortunately, I get exactly the same error
from the linker about the relative branch - I no longer get the syntax error
in the linker script for the OPTIONAL keyword though, so there's definitely
some difference between the versions.

I'm not willing to wipe my machine and put a 32-bit version on, and as I said
about v3.01, it segfaulted during the gcc build and I have no idea why.  I
think I'll try the GNUPIC list like you said; I'd certainly be willing to be
a tester for John if he is the official/unofficial package maintainer.

Many thanks,

Pete Restall

2009\05\03@205528 by Herbert Graf

picon face
On Sat, 2009-05-02 at 19:38 -0400, Olin Lathrop wrote:
> Herbert Graf wrote:
> > next time please don't bother wasting the list's time with it.
>
> My telling the OP I didn't understand him is a waste of time, but you
> telling me that's a waste of time isn't?  It doesn't work that way.

I'm an Admin telling you the error of your ways (since I easily
understood the meaning of the post and you are clearly more experienced
then I, I believe it is a fair assumption that you SHOULD have also
easily understood the post), that isn't a waste of time, and that is how
it works.

2009\05\03@234455 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 12:18 AM, Peter Restall <RemoveMEpeteTakeThisOuTspamrestall.net> wrote:
>
> I have just removed all my pic30 installation attempts and tried the build
> scripts/instructions you sent.  Unfortunately, I get exactly the same error
> from the linker about the relative branch - I no longer get the syntax error
> in the linker script for the OPTIONAL keyword though, so there's definitely
> some difference between the versions.

Unfortunately my test under Ubuntu 9.04 is of the same result just
like the test of the previous version V3.10 patches. I can build the
binutils but the installed version seg-faulted.

mcuee@ubuntu904:~/Desktop/c30$ pic30-elf-as
Segmentation fault
mcuee@ubuntu904:~/Desktop/c30$ pic30-elf-bin2hex

 pic30-elf-bin2hex -- convert an object file to Intel hex format
 Microchip %s Build date: May-04-2009
 usage: pic30-elf-bin2hex file [options]

 options:
   -a        sort sections by address
   -u        use upper-case hex digits
   -v        print verbose messages

mcuee@ubuntu904:~/Desktop/c30$ pic30-elf-ld
Segmentation fault

mcuee@ubuntu904:~/Desktop/c30$ pic30-elf-gcc
Segmentation fault

> I'm not willing to wipe my machine and put a 32-bit version on, and as I said
> about v3.01, it segfaulted during the gcc build and I have no idea why.  I
> think I'll try the GNUPIC list like you said; I'd certainly be willing to be
> a tester for John if he is the official/unofficial package maintainer.
>

So it does not seem to be related to 64bit Linux. The guy who sent
me the patches have lucks with Zenwalk Linux. I will try to use
Arch Linux first.

As for V3.01, I think you may need to try GCC-3.3 or 3.4 as CC.
I have not tried it under 9.04 but I have success with 6.06/7.10
before.

--
Xiaofan http://mcuee.blogspot.com

2009\05\04@000447 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 11:44 AM, Xiaofan Chen <spamBeGonexiaofancspamBeGonespamgmail.com> wrote:
> As for V3.01, I think you may need to try GCC-3.3 or 3.4 as CC.
> I have not tried it under 9.04 but I have success with 6.06/7.10
> before.
>

I can send you the binary packages from my archived Ubuntu 6.06
files. It seems to work under 9.04 as well. The file size is rather
big though so I am not sure if your email box is okay with the files.

mcuee@ubuntu904:~/Desktop/c30$ pic30-elf-gcc -v
Using built-in specs.
Target: pic30-elf
Configured with:
/home/mcuee/Desktop/dspic/pic30-3.01/pic30-gcc-3.01/build_dir/src/gcc-4.0.2/gcc-4.0.2/configure
-v --prefix=/usr --target=pic30-elf --enable-languages=c
--with-gcc-version-trigger=/home/mcuee/Desktop/dspic/pic30-3.01/pic30-gcc-3.01/build_dir/objs/version-trigger
Thread model: single
gcc version 4.0.3 (dsPIC30, Microchip v3.01, modified for Debian
GNU/Linux) Build date: Nov  8 2007

mcuee@ubuntu904:~/Desktop/c30$ ls -la *.deb
-rw-r--r-- 1 mcuee mcuee 11080940 2007-11-08 22:12
pic30-binutils_3.01-1_i386.deb
-rw-r--r-- 1 mcuee mcuee  5894628 2007-11-08 22:22 pic30-gcc_3.01-1_i386.deb

--
Xiaofan http://mcuee.blogspot.com

2009\05\04@010027 by Xiaofan Chen
face picon face
On Mon, May 4, 2009 at 11:44 AM, Xiaofan Chen <TakeThisOuTxiaofancEraseMEspamspam_OUTgmail.com> wrote:
>
> Unfortunately my test under Ubuntu 9.04 is of the same result just
> like the test of the previous version V3.10 patches. I can build the
> binutils but the installed version seg-faulted.
>

This is from the person who sent me the patches.
"I had the same problem initially that's why I ended up with a mixes
of patches, but I can't remember exactly what I did or what I did not
do. I just had to keep trying."

He also sent me screenshots and it worked for him apparently.

To Peter:
You may have to keep trying. ;-)
On the other hand, you can always use Microchip's C30 compilers
under Wine if you do not to use Windows.

--
Xiaofan http://mcuee.blogspot.com

2009\05\04@041120 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 1:00 PM, Xiaofan Chen <RemoveMExiaofancspamTakeThisOuTgmail.com> wrote:
> On Mon, May 4, 2009 at 11:44 AM, Xiaofan Chen <xiaofancEraseMEspam.....gmail.com> wrote:
>>
>> Unfortunately my test under Ubuntu 9.04 is of the same result just
>> like the test of the previous version V3.10 patches. I can build the
>> binutils but the installed version seg-faulted.
>>
>
> This is from the person who sent me the patches.
> "I had the same problem initially that's why I ended up with a mixes
> of patches, but I can't remember exactly what I did or what I did not
> do. I just had to keep trying."
>
> He also sent me screenshots and it worked for him apparently.
>
> To Peter:
> You may have to keep trying. ;-)
> On the other hand, you can always use Microchip's C30 compilers
> under Wine if you do not to use Windows.

Apparently someone has good lucks with Mac OS X as well for
V3.10.
http://vanklinkenbergsoftware.nl/blog/?tag=dspic

I tried the build-script with V3.10 and the resultant compiler does
not work either (seg-faulted). So I think it may have something
to do with the compiler versions. I tried both Arch Linux and
Ubuntu 9.04 (both with gcc 4.3.3).

So I will give up for now...

--
Xiaofan http://mcuee.blogspot.com

2009\05\04@050101 by Peter Restall

flavicon
face

Xiaofan,

Thanks for the effort.  I've just installed those debs you sent and it doesn't
like them at all; missing locations and things.  I'll have a play and see if
I can get them working though, so thanks.

As for your segfaults in 9.04, try something like:

       ltrace pic30-elf-gcc

If ltrace doesn't give you the right sort of information, there's always:

       strace pic30-elf-gcc

Or if you're feeling really adventurous, fire up gdb :)

Your segfaults may be something stupid like a NULL string comparison or
opening a file that doesn't exist (and then trying to use the fd) - ie. it
may be something you can fix easily by applying a patch to the source before
you build.

I'm also using GCC-3.3 to compile the scripts; I normally use 4.2 but there
was a build dependency in the pic30 debs for 3.3, and when I tried to bypass
it I got the segfault during the build, so I installed 3.3.  I still got the
segfault during the build, but managed to get further with C30 versions > 3.01.

I can't believe how much effort this is taking - I remember building DOS
cross-compilers in the Good Old Days (ie. when Linux would run on a 4MB system
without special flags) and it causing less problems.  A 16-bit PIC can cause
all this...?!?

Cheers,

Pete Restall

2009\05\04@062046 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 4:55 PM, Peter Restall <EraseMEpetespamrestall.net> wrote:

> Thanks for the effort.  I've just installed those debs you sent and it doesn't
> like them at all; missing locations and things.  I'll have a play and see if
> I can get them working though, so thanks.

You need to build the third non-free support package. Last time, I just
copy the Wine installation of V3.01 to the corresponding directory.

> I'm also using GCC-3.3 to compile the scripts; I normally use 4.2 but there
> was a build dependency in the pic30 debs for 3.3, and when I tried to bypass
> it I got the segfault during the build, so I installed 3.3.  I still got the
> segfault during the build, but managed to get further with C30 versions > 3.01.

That may be the key. I will try it later this week.

> I can't believe how much effort this is taking - I remember building DOS
> cross-compilers in the Good Old Days (ie. when Linux would run on a 4MB system
> without special flags) and it causing less problems.  A 16-bit PIC can cause
> all this...?!?
>

C32 is easier now that Microchip is actually supporting it.
www.microchip.com/forums/tm.aspx?m=364626
www.microchip.com/forums/tm.aspx?m=416697
http://sourceforge.net/projects/ccompiler4pic32/

Microchip did not like people to build C30 last time.
www.microchip.com/forums/tm.aspx?m=139510
http://www.microchip.com/forums/tm.aspx?m=139360



--
Xiaofan http://mcuee.blogspot.com

2009\05\04@134142 by Peter Restall

flavicon
face

Xiaofan,

I got sick of messing around with this, so I decided to bite the bullet and
modify the linker slightly.  No doubt this will incur the wrath of the
Binary Gods - I dare say that random bit that flips in some object code when I
least expect it will be my own fault...

I've included the patch at the bottom of this e-mail so that it can be indexed
by Google and so forth.  Basically all it does is modify the PIC30 relocation
checking code to use 64-bit masks rather than 32-bit masks; this is the way
it should be I think, from what I can gather of the BFD source (there's a
header that says typedef bfd_vma should always be 64-bits - a #error occurs
otherwise).  Could be wrong though.

I'll run some comparisons between the Windows C30 and the files generated
natively to make sure the branches/calls don't differ wildly - they seem to
tally so far, but admittedly I've not done as much testing as I need to.  So
the patch is more of a 'use at your own risk' / 'for educational purposes
only' type thing :)

I'll look at getting proper PIC30 builds installed later without this sort of
jiggery pokery, but for now I've got other things I should be doing.

Oh, and the installation I ended up with (and patched) was the one you sent me
from the Dutch OSX guy - http://vanklinkenbergsoftware.nl/blog/?tag=dspic.  It
seemed cleaner than the Debian template builds that were hanging around the
'net - I quite like the way he'd glued it together (and allowed me to install
it to any place I liked).

As I said, I'll continue looking at this as I'd rather get a proper build from
somebody more familiar with the binutils internals - but this voodoo should do
for now.  Thanks for all the help and time so far.  Let me know if you think I
can be any assistance getting your own 9.04 troubles sorted though (and good
luck :)

Regards,

Pete Restall

--------

Patch for acme/bfd/elf32-pic30.c follows.  Be sure to add it to the build
script along with the other binutils patches.

--- acme/bfd/elf32-pic30.c.orig        2009-05-04 15:39:05.000000000 +0100
+++ acme/bfd/elf32-pic30.c        2009-05-04 15:35:43.000000000 +0100
@@ -1973,7 +1973,7 @@
      case R_PIC30_PCREL_BRANCH:
      case R_PIC30_BRANCH_ABSOLUTE:
        /* valid range is [-32768..32767] and not [-2, -1, 0] */
-        if ((relocation > 0x7FFF) && ~(relocation | 0xC0007FFF))
+        if ((relocation > 0x7FFF) && ~(relocation | 0xFFFFFFFFC0007FFFull))
          {
            *error_msg = (char *) malloc(BUFSIZ);
            sprintf(*error_msg,
@@ -1986,7 +1986,7 @@
      case R_PIC30_PCREL_DO:
      case R_PIC30_DO_ABSOLUTE:
        /* valid range is [-32768..32767] and not [-2, -1, 0] */
-        if ((relocation > 0x7FFF) && ~(relocation | 0xC0007FFF))
+        if ((relocation > 0x7FFF) && ~(relocation | 0xFFFFFFFFC0007FFFull))
          {
            *error_msg = (char *) malloc(BUFSIZ);
            sprintf(*error_msg,

2009\05\04@192921 by Xiaofan Chen

face picon face
On Tue, May 5, 2009 at 1:09 AM, Peter Restall <RemoveMEpeteEraseMEspamEraseMErestall.net> wrote:

> Oh, and the installation I ended up with (and patched) was the one you sent me
> from the Dutch OSX guy - http://vanklinkenbergsoftware.nl/blog/?tag=dspic.  It
> seemed cleaner than the Debian template builds that were hanging around the
> 'net - I quite like the way he'd glued it together (and allowed me to install
> it to any place I liked).
>
> As I said, I'll continue looking at this as I'd rather get a proper build from
> somebody more familiar with the binutils internals - but this voodoo should do
> for now.  Thanks for all the help and time so far.  Let me know if you think I
> can be any assistance getting your own 9.04 troubles sorted though (and good
> luck :)
>

Thanks. The nice guy who sent me the patches seems to find the bug.
He actually installed Ubuntu 9.04 and tried it. He has sent me a script and
I will try it later. I will post the script once I confirm it works.


--
Xiaofan http://mcuee.blogspot.com

2009\05\05@102441 by VICENTE COLOMAR PRATS

picon face
can you clarify me a doubt that has come reading this post:
If you make your own compilation of C30 in Linux, has it the same
restriction (working days fully featured) as windows student version
has?

2009/5/3, Xiaofan Chen <RemoveMExiaofancspam_OUTspamKILLspamgmail.com>:
{Quote hidden}

>

2009\05\05@104634 by Xiaofan Chen

face picon face
On Tue, May 5, 2009 at 7:29 AM, Xiaofan Chen <RemoveMExiaofancKILLspamspamgmail.com> wrote:
>
> Thanks. The nice guy who sent me the patches seems to find the bug.
> He actually installed Ubuntu 9.04 and tried it. He has sent me a script and
> I will try it later. I will post the script once I confirm it works.

He has since updated the scripts and it seems to work.
I will post the patches and build script in Microchip forum.
http://www.microchip.com/forums/tm.aspx?m=342218


--
Xiaofan http://mcuee.blogspot.com

2009\05\05@104859 by Xiaofan Chen

face picon face
On Tue, May 5, 2009 at 10:24 PM, VICENTE COLOMAR PRATS
<vicentecolomarSTOPspamspamspam_OUTgmail.com> wrote:
> can you clarify me a doubt that has come reading this post:
> If you make your own compilation of C30 in Linux, has it the same
> restriction (working days fully featured) as windows student version
> has?

Yes you still have the same restriction. The PA optimizer (procedure
abstraction) is proprietary and Microchip does not release
the source for that.

Take note, now there are no more student versions. Instead it
is called evaluation version. Now there are so called academic
version which is the same as expired evaluation version.

www.microchip.com/forums/tm.aspx?m=421112
http://www.microchip.com/forums/tm.aspx?m=420867

--
Xiaofan http://mcuee.blogspot.com

2009\05\05@105922 by Xiaofan Chen

face picon face
On Tue, May 5, 2009 at 1:09 AM, Peter Restall <spamBeGonepeteSTOPspamspamEraseMErestall.net> wrote:

> I've included the patch at the bottom of this e-mail so that it can be indexed
> by Google and so forth.  Basically all it does is modify the PIC30 relocation
> checking code to use 64-bit masks rather than 32-bit masks; this is the way
> it should be I think, from what I can gather of the BFD source (there's a
> header that says typedef bfd_vma should always be 64-bits - a #error occurs
> otherwise).  Could be wrong though.
>

Is this patch only needed for 64bit Linux? Or do you think it is needed
for both 32bit and 64 bit Linux? I'd like to post your patch as well.

--
Xiaofan http://mcuee.blogspot.com

2009\05\05@142019 by Peter Restall

flavicon
face

On Tue, 5 May 2009 22:59:21 +0800, Xiaofan Chen wrote:

> Is this patch only needed for 64bit Linux? Or do you think it is needed
> for both 32bit and 64 bit Linux? I'd like to post your patch as well.

It's a tough one; I've only tested it on my 64-bit installation.  The bfd_vma
typedef is supposedly a 64-bit number all the time though, so it should work
on 32-bit systems too.  I did try surrounding the changes with #ifdef something
or other, but I couldn't see any properly defined macros that I could reliably
check to indicate a 64-bit host - the ones that were #define'd in BFD headers
told me I was running a 32-bit system - this may have been because I was
looking at the elf32 code though, so it may have been coerced somewhere.

There's probably a more friendly way to do the test anyway; I used a 'ull'
constant, when I should probably have masked away bits from ((bfd_vma) -1)
or something.  Otherwise it may not work if a 'ull' constant is not the same
size as 64-bits.  My excuse is that it was a desperate hack - things always
look differently in the cold light of day :)

I'll also try the patches in your other e-mail when I get chance; been a bit
pre-occupied recently and probably will be for the next few days at least too.
I'll let you know what happens with it as soon as I can.

Regards,

Pete Restall

2009\05\06@072512 by Peter Restall

flavicon
face

Xiaofan,

I've tried running yours/mhel's updated scripts but they did not work; I still
got the same linker error.  I've sent you a personal e-mail with the scripts
in, with some modifications I've made to get it all to run on my machine.

I have updated mhel's build script to have the proper v3.12 binutils tar.gz
filename in it (he used a dot instead of an underscore somewhere), and also
to apply my binutils patch.  I have also added a revised version of my patch
to the patches.tar.gz file, which fixes the problem I'm having with the
linker.  The new patch does the same thing as the one I've already posted in
this thread, but it no longer relies on the non-standard 'ull' suffix and
does not assume bfd_vma is only ever 64-bits.  It should compile fine on a
32-bit system too.

I have checked that my blink.c compiles/links consistently with the official
C30 generated files and they seem to tally; the object files are different,
but the produced hex files are identical.  I suspect the object files are
different because of the different path/library names that are referenced
inside them, but I haven't confirmed this.

I still need to do more tests to ensure the patch is a proper bonafied
solution, but it's looking good so far.

Regards,

Pete Restall

2009\05\07@070411 by Xiaofan Chen

face picon face
On Wed, May 6, 2009 at 7:19 PM, Peter Restall <KILLspampetespamBeGonespamrestall.net> wrote:
> I've tried running yours/mhel's updated scripts but they did not work; I still
> got the same linker error.  I've sent you a personal e-mail with the scripts
> in, with some modifications I've made to get it all to run on my machine.
>

Thanks I will try your patch and post it to the Microchip forum thread.
http://www.microchip.com/forums/tm.aspx?m=342218

I will also try to request that Microchip makes it easier to
build the GCC source codes of MPLAB C30. They have
already done so for C32. So it may be nature to do so for
C30.
https://sourceforge.net/projects/ccompiler4pic32/



--
Xiaofan http://mcuee.blogspot.com

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...