sorry for a new thread when there are many threads on this topic but its just that i couldnt find any satisfactory solution : I am using keil evaluation version (small rom less than 2k) and i am getting the improper fixup error for the interrupts . When i comment those interrupt function , i dont get these error. From other threads , i understand that the code starts from 800h in this version and the interrupt is located in 13h and it is not possible to jump in code size : small .
Is there any solution for this or does it mean interrupts cannot be used in this model ? Please help me out here.. struck for several days
Thanks ! Ram
You don't download uVision, the IDE, standalone.
So you get an IDE and a compiler when downloading.
uVision 2 is old so that would indicate that both IDE and compiler is old.
It isn't even guaranteed that the IDE is compatible with a compiler with significant version difference, since command line parameters etc can change.
"You don't download uVision, the IDE, standalone."
or "You cann't download uVision, the IDE, standalone."
they are two different things and we are NOT discussing if you do or do not download uVision, the IDE, standalone, if you haven't already figured that out by now.
I have figured you, and your arguments, out a long time ago. Hence the comment about coffee.
You are too busy splitting hairs that you can't manage to focus on the main problems.
@Ashley Madison,
Do you write software for a living?
Well, we weren't until you raised the issue!
1) The OP did not say what compiler version they where using Only the IDE. Newbies often do not know the difference. 2) Based on the available information, a hypothesis was formed. Since mixing parts from different distribution is unlikely, but possible, it is a plausible hypothesis. Per-review is mostly positive. Is this hypothesis correct? the only way to prove or disprove it conclusively would be for the OP to state what compiler version they are actually using. 3) All Hail the Scientific Method.
The important thing here is to consider Occam's razor.
There are billions of potential problems/details/tracks in existence all around us. We wouldn't get anywhere by picking them at random.
It's way faster to try to cover the most likely sources of a problem first and only branch when there is a significant reason to. Being selective about what alternatives to try first is not the same as ignoring the existence of alternatives, but a required optimization step in real life.
We regularly discuss on this forum the importance of details. But real world problems don't have one detail to be careful about. It may have 100 or 10000 details. Some details more important than others. Some details impossible to handle because they are not compatible with something else. When going on vacation, there is much gear that would be good to bring. But the car has limited space. When doing embedded work, there is much cool things to implement, but a processor have limited code/ram space and may have a tight power budget.
Same thing when trying to solve problems. We don't have the mental computing power or bandwidth to hunt all potential alternatives concurrently. It's meaningless to stand 2 cm from the wall and discuss the structure of the wall paper when a viewer standing 2 meters from the wall would notice that the wall paper is hanging upside down.
Too early zooming down too deeply when problem solving is similar to prematurely starting to optimize source code. The end result will be suboptimial, or there will have been significant extra work without any gain.
"Newbies often do not know the difference."
that's exactly why it pays to make that distinction upfront so that everyone involved in this discussion can be as concise and helpful as possible.
"The end result will be suboptimial, or there will have been significant extra work without any gain."
real life engineering is rarely about being optimal. it is often about being practical and compromises.
in that sense, it is often optimal to be suboptimal.