Bootloader: C:0x0000 - C:0x7FFF Manages CAN-Communication and in-field update. Application C:0x8000 - C:0xEFFF Applications is controlled with bootloader over CAN 2.0. Compiled both seperatly and merge the Hex-file. Interrupts and function calls work. At level of 8 successive funtions calls the acces to an struct in Applications XDATA mem is incorrect. The expected pointer is not given. Any adwise?
@Erik: Very nice and smart comments, although you are right. The post I comment on illustrates how blatantly ignorant some are matching the application and the processor. I think one of the biggest challenges in embedded software development is the goal to build cross platform software efficient in size and speed, that is modular and maintainable. You often do not have the choice of the platform and have to make things going. You lucky, seems you lack that experience. I am, honestly getting fed up with those that select the wrong processor for the job and them start whining. I am fed up with people beeing so smart and and having no clue about real life. Its not always your nice little electronic playground in the basement. And if somebody is - like Micheal admitted - still a student who has to deal with this problem he obviously didn't choose, it is really nice helping him out. If you dont want to help him - leave it - but stop nagging around. And by the way, the person whining around is not him! cheerz
"I think one of the biggest challenges in embedded software development is the goal to build cross platform software..." I don't think that is generally a significant goal in embedded development at all! Generally, the task of an embedded system is so closely linked to its specific hardware platform that any effort at making it "portable" is largely pointless! Of course, there are some parts of an embedded system that can benefit from portability - comms protocols is one that springs to mind. "You often do not have the choice of the platform..." See above - the platform will usually have been chosen to be suited to the application. "a student who has to deal with this problem he obviously didn't choose" Is it obvious that he didn't choose it? If he didn't, it is indeed a shame that he's been given an inapproriate target, and/or inadequate guidance in using it; If he did, it is a shame that he's been given inapproriate and/or inadequate guidance in his choice. Oh well, he's probably learned something about selecting an appropriate target byt now...!
"a student who has to deal with this problem he obviously didn't choose" hold your horses, are you saying that somebody else told him to use function pointers? In my response to the "the '51 is a piece of $#!^' post I addressed a number of issues, and I think one thing has been lost: I did not say "what he wants to do can not be done with a '51", I said "what he wants to do can not be done applying PC coding style to a '51". Erik
hold your horses, are you saying that somebody else told him to use function pointers? I'd guess he probably "inherited" the software from someone else. How else could it happen that he already has a really large piece of software and only then finds out that some fairly basic functionality is missing ?
I am, honestly getting fed up with those that select the wrong processor for the job and them start whining. Its not always your nice little electronic playground in the basement. I wish I could have the income I have from my job, in "my nice little electronic playground" That would be luvverly. However, since I work with this 8+ hours a day I do not have a "nice little electronic playground" there are other things in life. And if somebody is - like Micheal admitted - still a student who has to deal with this problem he obviously didn't choose, it is really nice helping him out. If you dont want to help him - leave it - but stop nagging around. I have tried and tried to help him, but what has his response been to my helpful hint "get rid of function pointers"? Erik
I'd guess he probably "inherited" the software from someone else. How else could it happen that he already has a really large piece of software and only then finds out that some fairly basic functionality is missing ? As long as we are guessing, this is not the first time a beginner has written a huge project before even understanding what was going on, usually it is "while waiting for the hardware". Erik
Generally, the task of an embedded system is so closely linked to its specific hardware platform that any effort at making it "portable" is largely pointless! Well said The 'portability thing' is another academic idea that has virtually no practical value for microcontrollers. Where 'portability' may have a value (things like a 'fast approximate square root'), there will be no use of malloc, function pointers etc. and 'portability' is automatic. Now I may be sticking my foot in my mouth, because a 'fast approximate square root' may very well be adapted to a particilar processor/compiler as well and thus not 'portable'. When developing a product to be sold in 9 different versions from 'economy' to 'advanced' I was tasked with developing the 'OS' to allow two different processors run the same code and it turned out that the 'OS' (the 'controller' part) was totally different and the rest (the 'processor' part) was identical source. Which lead to the conclusion that 'portability' for a controler is an illusion and for a processor it makes sense. Erik
"a 'fast approximate square root' may very well be adapted to a particilar processor/compiler as well and thus not 'portable'." Unfortunately, "maximum performance" and "portable" do tend to be mutually exclusive; as the well-known phrase (almost) goes: Cheap, Fast, Portable - Pick one.
Thanks for plenty help. I solved the problem but the next problem trapped me.
Thanks for plenty help. I solved the problem ... Great ! So, what was the solution ?
Executing applications ?C_START when switch from bootloader to application.