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
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. It has been my experience that using the right tool for the right job is usually the best practice. I have worked on a project where the original designer spent weeks writing work-arounds to avoid using an RTOS (on an 8051). After one month he had a system that barely worked. There was still about 3 weeks of development left to do. The project was handed to me to finish (because, after all, it was almost finished). After an audit of what I had, I determined that the system, as designed, would not work. So, I tossed the design, and used an RTOS (RTX51 Tiny) and got the whole thing finished in about 1 week. There is a time and a place for each tool. RTOS, floating-point, and code banking are just more tools in the toolbox from which to choose. Jon
"Au contraire, I have had to remove it from a failed project to make it run." Indeed. But the fact remains that you haven't used these things yourself?
Indeed. But the fact remains that you haven't used these things yourself? OK, to clarify: The taks was to make the thing work, not "remove stuff" so: After several weeks of trying to get the darn thing to run with the above in place I converted floating point to fixed and almost got it to go. Then after several more weeks i removed the RTX. So, yes, I have "used" them and tried to make it work. There is ONE exception to my statements: if you are trying to use the '51 for comething it is not intended for you are just adding one wrong to another and that may not aggrevate the result There is a time and a place for each tool. RTOS, floating-point, and code banking are just more tools in the toolbox from which to choose. I do not think that Andy and I would have reacted as strongly had it been a tool. I do appreciate that Keil must provide all things to all customers and thus it is "possible" to use malloc with RTX and floating point. Does that make the '51 the right choice for that application? I doubt it. as said before "the '51 PC" may have been realistic when more powerful processors were an order of magnitude more expensive. Erik
"So, yes, I have "used" them and tried to make it work." You've used them in the context of taking over someone else's abandoned project. That's hardly a fair trial! In any case, it sounds as if an RTOS *was* the wrong tool for that particular project. "I do appreciate that Keil must provide all things to all customers and thus it is "possible" to use malloc with RTX and floating point. Does that make the '51 the right choice for that application? I doubt it." The point that you seem to be missing is that it doesn't necessarily make it the wrong choice. "as said before "the '51 PC" may have been realistic when more powerful processors were an order of magnitude more expensive." If you don't need a more powerful processor there's no benefit in using one. A more powerful processor is also likely to consume more power which for many applications is a problem.
If you don't need a more powerful processor there's no benefit in using one. A more powerful processor is also likely to consume more power which for many applications is a problem. Timing - Timing - Timing what about it? When you overload the poor little bugger, suddenly your serial int does not get processed in time and a fuse blows because you do not get a port pin pulled low fast enough. Of course if you suffer from the misconception that the '51 is a microprocessor rather than a microprocessor, all your wrong statemnts will be right if that premise is accepted. Erik
If you don't need a more powerful processor there's no benefit in using one. A more powerful processor is also likely to consume more power which for many applications is a problem. Timing - Timing - Timing what about it? When you overload the poor little bugger, suddenly your serial int does not get processed in ti,e and a fuse blows because you do not get a port pin pulled low fast enough. Of course if you suffer from tyhe misconception that the '51 is a microprocessor rather than a microcontroller, all your wrong statements will be right if that premise is accepted. Erik BTW re the statement about power consumption; for some reason '51s whatever the derivative are anything but power misers.
"Timing - Timing - Timing what about it? When you overload the poor little bugger, suddenly your serial int does not get processed in ti,e" How do you figure that? Interrupts interrupt the normal flow of program execution. It doesn't matter what the foreground process is doing. But once again you seem to think that using certain tools or facilities will inevitably 'overload' the 8051. I keep trying to explain to you that this is not a Universal Truth. You may believe it, but you are wrong. "and a fuse blows because you do not get a port pin pulled low fast enough." You design circuits with the 8051 that blow fuses when port pins are high? Time for another look at the drawing board, I think. "Of course if you suffer from tyhe misconception that the '51 is a microprocessor rather than a microcontroller, all your wrong statements will be right if that premise is accepted." I don't really get this. You're saying I'm right if I call the thing by a different name? "BTW re the statement about power consumption; for some reason '51s whatever the derivative are anything but power misers." However, I take it that you can see some sort of link between more powerful processors and increased power consumption?
"Of course if you suffer from the misconception that the '51 is a microprocessor rather than a microcontroller, all your wrong statements will be right if that premise is accepted." I don't really get this. You're saying I'm right if I call the thing by a different name? A microprocessor is a numbercruncher that should react in less than a second, a microcontroller is a device that shall react NOW. If you want to mislabel the '51 as a microprocessor (which it aint) you can state all kinds of things from that premise.
"you seem to think that using certain tools or facilities will inevitably 'overload' the 8051." 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! The real benefit of an RTOS really comes with larger systems, when the limitations of a simple "main loop" start to get in the way; so, as I said earlier, "if you've decided that a 'small' controller like an 8051 is suitable for your project, I can't really see why you should then need to use an RTOS."
amen
so, as I said earlier, "if you've decided that a 'small' controller like an 8051 is suitable for your project, I can't really see why you should then need to use an RTOS." Here are a few reasons... 1. The RTOS solves a problem that you can't or don't want to code (possibly incorrectly) my way around. 2. You will save development time that you can put to better use elsewhere. 3. The MCU has enough horsepower to run the RTOS and your application. 4. The complexity of the 8051 (with an RTOS) is simpler than some other architecture. 5. You have experience with the 8051 and RTOS. All of these sound like pretty good reasons to me. Jon
"All of these sound like pretty good reasons to me." Well, potentially good reasons...! ;-) <cynic>But you would say that - you've got an RTOS to sell...!</cynic> ;-) I didn't say it's impossible - just seems pretty improbable to me.
"A microprocessor is a numbercruncher that should react in less than a second, a microcontroller is a device that shall react NOW." 97.3% of statistics are made up on the spot. 98.2% of definitions of the words 'microcontroller' and 'microprocessor' also appear to be made up on the spot. One thing that neither a microprocessor or microcontroller can do is respond "NOW". I assume you're familiar with interrupt latency? "If you want to mislabel the '51 as a microprocessor (which it aint) you can state all kinds of things from that premise." I'm not really interested in labelling it as either as the distinction between the two has become hopelessly blurred.
"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'? "if you've decided that a 'small' controller like an 8051 is suitable for your project, I can't really see why you should then need to use an RTOS." You may not *need* to use an RTOS. Using one, however, may be a convenient and effective way of coding a given application.