Programming notes - SC12 @CHIP-RTOS V1.10

1. Limited Flash Write Cycles (of IPC@CHIPs 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:
   We recommend the usage of large memory model for user applications.
   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. No "exception handling" at Borland C 4.x or 5.x projects:
   Users of Borland C-Compilers (which provides "exception handling libraries" as it's default setting for 4.5 or 5.02) should choose for their program project "No exceptions" at the "Target Expert" window.   This setting saves Flash and RAM memory space.
   
   
4. Do not select "Test stack overflow" at Borland C 4.x or 5.x 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 user applications which are using several tasks inside their application, because every task has its own stack and the Borland runtime library stack functions are not aware of this.
   
   

5. 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.
   
   
6. Before starting the first Turbo Pascal program at the IPC@CHIP the memopt 1 command must be executed (e.g. in the autoexec.bat)
   
   
7. 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.
   
   
8. The old CLIB library (< V2.00) and some older examples are using the standard int86 and int86x calls from the Borland C standard library.   We used these functions for more readable code.   If developers need higher performance in their applications, it will be better to use the new CLIB library (>= V2.00) which implements the API calls with inline assembler code.   With inline assembler instructions it is possible to load the processor registers directly with the needed parameters and directly invoke the appropriate software interrupt int xxh.
   
   
9. For certain reasons it is not advisable to design an IPC@CHIP application as a set of several DOS programs:
   1. It is more meaningful to run several tasks (built with the RTOS API) inside of one DOS program because this requires much less RAM and Flash memory space, than running several DOS programs as tasks of the @CHIP-RTOS.
   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, which will be often terminated and restarted again.
   
   
10. Most of the used pointer variables and function parameters in the old CLIB library C files (< V2.00) are not declared as FAR pointer, because all of our test programs are using the memory model Large (at model Large all pointers become automatically FAR pointers).   If you want to use e.g. memory model Small for your application you should use the new CLIB (>= V2.00) and declare the pointer variables and function parameters inside your program explicit as FAR pointers.
    
    
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 is better to reserve inside of your application the memory by declaring an unsigned char array (or the type you require) with the needed memory size.
    
    
12. The @CHIP-RTOS has its own memory strategy.
    The @CHIP-RTOS always allocates memory in the following way:
    DOS programs are always loaded at the first lowest free memory block. For memory blocks allocated inside of the @CHIP-RTOS or e.g. with DOS service 0x48 the @CHIP-RTOS always start searching for a free memory block from the highest possible RAM address.   So the largest free memory block of the system is always located in the middle of the @CHIP-RTOS memory area.   The shell command mem shows the state of the internal memory map.
    
    

Using RTOS API