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
"Am I?" Yes. He's not going to ask whether he can clock a 12MHz chip at 50MHz. That would be a stupid question. As it happens, the derivative he's using can be clocked at 40MHz. "with "RTOS, code banking, floating point and whatever" he will need better than 12MHz to get the result in "less than an hour"." You don't know anything about the OP's project. He may well be able to achieve what he wants to do at 12MHz.
"True, but it may well be that an alternative processor would do it all very much more easily - and, therefore, very much more economically." Ok, but conversely the 8051 may be able to do the job without difficulty and therefore just as economically as the alternative. I assume you mean 'economically' in terms of development time?
"Once I were too lazy to go get a hammer when I needed to put up a picture, so I hammered the nail in with my shoe. So, since the nail is in "the resulting system did what it was required to do". Now, unfortunately, because of my poor choice of tool, my shoe broke but "the resulting system does what it is required to do"." Your analogy is amusing but irrelevant. Shoes may well break when used to hammer nails, software tools do not even when used in an inappropriate situation. "Had i used a hammer, the nail would have been in in less than half the time." Not when you consider the time to go and find the hammer then learn how to use it, which is what the OP will have to do.
"Well as Mr.Stefan Duncansan, said, if i am satisfied with the 8051, and the RTOS for my application, why is it that i need to look for higher performance processor or RTOS..." Exactly, you don't need to. "any way, kindly if anyone could throw some light on my initial query.." Unfortunately I don't know anything about RTX.
"Well, it is a Discussion forum - not just a free answer shop...! ;-)" Yes, but you can understand the OP's frustration when he sees his thread hijacked by a bunch of people telling him his mission is hopeless instead of answering the question. 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
"I assume you mean 'economically' in terms of development time?" No - not just development time: "Code Banking will impact your entire product lifecycle - Design, implementation, Test/Debug, and support/maintenance. All will be affected by having to consider the 'quirks' of code banking. Even your hardware cost may be increased, due to the extra stuff to do the bank switching."
"1) Code banking" Not on an 8051 project - not even with the Triscend E5 (now Zylogic ZE5), where the physical bank switching is trivial. I've suffered a banked project on another 8-bit processor, so I know the pain of trying to decide what goes in the "root" bank, and finding that you want to call function X - but it's in another bank, and a bankswitch at this point is really bad, and having to faff about with the HEX files to program your PROMs properly, and... Code banking is a kludge to overcome the fundamental design restriction in the 8051's address space - just like Expanded Memory was a kludge to overcome the fundamental design restriction in MS-DOS's address space. I can't see why you would want to start a project by designing-in a kludge! "2) Floating point" Never without the aid of a numerical co-processor. "3) RTX" Never on an 8051. Not even with a TCP/IP stack. I've done plenty of RTOS projects with "bigger" processors. 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. I've done RTOS projects on other 8-bit micros, and I can't say that the extra grief of working with the RTOS was any benefit over not having an RTOS.
""1) Code banking" Not on an 8051 project" ""2) Floating point" Never without the aid of a numerical co-processor." ""3) RTX" Never on an 8051." You see, this is the thing that gets me down. You are advising the OP not to use these things with little or no information about his project and no experience of using them yourself in the context of the 8051/Keil toolchain. I see that you do have experience of RTOS and code banking on other 8 bit devices, and I'm not surprised that the experience wasn't particularly enjoyable. However, neither of us has experience of the Keil implementations of these things so I don't think it's reasonable to just rule them out, especially without knowing any details of the project they're being used on. I have never used RTOS/code banking with an 8 bit processor and probably never will for a variety or reasons. However, I can see that there may be some applications where speed or timing are not issues in which case these may be perfectly reasonable to use. I do use floating point - lots of it, in most of my projects. The 8051 suits my applications very well and I have no timing issues with the maths. So, in my case, the 8051 is the right processor, the fact that it is not 'suited' to floating point is irrelevant.
"I don't think it's reasonable to just rule them out" I never ruled them out - just posed the question, "is this really a job for an 8051??"
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