1. we try to inventory, at our expense, single-source components if they’re in danger of becoming declared EOL;
2. we work with third-party vendors to develop multiple replacement sources for any vulnerable components;
3. finally, we design replacement solutions that are drop-in compatible at the source, firmware, or hardware level.
   Bottom line: TERN will inventory all currently available designs for 3-5 years, actively plan for 5-10 years, and aim for 10+ years.

This program is designed for customers who have specific requirements for a modified version of TERN controllers. In fact, many of the controllers in the TERN product line were first created as a custom design.

The process is incredibly easy, and if you are looking at a large volume project, it might be the right one for you. Specific terms differ from project to project, but for a small one-time fee, TERN can deliver three pre-production controllers according to your specifications, as well as complete software drivers.

These are usually available within a very short period (as little as a few days for minor changes such as additional UARTs, modified header configurations, etc.).

If you have problems with your board and need to get in touch with TERN tech support, remember to provide the serial number for your controller. This is typically a 5-6 letter/number code printed in a white sticker on the back of your PCB.

This code will help us identify details about the order, and help us understand the details of any order-specific configuration on this device. Without this code, we would just be making guesses in the dark.

In the past couple of years, AMD has announced they’re ceasing production of the popular Am188ES/Am186ES microprocessors. A large family of TERN controllers are based on this easy to use and highly reliable processor.

TERN’s fortunate in finding RDC, a Taiwanese-based processor-design/manufacture company that provides a family of products very similar to that of AMD. Also clocked at 20/40 MHz and with similar pin-outs, TERN has been able to adopt our hardware and software environment to work with the RDC-based processors.

As a new customer, whether the A-Engine controller you’ve purchased uses the AMD or RDC processor should not matter. Our libraries have been designed to work equally well with both. As an existing customer who has to now received AMD-based controllers, you should first of all be ecstatic that the life-time of your product has now been extended indefinitely! You should also contact TERN for updated version of your libraries (ae.lib, etc…) to assure compatibility.

KNOWN RDC COMPATIBILITY PROBLEMS: The RDC processor doesn’t seem to deal with non-word aligned variables correctly. If you are now working with a RDC-based processor, make sure you adjust the compilation. Within your Paradigm C++ IDE, choose ‘Project->Options’, ’16-bit Compiler->Processor’, and make sure ‘Data alignment is set to word.

The DEBUG ROM is a ROM IC (usually with a green-label) that contains the DEBUG kernel that allows you to remotely debug your application, as well as downloading through the serial port.

It is included in every software development kit, although additional ROMs can be purchased. The ROMs are different for each controller architecture (and sometimes within the same architecture), so be sure to confirm your part number when ordering. The DEBUG ROM is only needed for the debugging process. You can always burn your own ROMs to replace the DEBUG ROM to execute your code exclusively.

You only require one DEBUG ROM (assuming you are using the TERN development kits), but you might wish to purchase more to allow concurrent development on more than one controller. In newer TERN controllers, there is now no specific DEBUG ROM. Instead, newer TERN PCBs tend to use surface-mounted Flash ROM components for program memory.

This helps lower cost, decrease board size, as well as increasing reliability. Instead, your development package will include a DEBUG kernel program file (Intel HEX) that is loaded/programmed into the surface-mounted Flash when you need to debug your application.

Occasionally, we get these requests from engineers accustomed to writing their own drivers and working directly with the hardware components. While we are willing to accommodate your requests for just the controller, we once again strongly suggest you consider purchasing the software kits.

Whether or not you choose to take advantage of our driver libraries, the development kit will provide a controller of your choice with basic options, a complete technical manual that includes a schematic, and all at a cost that would be competitive with the bare controller itself.

The development kit provides a great way of prototyping your application, and you could always pick and choose between library functions you might not wish to implement.

When you install Paradigm C++ – TERN Edition off of the CD provided by TERN, you will come across a dialogue that asks you to type in your installation code/password. Customers that have purchased the EV-P evaluation kit (see software kits for details) will NOT have receive a password, and you don’t need one.

You can simply skip this screen and continue with the installation of Paradigm C++ – Lite. All of the TERN samples will still be installed as normal. If you have the full DV-P development package, then you should be able to find the installation code/password on the sleeve of your CD. If you’ve lost this, please contact us with your purchase information to retrieve the correct code.

If you’ve purchased your board along with a software development kit, it is typically shipped from TERN’s offices configured for immediate debugging. There shouldn’t be any configuration changes you need to make to the hardware itself; plug in the serial cable, power up the board, install the software and you’re ready to start work.

Sometimes things don’t work perfectly, and Paradigm C++ will respond with the general error message: “Connection could not be established.” When this happens, go down the following check-list to see if you can diagnose any problems with your system setup:

1. Is the LED blinking twice at powerup? If NO, this indicates the debug kernel isn’t running on the board, and there is no way for the board to communicate with the debugger on your PC. Return to chapter 1 of your technical manual, and follow the steps needed to “prepare your board for debugging”.
2.  Do you have the correct baud rate set in Paradigm C++? Almost always, the proper baud rate for communication through Paradigm C++’s debugger is 115200. If you have a low-power board (clocked at 20 MHz), this baud rate might be halved to 57600. Or, you might have loaded a different debug kernel with a non-default, slower baud rate for working with older systems. If you aren’t sure, contact us for details
3. Do you have the serial port/cable properly configured? You might have the wrong COM port, the serial cable might be plugged in improperly, or maybe your PC’s serial port is just broken. If you have a TERN board with a surface-mount Flash, there’s an easy way to test the serial port configuration for your system. Open up a basic communication program on the PC side (preferably not Hyperterminal; try ‘Tools->RTLOAD’ from inside Paradigm C++).

Configure the communication program for the COM port you have in mind, at 19200 baud. Now, remove the red “Step 2 jumper” from your controller and power up (you’ll have to replace this when actually debugging!). If the serial connection is correctly configured, you should see the TERN ACTF menu displayed across the serial link on your PC.

No, your development disk will include drivers, libraries, and sample files for all controllers in the TERN product line at the time of your purchase.

From a software point of view, you will not need to purchase additional development kits (although you must also meet the licensing requirements for Paradigm’s IDE if developing on multiple PCs). You should be aware, however, that controllers developed after the time of your initial purchase are not included in your development kit, and you would have to repurchase the appropriate kit.

You might also want to purchase a development kit for new controllers just because it includes a variety of other accessories that will be convenient: wall-transformer, serial cables, expansion boards (if needed to provide 5V regulator + RS-232 drivers).

Absolutely. All TERN controllers have the ability to work with floating point numbers, according to standard ANSI C definitions. On the V25/186/386-line of processors, there is no integrated math coprocessor. Instead, all floating point calculations are conducted via a runtime software emulation library.

This can be a burden on very floating-point heavy calculations. To enable floating point calculations, first bring up the Target Expert by right-clicking on your target (.axe) node, and then selecting ‘Emulation’ Math Support. With the 586-Engine, the onboard math coprocessor can be used for high-performance floating point calculations.

This can be many hundred of times faster than the software-emulation model. To enable this, select ‘Floating point’ under Math Support, as above.

NOTE: – When working with floating point numbers, take a look at the standard Paradigm demo \paradigm\examples\real\fpdemo. You might wish to add error-handling capability to your application. – Also, do not use floating points within your interrupt handlers. The stack requirements might cause strange behavior.

While we recognize that occasionally customers already own copies of Borland C++ or other software, the TERN development kits are bundled together to provide a complete and working software package.

There are many inherent benefits in using a software package that should run straight out of the box, and we strongly suggest that you use the TERN development kits to at least begin your software development project. If you prefer your own version of Paradigm software (allowing dynamic variable watching) or Windows-based compiler/environment, you should be able to replace the TERN included software components with your own further down the line.

The TERN development kit also includes a controller of your choice along with basic options. The benefit of purchasing a bundled package including software and hardware is that you receive a complete package, ready to run out of the box. The value of the hardware components alone often outweigh the cost of the development kits (i.e., if you added the cost for a controller, VE232, DEBUG ROM, wall transformer, serial cable, etc.).

There have been a few known issues with the Paradigm IDE, and they’re listed here along with recommended fixes. – DEBUGGER INCONSISTENCY When downloading code for debugging, the debugger does a simple checksum comparison of the code already in the controller’s SRAM with the current executable. If they match, by default the debugger skips the download phase and executes the code already resident in SRAM.

This can lead to problems when small modifications are made to your source. It’s possible the debugger will believe the executable has not changed because the checksum remains the same, and thus you’ll end up debugging an executable that does not match your source. Inside your IDE, select ‘Options->Environment’, ‘Debugger->Debugger Behavior’, and de-select “Reload target only if checksum differs” to avoid this problem.

The small model libraries are provided by default, but they limit you to data and code segments of 64 KB. For almost all embedded applications, this is sufficient, especially since the rest of the SRAM heap can be accessed for data purposes using peek() and poke().

The small model has benefits of being smaller and more efficient. The large model libraries are provided in the lib\large sub-directories, available for use if you need large amounts of code and data space.

Our recommendation is that any new customer start with one of our software development kits. These kits include all of the software (and hardware) you would require to begin development. The Evaluation version of this kit differs from the Development version in that you can not generate the .BIN or .HEX files needed to burn ROMs for your large-volume production controllers.

An upgrade is available for you to change from the Evaluation version to the Development version at a later date however. Depending on whether your application is for an OEM project, you might not require the Development version.

Remote debugging is provided by Paradigm C++. As your code executes on the controller, you can monitor and modify processor registers and memory values. You can also set breakpoints and single step your control point through the code.

Basically, every debugging feature you have become accustomed to in standard PC-based debugging tools are available through the Paradigm C++ debugger.

Programming TERN controllers is a painless process that still allows you to have great versatility and power in developing your application. TERN provides driver libraries with interface functions that allow you to control simple functions such as toggling parallel digital I/O, turning on the LED, checking analog I/O with a few simple function calls.

More complex programming features such as external interrupts, internal timers, error-free high-rate serial port transfers, the filesystem library for the CompactFlash controllers, and graphic libraries for the LCDs are also all supported within the driver libraries.

As part of the TERN software development kits, sample files are provided that demonstrate the various features available on your controller, and how they can be controlled within your source code.

One of the primary advantages of the TERN development environment is that it’s essentially a standard, x86, ANSI C-based system. Open-source software, existing libraries, existing code can all be easily ported over onto the TERN platform. There are few surprises in the development process.

TERN controllers are programmable in C/C++/asm, using Paradigm C++. Paradigm C++ is a Windows-based IDE with features that should be familiar to anyone who’s developed applications for an embedded, or even PC-based environment. You can check out more details about the TERN software packages here. Your application is developed to run on top of TERN-provided hardware drivers drivers.

There is no commercial-grade operating system responsible for multi-tasking support, that might also be used to control the use of hardware resources… but TERN’s software libraries provide an API that implements many of the useful functionality of embedded real-time OS’s. Your program code, written in C and using our software functions, are then compiled and linked with TERN libraries on the PC.

The linked executable is downloaded through the Paradigm environment using your PC’s COM port into the controller’s battery-backed static RAM. You can remotely debug your application as it executes on the board: setting breakpoints, evaluating expressions, monitoring watch variables… standard development tools thats make development on TERN controllers effortless. Finally, you will be able to generate .BIN/.HEX versions of your application for storage into the non-volatile memory on the controller.

There’s usually at least 512 KB of non-volatile memory available, either through surface-mounted Flash or through a ROM DIP socket.