Back to top

Falcon Development System

Falcon development system main screen

This product has been discontinued. This web page is provided so current customers using the product can have a quick reference for specifications. Please contact Automation Electronics for current products that may meet your needs.

Over the last twenty years or so, the development systems used to program our controllers have undergone several changes. Most of our early controllers were programmed in Ladder Logic and this is still offered as an option on most current controllers. From there, we moved to C programming using an interpreted C kernel. This gained us math processing power and an improvement in speed over ladder logic programming. As the mathematical processing requirements increased, it became clear that we needed a more powerful development and operating environment. Falcon was born.

Falcon added a native assembly code generator to our C compiler that eliminated the overhead of C code interpretation in our kernel. At the same time, we updated the native kernel we run in the controllers to provide multi-tasking priority based task scheduling in the controller. Core I/O can run at a high priority and guarantee that it will not be interrupted. User interface operations can be run at a low priority that won't interfere with the application. The application program itself can be split up into functional tasks that can be scheduled at particular run intervals with specified priorities to guarantee that more important parts of the application run first.

There are many other basic advantages to the FDS over the previous AEROS development platforms.

  1. The linker only links in library functions that are used in your application. In AEROS, the full library was always available in EPROM. Since only the required functions are linked, you can usually reduce the EPROM count for the final executable, reducing costs and simplifying upgrades.
  2. Before, you had to be sure you were using the right version of the development system for the AEROS kernel in the boards in the field. Now, you select an application programming interface (API) to compile against, with its include and library files, and do your compile. Since everything, including the micro-kernel, is part of these API specific files, you always get a runnable executable for your board.
  3. As improvements are made to the libraries you can recompile at any time and get the benefits of those improvements. If we ever need to change the API, we will start a new release of the library and include files. The choice of API is yours. You won't have to make changes to your code as long as you keep the same API. If you want new features that are available in a new API, you can decide when to do the code upgrades to your code to match the new API.
  4. New I/O devices can be rapidly prototyped and supported by adding an appropriate driver subroutine to the library. If we need to provide a different method of handling a particular piece of I/O hardware, we can create a new subroutine with a new name that handles the hardware in that particular way. When you reference that subroutine, it is automatically included in your program. No more O/S EPROM upgrades.
  5. Existing I/O operations can be optimized by only calling certain I/O subroutines when data changes. In the old AEROS kernel all I/O was serviced with each pass, even when no changes had been made.
  6. The time base of the controller has been standardized on Unix EPOCH time (unsigned long), which will give valid dates from 1/1/1970 GMT into 2106. The way it is encoded will now provide more uniform processing time to produce visible date strings. The older AEROS time handling was taking more and more time to process the further away from the epoch of 1980 that it got.
  7. The new development system provides access to many more "register" type variables and allows a wider range of items to be stored in registers. This speeds up the operation of the program significantly. Each task has its own register space to which it can assign its own important frequently used variables. Some smaller tasks can run completely from this semi-private register space for much faster execution.
  8. You have tighter control over where variables are stored. The number of variable types has increased slightly.
  9. The compiled nature of the code means that everything runs anywhere from 3 to 5 times faster and can be made re-entrant in most cases, simplifying code design further.
  10. You have the ability to embed assembly code directly in your program if needed for time critical situations.
  11. It is much easier to use our 65816 emulator with the code since you aren't using an interpreted C kernel.