If you can't add that internally, maybe you could add another option to the TOOL Macro drop down box that would include all project file names ???
--->> AND we need a way to see the output of the tool so that we'll know the complete line that will actually be executed before we hit the shortcut. (just a text box below the shortcut to show it should do) - OH, OH - we also need a way to call it from a menu - so we don't have to remember the shortcut key for seldom used ones
.--> I also just noted that if you don't have ANY parameters, it fails because '%1' is appended after the filename - which it doesn't recognize if the program doesn't allow parameters...
2). I don't see a way to execute the assembler/linker portion of the compiler by itself. I can see a time when I might want to 'tweak' the asm output a bit here and there and then assemble it. Seems it should be easy to do and possibly QUITE helpful to some.
3). Can you provide a brief explanation (if possible) of the differences in the 6 possible OPTIMIZATION levels available?
4). Can you provide a brief explanation of the compiler (success) messages below?
Used RX (bytes): 14 (44%) Free RX (bytes): 18 (56%) Used RX (bytes): 14 (44%) Free RX (bytes): 18 (56%)
Static RAM (bytes): 2 Dynamic RAM (bytes): 8190 Static RAM (bytes): 2 Dynamic RAM (bytes): 8190
Used ROM (bytes): 516 (0%) Free ROM (bytes): 122363 (100%) Used ROM (bytes): 516 (0%) Free ROM (bytes): 122363 (100%)
I'm not sure what 'RX' represents - oops - OK, I see that it is register space. I presume that this message means that I've used 14 registers and that there are still 18 more unused. (I have optimization turned OFF for debugging).
RAM info isn't clear whether it's USED bytes, or FREE bytes and why is it repeated twice? I think it's supposed to be USED/FREE, but it doesn't read that way.
ROM seems fine, except it's repeated twice. Possibly first from compiler and second from assembler?
Steve
PS. When using the math library, debugger seems to run INCREDIBLY SLOW. It takes some 20 minutes to run a loop like the one below
CONST PI 3.14159
for (i=0; i< (256+64); i++) { // probably don't need to go beyond 256
f = 2 * PI * i/256;
f = (1 + sin(f)) * 128; // float value from 0 to 2 & nomalize to 256
k = floor(f); // get integer value
if (k > 255) k = 255; // don't allow 256
DacVolts = k;
if ((f - k) > 0.5) // round up if necessary
if (DacVolts < 255) // as long as it isn't already at max
DacVolts += 1;
}
This is the one I had so much trouble trying to read parameter values at intermediate points within the loop. I finally had to let the loop run its course and break after it completed the full loop - only THEN could I look at the (final) values to see what happened. I solved my issue by adding several global arrays (already removed here) to hold intermediate values so I could study them after the fact. (and I took LONG breaks while letting the debugger run <G>).
