Technical Support Changes - PLEASE READ

Holiday Closures

Proudly Canadian

Frequently Asked Questions

This is the place to check for answers, before purchasing our products, or requesting Technical Support.  You are the person to check this page for information since Sept 13,1999. Thanks for checking here first!  

 Updated 7th January 2002

Table of Contents

I would like to receive more information about your products.  How do I get it?

Please visit our web site http://www.dunfield.com, for product listings, FAQ's and demos. Most products have a downloadable demo which will give you access to much of the documentation, and the chance to try out a few features.

If the information on the website does not provide the answers you are looking for, please contact Technical Support with specific questions.

Which of your products do I need to develop code for <CPU name>?

Why does your compiler do this (or that)...
Why not make your tools more like those of company XXX ...

My Tools:
---------
 I have been writing embedded development tools since the 70's, and all of my tools have been designed/created for the simple reason that I needed them... I do a great deal of contract embedded systems development, and I write (and **USE**) all of my own tools.

My tools reflect my own requirements, and work the way I "think" tools should work... Over the years I have added many extra features and options to the tools to accommodate the requests of other people, however I still enforce the simple rule that the products have to be exactly what I personally would want to use...

A lot of people really like my tools for this reason, and it is true that some do not ... I do what I can to accommodate those who think radically differently than I do, however I do not compromise my standards for the sake of expanding my market. My tools will ALWAYS reflect the quality and functionality that I personally require in my own work.

Since I have written all of my tools (every line of code in every module), I know them inside out, and am able to provide rapid support, and custom versions/adjustments in many cases.


My Compiler:
------------
Is called "Micro-C", and was designed by me "from the ground up" to be an
embedded systems compiler. It is not based on "Small-C", "GNU-C", "LCC" or
any other previously available parser or parser generator. The entire
toolset is composed of handcrafted code by yours truly.

Micro-C has a long history, and began life as a K&R only compiler. It has
evolved toward ANSI quite a bit, and continues to do so, however it is NOT
a fully ANSI compliant compiler, and most likely never will be... Micro-C
is targeted at **VERY** small systems, and reflects changes and compromises
that I feel are appropriate for such small platforms... This is the reason
it can support such a wide variety of processors including some with rather
"C unfriendly" architectures. It also provides several capabilities which
are very difficult or simply not possible with other C toolsets.

Just because Micro-C is not fully ANSI compliant does not mean that you
cannot write portable ANSI programs... I rarely resort to #if/#ifdef/#ifndef
etc. when writing portable code to be compiled by Micro-C and other ANSI
compilers. As a case in point, the Micro-C compiler itself (5 files and over
3500 lines of code) compiles with itself and Borland-C with no changes, and
without a single preprocessor conditional.

Is Micro-C a full ANSI compiler?

MICRO-C is a "near ANSI" subset compiler. It does however, support more of the 'C' language than most other subset compilers, including:

Micro-C has a long history, and began life as a K&R only compiler. It has evolved toward ANSI quite a bit, and continues to do so, however it is NOT a fully ANSI compliant compiler, and most likely never will be... Micro-C is targeted at **VERY** small systems, and reflects changes and compromises that I feel are apprioriate for such small platforms... This is the reason it can support such a wide variety of processors including some with rather "C unfriendly" architectures. It also provides several capabilities which are very difficult or simply not possible with other C toolsets.

Just because Micro-C is not fully ANSI compliant does not mean that you cannot write portable ANSI programs... I rarely resort to #if/#ifdef/#ifndef etc. when writing portable code to be compiled by Micro-C and other ANSI compilers. As a case in point, the Micro-C compiler itself (5 files and over 3500 lines of code) compiles with itself and Borland-C with no changes, and without a single preprocessor conditional.

** Note, the most common "complaints" of people not familier with my tools are the lack of Floating Point and Typedef... In over 20 years, I have never required Floating Point (which is very inefficent on small CPU's), and the most common use of Typedef is a misuse ... send email if you want to know why!

It should also be noted that all versions of Micro-C are based on a single parser, with separate backends for each processor. This means that with the exception of inline assembly language, processor specific library functions, and special features which may be specific to one CPU, code written for one CPU can be moved to any other CPU I support with little or no effort. All of
my "Developer Kits" are designed to be as similar to each other as possible, the compilers have the same common options, the libraries are designed to be as similar as possible, and all tools and interfaces look the same... This makes it very easy to take a project written for the HC11 as an example,
and move it to the HC12 ... You really can't get more portable than this!

Micro-C based toolsets are currently available for: 68HC08, 6809, 68HC11,
68HC12, 68HC16, 8051/52, 8080/85/Z80, 8086, 8096 and AVR processor families.
In addition, I offer C-FLEA, a virtual CPU which can be implemented on
virtually ANY platform to provide a C environment (I provide example C-FLEA
VM's for: 6800/01/02/03/08/11/12, 6805, 8051/52, 8086, AVR and PIC).

I also have Assembly/Disassembly/Debug tools for many other processors.

My Development Packages:
------------------------
Contain lots of extra goodies and information which makes them well worth
the low cost. Please visit www.dunfield.com for more information, and/or
drop a note to me via email if you require more information or details.

Do you have "windows" versions of your tools?

Dunfield Development Systems primary business focus is in the development
of very high reliability embedded systems software/firmware. The "Windows"
operating system, with it's well deserved reputation as the most unreliable
piece of software ever written goes against pretty much everything we stand
for. For this reason, DDS does not endorse "Windows", and does not produce
software specifically for this platform.

Our command line tools run under any DOS compatible system, including all
versions of "Windows". For a list of operating systems we have tested,
please refer to the "Do your tools run under ..." FAQ item.

We do offer "Micro-IDE", a windows Integrated Development Environment from
"Bipom Electronics" developed specifically for our Micro-C packages, which
gives the command line tools a complete "Windows look and feel".

If you are interested in "windows only" versions of the tools, Bipom is now
offering versions of our complete toolsets which are targeted specifically
at windows. These windows versions of our tools are only being distributed
though Bipom. For more information, please contact  http://www.bipom.com

Do your tools run under (Insert system name)?

DDS tools are designed to run under any DOS compatible system
or emulator. The tools have been confirmed to run under:

The system requirements for our tools are quite modest, and they do not utilize undocumented features or other "tricks". It is highly likely that they will also run on any other DOS compatible platform not listed above, but this list represents the platforms that I have available to test with... Please let us know if you experience problems with any unlisted DOS compatible system.

NOTE: For those of you who like to "mouse around", we do offer a third party Windows IDE (Micro-IDE) which gives our Micro-C Developers Kits a graphical "windows" interface... This IDE runs under Win95/98/NT4/2000+

** Some of our utilities which require direct access to the parallel
   port (PCLA, I2CE, AVRLOAD) do not run under WindowsNT/2000.

Do your tools come with an IDE (Integrated Development Environment)?

Our tools are fundamentally "command line" in nature. We do provide a small text mode IDE which integrates the compiler, assembler, linker with a nice text editor which captures error message output and provides many other nice "pop-up" features (See DDSIDE documentation in our demos).

For a windows environment, we offer Micro-IDE, a full-featured windows Integrated Development Environment for our tools by Bipom Electronics. Bipom is also the primary distributor for the windows versions of our tools. If you are interested in a graphical "windows only" toolset, please contact Bipon (www.bipom.com) and they will see to your needs. Bipom also provides windows oriented source level debuggers and other enhanced features for windows.

Does MICRO-C support the (My favourite processor)?

It is impossible for us to acquire and test all of the derivatives in the various CPU families that we support. DDS Micro-C has been designed to be very flexible in supporting derivative processors, and will accommodate most of them very easily. Please note the following guidelines when evaluating the suitability of our tools for a particular derivative processor:

** The AVR AT90S1200 is supported by the assembler only (no C compiler), the Mega devices will work, although currently limited to 64K of code memory.

NOTE that the C-FLEA virtual machine development tools can be made to work with ANY processor (even if it is not in a CPU family listed)!

Do you support the dual DPTR's of the Dallas 80C320/520?

We have available a free add-on to our 8051 compiler which provides:

This add-on is available at no charge to licensed DDS 8051 Micro-C users. Please contact Technical Support for details.

How much code can I fit in (nK) of memory?

That depends on so many factors that its impossible to give you a general answer. It is usually more that you would think, because MICRO-C produces fairly compact code. This is especially true with our "Developers Kits", because their libraries are hand-coded in assembly language, using very tight code. Here are some examples of applications:

Do your tools work with <manufacturers name> boards?
Can you recommend a board to use with your tools?

Our tools are NOT designed to work with specific boards. The tools are fully configurable to set the memory addresses and I/O ports used, and can be used with virtually any board or target system.

Full source code to the library is included so that you can perform any "tweaking" that you may need to do for a particular environment (normally, this only involves setting the available memory addresses). Information on setting up the library and memory map is included.

As long as your board uses a CPU which is instruction set compatible with a processor family which we support, you should have no problems adapting the tools to work with it.

For this reason, we do not like to "recommend" any particular manufacturers boards. Any reasonable board should work equally well with our tools. At the request of several users, I have prepared this list of board that we use on a regular basis in testing and maintaining the DDS toolsets, however this should not be considered an endorsement or recommendation for these particular boards.

Note: 'Proprietary' indicates that we have built our own target system for the express purpose of software debugging (usually with extra hardware to assist)... We use ALL of our tools on a daily basis in the course of embedded software development for the various proprietary hardware platforms of our clients.

How do I configure memory/registers/peripheral addresses?

Micro-C supports a very flexible library structure, which allows you to easily set memory addresses, processor function registers, hardware addresses etc. in the startup file. Detailed documentation on how to do this is provided with the compiler library.

Due to the way our linker operates (see FAQ), all you have to do is to make your changes to the startup file and compile. There is no need to "rebuild" the library or any other steps. A compile option allows you to have any number of startup files, and select the one you wish to use for any given compile.

Do you provide C libraries for <device name>?

I provide library functions and definitions to control basic services of the processor in question (serial port, peripheral control registers etc.), but I generally do not provide off-the-shelf drivers for external peripheral devices, or devices not common to all processors of a specific type.

There are a few exceptions (UARTS for processors which do not have a built in serial interface, I2C devices for the 8051), however for the most part the available devices which can be attached to a microcontroller are simply too numerous and varied for me to be able to acquire, develop interfaces for and test all the combinations.

It is therefore up to the user to provide support for external hardware which he wishes to connect to his target platform. This can be done either in pure 'C', or with inline assembly language. I do provide "helper" functions in my library (for example, if you wish to develop a "printf" which communicates with an LCD panel, you can take advantage of the existing "format" subroutine in my library to perform all of the formatting).

I you are used to hooking up a device to a microcontroller, and writing software (in C or Assembly) to read/write it's registers, set/clear required bits etc. to make it work, then you will not have a problem doing so with my tools. If you require assistance in getting a particular device working, I am available on a contract basis for such services.

Does your compiler support floating point?
Do you include "math.h" and related function?

No, Micro-C is an integer only (non floating point) implementation of C. This means that it does not support the "float" and "double" types, and does not include "sin(), cos(), tan(), log() etc. functions".

I made the decision not to support floating point partly because it simplifies type conversions and reduces the size of the runtime library, but mainly because I find floating point to be inefficient and usually unnecessary in most embedded systems. In over 20 years of embedded programming, I have not yet had a requirement to use floating point.

All of the development kits do include a long integer library, which can perform fast integer arithmetic on numbers of up to 256 bytes (2048 bits) in length. It has been my experience that many/most projects for which the programmer wishes to use floating point can often be more efficiently implemented with scaled large integers.

The 8051 compiler does include a floating point library, which was made available by one of my customers. This library and it's details can be downloaded free of charge from my web download area, and is located in a file called FLOAT51.ZIP.

Does your compiler compile C++ ?

No, DDS Micro-C is a standard C compiler. It does not compile C++. (Many C++ features require much more overhead than is reasonable for the small 8 and 16-bit systems which Micro-C targets - as a result of this, most small embedded systems continue to be developed in C).

What is the difference between the Micro-C/PC that is in your product listings, and the one that I can download "free" from the web?

The FREE version of Micro-C/PC contains exactly the same compiler and library as the "commercial" one. In fact, a given program compiled under either toolset will produce EXACTLY the same executable image.

DDS is not in the business of competing in the PC compiler market, which is why we offer our Micro-C/PC compiler available at no charge. Micro-C/PC has been developed and maintained as an in-house tool (most of our products are compiled with it), however we felt that it was too simply good to keep to ourselves...

To help offset the cost of maintaining the public version of the toolset, we do offer a low cost "commercial" version. If you would like to support the ongoing development of Micro-C/PC, or just say "thanks" for the effort put into it so far, please consider purchasing this version. In return, you will receive a CD ROM containing:

What is the difference between the 8086 Developers Kit and Micro-C/PC

The 8086 Developers Kit is exactly like our other Developers Kits, and targets the 8086 processor. It is designed to produce programs which run on "embedded" 8086 family platforms. Except for the fact that it runs in a PC environment (like all of our developers kits), it has nothing to do with DOS/Windows or PC's at all. 

The 8086 Developers Kit differs from Micro-C/PC in that it:

Micro-C/PC is a version of the DDS compiler that was developed to produce programs that run on a PC/DOS environment. This was done originally as an in-house tool (most of our software is written using Micro-C/PC), and was later released publicly for use both as a demo to show off the Micro-C compiler, and as an educational tool (Micro-C/PC on your desktop workstation makes a good platform for learning the C language and the details of the Micro-C implementation). Since we are not in the business of competing in the PC compiler market, Micro-C/PC is available free of charge (A fully functional version can be downloaded from our web site). We do offer a low cost "registered" version which contains the library source code and a large collection of example programs as a means of offsetting the cost of maintaining the PC version, however registration is not required for ongoing use of the compiler).

 Micro-C/PC differs from the 8086 Developers Kit in that it:

What is the difference between C-FLEA and your other development packages?

All of our other developers kits produce code that runs on an actual target CPU. For example, the 8051 Developers Kit produces code that runs on an 8051/52 family processor. The C-FLEA toolset produces code that runs on an imaginary "virtual" processor that I designed to be an efficient C platform.

To make the C-FLEA code work on any "real" system, you need a "Virtual Machine Interpreter" which reads the C-FLEA machine code, and performs the operations to execute it on the actual target CPU. We provide ready to go interpreters for a number of CPU's (See catalog listing) as well as a generic one written in C. It is quite easy to write your own if you wish to use a CPU that is not listed. You can use the VM's I supply as examples, and I do include a complete specification for the C-FLEA architecture and instruction set. C-FLEA VM interpreters are typically about 1Kbytes in size.

The C-FLEA approach carries several advantages:

Disadvantages:

Do your Micro-C embedded toolsets include a linker?

Yes, all Micro-C embedded compilers include a linker.  Our linker is specifically designed for use with embedded systems, and therefore operates differently from many other linkers:

The "source" Linker (SLINK.EXE) performs all operations that a
conventional object linker does, but at this assembly source level:

The final output of SLINK is a single assembly file which contains the entire program. This is then fed into an absolute assembler, which results in the final binary program.

Advantages of this approach for an embedded system:

As an example, many embedded architectures have multiple instructions which perform the same operation, but with different limits (eg: 8051 has LJMP spanning 64k and AJMP spanning only 2K). Small versions of the processor often choose not to implement the large versions of these instructions if the smaller one will cover all available memory in this particular version. A compiler would produce the large version however, because it was designed to cover the full range allowed by the instruction set... This causes a failure if that instruction has not been implemented on the processor that you are using.

With the SLINK approach, you can easily perform a global change to convert one instruction into the other. (In the 8051 case mentioned above, our assembler has an option to automatically translate LJMP/LCALL into AJMP/ACALL). Often these changes can be handled automatically with a simple macro. Other vendors would require a separate compiler, or a special mode of their compiler, as well as a separate set of libraries to accommodate a derivative processor such as this (Usually sold as a new toolset or option for additional $$$). With our toolsets, you will find that you can support virtually all derivative processors with no additional tools.

In conclusion, SLINK provides the convenience and simplicity of working with a single absolute source file and listing, while retaining the advantages of multi-module and library linking. You can see SLINK in action with the demo version of our Micro-C toolsets which is available on our web page and BBS. This demo will allow you to compile, link, assemble and even run code on the included simulator. You will see for yourself how simple and straightforward embedded development can be.

Does MICRO-C output assembly code? Do I need an assembler?

MICRO-C generates assembly code. All developers kits include our XASM cross assembler, which our IDE and CC commands automatically run for you, giving you a "one step" compile. A command option allows you to include the 'C' source code as comments in the ASM listing.

Can Micro-C generate assembly language source as it's output?

Yes! Micro-C is not only capable of generating a .ASM output file from your 'C' source, but it can also generate a .ASM output file for the entire program, including fully commented library source code! (This is a feature few other toolsets offer).

When generating .ASM source code from your 'C' program, Micro-C can optionally insert the original 'C' source code as comments in the assembly output. When assembled into a full listing, this provide a detailed map of all 'C' source code, the assembly code generated from it, and the hex object code actually placed into memory (for the ENTIRE program)!

Do your tools provide 'C' source debugging?

The simple debuggers provided with Micro-C do not perform source level debugging, however we do provide a capability which is nearly as good, and in many cases superior to standard 'C' source debugging:

Note that the compiler itself DOES provide source level debugging information, and that we provide a utility called MAPGEN which can be used to generate debug symbol (MAP) files for other vendors source debug tools. MAPGEN is provided free of charge in source form, and all vendors are encouraged to customize it for their tools, and to distribute it with those tools. Contact your debugger/simulator vendor to determine if a MAPGEN for Micro-C is available.

The NOICE debuggers which we offer in our "third party" section of our catalog include MAPGEN, and therefore perform source level debugging with our tools.

What are the "extras" included in the Developers Kits?

LOTS of good stuff!  

Does EMILY52 differ from the Monitor included in the 8051 Developers Kit?

Yes, the monitor included in the 8051 Developers kit is the same one that is
available in our XTOOLS/MONITORS package:

MONITORS: Powerful software debugger and monitor programs.

This is a "TTY" style monitor which resides in ROM on the target system. You communicate with it via any "Terminal Emulator" program, such as our own LAPTALK. This monitor does not include any simulation capability, it is a run-time CPU execution debugger only.

EMILY52 is a much more powerful simulator and PC hosted monitor which uses dedicated interface programs on the PC to add functionality.

EMILY52 provides three "modes" of operation:

1. "Pure simulation" on the PC, no target hardare involved.
2. "in-circuit" simulation, where the code is simulated on the PC, but physical I/O occurs on the target hardware.
3. "in-circuit monitor", where the code is downloaded into the target
   system and run on the actual 805x CPU.

The main advantages of EMILY52 over the TTY monitor are:

EMILY52: A PC based 8051/52 Simulator / Emulator

A software simulator/emulator for the Intel 8051/8052 series of microcontrollers, EMILY features an easy to use "windowed" user interface, and is capable of simulating at better than 500,000 instructions per second on a 486/33mhz PC.

Is your EMILY52 simulator really that fast?

EMILY's speed is dependant on your PC (>150,000 inst/sec on 386/25, >500,000 inst/sec on 486/33).  My tests have shown EMILY on the 386/25 to be roughly equivalent to a 4Mhz 8052. For example, a customer reported that an algorithm that should take about 1 second on a 12Mhz 8052 took 3 seconds under EMILY. The same program took over 20 MINUTES under another popular simulator.

Can I compile code written using <other vendors tools>?

Micro-C supports most of the standard 'C' programming language (See FAQ),
and will therefore accept most standard 'C' code without modification, however...

Standard 'C' does not specify a number of capabilities which are needed in most embedded systems. For this reason, all vendors of embedded tools have provided language and library extensions which are unique to their toolset. There are no standards for these extensions, and they differ greatly from one vendor to another. Any code which uses such extensions will very likely have to be modified when porting it to ANY other vendors tools.

DDS has made an effort to keep Micro-C as standard as possible, and our extensions are designed to be very similar to standard language features and syntax. Quite often code using other vendors extensions can be ported to our toolsets very easily, using techniques such as: global name changes, preprocessor macros and/or wrapper functions.

Do you have a demo for the <insert CPU name>?

Sorry, I do not provide demo's for the individual native CPU's that I support.

There are several reasons for this:

I do provide a generic DEMO for a CPU of my own invention (Called the C-FLEA). This demo works exactly the same way as the native CPU toolsets, and is in fact, just another CPU implementation of the standard Micro-C tools. It will give you a good understanding of the capability of the tools, and how they "look and feel". The compiler commands, features, options and library are all very indicative of a standard implementation.

Can we "try" your tools, and then return them for full refund?

No, our license agreement does not allow you to return the software
once the envelope containing the CD ROM has been opened. The main reason for this is that the entire package, including all documentation is contained on this CD ROM, and is simply too easy to copy, or to continue using without the original CD ROM. At one time we did accept returns on opened software, however on more than one occasion, we received technical support inquiries from companies that had previously "returned" the software...

This policy is consistent with that of the majority of software vendors.

A demo version of our embedded toolsets is available for download from our web page. This toolset provides documentation, and a working version of the tools for a "virtual" processor. A simulator is included so that you can actually run code. This evaluation package will give you a very good indication of our toolsets capabilities and ease of use.

I don't need the "extras" in your development kit, can I buy just the "compiler" for a discount?
Can I get a discount if I promise I won't make money with your tools?
What about student and educational discounts?

The simple answer is no, DDS tools are already very competitively priced, in fact we get much correspondence from our users who say we have under- priced the tools! We believe that the tools represent good value to anyone who has enough need for development tools to be looking... You will find that most of the reasonable alternatives are priced at least double, and often more than 10 times the low prices we ask.

Re: the "extras"

I have included many "extras" in the packages, mainly because I use these tools constantly myself, and often write some small utility to serve a particular need. It is my belief that I should pass on these extras to my customers, however these little utilities and files do not represent a significant portion of the value in the package or the costs in developing and maintaining it. They are basically "freebies" that I have included without raising the price. (DDS prices are set by perceived market value for the entire package, not by the relative values of individual components thereof).

Not only would it not reduce the price, but it would actually take more of my time to create a special master of a reduced package, whic