Affordable PCB Layout Software ???

that

I only found two out of over 100 6510 that would run his program. he contacted the software company abut it, and they admitted that it was written on a developer's pre production computer, but that they would not give him the current version, or even a discount, so RObert disassembled the software and re wrote the bad parts to work on any

6510.

Try running Basic programs written for the PET on either. They were stripped down so their business software won't run on the cheaper 'home' models.

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.

--
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
 Click to see the full signature
Reply to
Michael A. Terrell
Loading thread data ...

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.

Mark Borgerson

Reply to
Mark Borgerson

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.

Reply to
David Brown

that

Like I said; the PET had BASIC 4.0 where the VIC-20 and C64 had BASIC

2.0. The most important difference between the two is that BASIC 4.0 (PET) had disk commands. The advantage of BASIC 2.0 was that it could fit with the kernal in just 16 KByte. The VIC-20 and C64 were designed (in very short time) to be as cheap as possible, cutting corners where possible.

Reply to
Dombo

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.

Mark Borgerson

Reply to
Mark Borgerson

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.

Reply to
AZ Nomad

otherwise

laptop

where

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

Reply to
Mark Borgerson

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

Reply to
David Brown

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.

Reply to
AZ Nomad

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

Reply to
Mark Borgerson

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

Reply to
Anssi Saari

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.