***************************************************************** README for Dynamic C Version 10.60 ***************************************************************** -- Variable Initializer Support Variables can now be initialized at declaration. For example, void foo(int bar) { int i = 0, j = bar * 2; struct FOO {float pi, e, sqrt2;} fvals = {3.14159, 2.71828, 1.41421}; static far char carray[] = "String literal initializer"; ... } Simple variables (integer and floating point types, pointers) can be initialized with any appropriate expression that evaluates to the correct type. Aggregate types (structs, arrays, unions) can only be initialized with constant values (i.e., anything that can be used as an initializer for a constant). Variable initialization follows the ANSI C 1989/ISO C 1990 specification: - Initializers for auto (non-static local) variables are evaluated at each function entry. - Initializers for static and global variables are evaluated once at boot (much like Dynamic C's #GLOBAL_INIT statements). -- Preprocessor Support for "defined" Keyword The "defined" keyword can be used in #if/#elif expressions to determine whether a macro has be previously defined. If MACRO has be defined "defined MACRO" evaluates to 1, otherwise it evaluates to 0. The macro can be optionally surrounded by parentheses for clarity: Example: #define FOO #if defined FOO && ! defined(BAR) ... #endif - #include support. In addition to Dynamic C's #use (which is designed to work with specially formatted source files), Dynamic C 10.60 introduces the standard C #include, which follows the ANSI/ISO C90 specification. - Multiple C file projects. The new Project Explorer Window allows for the creation of projects utilizing multiple C files, and several menu options have been added to allow compilation of the current project. -- Cloning is deprecated Cloning is not supported on the RCM5750, RCM5760, and RCM5650W, and is deprecated on all other Rabbit 4000 and Rabbit 5000 based products. The Rabbit Field Utility (RFU) has been enhanced to handle loading firmware onto many devices at once. Please use RFU.exe located in the utilities directory instead of cloning. -- MiniCore RCM5750/RCM5760 Support The MiniCore RCM5750 and RCM5760 add an additional 512k fast SRAM and a 2 MB serial flash to the RCM5700 and RCM5710 respectively. -- Rabbit Embedded Security Pack The Rabbit Embedded Security Pack is now included with Dynamic C, adding enterprise level Wi-Fi authentication, SSL, and AES to the Dynamic C standard set of libraries. -- Remote Program Update Remote Program Update enables update of boot firmware without having physical access to the hardware. Supported on the RCM4200, RCM4300-series, RCM4400W-series, RCM5400W-series, RCM5600W, RCM5750/60, BL4S100-series, BL4S200 and BL5S220. Please read Application Note AN421 for details on the use of this new functionality. -- Wi-Fi Authentication The Rabbit Embedded Security Pack now supports enterprise level authentication for Wi-Fi networks. Authentication protocols supported include EAP-TLS and EAP-PEAP-MSCHAPv2. -- MiniCore RCM5600W Support The MiniCore RCM5600W is a low-cost, 802.11b/g (Wi-Fi) core module with a small form factor. It is pin compatible with the RCM5700 and uses the Rabbit 5000 microprocessor. -- Run-time Pointer Checking Disabled Run-time pointer checking has been permanantly disabled in Dynamic C 10.50 and will likely be removed in future releases. -- ZB Firmware support for XBee The library xbee_api.lib now supports ZB firmware for the XBee. ZB firmware is ZigBee Pro compliant and should be used for new development. ZNet 2.5 firmware is still supported on the RCM4510W. Please see the function help for changes to the API for the new firmware. -- BL4S200, BL4S210, BL5S220, and BL4S230 Support The BL5S220 and BL4S200 are highly configurable single board computers based on the Rabbit 5000 and Rabbit 4000 processors. The BL4S200 has 10/100 Ethernet and SD card support. The BL4S210 has 10Base-T Ethernet. The BL5S220 has 802.11g Wi-Fi. The BL4S230 has a ZB XBee installed for Zigbee networking. -- BL4S100, BL4S110, BL4S150, and BL4S160 Support The BL4S100, BL4S110, BL4S150 and BL4S160 are low-cost single board computers based on the Rabbit 4000 microprocessor. All four versions have 10Base-T Ethernet. The BL4S150 and BL4S160 have a larger memory configuration. The BL4S100 and BL4S150 have a ZB XBee installed for Zigbee networking. -- MiniCore RCM5700 Support The MiniCore RCM5700 is the first core module supporting both the Rabbit 5000 microprocessor and 10/100 Ethernet; it is a low-cost core module with a small form factor. -- RCM5400W Support The RCM5400W and RCM5450W are the first Rabbit Core Modules (RCM) to support 802.11g Wi-Fi. -- RCM43xx and RCM4050 Support The RCM4300 and the RCM4050 are the first Rabbit Core Modules (RCM) to support addressable memory beyond 1 megabyte utilizing the Rabbit 4000 microprocessor's extended memory capabilities. The software to support the new larger memories is included in Dynamic C version 10.21 and later. The RCM4310, also supported with Dynamic C 10.21 and later, is a scaled-down version of the RCM4300 with a total of 1MB of RAM. -- RCM4300 SD flash support Dynamic C now contains a driver for supporting SD flash. This driver is also supported by the FAT File System. -- RCM4510W Improvements The ZigBee support of the RCM4510W is improved so that incoming messages are queued in a buffer pool and removes some of the calling restrictions within cluster functions and the general message handler. See Samples\ZigBee\README_ZIGBEE.TXT for more information on ZigBee. IMPORTANT: Dynamic C 10.21 and later support the updated FCC-approved XBee Series 2 radios. If you have upgraded to Dynamic C 10.21 (or later) and have preview hardware, you must upgrade the firmware to version 1x21 or later for both the Digi XBee USB and the RCM4510W XBee radios. Dynamic C 10.40 ships with version 1x41 of the XBee ZNet firmware. It is compatible with existing 1x21 devices, but we recommend that you update the XBee modules on all RCM4510W core modules and the Digi XBee USB to the 1x41 release. To upgrade firmware on the Digi XBee USB, use the X-CTU utility included in Utilities\X-CTU. To upgrade the firmware on the RCM4510W, use Samples\ZigBee\ModemFWLoad.c. Please refer to Technical Note 256 for specific instructions. -- Flash selection options The Dynamic C IDE now lets you specify an additional program flash type: 8-bit serial flash. By default the IDE is configured to automatically detect among 8-bit parallel, 16-bit parallel, and 8-bit serial program flash. This adds some delay to the compile/download/execute cycle, and therefore if you wish to circumvent detection you may specify the program flash type directly through the "Options->Project Options" menu item in the "Compiler" tab. -- Software updates for the larger memories In order to support larger memories, some changes to the Dynamic C environment were necessary. Primarily, the changes are in two places: - The \LIB directory now contains 2 separate directories, Rabbit2000_3000 and Rabbit4000. Each directory contains the same structure that \LIB used to, but the libraries have been updated for the Rabbit 4000 processor in the \Lib\Rabbit4000 directory. Note that Dynamic C 10.21 and later only support Rabbit 4000 based products. - Memory mapping. Memory is mapped in Dynamic C using the "origin" mechanism. The mechanism has been updated to be easier to use and is now more effective at identifying collisions and producing useful error messages. All memory mapping directives are now located in a file called "memory_layout.lib" instead of the BIOS. Documentation for the new mechanism is forthcoming in the Rabbit 4000 Microprocessor Designer's manual. Please check the Rabbit Semiconductor website for updates. -- Far data and the Xmem API Products based on the Rabbit 2000 and 3000 processors utilized xmem through the xalloc function. Access to xmem was provided through a user API (xmem2root, root2xmem, xgetint, etc...). The xmem API is still needed for the Rabbit 2000 and 3000 processors, but the Rabbit 4000 (with DC 10.xx) now supports the "far" qualifier, which is easier to use and more efficient. Far data is backward-compatible with the xmem API (with casts of longs to far pointers), but it is recommended that far data be used for any new development, and any xmem functions should be updated to use the far variants ("_f_" prefix) instead. Examples: - _f_memset instead of xmemset - _f_memcpy instead of xmem2xmem - For simple variables, direct assignment from far data to root data is possible, as is assignment from root to far - For root2xmem and xmem2root, use _f_memcpy and call PADDR on the root address, as in: _f_memcpy(PADDR(root_var), far_var, len) -- Character assembly during break The RS232_NOCHARASSYINBRK macro now works for STDIO_DEBUG_SERIAL mode (part of the STDIO.LIB library). This suppresses the generation of multiple null characters when no cable is attached and the RX pin is not pulled up. It is now the default when STDIO_DEBUG_SERIAL is defined to SADR, but must still be explicitly defined for other ports, or when using RS232.LIB. (Pin PC7/RXA is pulled up on Rabbit 2000 and 3000 core modules, suppressing null character generation. Rabbit 4000 core modules do not pull up PC7/RXA. RS232_NOCHARASSYINBRK allows one null character to be generated.) -- Wi-Fi fixes and enhancements The wifi_ioctl() API function has slightly different semantics for some commands. In particular, many of the commands require that the Wi-Fi network interface is brought down before the command is accepted. See the function help (Ctrl-H) for wifi_ioctl() for details. Application code should ensure that the return code from wifi_ioctl() is checked after each call. In particular, note that you must bring the interface down using the ifdown() function before beginning a Wi-Fi scan. The interface should be kept down while the scan is being performed. Once the scan has been completed, then the interface can be brought back up with ifup(). See the samples wifiscan.c and wifiscanassociate.c in Samples\WiFi\ for demonstrations of how a scan is performed. Wi-Fi Protected Access (WPA), with Pre-Shared Key (PSK), is now available for applications which require robust privacy and integrity. In order to use WPA/PSK, simply define WIFI_USE_WPA plus a suitable ascii passphrase or hexadecimal key, and define _WIFI_WEP_FLAG to WIFICONF_WEP_TKIP. See samples\rcm4400w\tcpip\pingled_wpa_psk.c for more details. More documentation on the relevant macros may be found through typing Ctrl-H on the macro TCPCONFIG in a Dynamic C editor window. In order to be acceptable to various countries' regulatory authorities, there is an improved API for customizing the Wi-Fi library to conform to the radio regulations. The wifi_ioctl() API function has new commands to query and set the channel list and transmit power. The commands are WIFI_MULTI_DOMAIN which allows automatic configuration via 802.11d capable access points; WIFI_COUNTRY_SET which allows one of several known regulatory domains to be configured; WIFI_COUNTRY_GET which queries the current regulatory domain information. -- Wi-Fi Roaming The Wi-Fi libraries now support roaming. The Wi-Fi core modules can now follow an access point when it switches to a new channel, and can switch to a different access point if the current access point becomes unavailable. View the ifconfig() function help for details on the new IFS_WIFI_ROAM_* and IFG_WIFI_ROAM_* commands. View the function help for TCPCONFIG for information on the new IFC_WIFI_ROAM_* compile-time macros. -- Known Issues. 1. Debugger issues - In Separate Instruction and Data mode, stack corruption and loss of target communications can be caused by complex watch expressions that include parenthesized subexpressions, or have expressions as function parameters. This applies to expressions in the watch window, flyover evaluations, and expression evaluations. This may also result in multiple "Target communication error" dialog boxes being displayed. - 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. 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. Software module installation. The \LIB directory structure has been changed. It is now divided into 2 separate directories (Rabbit2000_3000 for older products, Rabbit4000 for all 4000-based products). If you want to install a software module that you own, you will have to move the libraries into the Lib\Rabbit4000\ directory by hand. 4. Execution tracing feature removed The execution tracing feature is no longer supported. If this feature is important to your development please contact Rabbit Tech Support. 5. Ad-hoc (IBSS) Mode and the RCM4400W Preview RCM4400W core modules often initially fail to broadcast beacons in ad-hoc (IBSS) mode. This prevents these boards from showing up on scans after starting ad-hoc mode, sometimes for several minutes. If ad-hoc mode is important to your development, please contact Rabbit Tech Support. 6. 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. 7. 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. 8. Error logging not supported The error logging feature has been removed from Dynamic C. If this feature is important to your application, please contact Rabbit Tech Support. 9. In separate I/D mode, if an array is 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,...}; 10. 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. 11. Dynamic C source code maximum line length exception. Attempting to compile a program containing a 252-character line containing a single printf("long string literal . . ."); call demonstrates an exception to Dynamic C's documented line length limit of parsing at most a 512 character line. 12. 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. 13. After opening the Project Options dialog and hitting OK, compiling can show the wrong board description in the progress window: while attached to an RCM4310, an RCM5400W or an RCM4510W the description will be for the SBC with that module, a BL4S200, BL5S220 or BL4S230 respectively, even if you are not attached to an SBC. Compilation is correct, the description displayed is the only discrepency. 14. Using evaluate expression with a sizeof on an out of scope symbol can cause either Dynamic C to crash or require that Dynamic C be closed and restarted. 15. Cloning issue on RCM4300 The CL_CLONE_WHOLE_FLASH option does not work correctly and fails to clone the system ID block. Otherwise, the program correctly clones. (#27855) 16. 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. 17. Using a struct as a boolean expression should be an illegal structure operation, but this version of Dynamic C allows it without warning or error. Avoid using expressions like "if (myStruct) ...". The address of myStruct will be used which always evaluates to true. 18. Adding Watch expressions on (any) variables while single stepping inside a cofunction will fail with an internal error message. (#28609) 19. Adding watches on string literals in a program with separate I&D space disabled will overwrite and corrupt root constants and code. (#28355) 20. More than one return statement in a cofunction will result in unpredictable behavior. 21. 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. 22. 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. 23. 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. 24. 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. 25. Programs larger than 512K will not compile to RAM successfully on an RCM5450W core module. Compiling such programs to flash works fine. 26. The compiler-generated struct "prog_param" can have some incorrect elements under certain circumstances. This struct is not generally used, and is provided for informational purposes only. The instance where it is used (in CLONE.LIB) doesn't involve an element that could be incorrect. 27. 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."