Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
05/19/06 08:36
Read: times


 
#116606 - Thanks
Responding to: ???'s previous message
Thanks Erik,

why not a "header file converter".

That would be a lot harder than this header file. What to convert from and how about unsupported vs. extra functionality? Besides the user would have to perform actions to get started and learn the converter tool. I want to keep it as simple as possible.

#ifdef #if are not 'helpers', they are 'unavoidable nuisances', the more you have, the more unreadable your code becomes.

True if used (excessively) inside the code, but I think in this case the use is exactly what it was meant for.

SFR16 is the death of many efforts. E.g. for the PCA the sequence of writing high and low is critically important, how do you propose handling that for requirements that vary (some A/Ds require the opposite?.

It's even worse as this is sometimes true within one mcu for different registers (f.e. F120 MAC0B vs. DAC0). Unfortunately I have no solution for that yet.

Also, some compilers require SFR16 to be to adjecent SFRs, I believe yours do not.

SDCC does not require the addresses to be adjacent, but requires all addresses are given. This is what I called a fulladdr in the macros for SFRxxE (extended). The 'normal' SFR16 macro calculates the fulladdr from the one addr it is given.

List of 31 messages in thread
TopicAuthorDate
predefined macros and sfr definitions            01/01/70 00:00      
   old Tasking version            01/01/70 00:00      
      Tasking            01/01/70 00:00      
         Here's what I have            01/01/70 00:00      
            reference            01/01/70 00:00      
   no aswer, but an extra question            01/01/70 00:00      
      assembler macros            01/01/70 00:00      
         not really            01/01/70 00:00      
   I doubt it - but            01/01/70 00:00      
      End of wrong stick?            01/01/70 00:00      
         OK "any", not "ant", but "8051-derivativ            01/01/70 00:00      
            Unfair            01/01/70 00:00      
               can be argued            01/01/70 00:00      
                  No unfair intentions            01/01/70 00:00      
                     universality is not desired            01/01/70 00:00      
                  it's especially all those installs            01/01/70 00:00      
                     They happily coexist at my place            01/01/70 00:00      
                        Uninstalling            01/01/70 00:00      
   Dunfield            01/01/70 00:00      
      Dunfield AppNotes            01/01/70 00:00      
         DDS            01/01/70 00:00      
         if it is asm            01/01/70 00:00      
         what's the big deal?            01/01/70 00:00      
            solution            01/01/70 00:00      
   First try            01/01/70 00:00      
      a couple of problems (for me)            01/01/70 00:00      
         Thanks            01/01/70 00:00      
            Sometimes even using things for "what it            01/01/70 00:00      
            Common Practice            01/01/70 00:00      
               nasty is relative            01/01/70 00:00      
         Limitations            01/01/70 00:00      

Back to Subject List