| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
All 'C' statements:
| |||||||||||||||||||
|
All 'C' operators:
| |||||||||||||||||||
|
The following data types:
| |||||||||||||||||||
|
Arrays of any type (incl. multi-dimension, pointers & structs) | |||||||||||||||||||
|
Function can return any type | |||||||||||||||||||
|
Typecast of values to other types | |||||||||||||||||||
|
Decimal, Octal and Hex constants. eg: 127, 0177, 0x7f | |||||||||||||||||||
|
Full support for strings and character
constants: ('' "") | |||||||||||||||||||
|
Inline assembly code (single or multi statement). | |||||||||||||||||||
|
Preprocessor commands:
|
|
It DOES NOT support:
|
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.
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
DDS tools are designed to run under any DOS compatible system
or emulator. The tools have been confirmed to run under:
| MS-DOS versions 3.0+ | |
| DR-DOS versions 6.0+ (Also called Novell and Caldera DOS) | |
| Windows 3.x | |
| Windows 95/98 | |
| Windows NT (3.x and 4.x and 2000)** | |
| OS/2 version 2.0+ | |
| Linux DOSemu |
| SOFT-PC emulator for Macintosh |
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.
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.
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:
| DDS Micro-C currently supports all processors which uses the standard instruction set of any of the following CPU families: 68HC08, 6809, 68HC11, 68HC12, 68HC16, 8051/52, 8080/85/Z80, 8086, 8096 and AVR **. | |
| Small 8051 & AVR derivatives which do not support the long JMP and CALL instructions are also supported. | |
| Additional peripheral registers (called SFRs in the 8051 family) can be easily defined for direct access of all on-chip peripheral features from C (I include application notes on how to do this). | |
| Superset processor architectures (those having extra instructions and/or additional memory addressing built into the instruction set) should work OK, but the extra features may not be directly accessible. | |
| Subset or modified processors (those which do not support all of the instructions, or have instructions which differ from the standard ones) may not work. Obscure instructions not normally used in normal data manipulation do not usually cause a problem (they may be used in the library, but complete source is provided should you have to modify it), Sometimes MACRO's can be used to translate or simulate instructions which are automatically generated by the compiler. |
** 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)!
We have available a free add-on to our 8051 compiler which provides:
| New library which takes advantage of the DUAL data pointers available in the 80C320. This drastically speeds up memory to memory operations in those memory models that use external memory. | |
| New ASM320 assembler, which supports the additional special function registers for the 80C320. | |
| New CC320 compile command which uses the 80C320 library and assembler. | |
| New 80320.IDE file for the integrated environment. | |
| New 80320REG.H file which defines ALL 80C320 SFR's to the compiler. |
This add-on is available at no charge to licensed DDS 8051 Micro-C users. Please contact Technical Support for details.
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:
| MICRO-C Compiler (compiled itself!) 25K | |
| ANSI terminal with built in XMODEM file transfer 10K | |
| Combination lock (rotary encoder, led indicator) 2K | |
| Telephone "distinctive ring" switcher (1 - 3 lines) 1K |
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.
| 6502 - Proprietary | |
| 6800/01/02/03 - Proprietary | |
| 68HC08 - Motorola | |
| 68HC09 - Proprietary | |
| 68HC11 - Motorola, New Micros, Proprietary | |
| 68HC12 - Motorola, New Micros | |
| 68HC16 - Motorola, New Micros, Intec | |
| 8048/9 - Proprietary | |
| 8051 - New Micros, Proprietary | |
| 8080/8085/Z80 - Midwest Micro-tek, MITS, Proprietary | |
| 8086 - Various PC clones, proprietary | |
| 8096 - Intel | |
| 80320/520 - Mid-Tech | |
| AVR - Kanda, Atmel, Proprietary | |
| H8 - Proprietary, Lego | |
| PIC - Microchip, Proprietary | |
| ST7 - Kanda | |
| Z8 - Proprietary |
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.
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.
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.
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.
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).
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:
| The latest version of Micro-C/PC | |
| The MAKE and TOUCH utility programs for automated builds | |
| The full set of over 100 example programs (**LOTS** of source) | |
| The source code to the entire Micro-C/PC library | |
| A compatible Public Domain Assembler and Linker | |
| Third party libraries and utilities | |
| Product demos and other free software |
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.
| Produces code which runs on the "bare metal", WITHOUT an operating system. | |
| Is easily customizable to address virtually any 8086 family hardware platform (no "standard" embedded platform is defined). | |
| Uses our own (DDS) assembler and linker to produce binary program images suitable for placing into ROM. | |
| Library and startup code do not include operating system specific functions (file access etc.), and do not make any calls or other references to any operating system. |
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).
| Produces code that runs only in a DOS compatible environment. | |
| Is not intended to be easily customizable to other environments. | |
| Uses DOS/Microsoft (MASM) compatible assembler and
linker, and produces standard DOS format executable files. | |
| Library and startup code make **many** references to DOS
and BIOS services and functions. Since the library is designed for a known target platform, it contains many OS and PC specific functions which would not be available on an embedded system. |
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.
| You can use C on ANY target system, even if a native code
C compiler is not available for it. All you have to do is to get a C-FLEA VM up and running, and all of the C-FLEA tools and libraries will work. | |||||||||||||
| C-FLEA code is portable and platform independent... You
can implement C-FLEA VM's with similar I/O features on multiple (different) hardware platforms, and then compile a single C-FLEA program which can be run on all of them without requiring any changes or recompilation. | |||||||||||||
| Since you "write" the C-FLEA CPU, you can
provide functionality that cannot be achieved in a conventional system. Here are some ideas:
| |||||||||||||
| C-FLEA code is very space efficient. The C-FLEA instruction set was designed from the beginning to be ideal for a C implementation, and as a result, you can pack a lot of C code into a fairly small image. In most cases, programs compiled for C-FLEA will be SMALLER than the same program compiled for a native CPU (Note: Since there is a memory overhead for the C-FLEA VM code, the total memory required will only be less for large programs). |
| C-FLEA code runs slower than native code, especially if the native CPU already has an instruction set which is well suited to C. | |
| The C-FLEA VM occupies memory, making that memory unavailable to the application code (more important with smaller systems). |
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:
| All of our libraries and linkable modules are stored in
the form of assembly language source files instead of a binary
"object" format. These may be hand-crafted (as in the case of our
libraries), or the assembly output of the C compiler. |
The "source" Linker (SLINK.EXE) performs all operations that a conventional object linker does, but at this assembly source level:
| Resolve inter-module external references. | |
| Resolve library references by pulling in the library code required (Only the library modules required are included). (SLINK also supports runtime loading of only sections of a library file, a feature not found on object linkers). | |
| Provide multiple output "segments", and allow code and data to be directed into these segments (by SLINK directives embedded in the source) as it is processed. This provide the ability or group all code, internal data, static data, dynamic data etc. into specifically allocated areas of memory. | |
| Update non-public and compiler generated symbols to be unique, eliminating symbol conflicts between modules. |
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.
| Our's is the only development system that we are aware of
which supports multiple modules and libraries, and which is
capable of GENERATING A COMPLETE ABSOLUTE ASSEMBLY LISTING
OF THE FINAL IMAGE. This listing includes all code, data and
directives, and shows the final/absolute HEX addresses where these items are placed in memory. A compiler switch allows the C compiler to include the original C source code as comments in this listing, and all of our hand-crafted library modules are well commented. This makes a very useful resource for debugging at all levels, and is the only way to see exactly what has been placed (and where) in your target system memory map. | |
| Minor edits and changes to library functions, including
the memory layout and startup code do not require any
special re-compilation and re-linking of the library. You
simply make the change to the library source files, and it will be in effect for the next compilation. (Library parameters, memory layout, startup code etc. are often changed during the debugging process, or as you move from one target system to another). | |
| The availability of a single .ASM source file for the entire code image makes it possible to perform global changes and instruction replacement not possible with "object" modules. |
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.
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.
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)!
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:
| Our compiler can generate an assembly listing with the C source code included as comments. ie: You see a line of 'C' code, followed by the assembly language instructions that were generated by it. Since it is a listing, it also includes the absolute hex address and opcode bytes. | |
| Due to the way our linker and assembler work, this listing covers the entire program module, including startup code, library functions, and any external modules. This is a feature that few other vendors can provide (NONE that we are aware of). | |
| You can use our IDE's built in browser to view this file
while you are debugging. This makes it very easy to follow the C logic,
while also giving the detailed perspective of the individual
instructions. If you prefer to use our command line tools (or anyone else's), we
supply a TSR browser that can be "popped up" while
operating in any environment. Note: Both browsers support multiple open files, and can be also be used to view source files, documentation etc. at the same time. |
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.
LOTS of good stuff!
| Application notes. | |
| Utilities: Editors, File/Directory manipulation, TSR browser, listing and symbol table utilities, MAP file generator, ASCII encoder/archiver, Complete COMM/TTY package... much more. | |
| Tiny MS-DOS compatible file system in C. Files for "embedding" PC's, Multi-tasking kernal for some cpu's. Not to mention all the good stuff in our DEMO files which is included at no charge. |
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:
The main advantages of EMILY52 over the TTY monitor are:
| EMILY52 has a much nicer user interface featuring multiple concurrent displays for registers, memory etc. with interactive menus. | |
| EMILY52 supports hardware to separate the 8051 CODE and DATA address spaces (64k CODE + 64k DATA), where the monitors requires a common CODE+DATA address space. | |
| EMILY52 provides a 4096 instruction "traceback" when operating in "Pure Simulation" or "In-circuit Simulation" modes. With this feature you can see where the code "came from" to get to a breakpoint etc. | |
| EMILY52 has "smart" breakpoints, which can be set to break immediately, break after 'n' occurrences, count occurrences only, update displays only, update displays then pause and continue, and more... | |
| EMILY52 supports user defined code to simulate hardware devices. | |
| EMILY52 has a special mode for 8051 in-circuit emulation using a Dallas DS5000 series CPU. This allows you to have all of the debug features while operating in "single-chip" mode (All I/O pins available). | |
| More... |
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.
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.
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:
| P&E .MAP debug files | |||
| NoICE .NOI debug files | |||
Intel .OMF (OMF-51) debug files
|
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.
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.
Sorry, I do not provide demo's for the individual native
CPU's that I support.
There are several reasons for this:
| It is very difficult to keep multiple demo's "up to date". | |
| Most users need to configure the native toolset to their
target environment (memory map, CPU derivative etc.) before
they can run the code, and many are unwilling to do this for
a simple demo... With my generic DEMO, I provide a
simulator so that you can run code right "out of the box". | |
| As my tools are very straightforward, simple, and not copy protected, they are easier targets of "hackers", and I could not present DEMO's that are hard to "crack" without altering the tools significantly. |
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.
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.
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.
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.
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.
Due to many legal and support problems, we no longer offer the source code to any of our products.
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:
| Meaningful symbol names | |
| All Programmer Comments | |
| Code/Data area boundaries and types |
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!
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:
| Disassemble the program into an assembly language source file. | |
| Examine this code and understand the program's function very well | |
| Write a 'C' program which performs the same function. |
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
| Sturgeons Rule has it that 90% of science fiction is junk.
A similar rule applies to PC software, but I'd say that 90%
is a lower bound. Once in a while, though, you find a
product that makes up for the rest.. If price has kept you
out of the micro controller C market, you have no further
excuses. Micro-C is as good as it gets! - Circuit Celler INK Dec91/Jan92 | |
| I just obtained Micro C, and I'm very impressed!... The
portability of Micro C is second-to-none, as is it's
professionally written code and overall usability... I need
to emphasize here that Micro C is by far the best coded
compiler I've ever seen. This excellent code quality extends
throughout all associated modules. - FIDOnet 'C' programmers echo | |
| Dave, Thanks for responding to the minor problem I had
with your wonderful little compiler. - A satisfied customer |
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.
![]()
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.
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
:
Bad return address
| |||||||||||||
Non-Delivery
| |||||||||||||
Solicitation
| |||||||||||||
Vacation / unforeseen events
| |||||||||||||
Priority
| |||||||||||||
Special Requests
| |||||||||||||
Forgetfulness
|
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.
YES! Please see the contract area of our website, for more information on other projects we have done.
© 2009 Dunfield Development Services Inc.
View our Privacy
Statement.
Refunds given at the discretion of management.
Last Updated: Monday, June 29, 2009
