<< Previous | Index | Next >>

Appendix A. Porting Existing Dynamic C Applications to RabbitSys

Most Dynamic C applications will run under RabbitSys with no code changes. All you have to do is recompile the application after checking "Compile program in RabbitSys user mode" on the Compiler tab of the Options | Project Options dialog box. This appendix will discuss the isolated cases where code changes are necessary and list any restrictions that programmers should know.

A.1 Applications that Require Code Changes

There are several scenarios that will require you to make code changes in order to port your application to RabbitSys.

A.1.1 Custom Memory Configurations

If you have coded your own org statements or have written to hard-coded areas of memory, your application will need modification.

A.1.2 Use of Level 3 Registers

With the System/User mode of operation, there are some registers that are always off limits to programs running in User mode. These registers are categorized as level 3 and are listed in Appendix B.2.

A.1.3 Applications with Size Constraints

If your program is pushing the available memory limits, you may have to look at ways to reduce its size. Some applications can take advantage of RabbitSys features to reduce code size. An example of doing this are the sample programs motor.c and motor_rs.c, both located in /Samples/RabbitSys/Motor. The program motor.c was rewritten as motor_rs.c to take advantage of the the RabbitSys internal HTTP server.

For more information on reducing memory usage, see Technical Note 238, "Rabbit Memory Usage Tips."

A.2 RabbitSys Differences

Listed here are some differences between Dynamic C with RabbitSys and Dynamic C without RabbitSys.

1. Cloning - You cannot define the cloning macro ENABLE_CLONING in the RabbitSys environment.

2. Download Manager - The macros used to compile programs for use with a download manager and a download program, COMPILE_PRIMARY_PROG and COMPILE_SECONDARY_PROG, cannot be used with RabbitSys and are not necessary. The RabbitSys remote program upload feature offers an easier way to accomplish the same task.

3. Error Logging - There is not a restriction on error logging, given that the Monitor allows you to create a wide range of error logs that are persistent over resets and crashes; however, the default error logging that is enabled by the macro ENABLE_ERROR_LOGGING is not available using RabbitSys.

4. FS2 - Although the FS2 file system is not compatible with RabbitSys, the Dynamic C FAT file system is.

5. PPP - The PPP protocol is not currently compatible with RabbitSys.

6. Slice Statements - Preemptive and cooperative multitasking are supported by RabbitSys, but not the use of the Dynamic C slice statement.

7. Timer Variables - The global timer variables MS_TIMER, SEC_TIMER and TICK_TIMER can no longer be changed by an application. Changing these variables has always been discouraged, but now will not be allowed.

8. Power Cycling - Resetting the power on a RabbitSys-enabled device without a programming cable attached will not necessarily cause a loaded application to run as it would without RabbitSys. If the application was running when the reset was applied, then it will run after reset; however, if the application was stopped when the reset was applied, the "app go" Console command must be issued to cause the application to run. In other words, the application status (running or stopped) is retained during a power cycle. The exception to the rule is an application that has been compiled to the target but has not yet executed. In that case, after a power reset the application will automatically run.

9. Spectrum Spreader - A RabbitSys application cannot currently configure the spectrum spreader. It is enabled for "normal spread" and may not be changed. More information on the spectrum spreader can be found in the user manual for your Rabbit microprocessor; e.g., the Rabbit 3000 Microprocessor User's Manual.