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?
That's not correct. Both Projects compilied together work. When compiling separately, did you tell the linker which RAM areas it may use for each of the projects ?
Thanks Christoph for not giving up! I'm a student at work. Sorry. Telling the linker wich RAM to use for app or bootloader made in linker-script. I thought. Another idea is the initialisation of constant during startup of application. I wrapped the startup-code into c-function
do_cinit()
The possible incapacity of microcontroller is disapointing. Sorry to tell you this, but the '51 is a mix between a dinosaur, a cockroach, and a mule. A dinosaur because it's ancient and outdated and shouldn't be around anymore today. A cockroach because it's prolific and it won't go away. Even if you step on it and flush it down the toilet, it'll just crawl out of the sink again. It'll probably also be around long after you're dead and buried. A mule because it does things its way. If you want it to do anything meaningful, you need to learn what "its way" is, since it won't do anything your way. Look at the instruction set of the '51, it will tell you why the '51 architecture is badly suited for function pointers. If you have the ability to step through the program, you might be able to figure out at which point in the function the pointer becomes corrupted. Most likely it is during/after a call to sprintf or another function.
Sorry to tell you this, but the '51 is a mix between a dinosaur, a cockroach, and a mule. A very interesting biological experiment A dinosaur because it's ancient and outdated and shouldn't be around anymore today. Well, so must the Pentium be, it is an x86 processor dating equally far back as far as the roots go. A cockroach because it's prolific and it won't go away. Even if you step on it and flush it down the toilet, it'll just crawl out of the sink again. It'll probably also be around long after you're dead and buried. That proves how resilient it is, just look at how much it has mutated. A mule because it does things its way. If you want it to do anything meaningful, you need to learn what "its way" is, since it won't do anything your way. I am very happy with the way it does things, that it is intended for, it does such things beautifully The post I comment on illustrates how blatantly ignorant some are matching the application and the processor. If you want "C is C" stay with your beloved PC. I do feel sorry for you, having accepted a job that required knowledge and actual thought in the belief that your PC coding skills were applicable to '51 programming I am, honestly getting fed up with those that select the wrong processor for the job and them start whining. The '51 Is a lousy processor if you try to use it for what it is not intended for. It is a great processor if you use it for what it is intended for I know that some, who can not accept that the reason they are getting paid is that they are supposed to work, but sit back an whine "why is it not easier to program" Go ahead and put a pentium in a $2 toy it is, after all easy to program, I wish you great success with your business. Erik
I am very happy with the way it does things, that it is intended for, it does such things beautifully No one would expect a racehorse to do the work of a mule, or vice versa. The post I comment on illustrates how blatantly ignorant some are matching the application and the processor. Whoaaa ... wait a minute. Easy on the coffee, maybe try decaf ? I'm not the one who's trying to do floating point math in an ISR, or implement paged virtual memory on a '51, or juggling function pointers around. My '51 project works just fine, and the MCU is quite suited for the task I have. If you want "C is C" stay with your beloved PC. I haven't programmed on a PC in, uh, years, and nothing I ever did on a PC was even close to a commercial project. I started directly with DSPs and uCs, and my very first project was pretty much pure assembly, except for some boring clerical parts that were easier to do in C.
@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
My '51 project works just fine, and the MCU is quite suited for the task I have. I am amazed you achieved that with a cross between a dinosaur, a mule and a cockroach. 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 ?