Searching \ for '[PIC] Relocatable Environment, was Re: Code packin' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=environ
Search entire site for: 'Relocatable Environment, was Re: Code packin'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Relocatable Environment, was Re: Code packin'
2008\07\07@074823 by Alan B. Pearce

face picon face
>Hi Olin,
>
>I would like to see this in action.  I find that your approach to
>programming quickly distracts me from what I actually want the
>processor to do.  When I am experimenting for some reason I often
>find it easier if references and values are hard coded.

This is the biggest hurdle I found, accepting that there may be a better
place to put things than where you feel they should go, or that there is an
easier way to work through fitting things to the chip constraints than
having you do the work.

>For example I tend to use the bit number to reference bits rather
>than by label then try to tidy it up after.
>
>However,I believe you approach is clearly superior and would like to
>embrace it but at the moment it distracts me from the problem at hand.

It is more difficult when you have been using absolute mode, because that
gets the job done, and then try and change. I was in a position to jump in
with both feet, as it were, as I had only 'played on paper' with the chips.
The biggest hurdle is getting your mind around the additional and/or
different commands that relocatable mode uses. Initially it does seem to
require a heap more typing, more files, and more fiddliness, but Olin has
done most of that with his template files and macros, so the mound you need
to climb is not quite as high as starting from scratch with just the MPLAB
IDE.

> Someone once commented that you use so many macros that you have
>forgoten what it is like to do real programming.  This was unfair but
>helps highlight the increased difficulty due to introduced obscurity.

Think of macros as more like stopping you micromanaging everything. There is
no need for you to go to the datasheet every time you set up a project to
work out how to set up Timer1, or the UART baud rate. Instead you type one
line with some parameters, and a dozen lines of code are generated for you -
including relevant comments through most of it.


2008\07\07@082204 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote:

> The biggest hurdle is getting your mind around the additional and/or
> different commands that relocatable mode uses. Initially it does seem to
> require a heap more typing, more files, and more fiddliness, but Olin has
> done most of that with his template files and macros, so the mound you need
> to climb is not quite as high as starting from scratch with just the MPLAB
> IDE.

I'm not sure that I understand this correctly. Are you saying that
it's easier to dive right into Olin's environment then to just
make the (rather minor) changes to use reloc mode as-is ?

My understanding is that the differences between absolut
and reloc mode are rather small as long as you, for
example, just are "porting" a singe-file source. Then you
can dive deeper into the reloc mode features such as
multiple file sources and other things.

Olin's environment OTOH, is a much stepper "step"
to get into, and *personaly* I would not recommend
that as a learning platform for reloc-mode. It's far
easier to understand Olin's macros and all if you
already know what reloc mode is all about.

Jan-Erik.

2008\07\07@091510 by Alan B. Pearce

face picon face
>I'm not sure that I understand this correctly. Are you saying
>that it's easier to dive right into Olin's environment then to
>just make the (rather minor) changes to use reloc mode as-is ?

I wasn't thinking about Olins environment especially, just reloc mode in
general.

>My understanding is that the differences between absolut
>and reloc mode are rather small as long as you, for
>example, just are "porting" a singe-file source.

Yes, if you are 'just' talking about modifying the source file, but then
there is the linker file ... "why have these extra files if I can get away
without them" seems to be the hurdle that people have to overcome.

>Then you can dive deeper into the reloc mode features such
>as multiple file sources and other things.

Yes, but as I point out above, for the single source file case, you have at
least one additional file anyway, and learning what needs to go in there is
part of the hurdle. Once you have that correct the 'rest is easy', as they
say ...

>Olin's environment OTOH, is a much stepper "step"
>to get into, and *personaly* I would not recommend
>that as a learning platform for reloc-mode. It's far
>easier to understand Olin's macros and all if you
>already know what reloc mode is all about.

Yes and no - Olins environment has a lot of the 'extra' things all sorted
out, even if using just one source file. He has the template linker file
which 'points the way' to how things need to be set up. Sure his environment
has its own set of idiosyncrasies carried over from how he has set up
projects in previous non-pic environments, which do make it a little harder
to deal with, but they are not that much different to the 'projects' system
under MPLAB.

The biggest hassle is taking the leap that lifts you off the springboard at
the relocatable deep end, instead of swimming around in the absolute mode
shallow end, where you can put your feet on the bottom of the pool when you
get in trouble.

2008\07\07@095431 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote:

> I wasn't thinking about Olins environment especially, just reloc mode in
> general.

OK.

> Yes, if you are 'just' talking about modifying the source file, but then
> there is the linker file...

Just a single "add file" in the project window.
No major problem, IMHO.
As much job as adding the #include for the device INC file.

> Yes, but as I point out above, for the single source file case, you have at
> least one additional file anyway, and learning what needs to go in there is
> part of the hurdle.

I don't get it. You do not have to *write* the linker scripts.
They're there, ready to be added to the project.

Now, for *advanced* reloc projects, you *might* want to make some
changes to the linker script, but you defenitely do not have to
either write them from scratch or add anything to it if you do not
need/want to.

Jan-Erik.

2008\07\07@114645 by Mongol Herdsman

picon face
On 7/7/08, Jan-Erik Soderholm <spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com> wrote:
> Olin's environment OTOH, is a much stepper "step"
> to get into, and *personaly* I would not recommend
> that

Let me disagree, my apologies. I'd recommend the relocatable
environment very much, In fact we've been using it for centuries,
thanks to Olin, The Great.
We call the relocatable environment "Yurt" (
http://en.wikipedia.org/wiki/Yurt ) Even kids could get into it in one
step.

2008\07\07@171108 by Jan-Erik Soderholm

face picon face
Mongol Herdsman wrote:
> On 7/7/08, Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:
>> Olin's environment OTOH, is a much stepper "step"
>> to get into, and *personaly* I would not recommend
>> that
>
> Let me disagree, my apologies. I'd recommend the relocatable
> environment very much, In fact we've been using it for centuries,
> thanks to Olin, The Great.
> We call the relocatable environment "Yurt" (
> http://en.wikipedia.org/wiki/Yurt ) Even kids could get into it in one
> step.

You cut out the most important part. :-)
The part after the last "that..." in the quote
above.

I do not think Olins environent is the best showcase
for someone *totaly new* to relocatable code. Those has
probably only seen rather straight forward absolute code
before and would be best helped by a more "gentle"
introduction to the world of relocatable code then
stepping right into Olins rather complex toolbox.

It's not only a change into relocatable code, it's
a whole lot of other macros and pre-processors that
dictate quite a few other code changes. And if not,
why use Olin's environment in the first place ?

> > thanks to Olin, The Great.

Was it the dev environment as such ? Or that Olin
often advocates in favor of relocatable code ?

Again (and just as Olin also said) relocatable code
is one thing, Olin's dev environment is quite
another thing.

Actualy, I do have a slight feeling that a few
might be scared away from relocatable mode becuse
they look at Olin's dev environment and thinks that
*that* equals relocatable code...

> I'd recommend the relocatable
> environment very much,

So so I. So do Olin. Of course.

Jan-Erik.



2008\07\08@005212 by Mongol Herdsman

picon face
On 7/8/08, Jan-Erik Soderholm <jan-erik.soderholmspamKILLspamtelia.com> wrote:

> Again (and just as Olin also said) relocatable code is one thing,
> Olin's dev environment is quite another thing.

Of course, the first is Olin's The Great Concept (OGC), the second is
ingenious Olin's The Implementation Of The Concept (OIC). Even
certifications are separate for OGC and OIC.

To pass OGC one should answer:
- why dead fish;
- why moon;
- what's The Golden Rule;
- what's the difference between idiot, stupid, bozoo, severe case of
moronic plague, two drunk neurons brained, etc;

To pass OIC one should demonstrate excelent skills in:
- waving the dead fish most eficiently;
- writing the code to calculate the right moon phase (usage of
asbsolute addressing would trigger a high voltage discharge over the
examinee);
- operating the storage of parts in relocatable mode, boxes of
different sizes should fit 1 bank space - 2048 cubic sm;
- naming a newbie with the right word (most complex part of the exam,
9 of 10 newbies should start driving crazy from half-turn)
---
I passed both certfications and even more - now I'm MVP (Most Valuable
Person) in the area. I planed visiting Microchip's MASTERs this month,
but the problem is our ox-carts are not quite good at crossing
Atlantic.

Regards.

2008\07\08@022341 by David Meiklejohn

face
flavicon
face
Alan B. Pearce wrote:

> The biggest hassle is taking the leap that lifts you off the springboard
> at
> the relocatable deep end, instead of swimming around in the absolute mode
> shallow end, where you can put your feet on the bottom of the pool when
> you
> get in trouble.

Oh, I don't think that making the switch to relocatable mode is like
jumping into the deep end...  There's nothing inherently difficult about
it.  Knowing to add an appropriate linker script to your project is no
harder than knowing to include the correct .inc file in your source.
Using CODE instead of ORG isn't hard, nor is using UDATA and RES instead
of CBLOCK.  Sure, you may need to throw in some banksels and pagesels that
you didn't before, but that's easy enough to get used to.

I guess the real problem is that, if you're used to absolute mode and it
works well for you, it's hard to change your mindset.  That's one reason I
started writing tutorials - all the introductory material I could find on
the 'net or in magazine articles (e.g. a recent series in EPE) used
absolute mode, and if people learn that way, they'll find it harder to
change later. You can argue that beginners are better off in absolute
mode, because it's easier, but I dispute that.  If you learn relocatable
to start with, and are never exposed to absolute, it will seem natural and
easy.  So in my tutorials, I just assume relocatable mode, and talk about
some aspects of it quite early (lesson 3:
http://www.gooligum.com.au/tutorials/baseline/PIC_Base_A_3.pdf, where a
LED is flashed by calling a delay routine in an external module...).

What I'm trying to say is that relocatable mode in itself is not
difficult, as long as you are not confusing it with Olin's environment,
and as long as absolute mode is not "ingrained" into you.


David Meiklejohn
http://www.gooligum.com.au

2008\07\08@030843 by Xiaofan Chen

face picon face
On Mon, Jul 7, 2008 at 11:46 PM, Mongol Herdsman
<.....inner.mongolia.herdKILLspamspam.....gmail.com> wrote:
> On 7/7/08, Jan-Erik Soderholm <EraseMEjan-erik.soderholmspam_OUTspamTakeThisOuTtelia.com> wrote:
>> Olin's environment OTOH, is a much stepper "step"
>> to get into, and *personally* I would not recommend
>> that

I agree with that. For me I only want to read some of Olin's
codes and not his build environment even though I did spend
some time on it. You do not need that to use relocatable mode.

It is good to under the linker script and relocatable mode
even if one does not want to use assembly (I use mainly C).

Quite some users have bigger problems with some
Microchip provided linker script and relocatable mode.
But if they care to read the documentation of MPASM/MPLINK
for one hour, they should  have not much issues with the
linker scripts.

> Let me disagree, my apologies. I'd recommend the relocatable
> environment very much, In fact we've been using it for centuries,
> thanks to Olin, The Great.

Nice to hear one more user of Olin's programming environment.
It would be nice to see how many real users of the environment.
If you are used to his environment, I think it is good. If you do
not, I do not think it is a problem.


Regards,
Xiaofan

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...