Mark Stokes wrote:
Ok, I haven't tried the one you made yesterday yet.
The version I installed was 20030306
After installing 20030506, I see that the support is included.
Any reason you didn't follow past conventions? For example:
You have this:
#define SELM_DCO 0x00 /* Select DCO for CPU MCLK
*/
#define SELM_XT2 0x10 /* Select XT2 for CPU MCLK
*/
#define SELM_A 0x18 /* Select A (from LFXT1) for
CPU MCLK */
Where in other places where two bits define a function, it would've
been:
#define SELM0 0x08
#define SELM1 0x10
An example is for Timer_A mode control bits. They are MC0 and MC1, not
MC_Stop, MC_UP, MC_DOWN, and MC_CONTINUOUS. Same with the input divider
on Timer_A, it's ID0 and ID1, not ID1, ID2, ID4, and ID8. Whereas for
the XT2 config, you have:
#define FLL_DIV_1 0x00 /* FLL+ Divide Px.x/ACLK By
1 */
#define FLL_DIV_2 0x01 /* FLL+ Divide Px.x/ACLK By
2 */
#define FLL_DIV_4 0x02 /* FLL+ Divide Px.x/ACLK By
4 */
#define FLL_DIV_8 0x03 /* FLL+ Divide Px.x/ACLK By
8 */
This makes configuration of different modules confusing.
One last question, I didn't quite understand why you didn't just add
another #define for ...have_xt2. Instead, the way you did it, you are
using a || in the #define to get both #defines to work w/ the same code
(have_fll and have_fll_with_xt2). This gets to be a rather long
underscorey variable. I prefer a "flat" system that allows xt2 without
forcing fll (who knows, maybe TI will release such an animal).
I realize that since I'm not a developer of this project I really have
no say in the actual layout of the tools. So, with that said, I am just
rambling on to give you my opinion about some of the things that I have
found that are bothering me. Again, please don't take offence to this
Hi Mark,
For the defines, I just followed what TI did in their 43x and 44x header
files. That is the way we built all the header files, to maximise
compatibility with other compilers, and with names used in the TI
documentation. Our headers tend to be as inconsistent as the TI ones :-)
This XT2 will never exist on its own. It is an integral part of the FLL,
so I never provided for it as a separate entity. Following our
convention, that would have made it a separate module in a separate
file, I think. :-)
Regards,
Steve
