| ??? 01/20/09 16:01 Read: times |
#161646 - It doesn't always work in that way Responding to: ???'s previous message |
Christian Meier said:
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 Have you simulated the T51 core without your CAN controller? 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. I do understand that you must meet your assigned requirements. You can, of course, write those low-level functions that communicate directly with the CAN controller in ASM and invoke them from 'C'. 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 base address 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? Back to the simulations ... have you attempted to access external memory at all, i.e, have you executed MOVX instructions under control of the simulator? How does the "ext_ram_en" signal behave? But besides that, we will use SFRs now. Nevertheless, I would be interested where we did the mistake or where we got something wrong. I would recommend that you attempt a T51 simulation that uses external memory, if for no reason other than to verify that the core functions properly. This means that you should probably verify that it works with external program memory as well as with external data memory. The T8051.VHD module defines and also uses the "ext_ram_en" signal. I haven't looked at this version of the core for years, but I suspect you'll find the issue that has you "stuck" within that module. RE |
