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 May 5th, 2003. 
Thanks for checking here first!  

 Updated 3rd May 2003

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.

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 familiar with my tools are the lack of Floating Point and Typedef... In over 20 years, I have never required Floating Point (which is very inefficient 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 Services Inc. 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.

Q: How big a program can I build with your compiler?
Q: How much code can I fit in (nK) of memory?

DDS tools all support 16 bit addressing, allowing a minimum 64k of memory. Many processor architectures allow for separation of code and data, and DDS Micro-C support this via different memory models, some
examples are:
8051: 64k code + 64k data + 256 bytes data
6816: 64k code + 64k data
8086: 64k code + 64k data

Note that although the compiler supports up to 64k addressing, many small embedded controllers do not. You will always be limited to the maximum memory available on your target system if it is less than 64k.

For processors which have more than 64k of memory address space, Micro-C can support this via "bank switching" techniques, as outlined in our application notes (similar techniques can be used to provide more than 64k
of code on processors which don't natively support more than 64k as well).

The question of how much code fits into (nK) of memory 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:

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 hardware 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:

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.

Q: Can I use debugger "xxx" with your compiler?

Micro-C should work at some level with virtually any debugger. At the very least, you should be able to load and manipulate the executable code, and use the listing produced by the compiler as a reference for line numbers and symbols (See FAQ item on 'C' source debugging).

To use source level features of your debugger, it must be able to obtain the symbol names/values/types and file/line number information from the original source code. Micro-C DOES provide this 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.

Unfortunately we do not have the resources to acquire the third party tools, reverse engineer the debug files format (in most cases vendors to not document their proprietary debug formats and "extensions"), and
write/test individual map file generators for every third party debug tool on the market. At this time, DDS has MAP generators available for:

If your debugger supports one of these formats, you may be able to use our "generic" MAP generator. If not, please ask your debug tool vendor to contact us to obtain the free MAP generator toolkit.

Can I use "xxx" assembler with your compiler?
Can I use your assembler with source written for assembler "xxx"?

Possibly, but it may take some work!

Every CPU vendor has it's own unique assembly source format. For example, Motorola assemblers use a very different syntax than Intel assemblers. On top of that, every tool vendor makes their own extensions and "slight
differences".

Here at DDS we use MANY different CPUs in the course of our day to day work. We found it very difficult to be constantly switching back and forth between the assembly language syntax used by one vendor and that used by another. For this reason, DDS assemblers are designed to represent a single syntax which applies to all CPU families. This makes it very easy to work with multiple CPU families when using DDS tools, however it also means that our assemblers do not exactly match the quirks and "features" of any single CPU vendor supplied assembler.

Our assemblers are designed to be very flexible and to minimize the work involved in porting code from most other assemblers (for example, the DDS assemblers accept BOTH Intel and Motorola style Hex & Binary constants).

Our XTOOLS package contains several utilities to assist and automate the conversion of assembly language source code from one format to another.

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, which would represent an increased price to you (the package price plus my time to make the special distribution for you).

Re: Use of product, educational or otherwise

While there may be cases where a discount in a particular situation could be warranted, DDS does not have the ability to verify the status of everyone who asks for a discount, or to police the use of the tools after the sale. The costs in doing so would quickly exceed the amount of any discount that we could offer.

It has sadly also been our experience that tools given out under such special conditions often find their way into other projects, and even in the hands of other people who have no awareness (or care) for the original conditions of sale. Therefore, all DDS tools offered for sale are licensed under our standard agreements (single or site license).

We do offer educational incentives in the form of site licenses to schools and discounts on products for resale by the school, however we do not offer "student" discounts on individual sales.

What about upgrading my products?

We offer an upgrade credit of 50% of your original purchase price. eg: if you have purchased a single Developers Kit package at a price of $100, and later wish to upgrade it to the current version you would receive a $50 credit toward the current package price.

The upgrade credit may be applied to the current version of a package you have already purchased, or to a larger package containing the one that you already have. eg: If you already have a single developers kit package, you can apply your upgrade credit to the "Super Developers Kit" or "DDS Complete packages".

In cases where an upgrade is requested within a short time from the original purchase (new version released or customer decides to purchase a larger package), we will usually offer a 100% credit. This is handled on a case by case basis. Contact us for more information. 

To be eligible, you must have sent in your product registration form to us, and be in our customer database. (Send in that registration now!)    If you purchased your product directly from us, you are already in our database.

You MUST include your DDS Serial Number when ordering an upgrade.

Can I upgrade my 'xxx' toolset to support processor family 'yyy'?

No, each developers kit is targeted at a specific processor family, and can be used only with members/derivatives of that processor family (see FAQ). To work with a completely different processor family, you will need to purchase the development toolset for that family, which is a separate product, and does not qualify as an upgrade.

We do however allow upgrades of one package to a larger package which contains the one you already have. The most common occurrence of this is when a customer has a single "Developers Kit" toolset, and wishes to upgrade to a "Super Developers Kit" or "DDS Complete" package. These packages DO qualify as upgrades to a single development toolset.

I heard that you sell source code, why is it not listed?

Due to many legal and support problems, we no longer offer the source code to any of our products.

Q: I "lost" my source code. Will your XTOOLS disassembler get it back?

A disassembler takes a binary image of your executable program, and performs a translation of the binary opcode values into a human readable assembly language source code form.

It is important to note however that much information which should have been contained in the original source code cannot be reconstructed by the disassembler. The most important of these are:

Because of this loss of source information, you cannot simply "run the disassembler once" and get back production quality source code.

DDS tools have capabilities to build an initial symbol table by analyzing the address references within the binary image, and to accept symbol names, memory block type information and comments from user supplied files, however creating these files for large/complex programs requires MANY hours of disassembly, understanding a bit more of the program, editing the information files and more disassembly.

Given enough time and effort, Yes! you can create good quality source code from a binary image using the XTOOLS disassemblers... But! be aware that this will often require effort comparable to that taken to write the code
in the first place. Software reverse engineering is not easy!

Q: Can your disassembler give me 'C' source code?

Sorry, Far too much information is lost in the source->binary compilation process to be able to reconstruct anything looking remotely like high-level
language source code. To reverse engineer a program to 'C' source code, your best bet is to:

Can you suggest books or material for learning embedded programming?

I've been working with embedded systems for well over 20 years, and I have not looked at any "novice" level publications for quite some time.

I would recommend doing a web search on the particular topics/CPU's of interest. There are a number of sites devoted to this type of information.

Also, check out the web sites of the manufacturers of the devices you wish to use. They usually have detailed data sheets and application notes.

For examples of embedded programming, I would refer you to the library source code that comes with my C toolsets, as well as the examples, projects and other material on my web site.

Other good resources:
---------------------
Circuit Cellar Magazine - www.circuitcellar.com
Embedded Systems Programming - www.embedded.com

Is MICRO-C really as good as you say it is?

Why don't I see you supporting your products on Usenet groups?

My company is not "visible" in the newsgroups, because I oppose the use of the public internet for commercial purposes... Anyone who has ever posted to usenet message with their email address "in the clear" knows why... Just look at the "Dear Friend" messages which arrive in your mailbox every day.

Other vendors post regularly in these and other groups, and are constantly promoting their products... Some blatantly, others in the guise of extra comments made in a helpful response... This is the way these people do business, however it is not the way I do business. My products are promoted and supported on the internet through a proper commercial website, which can be found via search engines, and receives much attention by word of mouth (http://www.dunfield.com).

I do monitor the newsgroups daily and I do respond privately to any inquiries or questions about my products which I feel would benefit from my response.

I provide sales and technical support via email, which I check several times a day... I make every effort to respond "same day", and can provide many testimonials which I have received praising my support (if anyone really wants to see them)...

I am the author of all Dunfield Development Services Inc. tools, code and documentation and I personally provide all of the support... When you receive a technical response from DDS, it is coming directly from me.

Q: Please provide your telephone number so I can call you?
Q: Please call me at ....... ?

Due to the high volume of telephone inquiries and frequent failure of international customers to observe our waking hours, I no longer provide easy telephone access in matters relating to Dunfield Development Services Inc. retail software. If you wish to inquire about our products, please visit our web site, read the FAQs, download
the demos, and correspond via email or FAX on any questions which remain unanswered.

If you require telephone contact for other matters, please contact me initially via my online request form or FAX with a detailed explanation of your requirements.

No response to EMAIL/FAX ... What gives?

Background: We are a very small company, consisting of 2 people, one who handles sales/administration (Sharleen), and one who handles all technical matters (Dave). We both tend to be very busy, and unlike most companies, we do place a higher priority on responding to existing customers over getting new ones. Correspondence with Sales may take a day or two if Sharleen is really swamped, while Dave tries to answer the technical email each and every morning.
There are however sometimes other circumstances... Here are some of the more common reasons why you might not be getting a fast response :

Do you sell site licenses?

YES!  Site licensing is available on any of our products.  Our standard license is one that allows up to 25 users, and is generally priced at 5 times the individual product price (eg:  a 25 user site license for the 8051 Developers Kit would be priced at $ 500 USD.  PLEASE NOTE:  Site licenses are ONLY available from Dunfield Development Services Inc. .  They are NOT offered through our distributors.

Do You Do Contract Work?

YES!  Please see the contract area of our website, for more information on other projects we have done.