Christian,

I can certainly understand the perception that using external memory space will be simpler because it is "out of the way" of other functions. However, if you look at the opportunities that are lost by doing so, primarily in the types of instructions that you can use to manipulate your external-memory-mapped CAN core, as opposed to one that's mapped into SFR-space, which, BTW, I view as "I/O space" for practical reasons, you'll see why I look askance at such an approach.

If you've followed my comments in the past, you'll have noted that I am generally hostile to the use of HLL's, including 'C', for code sets small enough to fit within the space of a typical MCU. For an OS, or any application with 100K-200K, or more, lines of code, well, it's probably appropriate, but at least the low-level functions e.g. "talking" directly to hardware features should be handled in ASM and not ever in any HLL, since timing is often very critical, and seldom predictable in HLL's.

If you really want to use external-memory-space, you certainly can do that. However, you're aware, I guess, that there is only one instructions with only a few modes by means of which you can access external-memory-space. You have more options in SFR-space.

Whether you use external memory or not, an elegant implementation of 805x puts its I/O in SFR-space. After all, the 805x is a poor hardware set with a marvelously ingenious instruction set very well suited for microcontroller tasks. It would be a shame to waste the benefits of the architecture and instruction set for the "convenience" of having the separation between presently internal peripheral hardware and your new CAN core.

I wish you luck, in any case, but I hope you'll consider using the benefits of the existing architecture.

RE