Hi all, In RTX we can assign a function as a task with the _task_ #NO tag. When calling os_create_task we just pass this task number as a parameter. Assume one has to use banking, in this case, how does RTX identify, in which bank the function exists ? from where does rtx get information about the banks of any task at runtime ? regards pachu
To cut the long story short - if the code banking is enabled in RXTSETUP.INC file, RTX51 will also save the current bank switch when changing context - so the next time it has to restore it, the correct bank address will be restored too... regards Dejan
I'm curious, Mr. Neil and Mr. Malund, please tell us which of these things you have used in an 8051 project: 1) Code banking 2) Floating point 3) RTX Au contraire, I have had to remove it from a failed project to make it run. Removing the RTX and the floating point made the code banking superfluous and, lo and behold, aftre doing the above, the project started behaving as required. Erik
OOPS "But there is no point in using code banking unless you've exceeded the 8051's address space - so that is inherently an "overload" of sorts!" Do you consider using more that 64k of NV xdata storage an 'overload'? Nobody said anything about data exceeding 64k. I have such, but access it by other means than Keils "banking" with associated overhead Erik
I think the point is that more powerful processors may still be an order of magnitude more expensive if you're not talking about some ultra-high-volume consumer electronics producth Digi-key sell Philips ARM processors at qty 1 priced $6 and up Erik
"Nobody said anything about data exceeding 64k." Er, yes *I* did. I was drawing a parallel between using more code space than the 8051 was designed to address and more xdata space that the 8051 was designed to address. "I have such, but access it by other means than Keils "banking" with associated overhead" You cannot access more than 64k of xdata without *some* overhead. The 8051 is not designed to address more than 64k. According to your philosophy you have used the wrong microprocessor for the job.
Digi-key sell Philips ARM processors at qty 1 priced $6 and up You've missed my point. Even if the more powerful processors sell for HALF the price of the 8051, you can't amortize out the extra development time for learning the architecture unless you sell ALOT of products. For instance, take the following math: Digi-Key 87C51FB33 @ qty. 1 = $7.76 Digi-Key ARM @ qty. 1 = $6.00 (I don't know ARM stuff, so I'll use your number) Now assume (since the OP wants to use an RTOS) that this is at least a moderately complex project. Assume that it will take 1000Hrs of programming time for the 8051 architecture with which the OP is familiar. Also assume that the RTOS price for both ARM and 8051 is the same (which might not be true). Also, we'll assume that the OP is a dynamite embedded systems guy and will suffer only a 10% degradation in efficiency switching to a new processor which means that it will take him 1100 Hrs. to complete the project with ARM. Let's just pick some reasonable billing rate for an embedded system engineer (I guess $50/Hr is likely low, but I'll be generous for my purposes here). Then, if we assume that the entire system is the same except for the processor selected and compare only incremental costs, we have this: 8051 Cost = (1000 * $50) + ($7.76 / unit) ARM Cost = (1100 * $50) + ($6 / unit) So, a break even analysis is as follows: (1000*50)+(7.76*units) = (1100*50)+(6*units) which yields units=2840 SO if all of these assumptions are correct (and I think they're reasonable), and even if we assume that the ARM cost is $1.76 less than the cost of the 8051, the 8051 makes the most money for the developers company unless he plans to sell more than 2,840 units over the product life-cycle.
You cannot access more than 64k of xdata without *some* overhead. The 8051 is not designed to address more than 64k. According to your philosophy you have used the wrong microprocessor for the job. No, I have not - even by my own philosophy. I only need access to about 25 bytes of the >64k data about once an hour. The reason that I do not use banking with its overhead is that the rest of the time I run "true '51" aka hauling @$$. Had I needed that data more often I would not have used a '51 derivative. Erik
You've missed my point. Even if the more powerful processors sell for HALF the price of the 8051, you can't amortize out the extra development time for learning the architecture unless you sell ALOT of products. ... Now assume ... that this is at least a moderately complex project. I do not think I have "missed the point". You are right that there will be "extra development time for learning" but that will be balanced with "less time for implementing and debugging" In your above example you did not include time for making things behave in time if a '51 was used, which arguably is one of the most difficult debugging tasks. With a combined complexity of RTOS, banking and floating point on a '51, I consider it highly unlikely that timing problems will not pop up. Erik
I do not think I have "missed the point". Perhaps not now, but you certainly did when I made this inital suggestion and you kindly quoted me a Digi-Key price for an ARM processor. You are right that there will be "extra development time for learning" but that will be balanced with "less time for implementing and debugging" The notion that implementation and debugging on a completely new architecture will be faster than a more concerted effort on a known processor is dubious as best. I'll run with it for you though. In your above example you did not include time for making things behave in time if a '51 was used, which arguably is one of the most difficult debugging tasks. A bit more math: Assume that debugging will be a horrendous chore on the 8051 and he'll have to use a whopping 100Hrs after the project's been "finished" to debug it and get things working. We'll also assume that by some miracle due to the ease-of-use in the new processor, he'll be TWICE as efficient at debugging and it will take only another 50Hrs. 8051 Cost = ((1000 + 100)*50) + (7.76 / unit) ARM Cost = ((1100 + 50)*50) + (6 / unit) This yields a break-even point in unit sales of 1420. Also, keep in mind that this continues to run on the assumption that the ARM processors are actually cheaper than the 8051's for a given quantity. I'm not sure if that's true. The upshot is this: We can keep pulling rather ethereal "efficiency" notions up when it comes to new processors, but eventually someone has to make some hard estimates about times, costs, etc. to make an informed decision. Just basing a choice on a percieved improvement in style is the reason engineers are rarely allowed to make business decisions.
"Even if the more powerful processors sell for HALF the price of the 8051, you can't amortize out the extra development time for learning the architecture unless you sell ALOT of products" This is a good point. However, you also have to consider the savings with the more powerful processor from not having to mess about with code banking. And we know that the code banking is causing extra issues - otherwise the original question would never have arisen!! You're also assuming that the entire cost of learning ARM (or whatever) would have to be amortised over a single project. Considering ARM specifically, I'd consider that an investment rather than a pure cost: I think knowing both ARM and 8051 would be a definite advantage! The 8051 must be the most widely available multi-sourced 8-bit architecture; and I think ARM must have a similar position for 32-bits. Definitely a powerful combination.
"No, I have not - even by my own philosophy." I think you have. It seems that you are quite happy to make sweeping generalisations to others along the lines of 'You must not do X because the 8051 is not the right processor for use with tool x or technique y or algorithm z', but you make an exception for yourself. I only need access to about 25 bytes of the >64k data about once an hour. "The reason that I do not use banking with its overhead is that the rest of the time I run "true '51" aka hauling @$$. Had I needed that data more often I would not have used a '51 derivative." So you're pushing it that close to the wire? Sounds like you should have used a faster processor. ""true '51" aka hauling @$$" Why do you have this idea that the 8051 is only 'true' when it is 'hauling @$$'?
"However, you also have to consider the savings with the more powerful processor from not having to mess about with code banking. And we know that the code banking is causing extra issues - otherwise the original question would never have arisen!!" I'll bet I'd be fully au fait with code banking in a fraction of the time it would take me to be up to speed on ARM or similar. "You're also assuming that the entire cost of learning ARM (or whatever) would have to be amortised over a single project." If it isn't I wouldn't be too happy to be the customer. 'Here's your product - with a bit of luck I'll know more about the architecture next time I have a go with one of those ARM things. Good luck.'
Considering ARM specifically, I'd consider that an investment rather than a pure cost: I think knowing both ARM and 8051 would be a definite advantage! The 8051 must be the most widely available multi-sourced 8-bit architecture; and I think ARM must have a similar position for 32-bits. Definitely a powerful combination. I certainly won't disagree with you there, but I just hate the way this forum ALWAYS turns into a pedantic rant about "The Right Way" to do things. I've seen too many threads to count that go (by your analogy) something like this: OP: How do I do X with the 8051? Someone else: Why not make an investment in your company and learn something new? I highly doubt anyone has come to this forum looking for business advice. Can't we just run on the assumption that unless someone's question puts them across as a complete novice that they know what they're talking about in general and that good decisions have led them to the point where they simply need to overcome some hurdle or another?
"but I just hate the way this forum ALWAYS turns into a pedantic rant about "The Right Way" to do things" I'm relieved that I'm not alone. Some contributors seem unable to understand that there are pros and cons to different solutions to a problem. Those pros and cons vary depending on the person, his/her experience, his/her location, his/her customer, his/her budget and even his/her personal taste etc. "Can't we just run on the assumption that unless someone's question puts them across as a complete novice that they know what they're talking about in general and that good decisions have led them to the point where they simply need to overcome some hurdle or another?" The problem with this is that anybody who asks a question about something that some of the more opinionated contributors think is a complete no-no, such as an RTOS, is then automatically treated as a complete novice. 'Well, they must be, mustn't they? Stands to reason as only a newbie would consider such a thing'. I wonder if it is obligatory to use an OS and floating point on a 32 bit processor?
Why do you have this idea that the 8051 is only 'true' when it is 'hauling @$$'? Staffan, Staffan, once more: because it has the features of a microcontroller and thus is great as such and pitiful for other things. The fact that you can hammer a nail in with a shoe does not make the shoe the right tool. There is a group of people that want to use "their" controller for whatever the task is (I have seen 386 equipped things that could have been done with a small PIC). How do you know that the OP is not one such? The point is not that it is "wrong" the point is that when the OP will not qualify ("if i am satisfied with the 8051") the use of the '51 for a particular purpose, we must assume that (s)he is applying the '51 to something where it does not belong. Thus to save the OP from spending an inordinate amount of time on something that most likely will fail Andy and I keep questioning the use of a '51. If this forum is to be helpful assumptions about whatever could be wrong for the OP must be refuted by the OP or left standing. You and I do not know that the OPs use of a '51 will ever work so why do you balk at the posts that state so when the OP does not even have the gumption to state why he insist on using a '51. On another note: So you're pushing it that close to the wire? Sounds like you should have used a faster processor. Not having the time to spend 3 more clock cycles for every memory access is hardly "pushing it that close to the wire". By my method, I only have overhead when accessing outside the 64k, and when that is needed, I am in "keyboard mode" Erik
"Some contributors seem unable to understand that there are pros and cons to different solutions to a problem. Those pros and cons vary depending on the person, his/her 1) experience, his/her 2) location, his/her 3) customer, his/her 4) budget and even his/her 5) personal taste etc. 1) Never. (lack of) experience is not an excuse for making something less than optimum. 2) OK, it can be an availaibility issue 3) if the customer insist on the "wrong" processor it is the engineers duty to correct him 4) N/A today 32 bits and 8 bits cost abt the same 5) if that influences, fire him "Can't we just run on the assumption that unless someone's question puts them across as a complete novice that they know what they're talking about in general and that good decisions have led them to the point where they simply need to overcome some hurdle or another?" re assumption: The OP WAS asked Why? and answered "because I want to" which is typical novice behaviour. The problem with this is that anybody who asks a question about something that some of the more opinionated contributors think is a complete no-no, such as an RTOS, is then automatically treated as a complete novice. 'Well, they must be, mustn't they? Stands to reason as only a newbie would consider such a thing'. nobody is treated as a "novice" when they qualify their statements. If you have any experience with todays "novices" you will find that unqualified statements in 98% of the cased means novice. re "more opinionated contributors", is it not "opinionated" to state that the '51 is the right choice for everything like some do? I doubt Andy or i would have anything to say but "I feel for you" if an OP from Farawayistan stated I can not purchase any other processor than a '51 in my country for less than $100 and I need this which will be better with a RTOS. However "becuase I want to from a novice will not result in "great idea, go ahead". Again advisingt novices is not just a matter of how to drive, it is also a matter of where to drive and what gas to buy. I wonder if it is obligatory to use an OS and floating point on a 32 bit processor if I can get around it, I'll not use floating point unless the processor has HW FP. I would think that for most jobs of the size where 32 bits were required an OS would be a good idea. Erik
"Staffan, Staffan, once more: because it has the features of a microcontroller and thus is great as such and pitiful for other things." So you're putting not only your favourite upper limits on what it should be used for (no floating point, code banking and RTOS) but now there is some lower limit as well? What is it, 90% CPU utilisation? 95%? "The fact that you can hammer a nail in with a shoe does not make the shoe the right tool." No, but there are a great many things to be cosidered. This analogy moves us a long way backwards in this discussion. "There is a group of people that want to use "their" controller for whatever the task is (I have seen 386 equipped things that could have been done with a small PIC). How do you know that the OP is not one such?" I don't, but you assume he is. "The point is not that it is "wrong" the point is that when the OP will not qualify ("if i am satisfied with the 8051") the use of the '51 for a particular purpose," Why should the OP qualify his use of an 8051 to you? It would be pointless anyway - you would never accept his reasons. "we must assume that (s)he is applying the '51 to something where it does not belong." You see - there it is again. You assume that the OP must be wrong without any knowledge of his project. "Thus to save the OP from spending an inordinate amount of time on something that most likely will fail Andy and I keep questioning the use of a '51." That's most commendable. "If this forum is to be helpful assumptions about whatever could be wrong for the OP must be refuted by the OP or left standing." What assumptions have you made that he must refute? "You and I do not know that the OPs use of a '51 will ever work so why do you balk at the posts that state so when the OP does not even have the gumption to state why he insist on using a '51." I balk for the reason you have just given: I do not know his application in detail and therefore cannot say whether he is using a suitable processor and suitable tools. Neither can you, so it becomes somewhat irritating to listen to the same tired old record '8051==no RTOS, no floating point and no code banking for reasons that I just can't quite adequately explain in any other way than it is wrong, wrong, and wrong again irrespective of the circumstances'. "Not having the time to spend 3 more clock cycles for every memory access is hardly "pushing it that close to the wire". By my method, I only have overhead when accessing outside the 64k, and when that is needed, I am in "keyboard mode"" I was attempting a little humour.
"If this forum is to be helpful assumptions about whatever could be wrong for the OP must be refuted by the OP or left standing." What assumptions have you made that he must refute? well, that is what this discussion now is about. I was attempting a little humour. sorry, missed that Erik
View all questions in Keil forum