| ??? 01/20/09 09:41 Read: times |
#161630 - in the end Responding to: ???'s previous message |
Hello again :-)
i´m kind of surprised that you answer so quickly, but of course, i appreciate that. Thanks ;-) I can certainly understand the perception that using external memory space will be simpler because it is "out of the way" of other functions. - That was one of a kind, but not the main reason. We just wanted to see, if we could easily connect some kind of periphery at our core. Something like LEGO :-P Get a new stone and change it with another, which is sticked at our XRAM lines. Sorry, can´t explain it better :-P 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. - You´re totally right with that. Point. Our way were much more difficult and not the best. 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. - You´re right again, but what would you do, if you got a prof in the back, who decides about your future and wants to program in HLL? ;-) For us, it would be a lot easier to program assembler, no question. 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. - OK, back to the beginning of our question/discussion :-) we KNOW that we have to enable the external RAM to get data through our XRAM lines. But we don´t know how our core activate the signal "ext_ram_en" to "1". It will only be activated, if the width of our Adressbus will be between 1 and 15 bit. Otherwise it will be set to "0". My problem with this condition is, that the internal RAM is only an 8 bit RAM. The external could be up to 16 bit. So the condition make no sense in that kind of form to me. Our idea was, to compare all the time the value of the bus with an baseadress of our CAN (0x8000). We implemented this in Hardware/Vhdl. But with the condition, i posted a few sentence before, we will never get the data of the adressbus right? Because the XRAM will never be enabled if we use 16 bit adresslines. Do you understand what i mean? But besides that, we will use SFRs now. Nevertheless, i would be interested where we did the mistake or where we got something wrong. |
