Hi all, I'm new to C and need a hint on an optimization problem. I have a 16 bit counter, divided into two 8bit SFRs, let's say TH0 and TL0, and I want to transfer them to a short. I could: mshort = (short)TH0 * 256 + TL0 but this takes 16bytes, similar to something like: mshort = (short)TH0 << 8 + TL0 I would like to do it more simple, like: MSB of mshort = TH0 LSB of mshort = TL0 I tried it that way: unsigned short *pINT; pINT = &TH0; but this is not possible with SFRs. Something else I tried: unsigned short mINT; unsigned char *pChar; pChar = & mINT; *pChar = TH0; *(pChar + 1) = TL0; results in even more code (31 bytes) So I think it would be the easiest, if I could place 2 char variables at the same address, covered by my short, like: unsigned short mINT; unsigned char mChar[2] (at the same address like mINT) mChar[0] = TH0; mchar[1] = TL0; but I don't know, how to place the mChar array at the same address of mINT. I tried it with: unsigned char mChar[2] _at_ mINT; but this is not possible (compiler error). So anyone here, who could give me a hint how to place both variables at the same address? Thanks in advance Marco Della Rocca
Hi, if the two SFRs are placed in contiguous addresses, you can just define an appropriate SFR16, e.g.:
sfr TL2 = 0xCC; sfr TH2 = 0xCD; sfr16 T2 = 0xCC;
if the two SFRs are placed in contiguous addresses, you can just define an appropriate SFR16, a very dangerous practice. Two years from now you will use another derivative where they are not "in contiguous addresses" and you will spend hours/days/weeks figuring out why this 'good' code suddenly does not work. This seems to be, based on reading some past posts, one of the bugs that are most difficult to catch for some. With an ICE it is no big deal. Erik PS in my opinion, SFR16 should be outlawed (it is here) for the above reason. Erik
you can just define an appropriate SFR16, Bad idea. Never define your own SFRs. That's what you get ready-made headers from Keil for.
That's what you get ready-made headers from Keil for. Which are sometimes woefully incomplete and/or just copied from a completely different device without modification *cough*ADuC845*cough*.
Bad idea. Never define your own SFRs. That's what you get ready-made headers from Keil for. I always do. The names, as they are, are not searchable, e.g. if you search on 'EA' you may miss IOR IE,080h. staying with the above example, my names are sfr SF_IE = 0xa8; sbit SB_IE_EA = 0x8f; #define SM_IE_EA 0x80 When you get to the derivatives with 'paged' SFRs such as SILabs f12x, it get even better. then I have SG_... //any sfrpage S0_... //SFRpage 0... Erik
Thanks Tim,
this would have been the best solution for me (let it be good coding or not). Unfortunately there's another 8bit SFR between them (did not see this yesterday and thought they were contiguous).
I posted: "PS in my opinion, SFR16 should be outlawed (it is here)" now you post Unfortunately there's another 8bit SFR between them (did not see this yesterday and thought they were contiguous).
I take it that you now have joined the group outlawing them.
Erik
Bad idea. Never define your own SFRs. That's what you get ready-made headers from Keil for.
I totally disagree, as I have found too many buggy ready-made headers from different sources. Therefore I always create my own headers for the target platforms I use.
However I have to admit that Eric is right. If the derivative is changed and the header is just used as it is, this may cause some bugs that are difficult to catch.
Assuming you're trying to get the 16 bits of a timer into a UINT16 and the timer is free running, beware the LSB to MSB rollover demon. This foul vermin of the firmware realm strikes predominantly after software release.
This foul vermin of the firmware realm wrong address This foul vermin of programmer incompetence
erik
wrong address This foul vermin of programmer incompetence
Well...yes, but I was giving him a break as he's admittedly a newb.
Well...yes, but I was giving him a break as he's admittedly a newb. That's nice, but please do not provide the excuse that such crap is due to a shortcoming of anything but the programmer. Your orignial post can be read as such.
Anyhow, this problem is not just with timers, atomicity has a much wider scope.