@CHIP-RTOS - Programming notes

1. Limited Flash Write Cycles (of IPC@CHIP®s internal Flash):
   To open files on the flash disk drive A: for reading or writing, you can use the standard C functions fopen or open.   We recommend the use of the fopen/fread/fwrite calls instead of open/read/write to reduce the flash write cycles, because these cycles are limited.
   For further information see the FlashWriteCycles document.
   
   
2. Compiler option settings:
   
   • The compiler must produce 186 processor instruction code.
     
   • The data alignment must be set to 8 Bit (Byte alignment), not to 16-Bit (Word alignment)!
   
   
   
3. For inexperienced programmers, we recommend the use of the Large memory model for user applications.   While Small (or Medium) memory models can offer more efficient use of memory and better performance than Large memory model, problems difficult to diagnose may occur when using the near data memory models such as:
   
   
   1. All pointer parameters passed to the @CHIP-RTOS API must be far pointers.   Normally, the compiler will handle this conversion when interfacing to the Beck C-Library functions.   But for functions that use a variable length argument list such as the helper_printf, one can end up generating invalid code without any warnings offered by the compiler.
      
      
   2. @CHIP-RTOS tasks created in a Small memory model program must have their stack memory declared in the program's data segment.   (This requirement is due to the compiler's "SS equals DS" assumption used in near data memory models.)   small memory model programmers who allocate their @CHIP-RTOS task stack space using the system memory allocation function, or declared as far data will observe some very strange program malfunctions and face tedious debugging.
      
      
   3. If floating point emulator is used within @CHIP-RTOS tasks, small memory model should not be used due to the emulator's stack requirements.

4. No "exception handling" in Paradigm or Borland C 4.x or 5.x projects:
   Users of Paradigm or Borland C-compilers should choose for their program project "No exceptions" at the "Target Expert" window.   This setting saves Flash and RAM memory space.
   
   
5. Do not select "Test stack overflow" in the Paradigm or Borland C project compiler settings:
   If "Test stack overflow" is selected a stack check is done at every function call.   If stack overflow is recognized the program halts.   This mechanism is not usable in applications which create additional @CHIP-RTOS tasks inside the application, because every task has its own stack and the compiler's runtime library stack functions are not aware of these additional stacks.
   
   

6. Turbo Pascal programmers should include the example file SC12.INC (part of each IPC@CHIP® Pascal example program).   At the start of their program, they should install the procedure Terminate_Program as the default exit procedure of the program.   Usage of the standard unit crt is not allowed.
   
   
7. Before starting the first Turbo Pascal program at the IPC@CHIP® the memopt 1 command must be executed (e.g. in the AUTOEXEC.BAT)
   
   
8. If programs that depend on one another are started from a batch file (e.g. if a user program needs a previous driver program) the Batchmode 1 in chip.ini should be set.
   
   
9. For C program development, the Beck C-Library should be used.   This library provides efficient wrapper functions around the software interrupt API offered by the @CHIP-RTOS.   Both the library source and binaries are available from the Beck Web site download area.
   
   
10. It is not advisable to design an IPC@CHIP® application as a set of several DOS programs for various reasons including:
    
    
    1. It is usually more efficient to run several tasks (created with the RTOS API) inside of a single DOS program rather than running several DOS programs as tasks of the @CHIP-RTOS.   The single program should require much less RAM and flash disk storage space compared to the memory requirements for a set of programs.
       
    2. It can lead to high memory fragmentation and insufficient memory, if more than one or two DOS programs are running on the IPC@CHIP® when these programs are often terminated and restarted again.
    
    
11. It is not advisable to use in your application the Borland C-library malloc function with memory model Large.   In that case the DOS program tries to increase its own memory block with int21h 0x4A.   If another program is loaded after that program the malloc call fails, because there is no memory space left between the two programs.   It is possible to define a memory gap between two loaded programs at chip.ini but then you must know what maximum memory is required by your malloc calls.   It may be better to statically reserve the memory inside your application by declaring an unsigned character array (or the type you require) of the required size.
    
    
12. The @CHIP-RTOS allocates memory in the following manner:
    
    
    • DOS programs are loaded into the lowest address free memory block of sufficient size.
    • Memory blocks allocated inside of the @CHIP-RTOS or with DOS service 0x48 are taken from the first free memory block of sufficient size, starting the search from the highest heap RAM address.
    
    So the largest free memory block in the system is usually located in the middle of the @CHIP-RTOS memory area.   The shell command mem shows the state of the internal memory map.
    
    

13. Compressed executable files
    
    Compressing executable files with e.g. pklite or upx are useful to reduce the required diskspace. In case that the compressed applications are executed by a batch file the following behaviour should be considered:
    If Batchmode 0 is set, the command shell task (MTSK) waits about 500 ms between executing each line of the batch file. In case of executing a large compressed application the execution of the next application may fail due to the large time (more than 500 ms) required for decompression of the executable in memory. The command shell prompts the error message "Not enough memory to load program" . To avoid this problem Batchmode 1 should be used. It is also possible to insert an additional delay command at the batchfile between the lines of executing applications. A delay of 1 second ( wait 1 ) should be sufficient.
    

Using RTOS API