Prev: LPC2888 Flash programming using DFU.
Next: servo motor controller using dspic
From: David Brown on 17 Nov 2009 04:12
Jim wrote:
> On Nov 4, 6:58 pm, Jim <adirondack...(a)yahoo.com> wrote:
>> First, I'd like to thank everyone for their input! Second, I'd like
>> to answer some of the questions so no one feels left out:
>>
>> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
>> Now, to avoid the "why": it's a Palm pda which has a display and
>> formfactor that I need and it's cheap.
>> - I'm using my own OS on the embedded system (no Linux).
>>
>> ...text deleted for brevity...
>>
>> So, I think the general consensus is I only get ColdFire micro support
>> with CodeSourcery and I agree with this. I can understand why
>> CodeSourcery may want to ignore older cores. However, don't they
>> still make micros with that (68000 based) core? I might email them,
>> but since I'm using the free version, I feel funny bothering them with
>> this (they do need to earn a living). Purchasing it would be a real
>> gamble since they do say it's a ColdFire compiler on their website
>> (and for home use, it's kinda a pricey gamble).
>>
>> I'm gonna try two things. First, I'll look for other precompiled
>> binaries for MS Windows. Maybe I'll luck out. I came across one the
>> other day, but now can't remember for the life of me who made it--I'm
>> sure it'll turn up in a search.
>>
>> Second, I'll see if I can buildlibgcc. I assume I'll get the source
>> to this when I download the source to gcc. David suggested I use
>> MinGW. I'm pretty sure I'll need "configure" and maybe autoconf &
>> automake. I'm not familiar with MinGW: does that package have them?
>>
>> I just got an idea. PrcTools was a MS Windows compiler for that very
>> micro. I remember trying it, but it was a limited 16b compiler trying
>> to be compatible with the Palm OS. However, I might be able to use
>> itslibgcc. The only issue is that compiler is so old it's probably
>> COFF based (and of course CodeSourcery is ELF). Nothing's ever
>> easy. :)
>>
>> Well, thanks again for your help everyone. I'll post what I finally
>> end up with (in case anyone else needs the info).
>>
>> Jim
>
> Problem solved. I looked at the libc files and they were pretty
> simple. I think there was only one macro definition I had to figure
> out. But, then I realized my next step would be to build newlib and
> that wasn't gonna be that simple.
>
> I looked at a bunch of pre-built stuff (thanks again everyone for the
> links--I may compare the Aztec C output to gcc someday). I decided I
> really wanted GNU because I know the debugger works with Eclipse.
> By the way, the other pre-built gcc I was thinking of was www.ronetix.it.
> It had everything I needed, but, unfortunately, there was a flaw with
> it (either the binary wasn't produced correctly or gdb didn't load it
> correctly--I didn't look into it further). One other by ASH WARE was
> too old (2.95 and coff based--I wasn't sure an elf type gdb would
> handle it). The Macgregor (sp?) didn't run (I need a cygwin dll).
>

Installing cygwin isn't hard, unless you bump into problems with
incompatible versions of cygwin1.dll...

> So, I ended up building gcc and newlib using mingw/msys like David
> suggested. I was intrigued by the idea. I'm still gonna use

Well done! Building gcc is not as hard as it used to be, but it is
still not for the faint of heart. It is somewhat like fixing your own
car instead of taking it to the garage - it takes time, and you can get
pretty stressed and dirty in the process, but it's fun if you like that
sort of thing and you get a sense of achievement in the end.

> CodeSourcery's gcc though (I figure they ran some of the gcc tests).
> I'll just link to the libc, libgcc, etc. produced by me (so far tests
> show it's ok). It wasn't TOO bad building the libs. There were some
> tricks to get things to build right--I spent some time doing
> searches. I think the biggest thing to remember is that many tools
> want you to do these three things:
> (1) create a folder outside of the source tree to hold intermediate
> files.
> (2) run configure and build from the folder created in (1)
> (3) Use a RELATIVE path when running configure in (2). You can get
> weird compile errors otherwise. Unfortunately many docs have scripts
> that use the full path (including the one at mingw). Maybe this used
> to work for older gcc.
>

Good advice.

> One last thing: gcc needs to build mpfr and gmp. It turns out for
> the 4.2.1 and 4.4.2 releases I did, all you have to do it place the
> source in the gcc folder (omit the -version part of the folder name).
> I'm sure there's other ways to do it as well.
>
> Well, thanks again everyone for all of your input! It was fun (for me
> anyways)!!
>

Thanks for the feedback.
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: LPC2888 Flash programming using DFU.
Next: servo motor controller using dspic