A wish concerning register definition files in assembler

[joerg]

Hi
as i am preparing some more versions of EBS08 i noticed, that the register definition files for the different devices (i.e QD4 and QGx as well as GBxx ...) are in different stiles.
They are sometimes using the bare bit names like ELS0A or a name with the register name an the bit name like TPM2C0SC_ELS0A.
Sometimes the names are differing from the data sheet.
I think the names strictly should be as they are listed in the data sheet!! with no exceptions!!! (please use bit names without register name in front!)

I know it is a hard work to write those files, but if they are written as they should they are easing the programming work a lot.

Thanks Joerg

[joerg]

Thanks

to Bigmac: good solution, but, as i am always saying "i am born lazy!!!", so i would like to have so little to do as possible. Since i like to give a hand to beginners also, i would like to prevent the IFNDEF stuff (like MACRO's).

In general the concept of the Freecsale "nameing" is weak. Why do they name i.e. the SCI1 register once "SCI" and once "SCI1". OK sometimes there is only the SCI1 implemented, but to write portable code we (the code developers) have to define a lot of exceptions.
It could work just fine in an other way.

I think Freescale should have a kind of Nomenclature Police.

Saluti Joerg

[bigmac]

Hello,

If I read AN2111 correctly, it is recommending that the register names chosen should match the data sheet - this probably doesn't help Joerg when the data sheets themselves are inconsistent with each other.

Yes, there are problems when some devices have more than one timer or SCI, and there also may be some inconsistency whether the naming is SCI0 and SCI1, or alternatively SCI1 and SCI2, for a device with two SCI modules.  When dealing with the HC08 devices, since I am not aware of any that have more than one SCI module, it doesn't make particular sense for the data sheet to refer to SCI0 (or SCI1).  It also doesn't help portability when a TIM (HC08) becomes a TPM (HCS08).

With respect to bit naming conventions, the "long" version is standard in CW, but the shortened version produces much more readable assembly code IMHO, particularly for bset and bclr instructions, so this is also my preference.  The shortened bit name is problematic only when the same bit name occurs within two different registers - I have only ever found one instance of this.

However, I woud assume that CW is unlikely to offer definitions for shortened bit names, simply because the long names are always unique, even if the data sheet has inconsistencies.

Regards,

Mac

[Nabla69]

Hello All,

I do agree these constant changes are a bit annoying when you program.

But I've noticed that it forces you to read the datasheet.

Therefore I do find it useful because sometimes bits are changing polarity or functionality. I would not see it otherwise and spend decades scanning my code.

I understand that's the balance between improving and keeping compatibility.

Personally, I just try to compile my new project and look at all register names that don't change colour...

(I am using CodeWarrior)

Alvin.

[joerg]

Hi,
all the said is just true.
Since i have begun programming (about 1982 with Z80 under CP/M80)it was always this complicated! But with the now existing tools i think one could do it better!

Saluti Joerg

[mke_et]

With me it was easy, as I did all my own definitions. I use the 9S12 and since I'm total assembly, I figured I had to do it anyway. I did my hardware design, and I just made up all my definitions from my schematics, which originally came from my app notes for the part, and the register descriptions.

I know some of my definitions don't match the current descriptions when I see examples of code that I did vs other people, but it does make it real easy to look at the old tech manuals I have and see where and what things are and do.

Along the same line, although not software oriented.

I've always wondered why companies like Freescale don't release 'building blocks' to download with every part. When I started with the 9S12, I had to take the time to build the part from scratch in Orcad. Even though I could get schematics for it as used on the 9S12Badge. It would seem to me that it would be to Freescales benefit to have a library of every single variation of the part available for download at the time the part is sampled out for all the popular CAD software packages out there.

Mike

[joerg]

Hi Mike,
i did also a lot of typing AND i have also created a lot of devices for EAGLE CAD libraries. Since i have some experience in this topics. Just for information: the libraries can be found on my homepage

http://www.systech-gmbh.ch/Eagle/-68hc.zip

the lib is growing (soon HCS08QD4, RS08KAx and QGxx)

Saluti Joerg

(Alban fixed link)

Message Edited by Alban on 2007-01-17 04:33 PM

[peg]

Hi,

Yes, it would be nice if they could follow their own standard. As proposed in AN2111

Regards

Peg

[bigmac]

Hello Joerg,

A practical solution might be to setup your own include file containing equates for your preferred names - the names used in EBS08.  This would be included immediately following the include for the "standard" register definitions.  This way, the actual EBS08 code shouldn't need to vary between differerent members of the same family, unless hardware differences dictate change.

Each entry might take the following form -

 IFNDEF ELS0A

ELS0A:   EQU  TPM2C0SC_ELS0A

 ENDIF

To limit the effort involved, I guess you would need to cover only the registers that EBS08 uses.

Regards,

Mac

Message Edited by bigmac on 2007-01-1702:25 PM