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