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?
"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'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.