On 09/09/2010 01:35, adrianunderwater wrote:
> I have been programming embedded systems for over 20
years, mainly in
> assembly forth a bit of C many proprietary languages etc and even
> java... In that respect i am definitely not a novice.
...without ever touching on linker scripts?
Regardless, anyone should find this trivial with the links I provided --
they directly answer the question and are far more useful than the
answer you give at the end of your own post!
> However, you will note that I said "a bit of C" and
recently for the
> location of stuff in memory I was frustrated not by the inability of C
> to do anything, but by the lack of clarity on how to have more control
> over what and where C does and puts things....
C is designed to take this stuff off your hands. You can easily place
variables at specific places in standard C using pointers; what is
harder is preventing the linker from putting other data in those places.
Consequently, the linker manual tells you exactly how to work around
this (the link I provided describes it). Crossworks documentation
almost certainly gives similar info.
> So, in a nutshell, the OP question is definitely a
valid source of
> frustration, and your responses could have been clear concise and
> polite, and a lot less arrogant.
You think that refusing to do someone else's work for free (when you
have given an answer and they then ask for source-code) -- while at the
same time providing direct links that solve their problem -- is
arrogant? Seriously?
Damn this list is annoying; I just won't bother in future.
Pete
--
Pete Vidler
Senior Systems Developer,
TTE Systems Ltd
Work: http://www.tte-systems.com
Home: http://petevidler.com
Force variable address / C / Crossworks
Started by ●September 7, 2010
Reply by ●September 9, 20102010-09-09
Reply by ●September 9, 20102010-09-09
Hi,
Thursday, September 9, 2010, 1:35:27 AM, you wrote:
> As for me, I would also like some other person's perspective on
> locating stuff in memory in C and assembly in crossworks.
> I defined a section, put my stuff there then defined the section's
> address, all of which in my mind is tedious and not perfectly
> straightforward. (That was for the assembly bits... )
There is no standard way of placing a variable at a specific address
using the C language. If there were, of course, then everybody in an
embedded context would be happy and tool vendors would have to deal
with it. But there isn't, embedded vendors have not proposed such an
extension, and so none exists. Witness the TR for embedded extensions
to get a flavor of the crap that a standards committee can come up
with--would you honestly use that stuff?
So, you need to use extensions. Heck, the C standard is crap at this,
I know, but there you go. Everybody can have their own non-standard
extension. But the concept of sections has been around forever, it's
not hard to learn a linker command language, and it's not hard to put
things in a "struct" and hide all this nonsense behind the scenes. At
least you then have a portable C body of code.
If, however, you don't even want to use sections, don't use them! Do
it all BY HAND:
struct my_placed_vars *my_vars = (void *)0x40003000; // EASY!
#define MY_VAR_1 (my_vars->var_1)
#define MY_VAR_2 (my_vars->var_2)
COMPLETELY PORTABLE AMONGST ALL COMPILERS FOR THE GIVEN TARGET!
Gee. What's to get in a lather about?
-- Paul.
Thursday, September 9, 2010, 1:35:27 AM, you wrote:
> As for me, I would also like some other person's perspective on
> locating stuff in memory in C and assembly in crossworks.
> I defined a section, put my stuff there then defined the section's
> address, all of which in my mind is tedious and not perfectly
> straightforward. (That was for the assembly bits... )
There is no standard way of placing a variable at a specific address
using the C language. If there were, of course, then everybody in an
embedded context would be happy and tool vendors would have to deal
with it. But there isn't, embedded vendors have not proposed such an
extension, and so none exists. Witness the TR for embedded extensions
to get a flavor of the crap that a standards committee can come up
with--would you honestly use that stuff?
So, you need to use extensions. Heck, the C standard is crap at this,
I know, but there you go. Everybody can have their own non-standard
extension. But the concept of sections has been around forever, it's
not hard to learn a linker command language, and it's not hard to put
things in a "struct" and hide all this nonsense behind the scenes. At
least you then have a portable C body of code.
If, however, you don't even want to use sections, don't use them! Do
it all BY HAND:
struct my_placed_vars *my_vars = (void *)0x40003000; // EASY!
#define MY_VAR_1 (my_vars->var_1)
#define MY_VAR_2 (my_vars->var_2)
COMPLETELY PORTABLE AMONGST ALL COMPILERS FOR THE GIVEN TARGET!
Gee. What's to get in a lather about?
-- Paul.
Reply by ●September 9, 20102010-09-09
Adrian
> So, in a nutshell, the OP question is definitely a valid source of
> frustration, and your responses could have been clear concise and
> polite, and a lot less arrogant.
My first answer was IMHO polite enough for his question. Just reminding
him to look up the relevant manuals and FAQs is not arrogant or impolite.
If he would have come back with a question showing he did not understand
what he has _read_ in the manual there would certainly be someone (if not
me) to explain in more detail.
> And you do have the option to not read what is not of interest and not
Oh, I do. Sometime the subject seems to be interesting. But if the
question shows a certain amount of laziness, the teacher in me wakes up.
To be honest, a co-worker with such a question showing up in my office
would have get a much ruder answer.
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
> So, in a nutshell, the OP question is definitely a valid source of
> frustration, and your responses could have been clear concise and
> polite, and a lot less arrogant.
My first answer was IMHO polite enough for his question. Just reminding
him to look up the relevant manuals and FAQs is not arrogant or impolite.
If he would have come back with a question showing he did not understand
what he has _read_ in the manual there would certainly be someone (if not
me) to explain in more detail.
> And you do have the option to not read what is not of interest and not
Oh, I do. Sometime the subject seems to be interesting. But if the
question shows a certain amount of laziness, the teacher in me wakes up.
To be honest, a co-worker with such a question showing up in my office
would have get a much ruder answer.
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by ●September 9, 20102010-09-09
In response to...
"To be honest, a co-worker with such a question showing up in my office would have get a much ruder answer."
All depends on what kind of office you work in.
Scenario A. Most people in that office work in C, in teams or individually working on the same or similar projects, all using the same or very similar tools and operating systems... Well yes such a question might raise some sort of laughter or outright rudeness depending on who your boss decides to employ and what kind of work environment he/she/it decides he/she/it wants...
Scenario B. In a previous life, I would be designing in C a java VM. I did not need to interface to hardware, and I had only slight memory constraints. I had an excellent understanding of Java VM operations, yet my actual application java programming skills were very limited (at that time). So I would be asking the games designers (silly) questions in java programming, even after doing a fair amount of research. And they would be asking me rather silly C questions when they wanted to implement native java methods in C... We all understood the limitations of the other team's expertise and were very patient and polite with each other, while respecting and using their strengths.
Scenario C. In a current life, I am designing in assembly a very resource constrained design tool. This has to also talk to 3rd party applications like USB written for the most part in C... So linker and the more exotic and not so standard parts of general embedded C integration have to be perfectly understood, even though the main part of my work is interfacing with hardware using assembly. In a similar manner the C programmers near me understand that the more intricate stumbling blocks are things I can ask them to save time researching for hours on end, while they can ask me why such and such hardware does not respond the way they thought the data sheet said it would... no rudeness there either, even for the "blond" moments we all have from time to time.
In a nutshell,
No one person can have a 100% level of knowledge in scores of different domains.
No question is too silly, and the answer may be needed if only to change a locked-in mindset.
Educating your peers and being educated by them is good. And asking questions, even silly ones from time to time, is a great way to change your perspective and also saves time.
Rudeness at the workplace is bad, as is mockery.
... and yes, none of the above excuses laziness, which is the source of most incompetence...
--- In l..., 42Bastian wrote:
>
> Adrian
>
> > So, in a nutshell, the OP question is definitely a valid source of
> > frustration, and your responses could have been clear concise and
> > polite, and a lot less arrogant.
>
> My first answer was IMHO polite enough for his question. Just reminding
> him to look up the relevant manuals and FAQs is not arrogant or impolite.
>
> If he would have come back with a question showing he did not understand
> what he has _read_ in the manual there would certainly be someone (if not
> me) to explain in more detail.
>
> > And you do have the option to not read what is not of interest and not
>
> Oh, I do. Sometime the subject seems to be interesting. But if the
> question shows a certain amount of laziness, the teacher in me wakes up.
>
> To be honest, a co-worker with such a question showing up in my office
> would have get a much ruder answer.
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
>
"To be honest, a co-worker with such a question showing up in my office would have get a much ruder answer."
All depends on what kind of office you work in.
Scenario A. Most people in that office work in C, in teams or individually working on the same or similar projects, all using the same or very similar tools and operating systems... Well yes such a question might raise some sort of laughter or outright rudeness depending on who your boss decides to employ and what kind of work environment he/she/it decides he/she/it wants...
Scenario B. In a previous life, I would be designing in C a java VM. I did not need to interface to hardware, and I had only slight memory constraints. I had an excellent understanding of Java VM operations, yet my actual application java programming skills were very limited (at that time). So I would be asking the games designers (silly) questions in java programming, even after doing a fair amount of research. And they would be asking me rather silly C questions when they wanted to implement native java methods in C... We all understood the limitations of the other team's expertise and were very patient and polite with each other, while respecting and using their strengths.
Scenario C. In a current life, I am designing in assembly a very resource constrained design tool. This has to also talk to 3rd party applications like USB written for the most part in C... So linker and the more exotic and not so standard parts of general embedded C integration have to be perfectly understood, even though the main part of my work is interfacing with hardware using assembly. In a similar manner the C programmers near me understand that the more intricate stumbling blocks are things I can ask them to save time researching for hours on end, while they can ask me why such and such hardware does not respond the way they thought the data sheet said it would... no rudeness there either, even for the "blond" moments we all have from time to time.
In a nutshell,
No one person can have a 100% level of knowledge in scores of different domains.
No question is too silly, and the answer may be needed if only to change a locked-in mindset.
Educating your peers and being educated by them is good. And asking questions, even silly ones from time to time, is a great way to change your perspective and also saves time.
Rudeness at the workplace is bad, as is mockery.
... and yes, none of the above excuses laziness, which is the source of most incompetence...
--- In l..., 42Bastian wrote:
>
> Adrian
>
> > So, in a nutshell, the OP question is definitely a valid source of
> > frustration, and your responses could have been clear concise and
> > polite, and a lot less arrogant.
>
> My first answer was IMHO polite enough for his question. Just reminding
> him to look up the relevant manuals and FAQs is not arrogant or impolite.
>
> If he would have come back with a question showing he did not understand
> what he has _read_ in the manual there would certainly be someone (if not
> me) to explain in more detail.
>
> > And you do have the option to not read what is not of interest and not
>
> Oh, I do. Sometime the subject seems to be interesting. But if the
> question shows a certain amount of laziness, the teacher in me wakes up.
>
> To be honest, a co-worker with such a question showing up in my office
> would have get a much ruder answer.
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
>
Reply by ●September 10, 20102010-09-10
--- In l..., Pete Vidler wrote:
>
> Damn this list is annoying; I just won't bother in future.
>
Hi Pete,
I really appreciate your thoughtful and insightful posts so I encourage you to continue in the future.
I can recommend a good supplier of asbestos underwear if it is of any help ;-)
Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com
>
> Damn this list is annoying; I just won't bother in future.
>
Hi Pete,
I really appreciate your thoughtful and insightful posts so I encourage you to continue in the future.
I can recommend a good supplier of asbestos underwear if it is of any help ;-)
Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com
Reply by ●September 10, 20102010-09-10
On 10/09/2010 04:16, cfbsoftware1 wrote:
> I really appreciate your thoughtful and insightful posts so I encourage
> you to continue in the future.
I appreciate your comment, but why would I bother? What's in it for the
people who answer these (semi-frequently asked) questions?
The situation boils down to this:
1) Person asks reasonable question, gets an answer from me without
specifics (but easily enough to google!).
2) Person asks for actual source-code, gets a refusal but with specific
details showing everything he needed to know.
And for refusing to do the guys work for him I get accused of being
arrogant and rude (by someone else, who then provides less detail than
in my original answer!).
I can usually just ignore this sort of thing, but my time is valuable to
me and I see little benefit when this is all you get back.
Pete
--
Pete Vidler
Senior Systems Developer,
TTE Systems Ltd
Work: http://www.tte-systems.com
Home: http://petevidler.com
> I really appreciate your thoughtful and insightful posts so I encourage
> you to continue in the future.
I appreciate your comment, but why would I bother? What's in it for the
people who answer these (semi-frequently asked) questions?
The situation boils down to this:
1) Person asks reasonable question, gets an answer from me without
specifics (but easily enough to google!).
2) Person asks for actual source-code, gets a refusal but with specific
details showing everything he needed to know.
And for refusing to do the guys work for him I get accused of being
arrogant and rude (by someone else, who then provides less detail than
in my original answer!).
I can usually just ignore this sort of thing, but my time is valuable to
me and I see little benefit when this is all you get back.
Pete
--
Pete Vidler
Senior Systems Developer,
TTE Systems Ltd
Work: http://www.tte-systems.com
Home: http://petevidler.com
