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.
"Isn't that just the same as having the table in the common bank?!" Ans: Not exactly the same. I can put the most frequently used and real time issue subroutines in common area. "What about copying the table to XDATA, or mapping it to XDATA, as mentioned earlier?" Ans: Unfortunately, base on cost issue, there is always no extra XDATA memory for a firmware programmer。:) Thank you A.W. Neil。 I will take OO-style。 In order to reduce switching frequency, I will fine tune whitch subroutine should place in whitch bank. Now, I read the calling tree, and rearrange thousands of subroutine. It is really a hard work, and waste time。Do you know is there a better way or software can do this job？ Ovid.
"It is really a hard work, and waste time ... is there a better way?" Code banking is always a bodge - you have too much code for an 8031, but you're still trying to cram it into an 8031! You need to balance the costs of banking - both in runtime overheads, and development and maintenance headaches - against the consts of switching to a processor better suited to the size of code that you have.
A.W. Neil, We(your company and my company) have different culture. The hardware chip cost down is always the first priority. Development and maintenance headaches...... The software group should find the best way and work overtime to solve it。 Thank you for your suggestion. Ovid.
The hardware chip cost down is always the first priority.<p> The decision should not be a "culture" thing but based on economics. If you're planning to build at most X units of a product, and you spend Y as development costs lower the cost of the hardware by Z, and you know that X*Z<y, and you do it anyway, then you should either have a darn good reason to do it ("culture" doesn't cut the mustard), or you're essentially deliberately and knowingly wasting money. there is a certain point at which development and expected support costs will exceed the savings of less expensive hardware. make sure you realize when you are approaching this point. < i>Unfortunately, base on cost issue, there is always no extra XDATA memory for a firmware programmer. If you can _map_ the table to xdata memory space somehow, no extra xdata memory is necessary. Have you tried compressing the table somehow ? For certain kinds of tables this can reduce the size by quite a bit (even if simple difference encoding is used), and you can trade cpu cycles for memory this way. Do you know is there a better way or software can do this job You can certainly do it in software. Somehow. You'll probably have to code everything yourself, though. Will it work? Quite probably. Will it be fast enough? Don't know, depends on your project. I would guess not. Will it be a royal pain in the neck to code and to maintain? Very likely.
"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