question 1: This is the original reset handler that is in the startup file (*.s)
Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT __main LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP
which i modify to
Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT OSInit IMPORT __main LDR R0, =SystemInit BLX R0 LDR R0, =OSInit BLX R0 LDR R0, =__main BX R0 ENDP
Here the OSInit is a function. This works fine.
But when i modify the original to following, I get a hard fault.
Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT main IMPORT OSInit LDR R0, =SystemInit BLX R0 LDR R0, =main BLX R0 ;getting hardfault here LDR R0, =OSInit BX R0 ENDP
Irrespective of whether the OSInit is a function or a task, i get Hardfault.
question 2: does the '__' (two underscores) before 'main' have any significance. Because when i write __OSInit, the compiler is unable to locate OSInit function (Error L6218E: undefined symbol). but for '__main' the function name is always 'main' and compiler locates it.
I am thinking of initializing os_sys_init from main() and initializing all the tasks from the master task. Then call 'app_entry()' at the end of main(). Create a *.lib file and add the *.lib in the projects that my colleagues can use.
They can now add the *.lib files and start building the code from the app_entry() function which they can define in their projects. So instead of starting from main() the entry point will be app_entry().
I am clocking the controller to 100MHz, which may be quite enough for my application. Dont have to run LCD on the board currently (not in this version of the product atleast. a dedicated controller handles the LCD display and touch screen). Hence, i think that the other peripherals will operate smoothly.
I may not go on with porting uCLinux right now. Linux is a total NO NO for the project. But ya, that becomes my hobby project.
Also want to learn uCLinux structure and try to implement some good features of linux on RTOS, which is what i am trying to achieve (hence the whole discussion).
My understanding:
The response time of OS is fast enough for human beings. The response time of RTOS is fast enough for machines.
But you did not mention anything about your Real Time requirement.What details do i have to mention?
You only mentioned that you want your device to behave like a Personal Computer or Smart Phone. But you did not mention anything about your Real Time requirement. Linux is an OS, not a RTOS. Linux kernel is only one part of the OS.
-> Like for example, an application on my mobile-phone has a new update. the application gets updated without switching off the phone or for that matter even the application. <-
To achieve the above goal, I guess that you would need quite a lot of external RAM for Cortex-M3/M4. Once you have that much external RAM, uClinux is good for you.
Per, Tamir, John, Andrew, Marcelle, Hans-Bernhard Thank you guys. The discussion was really awesome. :)
Marcelle, you got it correct. ...the OP has little real understaning of the C runtime startup sequence. If he learns about this he might find out what he can meaningfully do.Request all of you to give reference of good technical material, in case you know any (i m googling it already in the adjacent tab but your recommendations are priority).
Per, It is after this discussion, i came to know about the __main, scatter file, CRTL, etc. The idea _could_ have been better if you had owned the source code for the CRTL + the OS, allowing you to redesign the code for the changed use case. Is there any way to get source for CRTL + the OS? Would prefer the free one.
John, question, my thought is: Yes, and not only the procedures, but also the source code.where and How can i get the source code?
And you won't manage to fulfill that wish if you don't know exactly how that car works.
You obviously think you're smart by posting such a statement, but your extension to the comparison of the startup code to a complete car is just rediculous. There are many changes that can be made to a car without having to know exactly how that car works. An engine can be moved without, for example, knowing the intricacies of how the ECM works. I personally know mechanics who have done such tasks without knowing how the "black boxes" work and their results have been sweet.
What IS important is understanding the intricasies of the area involved and the associated components that might be affected.
Here, it is fairly clear to me that the OP has little real understaning of the C runtime startup sequence. If he learns about this he might find out what he can meaningfully do.
But the altering the designs is also allowed.
Allowed, sure. But it also requires knowing very well what that design actually is --- you have to know every detail of every assumption that went into designing all aspects of the design that you're trying to alter. Otherwise you'll just fail. Badly.
so i just want to shift engine behind. And you won't manage to fulfill that wish if you don't know exactly how that car works.
it must allow initialisation of os before we call main. no?
No.
If you change the foundations the code was written based on, then you need to modify the code to make it compatible.
You don't have the code? Then that should be an indication that you are running in the wrong direction. Other people aren't stuck with this issue because they aren't fighting with wind mills.
You have gotten a bad idea in your head. The idea will not be good because you invest more time on it. The idea _could_ have been better if you had owned the source code for the CRTL + the OS, allowing you to redesign the code for the changed use case.
Yes, cars can have the engine back. But they are normally designed from the start to have the engine at the back.
You don't take an Opel from the street and just move the engine to the back. You'll have lots of very interesting problems to solve. And you'll have lots of interesting paperwork to handle.
Your current idea is like taking a three-story building and splitting it up and then reconnect the pieces again so the bottom floor is now on the top, and the top floor is on the bottom. Most other people would instead just move between the top and bottom apartments without trying to rip the building to pieces.
main is just a name for the tool. it must allow initialisation of os before we call main. no?
It can do nothing to disallow it. However, you must appreciate what __main does. One task is to initialise memory and the data it is expected to hold. It sets up the C runtime environment prior to main being called. A lot of the RTX is written in C. It makes use of the C facilities. You seem to be suggesting, therefore, that C should be used before the C runtime is actually permitted.
Agreed, that there must be some assumptions. But the altering the designs is also allowed. Like there are cars with engine behind the drivers seat. so i just want to shift engine behind.
i have a start up file in which SystemInit function is not called from asm.
Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main LDR R0, =__main BX R0 ENDP
the asm only has __main. and then, i borrowed this new file from cmsis library where it has SystemInit function called from the asm code.
Your fault is that you don't realize that main() can be the function that initializes the OS. And that main() can then call funny_end_user_stupid_main_run_only_after_os_initialized_for_thread_1() and another_funny_end_user_main_run_only_after_os_initialized_for_thread_2().
As long as your goal is to put the donkey behind the wagon, you are going to have huge issues. The world works much better if you try to follow the normal path instead of going against the stream. Especially since you don't really have anything to gain by mucking up the startup sequence.
Why assumptions?
Because you can't design _anything_ without making assumptions.
What assumptions did a car manufacturer base the design on? - that people can buy gasoline? - that there exists tire companies? - that a human will sit with the legs down and the arms on the steering wheel? - that the customers will value safety and expect safety belt, air bags, impact zones, ... - that the customer would be angry if the noise levels did give loss of hearing. - that a normal road doesn't have holes larger than a certain size. - what size to expect for a normal parking space.
There are always assumptions.
Some are so obvious that you don't document them. S the car is designed for humans of "normal" size. The manufacturer leaves it up to people who are 270 cm long or weights 340 kg to check if they will fit.
Some are non-obvious and needs to be documented. So you get a document that tells the maximum weight you may transport with the car. And which specific fuel it can run on.
For majority of code written, the code is written under the assumption that someone else have already set up the processor stack. And all global variables have been given their intended start values.
If you play with the startup file, then you invalidate these design decisions, and ends up with a non-working program.
@Tamir The link is informative. as i said, i just want to alter the way. I definitely dont want to disturb the scatter file.
Dont we have any method by which, we can bring the code to main() after initialization of RTOS
as per my understanding, __main has some piece of code which copies non-root ro & rw regions, etc and at the end calls main(). so want to call os_sys_init jus before main or the other way, execute some piece of code (initialisation code in the same way as SystemInit is done in asm code) and then call os_sys_init and finally the main function.
like, in desktop pcs. Boot up, POST, then kernel is loaded and then windows starts up. Now the user is free to do as he wishes. he can also execute his own codes, other programmer codes etc.
will i have to read the procedure in which the os are booted up and try to do the same thing on my embedded board?
View all questions in Keil forum