This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Philips LPC2xxx variant port

Jani Monoses wrote:
I made the changes you suggested including the new var_io names and will shortly send the updated patch.

+cyg_uint32 lpc_cclk; //CPU clock frequency
+cyg_uint32 lpc_pclk; //peripheral devices clock speed (equal to, half, or quarter of CPU clock)

I did not make these CDL constant values so they can be changed at runtime when setting a different VPBDIV.

Hmm... setting a different VPBDIV is already problematic as anything that relies on it will in turn need to be reinitialised, otherwise e.g. serial chars will be at the wrong rate.

But I guess we should allow for this to be handled better in the future and allow it to be variable, so ok.

Although... an accessor macro would arguably be the absolutely correct way to do it (which can therefore point to a global, or function or constant or whatever). I'll leave it to you to decide if it's worth it. Some people take global variables accessed only via macros as a software engineering doctrine.

Should I add a cyg_ prefix to them? After a quick grep though packages/devs I don't see a naming pattern that devices use for extern variables that are set in the HAL.

cyg_hal_arm_lpc2xxx_cclk/pclk would be better I guess.[1] Oh the joys of hierarchical naming ;-).

[1] Or CYG_HAL_ARM_LPC2XXX_CCLK()/PCLK() if you do go with the accessor macro.
eCosCentric    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]