From: SourceForge.net <no...@so...> - 2006-05-11 13:40:27
|
Feature Requests item #1481734, was opened at 2006-05-04 12:14 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1481734&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Frieder Ferlemann (frief) Assigned to: Nobody/Anonymous (nobody) Summary: Allow: __sfr16 __at (0xcc) TMR2; Initial Comment: /* * Actually I hope this is uncontroversial * and could be pre 2.6.0 stuff? */ #define PROPER (0) #if PROPER /* * SDCC's proper and flexible way of defining * a two byte SFR */ __sfr16 __at (0xcdcc) TMR2; #else /* * If SDCC wants to share header files with * other compilers this "lazy" definition * should behave as __at(0xcdcc) */ __sfr16 __at (0xcc) TMR2; #endif void main(void){} ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2006-05-11 15:40 Message: Logged In: YES user_id=888171 I see what you mean. But I still think it can be done with macros. How about: #define SFR16(name, addr) __sfr16 __at(((addr+1)<<8) | addr) name; for legacy sfr16 and: #define SFR16E(name, addr) __sfr16 __at(addr) name; for SDCC Extended sfr16 functionality. I have another observation. 8051 derivatives with 24 bit sfr combinations are growing in numbers. Especially 24 bit ADC's. When I implemented sfr16 and sfr32, I also considered sfr24 but threw the idea away. I also considered sfr32 for these 24 bitters but the easy way requires there is some NUL sfr which always reads 0 and can be written anything to. For the SiLabs F350 there is none, I asked. My guess is the TI msc1210 doesn't have one either. One solution could be to extend sfr32 to accept address 0x00 as LSB or MSB address and make exceptions for that in aopGet and aopPut. This way you could easily access 24 bit sfr's as if they were (left- or right aligned) 32 bit int's. Now since sfr32 is also an SDCC unique selling point, we might do all. It only looses some built-in address- checking for sfr16/sfr32 declarations. I'm willing to take this on, but want a firm direction which way to go first. Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-05-09 23:38 Message: Logged In: YES user_id=589052 > ... how this will help. The request won't help with the notation the "other compiler" header uses. But I think the way to go for the mcs51 are the "atmel style" macros. It is certainly in the interest of Chip vendors and users to have a common denominator. So in the long run if we provide a convenient path then "our" include files might be commonly adopted one day. SDCC's proper format requiring 2 or 4 byte SFR address information for SFR16/SFR32 allows great flexibility (we have the unique selling points of non contiguous SFRs and both little- and big-endian SFRs and SFR32, thanks Maarten!). But it does so at a cost: the 2 or 4 byte addresses are more difficult to get right. They introduce a fair amount of entropy which is not needed in most cases (most SFR should be little-endian, with strictly ascending SFR addresses). Taking the c8051f120 as an example, this f.e. boils down to "__sfr32 __at (0x93) MAC0ACC;" being easier to check for humans than "__sfr32 __at (0x96959493) MAC0ACC;". If a macro would be needed to convert SDCC's long SFR16/32 addresses to another compiler which should just support ascending little-endian SFR or otherwise bail out this would get lengthy. Maybe we can prepare one Header file (with sfr16/sfr32) for maximum portability (that is with macros for SDCC / Hi-Tech / IAR / Keil / Raisonance / Tasking /...) before release? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-05-09 21:04 Message: Logged In: YES user_id=888171 Frieder, Maybe I'm stupid, but I still don't understand how this will help. A typical "other compiler" header file looks like this: sfr16 TMR2 = 0xcc; // Timer2 counter How are you going to convert that to: __sfr16 __at(0xcc) TMR2; If you use a script (like keil2sdcc.pl), the script can solve this. If you use macros (like atmel does), the macro can solve this. Btw. I've sent Atmel a message today about faulty macros in their header distribution. And I've sent TI a message about an outdated app.note. Maarten ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-05-04 15:13 Message: Logged In: YES user_id=589052 The macro would help for the header conversion *from* other compilers. You'd have to setup another one for the conversion *to* other compilers. I was hoping for a line like this for the SFR16 address setup within SDCC: address=(address&0xff00)?address:((address+1)<<8)|address; ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-05-04 14:02 Message: Logged In: YES user_id=888171 May I suggest a macro to do the substitution. #define SFR16(name, addr) __sfr16 __at(((addr+1)<<8) | addr) name; It's not like you can share SDCC notation with other compilers anyway. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1481734&group_id=599 |