We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Dear all, My project using code banking. I have a table that store in CODE memory(BANK1(?CO?MENUROOT(0x2000))). And my program in many Banks(Bank1, Bank2, Bank3......) reference to this table. But only program in bank1 can get the correct table value. Because a lot of reasons, I have to seperate these programs into different banks. And I don't want to create many copy of this table in defferent name to put them in each bank. How can I solve this problem? Thank you. Ovid.
"The hardware chip cost down is always the first priority." Have you actually looked at currently available ARM-based chips? Some are at comparable prices to 8051-based chips and, with plenty of on-chip Flash, you could do away with all the extra cost of separate flash, decoding, and banking hardware! So the "chip cost" might actually be cheaper! "The software group should find the best way and work overtime to solve it" One reason for not moving to a different processor is often the learning curve - but is it better to break your neck trying to get code banking working, or to spend the effort on getting to know a new chip? Your call.
Have you actually looked at currently available ARM-based chips? Some are at comparable prices to 8051-based chips and, with plenty of on-chip Flash, you could do away with all the extra cost of separate flash, decoding, and banking hardware! So the "chip cost" might actually be cheaper! Agreed. ARM-derivatives are _very_ competitively priced, as are some other families of MCUs. Switching chips in this case could very well end up saving hardware costs and development costs at the same time.
"The decision should not be a culture thing but based on economics...." Working overtime is not a cost to my company. "If you can _map_ the table to xdata memory space somehow, no extra xdata memory is necessary." How to do it? My entire program is in nand flash, It will be fetch into onchip ram(only 16k bytes), and execute. "Have you tried compressing the table somehow ? " The user interface script is also a table. If I have to decompress the table, the user may feel not so fluent. "You'll probably have to code everything yourself, though." There is no time for me to develope this tool and debug。:) "Will it work? Quite probably...." It seems on the margin. "Have you actually looked at currently available ARM-based chips?" My company develope our own IP, we don't have the ARM-based chips IP now.
"My entire program is in nand flash, It will be fetch into onchip ram(only 16k bytes), and execute." Why is everyone suddenly trying to do paged virtual memory on 8051s??!! http://www.keil.com/forum/docs/thread7519.asp
"Why is everyone suddenly trying to do paged virtual memory on 8051s??!!" Cost down issue。Why not?
Working overtime is not a cost to my company. Working extra weeks or months is going to cost something. Unless you work for free. And even if you do work for free, all the time spent is going to rack up costs elsewhere. You said you don't have time to develop and debug the software solution ? If your hours do not cost the company anything, then why is it a problem ? Mapping memory: How to do it? This depends on your hardware. You will probably not get a satisfactory answer unless you disclose more of your hardware design, which would probably not be in your best interest. Read the datasheet/documentation of the '51 you are using, especially the parts about memory organization. It should contain some information on how to connect external data memory to the thing. Then figure out how to make data that is in your already present external memory also appear in the processors xdata memory space.
"Working extra weeks or months is going to cost something" Yes, you are right.
Why is everyone suddenly trying to do paged virtual memory on 8051s??!! 'cause it's what you do today. Doesn't matter if you're using yesterdays hardware. The '51 is not Burger King. You don't have it your way. You have a '51, and if you don't like it, use a different chip.
My entire program is in nand flash, It will be fetch into onchip ram(only 16k bytes), and execute. That sounds like something I have missed "execute from onchip RAM" which chip is that that can do that? There is no time for me to develope this tool and debug。 the hang it up. How do you expect to do anything if you do not have the time to do it? Working overtime is not a cost to my company. Oh yes, it is. The craizest "little glitches" and "unfixable bugs" I have seen has come from excessive overtime groups. Erik
My entire program is in nand flash, It will be fetch into onchip ram(only 16k bytes), and execute. That sounds like something I have missed "execute from onchip RAM" which chip is that? "There is no time for me to develope this tool and debug。 the hang it up. How do you expect to do anything if you do not have the time to do it? Working overtime is not a cost to my company. Oh yes, it is. The craizest reasons I have seen for "little glitches" has come from excessive overtime groups. Erik
I wondered: "Why is everyone suddenly trying to do paged virtual memory on 8051s??!!" ovid sheu replied: "Cost down issue. Why not?" The storage itself might be "cheap" per bit but look at all the other costs you're having to incur to make it work! DRAM is far cheaper per bit than SRAM - so why aren't you using DRAM?? Low cost is one thing - but you also have to make sure that it is suitable for the application! A bicycle would be a very cheap way to travel around the world, but that doesn't make it practical for the purpose!
"Why is everyone suddenly trying to do paged virtual memory on 8051s??!!" Cost down issue。Why not? Because it is uttely STUPID. How does virtual memory save cost over e.g. banking. You can get 2 Mbyte of fast enough for code memory flash for $2 or less. I would like to know what device that, together with the cost of code RAM required for "virtual" comes out cheaper. NO, this is NOT a "Cost down issue" it is a "I am going to show how smart I am" issue. That this just makes you look dumb, you eveidently have not realized. Erik
ARM-derivatives are _very_ competitively priced Maybe as discrete ICs. But not as cores for integration into an ASIC. Decent 8051 cores are available that are literally free of both NRE and royalty charges. ARMs are not. And even an ARM7 is about 15 times the die area of an 8051, around 150,000 gates instead of 10,000. This is a noticeable proportion of even a fairly big and complicated chip. There are sometimes reasons to execute out of RAM. I don't know of any commonly available flash with less than about 70ns access time. I have a project that happens to be clocked at 62.5 MHz, or 32ns access time for a program store fetch. Flash isn't fast enough; we have to execute out of SRAM. As it happens, this also lets us get away with loading from a serial flash, which saves us a lot of cost, board area and layers, and pins, which in turn lets us squeeze into a cheaper package. Executing directly out of flash would add a lot of cost, direct and indirect, in this particular case. Volumes are in millions, so even tiny cost savings can buy you a lot of engineering time. In contrast, I once had a project that was a one-off implementation to control some machinery. A volume of 1 has exactly the opposite economics. Development time will swamp the production cost. On the main topic: if the OP's system copies code from flash to RAM, and executes out of RAM, then presumably the entire RAM space is mapped into the xdata address space. Otherwise, how would it be writeable at all? In that case, the "code memory" table is already located in xdata. No extra memory would be required. Just translate the code address to the xdata address.
Working overtime is not a cost to my company. It will be if it turns out that you need infinitely much of it, literally, i.e. never finish it, because the hardware you chose plain and simply isn't able to get your job done. Throwing more software at a task is not a universal cure. There are problems it simply won't solve. How to do it? My entire program is in nand flash, It will be fetch into onchip ram(only 16k bytes), and execute. Sorry to rain your parade, but that decision was rather obviously a bad one. You'll have to revisit that. 16 KB of real code space apparently isn't enough for what you're trying to do. Nothing will fundamentally change that.
In the end if you are going to try. Lets say the common area is 8K. then you will need 14banks of 8K each. In the banking code you will have to copy the new 8K from NAND flash to ram. I assume you have some hardware assist. If not I hope your IP core is a single clock one. 8K is kind of small for a bank so group your code wisely.