PBP projects for R/C models


Closed Thread
Results 1 to 40 of 772

Hybrid View

  1. #1
    Join Date
    Nov 2009
    Location
    Fitchburg, Mass
    Posts
    483


    Did you find this post helpful? Yes | No

    Smile I sped things up a bit.....

    Inline code is probably faster than subroutine based code. I commented out all the HPWM subroutines and substituted in place of their calls the HPWM statements themselves.

    My guess is that the SRF05's are blinking faster. That is very good.

    I checked the SRF05 responses. They seem to be immediately after the one millisecond trigger pulse. PULSIN should not be timing out, but that is a vulnerability worth considering.

    Ken

  2. #2
    Join Date
    Nov 2009
    Location
    Fitchburg, Mass
    Posts
    483


    Did you find this post helpful? Yes | No

    Default PULSIN is part of the problem!!

    I did a DEFINE PULSIN_MAX 1000 and the car is falling into my 'failed' because 'rangefront' or 'rangeright' equals zero. Interesting!! Something there is not consistent.

  3. #3
    Join Date
    Jan 2009
    Location
    California, USA
    Posts
    323


    Did you find this post helpful? Yes | No

    Default

    You'll probably need a longer timeout than 1000.
    That would only be 10mS that it waits.
    Maybe try 10000?

    Fool around with it a bit. It needs to be long enough to see the whole pulse, but short enough that it doesn't waste excessive time waiting.


    steve

  4. #4
    Join Date
    Nov 2009
    Location
    Fitchburg, Mass
    Posts
    483


    Did you find this post helpful? Yes | No

    Default Voltage supply seems to make a difference

    When running independently off the 7.2v voltage regulated battery the SRF05's seem more consistent with their responses than when running off the PIKkit2 USB provided 5volt supply. Interesting if true.

    Thanks again, all...

    Ken

  5. #5
    Join Date
    Nov 2009
    Location
    Fitchburg, Mass
    Posts
    483


    Did you find this post helpful? Yes | No

    Default It gets interestinger and interestinger....

    Added complexities. Classic amateur robot stuff I would guess.

    1. The sonar proximity detectors have a fairly wide field of "vision". If the car bumps against the side wall at a sharpish angle, the front detectors see the wall. The program thinks the car has come to a corner in the room and makes a maximum sharp left turn. This sets the car up for a very zigzag pattern.

    I tried making a "megaphone" for the front sonar pingers out of the cardboard tube on a toilet paper roll. The sonar "detected" the tube. Hmmmm

    2. When the battery begins to fade the car has a difficult time moving from a dead stop. Given a nudge, it takes off. The net behavior becomes quite different. Discombobulating to say the least.

    3. The wheels and the steering servo still appear to be reacting too slowly. Exactly what is the problem is not clear.

    That is the report for today...

    Ken

  6. #6
    Join Date
    Nov 2009
    Location
    Fitchburg, Mass
    Posts
    483


    Did you find this post helpful? Yes | No

    Red face Still the car responds too slowly

    I am thinking that I need to better understand 16F887 machine language to make real progress. Certainly if I were to code in Assembly I would have a better feel for which macros take more time than others. I have not paid any attention to this until now.

    This morning I looked at the ASM command list. I noticed that ASM has both a CALL and a RETURN command. This makes PBP's GOSUB and RETURN inexpensive I would think. Getting rid of subroutines will not improve speed.

    I also note that PBP's IF, THEN, ELSE, ENDIF do not match straight into ASM code. Maybe I should write these case specific in ASM instead of PBP.

    Somehow I have to speed up my processing loop.

    Any suggestions?

    Ken

  7. #7
    Join Date
    Oct 2004
    Posts
    448


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Kenjones1935 View Post
    I am thinking that I need to better understand 16F887 machine language to make real progress.
    This might help:

    http://www.mikroe.com/en/books/picmcubook/

    Regards,

    Anand

  8. #8
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Kenjones1935 View Post
    I am thinking that I need to better understand 16F887 machine language to make real progress. Certainly if I were to code in Assembly I would have a better feel for which macros take more time than others. I have not paid any attention to this until now.

    This morning I looked at the ASM command list. I noticed that ASM has both a CALL and a RETURN command. This makes PBP's GOSUB and RETURN inexpensive I would think. Getting rid of subroutines will not improve speed.

    I also note that PBP's IF, THEN, ELSE, ENDIF do not match straight into ASM code. Maybe I should write these case specific in ASM instead of PBP.

    Somehow I have to speed up my processing loop.

    Any suggestions?

    Ken
    Hello Ken,

    I don't think your gosub's, or commands are taking too long, although it is possible they are too many nested. The PIC is a very fast piece of hardware, and nothing you have should take it a second to complete. After all, at 4 mhz, it can do one million instructions per second. Your pause 200 takes the most time here (the equivalent of about 200,000 lines of assembly code). I do not think you need to write this in assembly. You just need to find a bug that seems to be monopolizing your 16f887, or minimizing your sonar pings.

    Can you write some simple code to make your sonar sense at more than 1 pulse per second? That would be my first test. You could also blink an led as your code passes different spots, to see if you get caught in any loops.

    I would change most of your gosubs to just include the HPWM command to make for easier reading. That would make it cleaner, and easier to spot a problem. Any chance you could post the whole code, with the variables, and the config settings?

    By the way, nice job! It is really progressing nicely.

    Walter

    Edit:

    I don't think this will help anything, but how about changing all your HPWM's to HPWM x,x,245 since that is the minimum for 4 mhz? Maybe it is just defaulting to that anyway, but it is outside the range given in the manual.
    Last edited by ScaleRobotics; - 14th March 2010 at 17:33.

  9. #9
    Join Date
    Jan 2009
    Location
    California, USA
    Posts
    323


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Kenjones1935 View Post

    Somehow I have to speed up my processing loop.

    Any suggestions?
    What oscillator speed are you running?
    8MHz on internal osc?

    I believe the 16F887 will run up to 20MHz with external crystal.
    That would speed things up a bunch.


    steve

  10. #10
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    Another thing you could do, is ICD compile it in micro code studio (for something like a PIC16f876a) and run it to see where it is getting stuck. Of course, you would need a serial port, and a PIC16f876a laying around to test it that way.

    It would show you step by step, or animated, something like this:


    Walter
    Attached Images Attached Images  

Similar Threads

  1. PBP Book
    By Bruce in forum Off Topic
    Replies: 83
    Last Post: - 4th October 2021, 12:55
  2. PBP Extensions, What are they?
    By PJALM in forum PBP Extensions
    Replies: 9
    Last Post: - 28th September 2021, 11:26
  3. Compiler differences between PBP 2.33 & 2.46
    By nikopolis in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 2nd May 2006, 19:01
  4. Newby- PBP wont compile for 18F (MPLAB)
    By jd76duke in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 17th December 2005, 23:30
  5. Making PBP code more modular
    By forgie in forum General
    Replies: 30
    Last Post: - 25th October 2005, 16:24

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts