Hello everyone,
I would like to read compiler options from a file, so I followed the links starting here:
http://www.keil.com/support/man/docs/armcc/armcc_BCFFECIG.htm
The problem is that I get this error:
RTX_Conf_LPC23xx.c: error: C3904U: Could not open via file 'smpl_config.dat'.
I followed all the via file syntax rules, particularly regarding -Dsymbol="value" type options and comments, as expressed in this link:
www.keil.com/.../armccref_Babbface.htm
Below is my via file... any hints as to why I am not being able to use it?
Regards, George Andrew Brindeiro Robotron Automation and Technology
#/************************************************************************************************** # Filename: smpl_config.dat # Revised: $Date: 2008-05-12 14:13:04 -0700 (Mon, 12 May 2008) $ # Revision: $Revision: 17057 $ # Author: $Author: lfriedman $ # # Description: This file supports the SimpliciTI Customer Configuration for End Devices. # # Copyright 2004-2007 Texas Instruments Incorporated. All rights reserved. # # IMPORTANT: Your use of this Software is limited to those specific rights granted under # the terms of a software license agreement between the user who downloaded the software, # his/her employer (which must be your employer) and Texas Instruments Incorporated (the # "License"). You may not use this Software unless you agree to abide by the terms of the # License. The License limits your use, and you acknowledge, that the Software may not be # modified, copied or distributed unless embedded on a Texas Instruments microcontroller # or used solely and exclusively in conjunction with a Texas Instruments radio frequency # transceiver, which is integrated into your product. Other than for the foregoing purpose, # you may not use, reproduce, copy, prepare derivative works of, modify, distribute, # perform, display or sell this Software and/or its documentation for any purpose. # # YOU FURTHER ACKNOWLEDGE AND AGREE THAT THE SOFTWARE AND DOCUMENTATION ARE PROVIDED “AS IS” # WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY # WARRANTY OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE. # IN NO EVENT SHALL TEXAS INSTRUMENTS OR ITS LICENSORS BE LIABLE OR OBLIGATED UNDER CONTRACT, # NEGLIGENCE, STRICT LIABILITY, CONTRIBUTION, BREACH OF WARRANTY, OR OTHER LEGAL EQUITABLE # THEORY ANY DIRECT OR INDIRECT DAMAGES OR EXPENSES INCLUDING BUT NOT LIMITED TO ANY # INCIDENTAL, SPECIAL, INDIRECT, PUNITIVE OR CONSEQUENTIAL DAMAGES, LOST PROFITS OR LOST # DATA, COST OF PROCUREMENT OF SUBSTITUTE GOODS, TECHNOLOGY, SERVICES, OR ANY CLAIMS BY # THIRD PARTIES (INCLUDING BUT NOT LIMITED TO ANY DEFENSE THEREOF), OR OTHER SIMILAR COSTS. # # Should you have any questions regarding your right to use this Software, # contact Texas Instruments Incorporated at http://www.TI.com. #**************************************************************************************************/ #/* Number of connections supported. each connection supports bi-directional # * communication. Access Points and Range Extenders can set this to 0 if they # * do not host End Device objects # */ '-DNUM_CONNECTIONS=2' #/* *** Size of low level queues for sent and received frames. Affects RAM usage *** */ #/* AP needs larger input frame queue if it is supporting store-and-forward # * clients because the forwarded messages are held here. Two is probably enough # * for an End Device # */ '-DSIZE_INFRAME_Q=2' #/* The output frame queue can be small since Tx is done synchronously. Actually # * 1 is probably enough. If an Access Point device is also hosting an End Device # * that sends to a sleeping peer the output queue should be larger -- the waiting # * frames in this case are held here. In that case the output frame queue should # * be bigger. # */ '-DSIZE_OUTFRAME_Q=2' #/* This device's address. The first byte is used as a filter on the CC1100/CC2500 # * radios so THE FIRST BYTE MUST NOT BE either 0x00 or 0xFF. Also, for these radios # * on End Devices the first byte should be the least significant byte so the filtering # * is maximally effective. Otherwise the frame has to be processed by the MCU before it # * is recognized as not intended for the device. APs and REs run in promiscuous mode so # * the filtering is not done. This macro intializes a static const array of unsigned # * characters of length NET_ADDR_SIZE (found in nwk_types.h). the quotes (") are # * necessary below unless the spaces are removed. # */ '-DTHIS_DEVICE_ADDRESS="{0x79, 0x56, 0x34, 0x12}"' #/* device type */ -DEND_DEVICE #/* For polling End Devices we need to specify that they do so. Uncomment the # * macro definition below if this is a polling device. This field is used # * by the Access Point to know whether to reserve store-and-forward support # * for the polling End Device during the Join exchange. # */ #/* -DRX_POLLS */
This problem is solved, and there was nothing wrong with my via files.
Apparently it is not enough for the folders containing via files to be in the path, you should explicitly write their path relative to the build directory.
"there was nothing wrong with my via files"
There was nothing in the message to suggest anything wrong with the file content:
Could not open via file 'smpl_config.dat'.
The message clearly tells you that the problem was with opening the file - not with the file's contents!
An obvious reason for being unable to open a file would be that the tool couldn't find it.
"Apparently it is not enough for the folders containing via files to be in the path"
The PATH is used by the system to find executable files - it's not for applications to find their data files.
Andrew,
Agreed. Maybe a clearer message would be 'Could not find file', because there are other reasons why a file could not be opened... Either way, you are right, it is always best to stick to what the compiler is saying.
"Maybe a clearer message would be 'Could not find file'"
Indeed.
It should be trivial for the compiler to distinguish between this and other reasons for being unable to open a file - and that information should be presented to the user.
You would have thought that compiler writers, as programmers themselves, should understand the value of good error messages and, therefore, not give us rubbish like this!
:-(
However, my point here was that the message clearly stated that the problem was in opening the file - and, therefore, nothing to do with the content of the file.