This patch adds support (i.e. header files) for Axsem 8052 microcontrollers
add header files for Axsem 8052 devices
Thank you for the patch. I was wondering how you managed to create the header files without a datasheet available, but from your email address I see you are an Axsem employee.
There is one problem though. From the comments in compiler.h:
* SFR16X and SFR32X for 16 bit and 32 bit xdata registers are not defined
* to avoid portability issues because of compiler endianness.
But you added SFR16X, even for big-endian compilers and used it. I think it is better leave SFR16X out.
What do you want me to do?
I'm reluctant to remove convenience for SDCC users for the benefit of other, inferior compilers.
Splitting access to 16bit registers in 8bit halves manually is a PITA for the programmer and often generates worse code with SDCC as well.
new version with SFR16X renamed to SFR16LEX
I don't think other compilers are inferior. I think the market leader beats SDCC easily when it comes to code size. And they chose to use a big-endian implementation, where SDCC chose little-endian. And if the engineers at Axsem had chosen big-endian too for the XDATA mapped registers you probably would be calling SDCC inferior. All this stems from the fact that the 8051 has no native endianness.
I created compiler.h to solve the compatibility problem so users can migrate easier. So that a silicon vendor such as Axsem need not support several compilers. And so that it suffices to create only one header file and one example set.
If we're going to add something like SFR16X I think it needs to include endianness in its name, probably SFR16LEX. And for big-endian compilers it must be defined empty like SFR16E for most compilers. That way at least the user gets compile time errors when it is used. But expect to get support questions about it when you use it in example code.
Another common problem with multi-byte special function registers is atomicity. The core cannot read both bytes at the same time for a precise capture of their value. Sometimes silicon vendors solve that by latching the other byte(s) when one particular one is read/written (e.g. the LSB). But the compilers do not guarantee access order and thus splitting the access is still necessary to force the order. I would advise not to define such register combinations as they generate incorrect code without any warning. (i can't check in this case as there is no public datasheet yet).
correct SFR16LEX for Keil
> Another common problem with multi-byte special function registers is
> atomicity. The core cannot read both bytes at the same time for a precise
Of course. But this is not specific to xdata space, that applies equally to direct space as well. In C8051F320.h, you defined a sfr16 for PCA0. The chip manual states, that to read PCA0, the low byte should be read first. Yet the sdcc manual says that while sdcc usually accesses LSB first, one should not rely on it (sdccman.lyx lines 19554 and following). So there is some precedent for defining 16bit registers even if under some corner cases this might go wrong. (btw why does C8051F320.h not use compiler.h, while most other C8051* do?)
Also, on what compilers have you actually tested compiler.h? It does not work for me with keil. The reason is that because the semicolon is not part of the macro definition, whenever a register definition is "zapped" (as happens for SFR16E for keil, for example), you end up with spurious semicolons. Both sdcc and keil don't like those spurious semicolons, it just does not happen on sdcc, because all SFR macros actually define registers. It seems to me that this semicolon should be moved into the macro definition.
Any news on this? Maarten, what do you think about the updated patch from 2011-09-14? Can it go in?
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.