SX 28 48 code cross-compatibility

mike p · 2010-12-27 14:57

I'm writing some SX code and one goal is to make it cross-compatible between the SX 28 and 48. I.e. I want to compile/run SXB & ASM on both processors with no changes or a few predictable ones (e.g. easily conditional-compiled). I am aware of some of the obvious stuff like:

1. different Device statement parameters
2. use only the first 8 banks of RAM, 3-level stack, 1st 3 ports (i.e. things easily visible on block diagram)

But I suspect there may be some more subtle issues. E.g. it appears that indirect access to RAM Bank 0 via the $00 INDF register is possible on the SX28 but not the SX48. I have already searched the forum via both the forum and Google searches using keyword sets such as:

sx 28 48 compatible
sx cross compatible

I did not notice any significant results. Is anyone aware of any threads that address this, any better keyword sets, or have any compatibility tips of their own? Thanks!

Zoot · 2010-12-27 18:42

Global variable assignments are different, yes.

The best way to handle SX28/SX48 applications (if you want the same app to run on both devices without having two separate "files") is to use SX/B's conditional compilation and to use macros with defs for ASM. The biggest key for cross-device compatiblity is the assembly BANK instruction which WILL NOT work properly on the SX48. If you check the assembly manual, you will find that BANK only sets 5 bits of the FSR, and the upper bit needs to be set manually. So generally, I use a macro called _BANK regardless of the device, so that I don't have to worry about code that will run on the 48 vs. the 28. Of course, the extra set bit / clear bit instruction for handling "bank" on the 48 will take a bit more code space, and you can't do a single instruction skip of a "bank". Here is an example:

ASM
_BANK MACRO 1
  BANK \1 
  IFDEF SX48_52; For SX48/52 change
     IF \1 & %10000000 ; FSR bit 7
         SETB FSR.7
     ELSE
         CLRB FSR.7
     ENDIF
  ENDIF
  ENDM
ENDASM

'....

' in use:
' if compiled for SX48
SX48_52 CON 1 ' or 0 if SX28

ASM
_BANK someVar
MOV someVar, W
ENDASM

The other biggest difference (aside from the extra four pages of codespace), at least in my opinion, is the extra RAM space taken up by the I/O registers and the loss of a bit of global variable space (if using SX/B). In my own projects, I generally tend to let SX/B handle all TRIS I/O and memory assignments (either through VAR, array or @var) to make it easier. Then with the proper macros, I can run the same assembly code libraries on either device without editing.

mike p · 2010-12-27 22:52

Zoot: Thanks for the prompt response. I did notice from the SX48 RAM block diagram that FSR 7 was my responsibility. Your macro solution is very handy. Great also is your advice about having SX/B handle the appropriate foundational stuff. The ability to easily mix and match SX/B and assembly is an amazing feature of the Parallax SX/B platform. The relatively fast performance of the SX/B (compiled) code makes it so useful as both a starting point and in the finished code.

After reading Zoot's reply, I noticed the "Similar Threads" section below the posting section. I guess this is an automated "search" function performed on posts (I'll check it right away next time). Although only 1 of the 5 suggestions was relevant ("sx28 to sx48 code compatibility"), it was very helpful. I found it interesting that the "one picture is a 1000 words" principle applied to that post. The indirect addressing (access via register INDF $00) issue is (in my opinion) easily discovered and understood via the SX48 RAM block diagram (found on page 27 of SX Users Manual Rev. 3.1, and on page 19 of SX48BD-Data-v1.5.pdf). That block diagram also made me aware of the FSR bit 7 issue. Other comments by Bean in that post revealed some subtle differences between the sx28/48 (eg the Mode register -- no doubt why Zoot suggested using SX/B for this stuff).

If anyone can add anything further beyond the items mentioned above, please do. Thanks again.

SX 28 48 code cross-compatibility

Comments