To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.handyboardOpen lugnet.robotics.handyboard in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / Handy Board / 8560
8559  |  8561
Subject: 
Re: 0x8000 and main()
Newsgroups: 
lugnet.robotics.handyboard
Date: 
Sun, 6 Jan 2002 05:12:20 GMT
Viewed: 
2929 times
  
Fred, Dan, and Chuck,

Thanks to an email from Chuck McManis (thanks, Chuck), I now have a better
understanding of what's going on with respect to the main() function and
memory location 0x8000.

Chuck asked me if the main() function is executed after reset if I poke 0 to
address 0x8000 prior to resetting the HB......the answer is no, it doesn't
execute following reset.  You can, however, get the main() function to
execute by typing "  main();  " on the PC (so it IS there).

Chuck suggests that 0x8000 being set to 1 simply indicates that "user code
is loaded" and then the function table is scanned to see if a " main() " is
present.

By Jove, I believe he's got it....and now, so do I.

Many thanks to Chuck for clearing this up.

Regards,

John



In lugnet.robotics.handyboard, John R. McDaniel writes:
Fred and Dan,

For some reason, I'm apparently having trouble explaining my findings, doing
something wrong -- or not understanding what Fred is telling me.

Now that my HB runs " main() " functions just fine upon powerup reset, I did
my experiment on memory location 0x8000 again.

1.  If I download a file containing a "  main() " function, memory location
0x8000 is set to 1, and my main() function runs upon reset.

2.  If I download a file which does NOT have a "  main()  " function, memory
location 0x8000 is STILL set to 1, and the downloaded program does not
execute upon reset (which is obviously correct).

I know that this point is probably not important (since my HB now properly
runs a  " main() " function upon reset) but it's bugging me that I
apparently don't yet understand this 0x8000 thing.

Regards,

John





In lugnet.robotics.handyboard, Fred G. Martin writes:
I don't think this is quite it -- IC sets the byte if there's a main
fcn.  It also sets up some code so that main fcn gets run.

Fred

On Thursday, January 3, 2002, at 02:57 PM, Dan Gates wrote:

John,
I think it lies in the Pcode, in other words if the pcode sets the
0x8000 to 1
then any program loaded that has main() in it will auto run at startup.
If the
pcode does NOT set 0x8000 to 1 then no matter what you have loaded as a
program
it will NOT auto run on startup. The startup registry is therefore
controled by
the Pcode, not the program with main() in it.
-Dan

In lugnet.robotics.handyboard, John R. McDaniel writes:
Dan,

Perhaps I'm misinterpreting what you mean by "a startup program".  To
me, a
"startup program" means there is a file downloaded to the HB that
contains a
"  main()  " function, i.e., a function which will automatically be
executed
upon startup (powerup reset) of the HB.  I think this is what Fred
means by
an "auto-start program".

Therefore, I take Fred's explanation of RAM location 0x8000 to mean
that if
you have a " main() " function resident on the HB, 0x8000 will be a
1.  If
you have a program resident on the HB, but it does not contain a "
main() "
function, 0x8000 will be a 0.

If 0x8000 is set to 1 if ANY program ( with or without a " main() "
functon)
is loaded on the HB, I don't see that the value of 0x8000 has much • significance.

When you say you saw 0x8000 set to 1 when you loaded "any" program, did
"any" include both programs with and without a " main() " function?
This
is, in fact, what I see.  Loading ANY program to the HB sets 0x8000 to
1..... hmmmmm?

Smack me up side the head and get me straightened out.

Thanks,
John



In lugnet.robotics.handyboard, Dan Gates writes:
John,
I just did the same test, I think what Fred was saying is that IC
sets the
0x8000 to accept a startup program if one is loaded. If I poke a 0 to
that
address then load any program it sets back to 1.  I think he was
wandering if
your IC version was messed up, and not setting that register
correctly. • Anyway,
I'm glad you got to the bottom of it!!  Now we all have more
experience under
our belts.
-Dan

In lugnet.robotics.handyboard, John R. McDaniel writes:
Dan,

Yes, I did cut the trace for external motor power.  I know the HB
and the
motor power "+" sources are isolated because I not only checked with
a VOM,
but I removed the motor supply batteries and when I run my motor test
program (remember, no motor supply batteries installed), the motors
do not • run.

In fact, one of the reasons I wrote the program to have output to
the LCD
was so I could be positive the program was executing even when the
motors
are unpowered.

Would you mind trying to duplicate my "experiment" relative to RAM
location
0x8000, i.e., would you download a file with " main() " and peek
0x8000 .
Then unload that file and download a file which has NO " main() "
functon
and see what value 0x8000 has then?

I'll rest a little easier if I know someone else gets the same
results I • did.

Keep shootin' in the dark ---- I'm almost out of bullets over here !!

Thanks,

John




In lugnet.robotics.handyboard, Dan Gates writes:
Wow, What a bugger!  This is one of the strangest cases I've seen.
Works • fine
while connected, but not when reset.  Works fine on my board either
way. • Memory
and 68HC11 have been traded out. Scope shows no voltage drop at
Mem-power
durring reset. Both the free version and the Newton labs version of
IC have
been tried. What else could it possibly be!!!
Did you cut the trace to internal motor power when you added the
external
motor power?  I'm just shootin' in the dark now, I'm sure you did
all that
right.
-Dan




In lugnet.robotics.handyboard, John R. McDaniel writes:

Fred,

Thanks for the info on how IC determines whether to auto-start a
program • or
not.  Based on your suggestions ----

I just finished downloading the open-source (free) version of
IC.    I had
been running Newton Labs 3.1 and most recently 3.2.

I unzipped the open-source version of IC files, configured DL and
IC and
successfully downloaded the "new" Pcode to my HB.   My HB LCD
displayed: • "
Interactive C V2.81  9/28/93 " and the heartbeat.

Using  peek(0x8000),  showed 0x8000 to be equal to 1 (one).   I
used
poke(0x8000,0); to change memory location 0x8000 to be equal to 0
(zero).
I then used peek(0x8000) to confirm that 0x8000 had been changed
to equal • to
0 (zero)......it had.

With 0x8000 set to 0 (zero), I downloaded my "  main()  " file
(filename:
jrm1.c) to the HB.   Again, using peek(0x8000); I checked 0x8000
and is • was
equal to 1 (one).....so far, so good.

I then reset the HB and my "  main()  " program would not run.  I
tried
multiple times.  As always, typing   "    main();  "  on the PC
caused my • "
main()  " program to run properly.

Now, it gets more interesting. I unloaded the "  main()  " program
(filename: jrm1.c).  Unloading did not cause 0x8000 to be set
equal to 0
(zero).    This might or might not be ok.

To find out,  I confirmed the unload  using " list files ".
Then, I • poked
0x8000 to equal 0, and confirmed the poke with peek(0x8000);....
0x8000 • was
equal to 0 (zero).  Calling "  main()  " from the PC resulted in
the
"Function main undefined" message.  So, no " main() " function
resident on
the HB and 0x8000 is equal to 0 (zero).

Next, I loaded a file which does NOT have a "  main()  " function • (filename:
music.c)...... peeked 0x8000 and it was now equal  to 1
(one) !!??  Both a
program WITH  a " main() " function and one WITHOUT a " main() "
function
set RAM location 0x8000 to equal 1 (one).....???!!

Incidentally, "music.c" worked fine, I could call the various
tunes from • the
PC and it did not start running upon HB reset.  I could further
confirm • that
music.c had no " main() " function by trying to call "  main()  "
from the
PC.......I simply got the "Functon main undefined" message.

Just to double check, I then changed everything back to Newton
Labs IC • v3.2.
I downloaded the Pcode (3.10)  and my HB LCD displayed "  IC v3.1
Handy
Board 1.2  " and the heartbeat.  Yes, it does display v3.1, even
though
under Help/About the message says I'm running v3.2  (Newton Labs
take • note).

Anyway,  I repeated all the  above peeks, pokes, loads, peeks,
unloads, et
cetera, ......getting exactly the same results.

My testing would indicate that 0x8000 being a 1 or a 0 does not
define a
downloaded file which contains a "  main()  " function.  Have I
misinterpreted something....sorry if so.

I've looked at the source code, but can't figure out how to
determine the
memory address of PCODE_ORIGIN.....I'll study it more.

Suggestions?


Thanks,

John



















In lugnet.robotics.handyboard, Fred G. Martin writes:
OK, I looked at the source code to try to understand what could
be the
problem.  If anyone wants to download the source themselves, go to
http://handyboard.com/software/base.html and click on the link at
the
bottom of the page.

The following is true of the open-source (free) version of IC.  I
don't
think it's changed in Newton Labs' IC, but I could be wrong.

The very first byte of battery-backed RAM, 0x8000, marks whether
or not
an auto-start program is in place.

If this byte is 0, there is no auto-start program.
If this byte is 1, there is an auto-start program, and compiled
code
beginning at 0x8001 is executed.

So, given this, I'd check that you can properly read and write to
location 0x8000 of your RAM.

I haven't heard of this problem before so I too am curious as to
what's
going on.  Definitely try things with the open-source IC that's
distributed from the HB site.

Fred



On Tuesday, January 1, 2002, at 11:03 PM, John McDaniel wrote:

Dan,

Thanks for hanging tough on this problem.....I'm feeling really
inadequate
on this one.

I downloaded your revision of my program and it did not help.  Of
course, if
I do type " main() " on the PC, it does give your "Press
Start....."
message
and waits for me to press START.  After pressing START, the HB
beeps • and
starts running "my" program.

Yes, I'm downloading the Pcode version 3.1.  However, per your
earlier
suggestion, I downloaded the "PWM Pcode" to my HB and then
downloaded
my "
main()  " file......no joy!.... same problem.

I will download the 'free' IC version and try everything from a
DOS
prompt,
although that'll have to wait until tomorrow.

Incidentally, I just reattached the battery pack after
resoldering • every
connection on the HB.....no change.

Well, I've got 103 fewer Toshiba 68HC11's than you, but I'm glad
to • hear
that you don't think that the Toshiba is the problem -- or maybe
I wish
it
were that.

Please feel free to post any/all of this discussion on the other
board....I'll take any help I can get.  You can probably tell
that I'm
really frustrated with this problem.  I'm ready to get on with
my robot
project, but I have to get past this problem
first......arrrrgh.   If I
can't get this squared away, I'm going to have a very expensive
paperweight.

Regards,
John



In lugnet.robotics.handyboard, Dan Gates writes:
John,
I added a little sub routine to your program, see if you can
use it
this way.
Probably not, but hey it's worth a try. Also, if you don't mind
I'd
like to
post it to the yahoo handyboard files too at
http://groups.yahoo.com/group/handyboard/files/
-Dan

/* filename: jrm1.c    John R. McDaniel */

  void main()
             {

  init();         /* Run initialize routine */

  while(1){ /*do this loop endlessly*/


  printf("Test Motors !!\n");   /*print 'Test Motors !!' on
LCD*/

  ao(); /*both motor off for 2 seconds*/
  sleep(2.0); /*delay start so can unplug cable*/

  /*go forward*/
  printf("Forward\n"); /*print 'Forward' on LCD*/
  fd(0); /*left motor forward*/
  fd(2); /*right motor forward*/
  sleep(3.0); /*do this for 3 seconds*/
  alloff(); /*let motors coast to stop*/
  sleep(1.0);

  /*turn right*/
  printf("Right\n"); /*print 'Right' on LCD*/
  fd(0); /*left motor forward*/
  bk(2); /*right motor backwards*/
  sleep(2.0); /*do this for 2 seconds*/
  alloff(); /*let motors coast to stop*/
  sleep(1.0);

  /*turn left*/
  printf("Left\n"); /*print 'Left' on LCD*/
  bk(0); /*left motor backwards*/
  fd(2); /*right motor forward*/
  sleep(2.0); /*do this for 2 seconds*/
  alloff(); /*let motors coast to stop*/
  sleep(1.0);

  /*go backward*/
  printf("Back\n"); /*print 'Back' on LCD*/
  bk(0); /*left motor backwards*/
  bk(2); /*right motor backwards*/
  sleep(3.0); /*do this for 3 seconds*/


  alloff(); /*all motors off, rest until next loop*/
  printf("Loop Done\n"); /*print 'Loop Done' on LCD*/

  sleep(5.0); /*pause before doing loop again*/

  }
  }

  /* end */

  /* ****************** Subroutines ************************* */


  void init()
  {
       printf("Press Start to  Go!\n");
       while(!start_button()){}
       tone(800.,1.);
}





Message is in Reply To:
  Re: 0x8000 and main()
 
Fred and Dan, For some reason, I'm apparently having trouble explaining my findings, doing something wrong -- or not understanding what Fred is telling me. Now that my HB runs " main() " functions just fine upon powerup reset, I did my experiment on (...) (23 years ago, 5-Jan-02, to lugnet.robotics.handyboard)

16 Messages in This Thread:


Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR