DIGI Dynamic C 10 User Manual

DIGI INTERNATIONAL
9350 Excelsior Blvd, Suite 700 Hopkins, MN 55343, USA +1 (952) 912-3444 | +1 (877) 912-3444
www.digi.com
Dynamic C 10 Release Notes
Dynamic C 10
INTRODUCTION
These are the release notes for Dynamic C 10.
Dynamic C 10 is the IDE (Integrated Development Environment) for Digi International’s core modules and single-board computers based
on Rabbit 4000, 5000 and 6000 processors.
The IDE includes a graphical editor and debugger, a command-line compiler, and a graphical tool (Rabbit Field Utility) for installing compiled binary firmware to a serially-connected device.
SUPPORTED PRODUCTS
RCM4000, RCM4010, RCM4050 RCM4100, RCM4110, RCM4120 RCM4200, RCM4210 RCM4300, RCM4310, RCM4320 RCM4400W RCM4510W RCM5400W, RCM5450W RCM5600W, RCM5650W RCM5700, RCM5710, RCM5750, RCM5760 RCM6600W, RCM6650W RCM6700, RCM6710, RCM6720, RCM6730, RCM6750, RCM6760 BL4S100, BL4S110, BL4S150, BL4S160 BL4S200, BL4S210, BL5S220, BL4S230
KNOWN ISSUES
1. Debugger issues
When debugging a program using either F7 or F8 into or over a call to kbhit() will cause the debug cursor to disappear. Pressing F7 or F8 two more times will make the debug cursor reappear following the kbhit() call.
The breakpoint highlight for the closing brace of a function does not display correctly if the brace is not in the first column of the editor window.
The debugger currently only supports 128 breakpoints. Setting more than 128 breakpoints will result in the loss of target communications.
The debugger does not support assembly language single stepping over function calls that do not return to the instruction following the call such as "_switch". Any attempt to do so will result in loss of target communication. Stepping into the function in assembly is supported, as is stepping over such functions in C.
If an ipset or ipres instruction is followed immediately by an rst 0x28, the debug kernel will not step over the rst 0x28 correctly, but will end up in an unexpected location. When either of these instructions are followed by instructions other than rst 0x28, the debug kernel behaves correctly.
The Register Contents debug window (F11) doesn’t report the correct LXPC value if it’s >= 0xFF. It reports 0x0FF as “LXPC: FFF” and leaves the high nibble off of values >= 0x100 (so 0x123 appears as “LXPC: 023”).
2. Software modules.
RabbitWeb gives a cryptic error message for buffer overflow when using the print_select() statement. The workaround is to make HTTP_MAXBUFFER large enough to hold all of the OPTION statements generated by the print_select() statement.
3. Complex casts
The compiler will not accept multidimensional array types or derivatives thereof as cast expressions, even if the cast expression is a typedef name. Use a union to work around this problem.
4. Advanced 16-bit memory mode CPU bug
The Rabbit 4000 CPU’s advanced 16-bit memory mode has a defect which affects ioe instructions (auxiliary I/O, external I/O) and self-timed chip select. The Dynamic C BIOS has been updated to work around this ioe defect on affected boards, all of the RCM40xx family. If absolute top performance is required and the User is certain their application is unaffected by the ioe bug, the work around can be disabled by adding the __ALLOW_16BIT_AUXIO_DEFECT macro into Dynamic C’s Project Options Defines Box. See the Rabbit 4000 Users Manual Appendix B (errata section) or TN255 for complete details.
5. In separate I/D mode, an array declared as
far char bar[] = {0,1,2,3,...};
will not compile correctly when the size of the array exceeds the size of the root constant space and will give an error that the ‘}’ character is missing. The work-around is to specify the size of the array as follows:
far char bar[32000] = {0,1,2,3,...};
6. Highlighting a block of text while in Stop mode
In some cases, depending on the specific text, highlighting a block of text can result in a flyover watch which returns a copy of that text in the hint window.
7. Using #pragma SIZEOF32 can result in a sizeof problem for a large struct.
Using #pragma SIZEOF32 allows the argument of sizeof to be up to 4GB but will return an incorrect value without warning or error if the argument involves a struct of size 32K or larger. When using #pragma SIZEOF32, always restore to the default with
#pragma SIZEOF16 following the use of sizeof.
8. Initialized global and static variables and #GLOBAL_INIT expressions run with a limited stack (256 bytes). Deeply nested functions (including printf()) will cause a loss of target communications.
9. Cast ternary operator(s) if both values do not have the same type and type qualifiers - example: condition ? &aFarChar : (far
char *)NULL. In the example, if condition is true and NULL is not cast, a near address is erroneously returned.
10. As of 10.66, symbols are distinguished using the first 63 characters of the name. Older versions used 31 characters, the minimum per the ANSI specification. If a long symbol name is used as a library module label (i.e., in a BeginHeader statement), the library’s .MD1 file will contain the short version of the name, and the module will not be found. For example:
/*** BeginHeader A12345678911234567892123456789312 ***/ extern int A12345678911234567892123456789312; /*** EndHeader ***/ int A12345678911234567892123456789312;
will generate the error line XXX : ERROR MY_LIB.LIB : Undefined (but used) global label
A12345678911234567892123456789312. The workaround is to change the timestamp on the library file (e.g., modify it and save it)
and recompile. The .MD1 file will be regenerated with the correct (longer) module label.
11. More than one return statement in a cofunction will result in unpredictable behavior.
12. For auto int i, the expression (far*)&i should be (far int*)&i, but the first form will produce confusing error messages:
Invalid expression. Missing character ';'. Missing character ')'. Not a pointer, cannot dereference.
13. A c return statement in an assembly block can produce an error like Undefined (but used) global label
.DCLAB__ZW00000190 in large programs. The assembly block can be ended followed by the return statement in C followed by the
remaining assembly in a new assembly block.
14. The active status of hardware breakpoints is not retained when a program restarts. Each breakpoint must be modified in some way such as toggling a checkbox so that the “Update” button becomes active.
15. Setting a hardware breakpoint on some internal I/O addresses can lead to a target communication error. Since setting a breakpoint mask to 0xffffff will include all internal I/O address, the address and mask should be set to include only the intended range of addresses.
16. Programs larger than 512K will not compile to RAM successfully on an RCM5450W core module. Compiling such programs to flash works fine.
17. Number of dimensions in array initializer are not checked against the array declaration.
Dynamic C will compile an initializer with too few dimensions without complaining:
// two few dimensions in initializer const static int a[][3][2] = {{11, 12}, {21, 22}};
The results are undefined. If there are too many dimensions in the initializer, Dynamic C will indicate an error } is
missing/expected.
18. For functions with both a near and far syntax, function help is available only using the unadorned name. For instance, placing the cursor over _f_memset will not find the function help for memset. In order to find function help for a function prepended with either _n_ or _f_, such as _f_memset, separate the main part of the function name before pressing Ctrl+h.
19. A function that returns a struct by value does not work correctly within a cofunction. A work around is to have the function return a static struct by reference and then dereference the function result on assignment in the cofunction, e.g.:
struct point { int x; int y; };
struct point *foop(void) { static struct point tmp;
tmp.x = 3; tmp.y = 4; return &tmp; }
cofunc void co_func(void) { struct point tmp;
tmp = *foop(); // dereference the result at time of assignment printf("cofunction by reference, x=%d, y=%d\n", tmp.x, tmp.y); }
void main(void) { struct point tmp;
costate { wfd co_func(); } }
20. An index variable used in calling an indexed cofunction cannot be auto. The index variable must have static (local) or global storage, e.g.:
#define INDICES 5
cofunc void my_icofunc[INDICES](void) { ; }
void main(void) { static int i;
while (1) { for (i = 0; i < INDICES; ++i) { costate { wfd my_icofunc[i](); } } } }
21. Auto pointers to CoData structures cannot be used in named costatements. The CoData structure pointer must have static (local) or global storage, e.g.:
#define NUMTASKS 5
void main(void) { auto int i; static CoData task[NUMTASKS]; static CoData *ptr2codata;
for (i = 0; i < NUMTASKS; ++i) CoBegin(&task[i]);
while (1) { for (i = 0; i < NUMTASKS; ++i) { ptr2codata = &task[i]; costate ptr2codata always_on { ; } } } }
22. Dynamic C currently does not allow function pointers to return structures by value. The following code snippet will generate an error:
typedef struct { int a; } my_struct_t; my_struct_t (*func_ptr)(); main() { my_struct_t s; s = func_ptr(); }
23. Assembly labels within #asm blocks inside C functions are treated as if they are local C-labels, rather than existing within their own scopes. In the following code, the expected behavior would be an “unknown label” error on the jp to foo since there is no global label foo defined. However, the linker associates the local label with the jp instruction and the code compiles.
Note that this behavior only occurs between #asm blocks within C functions. It does not exist between stand-alone #asm blocks or between blocks in separate C functions.
void func(void) { #asm jp foo ; This jumps to the label in the next block #endasm // Some C code #asm foo: ; The jp above lands here #endasm }
Loading...
+ 8 hidden pages