Affordable PCB Layout Software ???

In article <slrngbdl0v.2p9.aznomad.3@ip70-176-155-130.ph.ph.cox.net>, 
aznomad.3@PremoveOBthisOX.COM says...
> On Thu, 28 Aug 2008 09:25:23 -0700, Mark Borgerson <mborgerson@comcast.net> wrote:
> >In article <48b6474f$0$25381$8404b019@news.wineasy.se>, 
> >david@westcontrol.removethisbit.com says...
> >> Mark Borgerson wrote:
> >> > In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
> >> > david.brown@hesbynett.removethisbit.no says...
> >> >> Dombo wrote:
> >> >>> AZ Nomad wrote:
> >> >>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
> >> >>>> wrote:
> >> >> <snip>
> >> >>>> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
> >> >>>> it's a steaming mountain of pig shit.
> >> >>>>
> >> >>>> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
> >> >>>> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
> >> >>>> on it
> >> >>>> being unable to run on such hardware.
> >> >>> Consider that Adobe needs 100MB hard disk space for just a reader, where 
> >> >>> others can produce a PDF reader that takes less than 1 MB and starts at 
> >> >>> least 10x faster, and you still believe Adobe is producing efficient 
> >> >>> software?
> >> >>>
> >> >>> Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
> >> >>> C++ Builder and still believe Microsoft is the only company that 
> >> >>> produces crap software.
> >> >>>
> >> >> For an example a little closer to the group's topic - Code Worrier for 
> >> >> the Freescale 6805 devices was something like a 600 MB download, and 1 
> >> >> GB install, for a compiler for a device with a couple of KB code space.
> >> >>
> >> > The sise of the IDE has little to do with the size of the code space
> >> > on the target.  The size of the compiler also has little to do with
> >> > the processor code space.
> >> > 
> >> 
> >> That's not entirely true - for a bigger and more powerful target, you 
> >> could expect larger libraries (with corresponding files such as 
> >> documentation), more IDE features (such as a more powerful debugger 
> >> taking advantage of the target's features), etc.  Green Hills for the 
> >> ColdFire, for example, weighs in at about 400 MB - a lot of that is from 
> >> dozens of copies of very large static libraries for each target 
> >> variation.  The actual useful bit of Code Worrier, the compiler, is 
> >> pretty good, but the rest is an impressive quantity of bloat.
> >> 
> 
> 
> >I just took a look at the CodeWarrior demo CD for the ColdFire 
> >architecture.  The total data on the CD was  303MB.   That seems
> >comparable to the Green Hills package---although the 270MB .cab
> >file could expand quite a bit on installation.
> 
> >I still use Codewarrior  8.0 for the PalmOS to compile M68K code
> >for Persistor data loggers.  The Codewarrior folder with the
> >IDE, help files, compiler and libraries is just 88MB.  The HTML
> >help and manuals are about 45MB of the 88MB.  Perhaps this was
> >one of the last pre-bloat versions of Codewarrior.
> 
> >By comparison, the IAR Embedded Workbench for the Arm processor
> >occupies about  435MB of disk space.  Of that, the bin folder
> >is about 35MB, while the doc and examples folders add up
> >to more than 200MB.  The rest goes to libraries, include files,
> >drivers and  about 62MB for a sample version of their PowerPac
> >RTOS.
> 
> 
> >What elements of Codewarrior could be eliminated?   After all one
> >programmer's help files are another's bloat.
> 
> Disk space is irrelevent unless you are running on a 10GB drive which is
> rather silly in this age where 500GB drives sell for $80. Other resources
> are far more important including the memory footprint, number and frequency
> of drive accesses such as to load ten thousand data files needed for
> operation, and lastly cpu usage.  450GB of application just sit on the hard
> drive and really don't matter one bit.
> 
The point about disk spacebeing irrelevant is true---especially if half 
the disk footprint is help files and example code, as is the case with
the IAR system.  I don't see memory footprint as much of an issue
either--when a recent PC ought to be able to malloc()  a
few hundred megabytes  for symbol tables,   etc.

The comment about requiring many files is valid---especially as
a complex C program may require  LOTS of header files.  There's
no reason any particular file should have to be read more than
once, though.  Read it once and cache it in RAM.

My largest embedded programs may get to a few hundred KBytes of
object code.  Compiling them generally takes only a few seconds--
even for a full rebuild, so I don't see CPU usage as a major issue.
This is especially true as my development PC has dual cores---
one of which is sitting idle most of the time anyway.


Mark Borgerson

Mark Borgerson wrote:
> In article <48b6474f$0$25381$8404b019@news.wineasy.se>, 
> david@westcontrol.removethisbit.com says...
>> Mark Borgerson wrote:
>>> In article <Es-dneuLX7SdAyjVnZ2dnUVZ8hidnZ2d@lyse.net>, 
>>> david.brown@hesbynett.removethisbit.no says...
>>>> Dombo wrote:
>>>>> AZ Nomad wrote:
>>>>>> On Tue, 26 Aug 2008 22:05:06 +0200, Dombo <dombo@disposable.invalid> 
>>>>>> wrote:
>>>> <snip>
>>>>>> Maybe with 10ghz of cpu and 20GB of ram vista might run OK, but otherwise
>>>>>> it's a steaming mountain of pig shit.
>>>>>>
>>>>>> And adobe's latest reader runs just fine under linux on my 1.4 ghz laptop
>>>>>> with a typical 5200rpm laptop drive.  If MS wrote it, you could count 
>>>>>> on it
>>>>>> being unable to run on such hardware.
>>>>> Consider that Adobe needs 100MB hard disk space for just a reader, where 
>>>>> others can produce a PDF reader that takes less than 1 MB and starts at 
>>>>> least 10x faster, and you still believe Adobe is producing efficient 
>>>>> software?
>>>>>
>>>>> Ever tried Lotus Notes, or CM Synergy (nowadays both IBM), or Borland 
>>>>> C++ Builder and still believe Microsoft is the only company that 
>>>>> produces crap software.
>>>>>
>>>> For an example a little closer to the group's topic - Code Worrier for 
>>>> the Freescale 6805 devices was something like a 600 MB download, and 1 
>>>> GB install, for a compiler for a device with a couple of KB code space.
>>>>
>>> The sise of the IDE has little to do with the size of the code space
>>> on the target.  The size of the compiler also has little to do with
>>> the processor code space.
>>>
>> That's not entirely true - for a bigger and more powerful target, you 
>> could expect larger libraries (with corresponding files such as 
>> documentation), more IDE features (such as a more powerful debugger 
>> taking advantage of the target's features), etc.  Green Hills for the 
>> ColdFire, for example, weighs in at about 400 MB - a lot of that is from 
>> dozens of copies of very large static libraries for each target 
>> variation.  The actual useful bit of Code Worrier, the compiler, is 
>> pretty good, but the rest is an impressive quantity of bloat.
>>
> 
> 
> I just took a look at the CodeWarrior demo CD for the ColdFire 
> architecture.  The total data on the CD was  303MB.   That seems
> comparable to the Green Hills package---although the 270MB .cab
> file could expand quite a bit on installation.
> 
> I still use Codewarrior  8.0 for the PalmOS to compile M68K code
> for Persistor data loggers.  The Codewarrior folder with the
> IDE, help files, compiler and libraries is just 88MB.  The HTML
> help and manuals are about 45MB of the 88MB.  Perhaps this was
> one of the last pre-bloat versions of Codewarrior.
> 
> By comparison, the IAR Embedded Workbench for the Arm processor
> occupies about  435MB of disk space.  Of that, the bin folder
> is about 35MB, while the doc and examples folders add up
> to more than 200MB.  The rest goes to libraries, include files,
> drivers and  about 62MB for a sample version of their PowerPac
> RTOS.
> 
> 
> What elements of Codewarrior could be eliminated?   After all one
> programmer's help files are another's bloat.
> 

As I said, I'd expect toolkits for larger processors to be larger - 
libraries, examples, help files are all significantly larger.  As for 
what could be eliminated on Code Worrier for the 6805 - practically all 
the "beans" could be dropped.  I can see the point of trying to have a 
set of ready-to-use components with a fairly consistent interface for 
different targets, but they are wildly unsuitable for small 8-bit 
devices (the ADC "bean" took about 1.5k out of the 4k flash on the 
device - a single line of C code did pretty much the same job).

On Thu, 28 Aug 2008 22:54:17 +0200, David Brown <david.brown@hesbynett.removethisbit.no> wrote:
>As I said, I'd expect toolkits for larger processors to be larger - 
>libraries, examples, help files are all significantly larger.  As for 
>what could be eliminated on Code Worrier for the 6805 - practically all 
>the "beans" could be dropped.  I can see the point of trying to have a 
>set of ready-to-use components with a fairly consistent interface for 
>different targets, but they are wildly unsuitable for small 8-bit 
>devices (the ADC "bean" took about 1.5k out of the 4k flash on the 
>device - a single line of C code did pretty much the same job).

It's more a function of the quality of the libraries.  It goes back to the
old "hello world" test, looking at the generated code to see how much
irrelevent bullshit gets included. 

In article <slrngbe57c.ka4.aznomad.3@ip70-176-155-130.ph.ph.cox.net>, 
aznomad.3@PremoveOBthisOX.COM says...
> On Thu, 28 Aug 2008 22:54:17 +0200, David Brown <david.brown@hesbynett.removethisbit.no> wrote:
> >As I said, I'd expect toolkits for larger processors to be larger - 
> >libraries, examples, help files are all significantly larger.  As for 
> >what could be eliminated on Code Worrier for the 6805 - practically all 
> >the "beans" could be dropped.  I can see the point of trying to have a 
> >set of ready-to-use components with a fairly consistent interface for 
> >different targets, but they are wildly unsuitable for small 8-bit 
> >devices (the ADC "bean" took about 1.5k out of the 4k flash on the 
> >device - a single line of C code did pretty much the same job).
> 
> It's more a function of the quality of the libraries.  It goes back to the
> old "hello world" test, looking at the generated code to see how much
> irrelevent bullshit gets included. 
> 

One programmer's irrelevant bullshit is another's initialization code.

I expect that most embedded programmers will know that

printf("hello world");

will produce a different result from

puts("hello world");


Of course the result will also depend on whether the
program has to run on bare silicon or can take advantage
of a bios or more complet OS.   I generally start with
bare silicon, so I'm not surprised when the program has
to link in serial port drivers, initialization code,
etc. etc.


For a system like the 6805,  I would  probably consider the
'beans' to be example code and extract only the essence.
Codewarrior was probably a better system back when it
was only generating code for the M68K systems or systems
of equivalent register complexity.

I've never been a big fan of 'one size fits all' tool
vendors.  That's why I use tool sets from IAR for the 
Atmel ARM chips,  Codewarrior for the M68K, Imagecraft for the
MSP430 and GCC for an ARM-Linux system.  (The latter
was not my choice, though).  I've also used Keil for the
8051 series---but I'm not sure I'd pick them for an
ARM compiler vendor.

Mark Borgerson

"Michael A. Terrell" <mike.terrell@earthlink.net> writes:

>> (comp.sys.cbm would be a better place to discuss this)
>
>
>   I used to visit there, but there was very little traffic that wasn't
> cross posted from British Sinclair users.  It had more trolls than
> regulars, so I gave up.

There is an annual Sinclair/Commodore flame war, but for the rest it's
mostly relevant stuff in my experience.