• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 21 subscribers
  • Views 1270 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ucfg1 & eprom

geert starre

Hi,

How can I config the UCFG1
( system configuration for
clock, watchdog enz ) for
a LPC controller in C ?

And how can I use the 32
bytes eprom ?

I tried the following but
the compiler returnes an
error
//xdata char _at_ 0x10 ;
//xdata char UCFG1 _at_ 0xFD00 = 6;
//xdata char UCFG1 = 8 _at_ 0xFD00;
//xdata char UCFG1 _at_ 0xFD00 = 0x7B;
//pdata const UCFG1 _at_ 0xFD00=4;
//pdata const UCFG1 _at_ 0xFD00;
//UCFG1=222;// not an error here
// but it does't work either

thanx!
geert

Parents
  • 0 in reply to geert starre 

    // Header file for LPC764 MCU:
// #include "REG764.H"
    Any particular reason why you're putting the "//" on the front of everything?
    When posting code to the forum, please enclose it within &ltpre&gt and &lt/pre&gt tags (it gives you a monospaced font, and that lovely tuquoise tint!)
    // no error, but not a value:
// xdata char P_UCFG1 _at_ 0xFD00;
    what do you mean by, "not a value?"
    // syntax error near _at_:
// pdata const P_UCFG1=123 _at_ 0xFD00;
    Please consult the C51 User's Guide (C51.pdf), which specifies the correct syntax of the _at_ keyword.
    In particular, note that initialisation is not allowed in conjuction with _at_ :-(
    All the manuals are accessible via the 'Books' tab in the uVision Project window.
    // no error, but not a value:
// pdata const P_UCFG1 _at_ 0xFD00;

// syntax error:
// pdata const P_UCFG1 _at_ 0xFD00;
    They look the same to me!?
    Don't forget that one syntax error can lead to further errors later in code which would otherwise be OK.
    Always fix the 1st error first, before worrying about subsequent errors!
    // In another compiler ( Tasking )
// this works:
    There is no reason to ever assume that one compiler's specific extensions will be in any way compatible with another compiler!
    If you want your code to be portable, then you must stick to strict ANSI 'C' and beware of all implementation-defined behaviour.
    // the next is strange: compiler does
// not return an // error, but UCFG1
// is not listed in REG764.H. It has
// no effect.
// UCFG1=222;
    In the absence of a specific definition, 'C' assumes that an identifier is an int.
    This might compile OK, but the Linker would give you an "unresolved external" error (unless, of course, you just happened to have a public UCFG1 somewhere...)
    // UCFG1 & UCFG2 is EPROM, nor RAM,
// not SFR of normal ROM ( code )
    Pardon?

Reply
  • 0 in reply to geert starre 

    // Header file for LPC764 MCU:
// #include "REG764.H"
    Any particular reason why you're putting the "//" on the front of everything?
    When posting code to the forum, please enclose it within &ltpre&gt and &lt/pre&gt tags (it gives you a monospaced font, and that lovely tuquoise tint!)
    // no error, but not a value:
// xdata char P_UCFG1 _at_ 0xFD00;
    what do you mean by, "not a value?"
    // syntax error near _at_:
// pdata const P_UCFG1=123 _at_ 0xFD00;
    Please consult the C51 User's Guide (C51.pdf), which specifies the correct syntax of the _at_ keyword.
    In particular, note that initialisation is not allowed in conjuction with _at_ :-(
    All the manuals are accessible via the 'Books' tab in the uVision Project window.
    // no error, but not a value:
// pdata const P_UCFG1 _at_ 0xFD00;

// syntax error:
// pdata const P_UCFG1 _at_ 0xFD00;
    They look the same to me!?
    Don't forget that one syntax error can lead to further errors later in code which would otherwise be OK.
    Always fix the 1st error first, before worrying about subsequent errors!
    // In another compiler ( Tasking )
// this works:
    There is no reason to ever assume that one compiler's specific extensions will be in any way compatible with another compiler!
    If you want your code to be portable, then you must stick to strict ANSI 'C' and beware of all implementation-defined behaviour.
    // the next is strange: compiler does
// not return an // error, but UCFG1
// is not listed in REG764.H. It has
// no effect.
// UCFG1=222;
    In the absence of a specific definition, 'C' assumes that an identifier is an int.
    This might compile OK, but the Linker would give you an "unresolved external" error (unless, of course, you just happened to have a public UCFG1 somewhere...)
    // UCFG1 & UCFG2 is EPROM, nor RAM,
// not SFR of normal ROM ( code )
    Pardon?

Children
  • 0 in reply to Andrew Neil

    Hi andrew, thanx again for fast your reply!

    You are right that I cannot use the same code in different compilers. (unless ANSI C only) the reason I posted that code whas that I know how to solve the problem in Tasking C and also in Keil assembler, but not in Keil C. ( In Tasking:

     _rom char UCFG1 _at(0xFD00) = 0x7B
    )

    The problem in words is:
    I want to have a 'const' at a specified adress ( 0xFD00. ) It can not be a var that get's initialized during runtime ( like a SFR )

    The reason is that in this reagion my controller has configuration bits in EPROM. ( a small part of ROM is EPROM ) Configuration for, among others, the selection for external of internal clock. External is default. There's the reason why I cannot fill a var during runtime. If I don't have a external clock, code will never be executed, and the program will not change the content of the byte at 0xFD00. So if you know how to define a 'const' in ROM at a specified addres, in Keil C I will be very thankfull.

    Thanx in advance!
    geert



  • 0 in reply to geert starre

    If you know how to do it in Keil assembler, why not just do it in assembler!?
    In this case, I don't think there is anything to gain in doing it in 'C'; in fact, assembler might even be better, as it allows you to write numbers in binary - which is easier to read when you're setting bit patterns (in 'C', you'd have to convert it to Hex).

    Just create a little assembler file to set these two ROM "registers" - you don't even have to worry about C/Assembler interfacing, as there is nothing to "call" or be called; it just sets these 2 locations at build time.

  • 0 in reply to Andrew Neil

    When posting code to the forum, please enclose it within <pre> and </pre> tags (it gives you a monospaced font, and that lovely tuquoise tint!)

    Are you complaining about my lovely turquoise tint? :-)

    Jon