From bobsmith5 at verizon.net Tue May 1 08:30:59 2007 From: bobsmith5 at verizon.net (Bob Smith) Date: Tue May 1 08:40:28 2007 Subject: [Icc-mot] 9S08 Interrupt mask. References: <4621069D.6070504@spotengineering.com><000f01c77ec7$2b5486e0$a300a8c0@REKS> <46237585.4060303@spotengineering.com> <001801c7802b$6cdcd7b0$0400a8c0@edvardo> Message-ID: <004401c78c05$b9fa1d10$aba7fea9@apollo> A couple lf weeks ago, I mentioned that I couldn't get the RTI on my 9S08AW60 to throw interrupts as expected. Well the problem is now worse as I can't get the SCIx to throw interrupts either. Further, according to my debugger (NoIce08) the interrupt mask bit in the CCR is set at the entrance to main() and at all other times in my program. Well after a bit of arm-chair digging in the AW60 Data Sheet this A.M. it seems that the AW60 comes out of reset with the I bit in the CCR set, thus masking all interrupts. This is, they claim, to allow me time to set up the stack pointer, et al. OK, I can live with that but, I have a fussy client who insists that everything be done in C so I am not happy with the idea of sticking an "asm("CLI") in main() or my HC08Setup routine. Of course I could modify the library cstart routine and hide a CLI in there. Anybody got any better ideas; how do _you_ deal with this problem?? All suggestions welcome. Many thanks, Bob Smith --------------------------------------------------------- PCB and Embedded Control Sys Design Smith Machine Works, Inc. http://www.smithmachineworks.com From genenorris at spotengineering.com Tue May 1 12:13:00 2007 From: genenorris at spotengineering.com (Gene Norris) Date: Tue May 1 12:29:19 2007 Subject: [Icc-mot] 9S08 Interrupt mask. In-Reply-To: <004401c78c05$b9fa1d10$aba7fea9@apollo> References: <4621069D.6070504@spotengineering.com><000f01c77ec7$2b5486e0$a300a8c0@REKS> <46237585.4060303@spotengineering.com> <001801c7802b$6cdcd7b0$0400a8c0@edvardo> <004401c78c05$b9fa1d10$aba7fea9@apollo> Message-ID: <4637913C.2050001@spotengineering.com> Bob, To start a new thread e-mail icc-mot@imagecraft.com instead of replying. (FYI) Bob Smith wrote: > A couple lf weeks ago, I mentioned that I couldn't get the RTI on my > 9S08AW60 to throw interrupts as expected. You must turn that interrupt on too?! Weren't you talking about void _HC08Setup(void)? > > Well the problem is now worse as I can't get the SCIx to throw > interrupts either. Are you setting the appropriate flags to enable interrupts for the SCIx explicitly? > > Further, according to my debugger (NoIce08) the interrupt mask bit in > the CCR is set at the entrance to main() and at all other times in my > program. Well after a bit of arm-chair digging in the AW60 Data Sheet > this A.M. it seems that the AW60 comes out of reset with the I bit in > the CCR set, thus masking all interrupts. This is, they claim, to allow > me time to set up the stack pointer, et al. OK, I can live with that > but, I have a fussy client who insists that everything be done in C so I > am not happy with the idea of sticking an "asm("CLI") in main() or my > HC08Setup routine. Of course I could modify the library cstart routine > and hide a CLI in there. I would put it in main in your case. Use the setup for port and peripheral (SCI, timer...) configuration. Then enable interrupts in main... > > Anybody got any better ideas; how do _you_ deal with this problem?? You could use #define INTERRUPTS_ON() asm("cli") #define INTERRUPTS_OFF() asm("sei") The following used to be defined in the hc12 header #define INTR_ON() asm("cli") #define INTR_OFF() asm("sei") This give the illusion of 'C' in your program. Embedded systems _Always_ have this sort of work around. Nobody should fuss. Good luck. > > All suggestions welcome. > > Many thanks, Bob Smith > > --------------------------------------------------------- > PCB and Embedded Control Sys Design > Smith Machine Works, Inc. > > http://www.smithmachineworks.com > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > > -- Gene Norris Chief Engineer SPOT Engineering, Inc. 1261 Campground Road Lancaster, Ohio 43130 740.654.0880 FAX.654.0889 http://www.spotengineering.com/ From richard-lists at imagecraft.com Tue May 1 12:28:54 2007 From: richard-lists at imagecraft.com (Richard) Date: Tue May 1 12:38:20 2007 Subject: [Icc-mot] 9S08 Interrupt mask. In-Reply-To: <004401c78c05$b9fa1d10$aba7fea9@apollo> References: <4621069D.6070504@spotengineering.com> <000f01c77ec7$2b5486e0$a300a8c0@REKS> <46237585.4060303@spotengineering.com> <001801c7802b$6cdcd7b0$0400a8c0@edvardo> <004401c78c05$b9fa1d10$aba7fea9@apollo> Message-ID: <6.1.0.6.2.20070501122754.07fb1988@192.168.100.42> Modify the Startup file. Call it crt09aw60 or something so it is clear that it is doing something AW60 specific. That ought to make your client happy. At 08:30 AM 5/1/2007, Bob Smith wrote: >A couple lf weeks ago, I mentioned that I couldn't get the RTI on my >9S08AW60 to throw interrupts as expected. > >Well the problem is now worse as I can't get the SCIx to throw >interrupts either. > >Further, according to my debugger (NoIce08) the interrupt mask bit in >the CCR is set at the entrance to main() and at all other times in my >program. Well after a bit of arm-chair digging in the AW60 Data Sheet >this A.M. it seems that the AW60 comes out of reset with the I bit in >the CCR set, thus masking all interrupts. This is, they claim, to allow >me time to set up the stack pointer, et al. OK, I can live with that >but, I have a fussy client who insists that everything be done in C so I >am not happy with the idea of sticking an "asm("CLI") in main() or my >HC08Setup routine. Of course I could modify the library cstart routine >and hide a CLI in there. > >Anybody got any better ideas; how do _you_ deal with this problem?? > >All suggestions welcome. > >Many thanks, Bob Smith // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From richard at imagecraft.com Fri May 11 00:47:22 2007 From: richard at imagecraft.com (Richard) Date: Fri May 11 02:44:33 2007 Subject: [Icc-mot] Some mail messages lost due to hard drive failure Message-ID: <200705110757.l4B7uwi1095789@dragonsgate2.imagecraft.com> One of our systems suffered a hard drive failure (two less than a year old Seagate drives died within a span of 2 weeks in 2 different systems, draw your own conclusions?) Fortunately, our back up system minimizes the data loss, less minimal for the email messages because unfortunately the email clients run all the time and the backup utility cannot access the data file. So if you have emailed us in the last few weeks and are still awaiting a response from us, please email again. Sorry for the inconvenience. // richard On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From barryc at rjlsystems.com Fri May 11 06:04:09 2007 From: barryc at rjlsystems.com (Barry Callahan) Date: Fri May 11 06:16:21 2007 Subject: [Icc-mot] Some mail messages lost due to hard drive failure In-Reply-To: <200705110757.l4B7uwi1095789@dragonsgate2.imagecraft.com> References: <200705110757.l4B7uwi1095789@dragonsgate2.imagecraft.com> Message-ID: <464469C9.2030203@rjlsystems.com> Richard wrote: > One of our systems suffered a hard drive failure (two less than a year > old Seagate drives died within a span of 2 weeks in 2 different > systems, draw your own conclusions?) A bad batch? I wonder if they were made in the same lot at the plant. Generally, Seagate stands behind their (retail-packaged) drives with a 5-year warranty. Only Mfr that I know of who does. Rarely will I put anything else in a system. -- #/******************************\ #* Barry Callahan * #* RJL Systems * #* phone: 1 586 790 - 0200 x112 * #* 1 800 528 - 4513 x112 * #* fax: 1 586 790 - 0205 * #\******************************/ From barryc at rjlsystems.com Fri May 11 10:05:34 2007 From: barryc at rjlsystems.com (Barry Callahan) Date: Fri May 11 10:17:38 2007 Subject: [Icc-mot] Arrays of function pointers and paged functions Message-ID: <4644A25E.5090209@rjlsystems.com> I've been playing, off and on, with some code to try and figure out why, when I have expanded memory enabled and paged functions are default in my project, trying to call functions via an array of pointers "Just Doesn't Work". This morning, I had an epiphany. The reason it doesn't work is that the MCU doesn't know it needs to swap pages before calling the function. If I use a pragma to make all of the functions that I want to call via the array nonpaged, it works. Is there a way that I can use an array to call the functions without having them all have to be nonpaged? I mean, I know I can use trampolines. Or I can use a switch structure. But both of these alternatives are somewhat sub-optimal. -- #/******************************\ #* Barry Callahan * #* RJL Systems * #* phone: 1 586 790 - 0200 x112 * #* 1 800 528 - 4513 x112 * #* fax: 1 586 790 - 0205 * #\******************************/ From richard at imagecraft.com Tue May 15 23:29:09 2007 From: richard at imagecraft.com (Richard) Date: Tue May 15 23:39:09 2007 Subject: [Icc-mot] 64 bits FP chip.... Message-ID: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> I am considering producing something like this: 64 bits FP support will be provided by the new iFPLightning chip. The product is integrated fully into our compilers (initially AVR but later on supporting other ICC compilers as well). The approximate performance goals are 1 uSec for 32 bit FP MUL 1.5 uSec for DIV and ~2X for 64 bits. This is at least 15x-20X faster than the equivalent AVR code and of course free up code space on the AVR chip. The data transfer overheard is ~10 uSec to transfer two operands and a result. Complex expressions will use the intermediate results directly without data transfer. The API uses a stack architecture so interrupt can remain enabled except during the data transfer. The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x 0.6" in size. The following pricing is very tentative, but is our best guess: 1-50 $30 100 $27 500 $25 1000 $22 It is highly likely that the chip will provide full high level math support such as sin/cos/etc. We are also open to other API such as DSP etc. What do you think? // richard From ekarpicz at freemail.lt Wed May 16 01:14:23 2007 From: ekarpicz at freemail.lt (Edvardas) Date: Wed May 16 01:23:46 2007 Subject: [Icc-mot] 64 bits FP chip.... References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> Message-ID: <00e201c79792$366d4a60$0400a8c0@edvardo> >I am considering producing something like this: > > 64 bits FP support will be provided by the new iFPLightning chip. The > product is integrated fully into our compilers (initially AVR but later on > supporting other ICC compilers as well). The approximate performance goals > are What, already integrated?; do you support 64bit FP on 8bit AVRs and only 32bit FP on 16bit HC12? :-( > 1 uSec for 32 bit FP MUL > 1.5 uSec for DIV > and ~2X for 64 bits. Could you shed some more light on this? 1) First of all are these */+- fully standard compliant (sorry, but I little doubt it)? Does it pass compliancy tests? 2) Having hardware mul and div, FP add can be the slowest OP. How long does it take to SUB something like 1.00001 - 1.00002 (close to the worst single precision case)? 3) 64 bits only 2X slower? What are internal data paths then, 64bits? > > This is at least 15x-20X faster than the equivalent AVR code and of course > free up code space on the AVR chip. > > The data transfer overheard is ~10 uSec to transfer two operands and Is it SPI/IIC/something else? > a result. Complex expressions will use the intermediate results directly > without data transfer. The API uses a stack architecture so interrupt can > remain enabled except during the data transfer. > > The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x 0.6" in > size. > > The following pricing is very tentative, but is our best guess: > > 1-50 $30 > 100 $27 > 500 $25 > 1000 $22 > > It is highly likely that the chip will provide full high level math > support such as sin/cos/etc. We are also open to other API such as DSP > etc. Since data transfer takes quite a lot, I think you shouldn't release it without most popular sin/cos/etc. > > What do you think? 64bits doubles are of course welcome. Edward > > // richard > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From richard-lists at imagecraft.com Wed May 16 01:32:31 2007 From: richard-lists at imagecraft.com (Richard) Date: Wed May 16 01:42:31 2007 Subject: [Icc-mot] 64 bits FP chip.... In-Reply-To: <00e201c79792$366d4a60$0400a8c0@edvardo> References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com> <00e201c79792$366d4a60$0400a8c0@edvardo> Message-ID: <200705160842.l4G8gTb5069969@dragonsgate2.imagecraft.com> At 01:14 AM 5/16/2007, Edvardas wrote: >>I am considering producing something like this: >> >>64 bits FP support will be provided by the new iFPLightning chip. >>The product is integrated fully into our compilers (initially AVR >>but later on supporting other ICC compilers as well). The >>approximate performance goals are > > >What, already integrated?; do you support 64bit FP on 8bit AVRs and >only 32bit FP on 16bit HC12? :-( I meant that the use of this chip will be transparent to ICC users. They click on a checkbox, and the compiler will generate the right library code, which will be supplied by us. All you have to do is to hook up the chip to your system using the SPI bus. Currently, only 32-bit FP is supported on all our compilers. >>1 uSec for 32 bit FP MUL >>1.5 uSec for DIV >>and ~2X for 64 bits. > >Could you shed some more light on this? >1) First of all are these */+- fully standard compliant (sorry, but >I little doubt it)? Does it pass compliancy tests? Yes, the are IEEE compliant. We will be sure to run the torture tests etc. >2) Having hardware mul and div, FP add can be the slowest OP. How >long does it take to SUB something like 1.00001 - 1.00002 (close to >the worst single precision case)? FP add should not be slower than FPadd. >3) 64 bits only 2X slower? What are internal data paths then, 64bits? It's based on a 70Mhz ARM7TDMI >>This is at least 15x-20X faster than the equivalent AVR code and of >>course free up code space on the AVR chip. >> >>The data transfer overheard is ~10 uSec to transfer two operands and > >Is it SPI/IIC/something else? SPI. I2C is too slow? >>a result. Complex expressions will use the intermediate results >>directly without data transfer. The API uses a stack architecture >>so interrupt can remain enabled except during the data transfer. >> >>The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x >>0.6" in size. >> >>The following pricing is very tentative, but is our best guess: >> >>1-50 $30 >>100 $27 >>500 $25 >>1000 $22 >> >>It is highly likely that the chip will provide full high level math >>support such as sin/cos/etc. We are also open to other API such as DSP etc. > >Since data transfer takes quite a lot, I think you shouldn't release >it without most popular sin/cos/etc. > >> >>What do you think? > >64bits doubles are of course welcome. > >Edward // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com) From ekarpicz at freemail.lt Wed May 16 04:35:49 2007 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Wed May 16 05:40:40 2007 Subject: [Icc-mot] 64 bits FP chip.... References: <200705160639.l4G6d7mj067739@dragonsgate2.imagecraft.com><00e201c79792$366d4a60$0400a8c0@edvardo> <200705160842.l4G8gTb5069969@dragonsgate2.imagecraft.com> Message-ID: <001b01c797ae$5a0a0be0$0400a8c0@edvardo> Richard wrote: > At 01:14 AM 5/16/2007, Edvardas wrote: > > >>>I am considering producing something like this: >>> >>>64 bits FP support will be provided by the new iFPLightning chip. The >>>product is integrated fully into our compilers (initially AVR but later >>>on supporting other ICC compilers as well). The approximate performance >>>goals are >> >> >>What, already integrated?; do you support 64bit FP on 8bit AVRs and only >>32bit FP on 16bit HC12? :-( > > I meant that the use of this chip will be transparent to ICC users. They > click on a checkbox, and the compiler will generate the right library > code, which will be supplied by us. All you have to do is to hook up the > chip to your system using the SPI bus. > > Currently, only 32-bit FP is supported on all our compilers. > Sorry, bad joke. I know you don't have doubles. And I like your idea of FP coprocessor because I guess that when done - double FP emulation in just HC12 will be also possible (I can write necessary libs) :-). > >>>1 uSec for 32 bit FP MUL >>>1.5 uSec for DIV >>>and ~2X for 64 bits. >> >>Could you shed some more light on this? >>1) First of all are these */+- fully standard compliant (sorry, but I >>little doubt it)? Does it pass compliancy tests? > > Yes, the are IEEE compliant. We will be sure to run the torture tests etc. > >>2) Having hardware mul and div, FP add can be the slowest OP. How long >>does it take to SUB something like 1.00001 - 1.00002 (close to the worst >>single precision case)? > > FP add should not be slower than FPadd. > >>3) 64 bits only 2X slower? What are internal data paths then, 64bits? > > It's based on a 70Mhz ARM7TDMI I believe doubles must be much more than 2X slower than floats. Didn't try ARM yet but thanks for its 32bit FP speed figures. 70MHz ARM iFPLightning ~1us + ~10us SPI comms is comparable to S12 emulated FP. Of course something like sin/cos inside iFPLightning should be much more faster than the same done in S12. But price, extra chip, and ..are those math libs as accurate as advertized... Edward > > >>>This is at least 15x-20X faster than the equivalent AVR code and of >>>course free up code space on the AVR chip. >>> >>>The data transfer overheard is ~10 uSec to transfer two operands and >> >>Is it SPI/IIC/something else? > > SPI. I2C is too slow? > >>>a result. Complex expressions will use the intermediate results directly >>>without data transfer. The API uses a stack architecture so interrupt can >>>remain enabled except during the data transfer. >>> >>>The iFPLightning chip comes in a 16 or 18 pin DIP module, ~0.7" x 0.6" in >>>size. >>> >>>The following pricing is very tentative, but is our best guess: >>> >>>1-50 $30 >>>100 $27 >>>500 $25 >>>1000 $22 >>> >>>It is highly likely that the chip will provide full high level math >>>support such as sin/cos/etc. We are also open to other API such as DSP >>>etc. >> >>Since data transfer takes quite a lot, I think you shouldn't release it >>without most popular sin/cos/etc. >> >>> >>>What do you think? >> >>64bits doubles are of course welcome. >> >>Edward > > // richard (This email is for mailing lists. To reach me directly, please > use richard at imagecraft.com) > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot From barryc at rjlsystems.com Fri May 25 14:10:55 2007 From: barryc at rjlsystems.com (Barry Callahan) Date: Fri May 25 14:23:41 2007 Subject: [Icc-mot] Build/Link time Message-ID: <465750DF.5020408@rjlsystems.com> I want to keep a string that indicates the date and time that the firmware was built. Right now, I'm building a string with __DATE__ and __TIME__ Problem is, those are evaluated by the preprocessor at compile time. If I modify a file which doesn't reference those macros and forget to do a "rebuild all", the version string doesn't get updated. In ICC12 (both v6 and v7) there's a text field under the "Compiler" tab of the "Compiler Options" dialog labeled "Execute Command After Successful Build:" Right now, I'm using this field to touch (update the modification time) on the file which builds the timestamp. That way, (assuming the build completed successfully) the next time I rebuild, that file will be guaranteed to recompile, regardless of whether I edit it or not. Ideally, I'd touch this file *before* building so I know that the string always accurately reflects the date and time of when the program was built, regardless of whether the previous compile was clean or not.. Any suggestions? Thanks. Barry From genenorris at spotengineering.com Fri May 25 14:46:38 2007 From: genenorris at spotengineering.com (Gene Norris) Date: Fri May 25 14:56:35 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <465750DF.5020408@rjlsystems.com> References: <465750DF.5020408@rjlsystems.com> Message-ID: <4657593E.1080904@spotengineering.com> You already effectively touch the file before building. build. touch. build. touch. build. works exactly the same as touch. build. touch. build... By updating the file after compilation, you ensure it will be compiled on the next make or build. Gene Barry Callahan wrote: > I want to keep a string that indicates the date and time that the > firmware was built. > > Right now, I'm building a string with __DATE__ and __TIME__ > > Problem is, those are evaluated by the preprocessor at compile time. If > I modify a file which doesn't reference those macros and forget to do a > "rebuild all", the version string doesn't get updated. > > In ICC12 (both v6 and v7) there's a text field under the "Compiler" tab > of the "Compiler Options" dialog labeled "Execute Command After > Successful Build:" > > Right now, I'm using this field to touch (update the modification time) > on the file which builds the timestamp. That way, (assuming the build > completed successfully) the next time I rebuild, that file will be > guaranteed to recompile, regardless of whether I edit it or not. > > Ideally, I'd touch this file *before* building so I know that the string > always accurately reflects the date and time of when the program was > built, regardless of whether the previous compile was clean or not.. > > > Any suggestions? > Thanks. > > Barry > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > > > -- Gene Norris Chief Engineer SPOT Engineering, Inc. 1261 Campground Road Lancaster, Ohio 43130 740.654.0880 FAX.654.0889 http://www.spotengineering.com/ From barryc at rjlsystems.com Fri May 25 19:23:01 2007 From: barryc at rjlsystems.com (Barry Callahan) Date: Fri May 25 19:32:43 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <4657593E.1080904@spotengineering.com> References: <465750DF.5020408@rjlsystems.com> <4657593E.1080904@spotengineering.com> Message-ID: <46579A05.7080000@rjlsystems.com> Only if every build executes successfully: build. touch. build. error. build. touch. build. if imakew doesn't report a clean build, the file doesn't get touched. Gene Norris wrote: > You already effectively touch the file before building. > > build. touch. build. touch. build. > > works exactly the same as > > touch. build. touch. build... > > By updating the file after compilation, you ensure it will be compiled > on the next make or build. > > Gene > > Barry Callahan wrote: > >> I want to keep a string that indicates the date and time that the >> firmware was built. >> >> Right now, I'm building a string with __DATE__ and __TIME__ >> >> Problem is, those are evaluated by the preprocessor at compile time. >> If I modify a file which doesn't reference those macros and forget to >> do a "rebuild all", the version string doesn't get updated. >> >> In ICC12 (both v6 and v7) there's a text field under the "Compiler" >> tab of the "Compiler Options" dialog labeled "Execute Command After >> Successful Build:" >> >> Right now, I'm using this field to touch (update the modification >> time) on the file which builds the timestamp. That way, (assuming the >> build completed successfully) the next time I rebuild, that file will >> be guaranteed to recompile, regardless of whether I edit it or not. >> >> Ideally, I'd touch this file *before* building so I know that the >> string always accurately reflects the date and time of when the >> program was built, regardless of whether the previous compile was >> clean or not.. >> >> >> Any suggestions? >> Thanks. >> >> Barry >> >> _______________________________________________ >> Icc-mot mailing list >> Icc-mot@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-mot >> >> >> > From ekarpicz at freemail.lt Fri May 25 23:49:01 2007 From: ekarpicz at freemail.lt (Edward Karpicz) Date: Fri May 25 23:58:45 2007 Subject: [Icc-mot] Build/Link time References: <465750DF.5020408@rjlsystems.com> Message-ID: <007101c79f61$f20b9d40$a300a8c0@REKS> Trying to solve what you are asking about, a long long ago I did some simple utility that creates (and overwrites) h file at specified location. Utility is writing the date in format I prefer to the file, something like: const char VERDATE[] = "date here"; and I'm including it in many projects. I was execing this utility first from win95/98 autoexec.bat, then I moved it to the winXP scheduler to run at least every day at start up. Of course h file gets touched automatically and just date but no time is enough for me. Also there are freeware utilities on the net to change file date, I hope those can set file time to current time. If you had some common h or c file with __DATE__ and __TIME__ inside, then you could touch this file from the scheduler regularily by executing this setfiletime. Edward ----- Original Message ----- From: "Barry Callahan" To: "Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe toicc-announce if you are a member of this." Sent: Saturday, May 26, 2007 00:10 Subject: [Icc-mot] Build/Link time >I want to keep a string that indicates the date and time that the firmware >was built. > > Right now, I'm building a string with __DATE__ and __TIME__ > > Problem is, those are evaluated by the preprocessor at compile time. If I > modify a file which doesn't reference those macros and forget to do a > "rebuild all", the version string doesn't get updated. > > In ICC12 (both v6 and v7) there's a text field under the "Compiler" tab of > the "Compiler Options" dialog labeled "Execute Command After Successful > Build:" > > Right now, I'm using this field to touch (update the modification time) on > the file which builds the timestamp. That way, (assuming the build > completed successfully) the next time I rebuild, that file will be > guaranteed to recompile, regardless of whether I edit it or not. > > Ideally, I'd touch this file *before* building so I know that the string > always accurately reflects the date and time of when the program was > built, regardless of whether the previous compile was clean or not.. > > > Any suggestions? > Thanks. > > Barry > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > From j_baraclough at zetnet.co.uk Sat May 26 10:24:34 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Sat May 26 10:34:22 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <465750DF.5020408@rjlsystems.com> References: <465750DF.5020408@rjlsystems.com> Message-ID: Hi Barry, Just put the __DATE__ & __TIME__ macros into a very small file as below then delete the '.o' file after every build. HTH John /* ************************************************************************ *\ File: DateAndTime.c Purpose: Creates a string containing the compilation date & time. Revisions: 1.00 JNB 2006-10-18 Notes: The intermediate file 'DateAndTime.o' is deleted after every compilation, so that it is recompiled each time with the new date and time. \* ************************************************************************ */ #include void GetCompileDateAndTime(void) { cstrcpy(MessageOut, "Build - "); cstrcat(MessageOut, __DATE__); cstrcat(MessageOut, " \100 "); cstrcat(MessageOut, __TIME__); } At 22:10 25/05/2007, you wrote: >I want to keep a string that indicates the date and time that the >firmware was built. > >Right now, I'm building a string with __DATE__ and __TIME__ > >Problem is, those are evaluated by the preprocessor at compile time. >If I modify a file which doesn't reference those macros and forget >to do a "rebuild all", the version string doesn't get updated. > >In ICC12 (both v6 and v7) there's a text field under the "Compiler" >tab of the "Compiler Options" dialog labeled "Execute Command After >Successful Build:" > >Right now, I'm using this field to touch (update the modification >time) on the file which builds the timestamp. That way, (assuming >the build completed successfully) the next time I rebuild, that file >will be guaranteed to recompile, regardless of whether I edit it or not. > >Ideally, I'd touch this file *before* building so I know that the >string always accurately reflects the date and time of when the >program was built, regardless of whether the previous compile was >clean or not.. > > >Any suggestions? >Thanks. > >Barry > >_______________________________________________ >Icc-mot mailing list >Icc-mot@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-mot > From lance at rapidware.com Sat May 26 10:58:32 2007 From: lance at rapidware.com (Lance B. Smith) Date: Sat May 26 11:08:24 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: Message-ID: <200705261808.l4QI8Np0028315@dragonsgate2.imagecraft.com> One other thought on all of this. I purposefully DON'T want date / time embedded. When it was built is irrelevant because of the magic of S-records. What matters is that I can diff the S-record and get verification that what I just built is still the same as the release build. The release S-record has its own OS file date and time. It also has unique version number which is embedded. If I embed the date time, then that will make it not diff clean and I would have to know to ignore that difference and not others, which is an error-prone hassle. This is very useful because I can go on writing new stuff conditionally and test it carefully in a special test build turning on new code here and there until I know it is ready for prime-time, but can quickly revert back to the last release, by turning off the new conditional (#define) switches. Furthermore, I may have to release another variant of the same base-project during the new-coding phase. So, for example if two variants still build to match the same two respective release S-record files, then I know the third one will also represent the same level of testing, except of course for the variation. (We do a lot of testing on our releases, and are fortunate to have a very talented tester who can find the whackiest subtle bugs). This allows me to keep incrementing the same source-control project and not have so many versions of individual files to keep track of. And also allows me to quickly fix any bugs that may come up during testing after the code is handed off. Every hand-off gets unique suffix, that's the release control. To avoid having too many suffixes go out the door, all test suffixes are lower case. The final release suffix is upper case. The final S-rec must diff clean against the latest test suffix, except for the one variation in the suffix character. Just some thoughts. Best to all -- Lance ===================== Lance B. Smith, President Rapidware, Inc. 108 East Main Street Milan, MI 48160 734 439 3990 734 439 3975 Fax lance@rapidware.com www.rapidware.com ===================== -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com] On Behalf Of John Baraclough Sent: Saturday, May 26, 2007 1:25 PM To: Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe toicc-announce if you are a member of this. Subject: Re: [Icc-mot] Build/Link time Hi Barry, Just put the __DATE__ & __TIME__ macros into a very small file as below then delete the '.o' file after every build. HTH John /* ************************************************************************ *\ File: DateAndTime.c Purpose: Creates a string containing the compilation date & time. Revisions: 1.00 JNB 2006-10-18 Notes: The intermediate file 'DateAndTime.o' is deleted after every compilation, so that it is recompiled each time with the new date and time. \* ************************************************************************ */ #include void GetCompileDateAndTime(void) { cstrcpy(MessageOut, "Build - "); cstrcat(MessageOut, __DATE__); cstrcat(MessageOut, " \100 "); cstrcat(MessageOut, __TIME__); } At 22:10 25/05/2007, you wrote: >I want to keep a string that indicates the date and time that the >firmware was built. > >Right now, I'm building a string with __DATE__ and __TIME__ > >Problem is, those are evaluated by the preprocessor at compile time. >If I modify a file which doesn't reference those macros and forget >to do a "rebuild all", the version string doesn't get updated. > >In ICC12 (both v6 and v7) there's a text field under the "Compiler" >tab of the "Compiler Options" dialog labeled "Execute Command After >Successful Build:" > >Right now, I'm using this field to touch (update the modification >time) on the file which builds the timestamp. That way, (assuming >the build completed successfully) the next time I rebuild, that file >will be guaranteed to recompile, regardless of whether I edit it or not. > >Ideally, I'd touch this file *before* building so I know that the >string always accurately reflects the date and time of when the >program was built, regardless of whether the previous compile was >clean or not.. > > >Any suggestions? >Thanks. > >Barry > >_______________________________________________ >Icc-mot mailing list >Icc-mot@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-mot > _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot From barryc at rjlsystems.com Sat May 26 11:21:20 2007 From: barryc at rjlsystems.com (Barry Callahan) Date: Sat May 26 11:30:54 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: References: <465750DF.5020408@rjlsystems.com> Message-ID: <46587AA0.10205@rjlsystems.com> End result is the same. If I tell ICC to automatically delete the .o file for me, it will only do it after a successful build. IE: if *ALL* source files compiled successfully. Consider this: The file with __DATE__ and __TIME__ is the fourth .c file to be compiled, and the ninth is the one that errors out. You fix the ninth file and rebuild. Maybe it only takes you a few minutes to fix the file. Maybe it takes you hours or days. The point is, time passes. Because the first build did not complete successfully, the .o file containing the timestamps was not removed. (or, using my existing solution, the .c file was not touched.) Once the ninth file has been fixed and the project built, the timestamp embedded in the .s19 does *NOT* reflect the time when the project was successfully built. -- It is the time when I attempted the first build. If all I cared about was that I had a means to ensure that I have distinct version strings between successful builds, this would not be a problem. But I actually, specifically, want the timestamp of the successful compile. If I could specify a command to be executed before the first file was compiled, or if I could alter the order in which files are compiled to force the file with the timestamp to always be the last file to compile,(something that didn't occur to me until just now to try to fiddle with) I'd be peachy-keen. John Baraclough wrote: > Hi Barry, > > Just put the __DATE__ & __TIME__ macros into a very small file as > below then delete the '.o' file after every build. > > HTH > > John > > /* > ************************************************************************ > *\ > File: DateAndTime.c > > Purpose: Creates a string containing the compilation date & time. > > Revisions: > 1.00 JNB 2006-10-18 > > Notes: The intermediate file 'DateAndTime.o' is deleted after every > compilation, so that it is recompiled each time with the new > date > and time. > > \* > ************************************************************************ > */ > > #include > > void GetCompileDateAndTime(void) > { > cstrcpy(MessageOut, "Build - "); > cstrcat(MessageOut, __DATE__); > cstrcat(MessageOut, " \100 "); > cstrcat(MessageOut, __TIME__); > } > > > > > > > At 22:10 25/05/2007, you wrote: > >> I want to keep a string that indicates the date and time that the >> firmware was built. >> >> Right now, I'm building a string with __DATE__ and __TIME__ >> >> Problem is, those are evaluated by the preprocessor at compile time. >> If I modify a file which doesn't reference those macros and forget to >> do a "rebuild all", the version string doesn't get updated. >> >> In ICC12 (both v6 and v7) there's a text field under the "Compiler" >> tab of the "Compiler Options" dialog labeled "Execute Command After >> Successful Build:" >> >> Right now, I'm using this field to touch (update the modification >> time) on the file which builds the timestamp. That way, (assuming the >> build completed successfully) the next time I rebuild, that file will >> be guaranteed to recompile, regardless of whether I edit it or not. >> >> Ideally, I'd touch this file *before* building so I know that the >> string always accurately reflects the date and time of when the >> program was built, regardless of whether the previous compile was >> clean or not.. >> >> >> Any suggestions? >> Thanks. >> >> Barry >> >> _______________________________________________ >> Icc-mot mailing list >> Icc-mot@imagecraft.com >> http://dragonsgate.net/mailman/listinfo/icc-mot >> > > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot From barryc at rjlsystems.com Sat May 26 11:29:49 2007 From: barryc at rjlsystems.com (Barry Callahan) Date: Sat May 26 11:39:21 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <200705261808.l4QI8Np0028315@dragonsgate2.imagecraft.com> References: <200705261808.l4QI8Np0028315@dragonsgate2.imagecraft.com> Message-ID: <46587C9D.2000601@rjlsystems.com> Lance, I'm happy that you found a solution for release control that works well in your shop. I'm not going to get into the various reasons (some of which are political) why we *specifically* want the build timestamp in the final output. Barry Lance B. Smith wrote: >One other thought on all of this. I purposefully DON'T want date / time >embedded. When it was built is irrelevant because of the magic of S-records. >What matters is that I can diff the S-record and get verification that what >I just built is still the same as the release build. The release S-record >has its own OS file date and time. It also has unique version number which >is embedded. If I embed the date time, then that will make it not diff clean >and I would have to know to ignore that difference and not others, which is >an error-prone hassle. > >This is very useful because I can go on writing new stuff conditionally and >test it carefully in a special test build turning on new code here and there >until I know it is ready for prime-time, but can quickly revert back to the >last release, by turning off the new conditional (#define) switches. >Furthermore, I may have to release another variant of the same base-project >during the new-coding phase. So, for example if two variants still build to >match the same two respective release S-record files, then I know the third >one will also represent the same level of testing, except of course for the >variation. (We do a lot of testing on our releases, and are fortunate to >have a very talented tester who can find the whackiest subtle bugs). > >This allows me to keep incrementing the same source-control project and not >have so many versions of individual files to keep track of. And also allows >me to quickly fix any bugs that may come up during testing after the code is >handed off. Every hand-off gets unique suffix, that's the release control. >To avoid having too many suffixes go out the door, all test suffixes are >lower case. The final release suffix is upper case. The final S-rec must >diff clean against the latest test suffix, except for the one variation in >the suffix character. > >Just some thoughts. > >Best to all >-- Lance > >===================== >Lance B. Smith, President >Rapidware, Inc. >108 East Main Street >Milan, MI 48160 >734 439 3990 >734 439 3975 Fax >lance@rapidware.com >www.rapidware.com >===================== > > >-----Original Message----- >From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com] >On Behalf Of John Baraclough >Sent: Saturday, May 26, 2007 1:25 PM >To: Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe >toicc-announce if you are a member of this. >Subject: Re: [Icc-mot] Build/Link time > >Hi Barry, > >Just put the __DATE__ & __TIME__ macros into a very small file as >below then delete the '.o' file after every build. > >HTH > >John > >/* ************************************************************************ >*\ > File: DateAndTime.c > > Purpose: Creates a string containing the compilation date & time. > > Revisions: > 1.00 JNB 2006-10-18 > > Notes: The intermediate file 'DateAndTime.o' is deleted after every > compilation, so that it is recompiled each time with the new date > and time. > >\* ************************************************************************ >*/ > >#include > >void GetCompileDateAndTime(void) >{ > cstrcpy(MessageOut, "Build - "); > cstrcat(MessageOut, __DATE__); > cstrcat(MessageOut, " \100 "); > cstrcat(MessageOut, __TIME__); >} > > > > > > >At 22:10 25/05/2007, you wrote: > > >>I want to keep a string that indicates the date and time that the >>firmware was built. >> >>Right now, I'm building a string with __DATE__ and __TIME__ >> >>Problem is, those are evaluated by the preprocessor at compile time. >>If I modify a file which doesn't reference those macros and forget >>to do a "rebuild all", the version string doesn't get updated. >> >>In ICC12 (both v6 and v7) there's a text field under the "Compiler" >>tab of the "Compiler Options" dialog labeled "Execute Command After >>Successful Build:" >> >>Right now, I'm using this field to touch (update the modification >>time) on the file which builds the timestamp. That way, (assuming >>the build completed successfully) the next time I rebuild, that file >>will be guaranteed to recompile, regardless of whether I edit it or not. >> >>Ideally, I'd touch this file *before* building so I know that the >>string always accurately reflects the date and time of when the >>program was built, regardless of whether the previous compile was >>clean or not.. >> >> >>Any suggestions? >>Thanks. >> >>Barry >> >>_______________________________________________ >>Icc-mot mailing list >>Icc-mot@imagecraft.com >>http://dragonsgate.net/mailman/listinfo/icc-mot >> >> >> > > >_______________________________________________ >Icc-mot mailing list >Icc-mot@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-mot > >_______________________________________________ >Icc-mot mailing list >Icc-mot@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-mot > > From j_baraclough at zetnet.co.uk Sat May 26 12:16:01 2007 From: j_baraclough at zetnet.co.uk (John Baraclough) Date: Sat May 26 14:50:43 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <46587AA0.10205@rjlsystems.com> References: <465750DF.5020408@rjlsystems.com> <46587AA0.10205@rjlsystems.com> Message-ID: I always put the DateAndTime file at the end of the IDE file list. Then it will be the last one to build and the .o file will only exist briefly after a successful build. If the build fails at an earlier point then the .o file will not exist. If you are not using the IDE then edit your makefile to put the DAteAndTime file at the end of the list. All the best for now, John At 19:21 26/05/2007, you wrote: >End result is the same. If I tell ICC to automatically delete the .o >file for me, it will only do it after a successful build. >IE: if *ALL* source files compiled successfully. > >Consider this: >The file with __DATE__ and __TIME__ is the fourth .c file to be >compiled, and the ninth is the one that errors out. >You fix the ninth file and rebuild. Maybe it only takes you a few >minutes to fix the file. Maybe it takes you hours or days. The point >is, time passes. > >Because the first build did not complete successfully, the .o file >containing the timestamps was not removed. (or, using my existing >solution, the .c file was not touched.) Once the ninth file has been >fixed and the project built, the timestamp embedded in the .s19 does >*NOT* reflect the time when the project was successfully built. -- >It is the time when I attempted the first build. > >If all I cared about was that I had a means to ensure that I have >distinct version strings between successful builds, this would not >be a problem. But I actually, specifically, want the timestamp of >the successful compile. > >If I could specify a command to be executed before the first file >was compiled, or if I could alter the order in which files are >compiled to force the file with the timestamp to always be the last >file to compile,(something that didn't occur to me until just now to >try to fiddle with) I'd be peachy-keen. > >John Baraclough wrote: > >>Hi Barry, >> >>Just put the __DATE__ & __TIME__ macros into a very small file as >>below then delete the '.o' file after every build. >> >>HTH >> >>John >> >>/* >>************************************************************************ *\ >> File: DateAndTime.c >> >> Purpose: Creates a string containing the compilation date & time. >> >> Revisions: >> 1.00 JNB 2006-10-18 >> >> Notes: The intermediate file 'DateAndTime.o' is deleted after every >> compilation, so that it is recompiled each time with the new date >> and time. >> >>\* >>************************************************************************ */ >> >>#include >> >>void GetCompileDateAndTime(void) >>{ >> cstrcpy(MessageOut, "Build - "); >> cstrcat(MessageOut, __DATE__); >> cstrcat(MessageOut, " \100 "); >> cstrcat(MessageOut, __TIME__); >>} >> >> >> >> >> >> >>At 22:10 25/05/2007, you wrote: >> >>>I want to keep a string that indicates the date and time that the >>>firmware was built. >>> >>>Right now, I'm building a string with __DATE__ and __TIME__ >>> >>>Problem is, those are evaluated by the preprocessor at compile >>>time. If I modify a file which doesn't reference those macros and >>>forget to do a "rebuild all", the version string doesn't get updated. >>> >>>In ICC12 (both v6 and v7) there's a text field under the >>>"Compiler" tab of the "Compiler Options" dialog labeled "Execute >>>Command After Successful Build:" >>> >>>Right now, I'm using this field to touch (update the modification >>>time) on the file which builds the timestamp. That way, (assuming >>>the build completed successfully) the next time I rebuild, that >>>file will be guaranteed to recompile, regardless of whether I edit it or not. >>> >>>Ideally, I'd touch this file *before* building so I know that the >>>string always accurately reflects the date and time of when the >>>program was built, regardless of whether the previous compile was >>>clean or not.. >>> >>> >>>Any suggestions? >>>Thanks. >>> >>>Barry >>> >>>_______________________________________________ >>>Icc-mot mailing list >>>Icc-mot@imagecraft.com >>>http://dragonsgate.net/mailman/listinfo/icc-mot >> >> >>_______________________________________________ >>Icc-mot mailing list >>Icc-mot@imagecraft.com >>http://dragonsgate.net/mailman/listinfo/icc-mot > >_______________________________________________ >Icc-mot mailing list >Icc-mot@imagecraft.com >http://dragonsgate.net/mailman/listinfo/icc-mot > From dean.bell at flightec.com Mon May 28 15:04:30 2007 From: dean.bell at flightec.com (Dean Bell) Date: Mon May 28 15:15:21 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <465750DF.5020408@rjlsystems.com> References: <465750DF.5020408@rjlsystems.com> Message-ID: <001201c7a174$2ac329a0$1101a8c0@Technicaldesgnxp1b12e69c9632> I did ask Richard some time ago for an "Execute command before build" option for V7 to do the .h file modifications similar to what Edward was doing with his autoexec.bat file, but Richards comment was that I was the only one who has requested this future. So are there more people who would like this future? There are three other compiler options I would like to see __BULID__, __NOW__ and a build history file "projectname.hst" with tick box activation. Macro __BULID__ returns an unsigned integer of the current project's successful build count. For a new project this counter would start at 1 and is found in the "projectname.prj" file. Macro __NOW__ (4 bytes) returns an unsigned long of the build date & time in seconds with an epoch of 1/1/1970 (like UNIX) it is good for 136 years (1/1/2106). This is an alternant to using the strings __DATE__ (12 bytes), __TIME__ (9 bytes), handy for small micro and doing logical checks:- if( new_time > __NOW__ ){DoSomeThing( &new_time );}. Build history is a file that contains the warnings and errors that appear in the IDE status window with the current build count EG:- !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(19):[warning] parameter `pointer to char txt' is not referenced !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(19):[warning] parameter `char prt' is not referenced !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(22):[warning] parameter `pointer to char txt' is not referenced !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(22):[warning] parameter `char prt' is not referenced Device 0% full. Build 1, Done. Mon May 28 10:23:52 2007 !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(19):[warning] parameter `pointer to char txt' is not referenced !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(19):[warning] parameter `char prt' is not referenced !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(22):[warning] parameter `pointer to char txt' is not referenced !W C:\iccv712\Icc-mot\BuildAndLink\DateAndTime.c(22):[warning] parameter `char prt' is not referenced !E C:\iccv712\Icc-mot\BuildAndLink\BuildAndLinkMain.c(8): undeclared identifier `x' !W C:\iccv712\Icc-mot\BuildAndLink\BuildAndLinkMain.c(9):[warning] expression with no effect elided !E C:\iccv712\Icc-mot\BuildAndLink\BuildAndLinkMain.c(9): syntax error; found `}' expecting `;' Build 2, Done: there are error(s). Exit code: 1. Mon May 28 10:27:34 2007 !W DateAndTime.c(19):[warning] parameter `pointer to char txt' is not referenced Device 0% full. Build 2, Done. Mon May 28 10:30:31 2007 Device 0% full. Build 3, Done. Mon May 28 10:33:04 2007 It would be advantages to have additional information in the "projectname.mp" file showing the last modification date/time & size of the source files (.c .s .a) EG:- 8032 _GetCompileDateAndTime 8085 _main 8086 __HC12Setup 808B __text_end Files Linked, Build 3 [ module(s) ] C:\iccv712\lib\crt12.o [ crt12.s, ?, ?, ? ] DateAndTime.o [ DateAndTime.c, 28 May 2007, 09:56:11, 811 bytes ] BuildAndLinkMain.o [ BuildAndLinkMain.c, 28 May 2007, 10:03:24, 33 bytes ] [ setup.s, ?, ?, ? ] User Global Definitions init_sp = 0x1000 User Base Address Definitions text = 0x8000 data = 0x800 I think the key thing we are all trying to achieve here is tractability (object to source) what ever method we use. Any comments? Dean. -----Original Message----- From: icc-mot-bounces@imagecraft.com [mailto:icc-mot-bounces@imagecraft.com] On Behalf Of Barry Callahan Sent: Saturday, 26 May 2007 09:11 To: Discussion List for ICC08/11/12/16 users. You do NOT need to subscribe to icc-announce if you are a member of this. Subject: [Icc-mot] Build/Link time I want to keep a string that indicates the date and time that the firmware was built. Right now, I'm building a string with __DATE__ and __TIME__ Problem is, those are evaluated by the preprocessor at compile time. If I modify a file which doesn't reference those macros and forget to do a "rebuild all", the version string doesn't get updated. In ICC12 (both v6 and v7) there's a text field under the "Compiler" tab of the "Compiler Options" dialog labeled "Execute Command After Successful Build:" Right now, I'm using this field to touch (update the modification time) on the file which builds the timestamp. That way, (assuming the build completed successfully) the next time I rebuild, that file will be guaranteed to recompile, regardless of whether I edit it or not. Ideally, I'd touch this file *before* building so I know that the string always accurately reflects the date and time of when the program was built, regardless of whether the previous compile was clean or not.. Any suggestions? Thanks. Barry _______________________________________________ Icc-mot mailing list Icc-mot@imagecraft.com http://dragonsgate.net/mailman/listinfo/icc-mot From john at labxtechnologies.com Tue May 29 07:46:30 2007 From: john at labxtechnologies.com (John Passaniti) Date: Tue May 29 07:56:33 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <001201c7a174$2ac329a0$1101a8c0@Technicaldesgnxp1b12e69c9632> References: <465750DF.5020408@rjlsystems.com> <001201c7a174$2ac329a0$1101a8c0@Technicaldesgnxp1b12e69c9632> Message-ID: <465C3CC6.4080007@labxtechnologies.com> Dean Bell wrote: > I did ask Richard some time ago for an "Execute command before build" option > for V7 to do the .h file modifications similar to what Edward was doing with > his autoexec.bat file, but Richards comment was that I was the only one who > has requested this future. So are there more people who would like this > future? Yes, I would like this feature very much and have asked for it in the past. But what would be better in my opinion would be some mechanism by which I could customize the generated make file. That is, I still want the IDE to build the list of dependencies and to declare the targets specified in the IDE. But I also want the ability to add additional targets and rules that are protected. > Macro __BULID__ returns an unsigned integer of the current project's > successful build count. For a new project this counter would start at 1 and > is found in the "projectname.prj" file. I would find this very useful as well. It is in fact one of the reasons I want to be able to have an "execute command before build" option. From dieseinfo at free.fr Tue May 29 08:39:09 2007 From: dieseinfo at free.fr (dieseinfo@free.fr) Date: Tue May 29 08:46:56 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <465C3CC6.4080007@labxtechnologies.com> References: <465750DF.5020408@rjlsystems.com><001201c7a174$2ac329a0$1101a8c0@Technicaldesgnxp1b12e69c9632> <465C3CC6.4080007@labxtechnologies.com> Message-ID: <002e01c7a207$80a58370$f68afd52@winxp> Following the discussion about date and compile time, I discover here there are 2 symbolic constants __DATE__ and __TIME__, and this is very important for me too. Are there other constants ? For example compiler version ? I did'n read anything about this. Thank you all, Best regards. Joel Petrique From genenorris at spotengineering.com Thu May 31 09:29:29 2007 From: genenorris at spotengineering.com (Gene Norris) Date: Thu May 31 09:39:31 2007 Subject: [Icc-mot] Build/Link time In-Reply-To: <002e01c7a207$80a58370$f68afd52@winxp> References: <465750DF.5020408@rjlsystems.com><001201c7a174$2ac329a0$1101a8c0@Technicaldesgnxp1b12e69c9632> <465C3CC6.4080007@labxtechnologies.com> <002e01c7a207$80a58370$f68afd52@winxp> Message-ID: <465EF7E9.6090904@spotengineering.com> Standard (ANSI) 'C' has 5 predefined macros: Note: they cannot be undefined or redefined. printf("%s",__DATE__); printf("%s",__TIME__); printf("%s",__FILE__); printf("%d",__LINE__); printf("%s",(__STDC__)?"This is standard C.":"This is NOT standard C."); Richard has added the following: __IMAGECRAFT__ and others depending on the specific compiler used: _HC12 (For the hc12 compiler) I believe there is also one based on the specific micro processor...but I'm not exactly sure Gene dieseinfo@free.fr wrote: > Following the discussion about date and compile time, I discover here there are 2 symbolic constants __DATE__ and __TIME__, and this > is very important for me too. > > Are there other constants ? For example compiler version ? > I did'n read anything about this. > > Thank you all, > Best regards. > > Joel Petrique > > > _______________________________________________ > Icc-mot mailing list > Icc-mot@imagecraft.com > http://dragonsgate.net/mailman/listinfo/icc-mot > > > -- Gene Norris Chief Engineer SPOT Engineering, Inc. 1261 Campground Road Lancaster, Ohio 43130 740.654.0880 FAX.654.0889 http://www.spotengineering.com/