PBP projects for R/C models

[Kenjones1935]

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

[ardhuru]

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

[ScaleRobotics]

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.

[Byte_Butcher]

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

[ScaleRobotics]

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

[Kenjones1935]

You all suspected my usage of PULSIN.

You were correct.

To determine whether to take control itself or let the radio receiver do its thing, my PIC must read the PWM code from the radio receiver channel 3. That PWM comes in only fifty times per second.

I was asking PULSIN to measure that pulse without setting an interrupt for when it sees a rising edge. What are the chances of my PULSIN moment (plus delay waiting according to pulsin_max) seeing something happening only 50 times per second. Answer, not good.

What are the chances of my PIC seeing that pulse when the radio transmitter is not powered? None whatsoever!

So: When testing my car up on blocks in my "lab" and not remembering to turn on my radio transmitter the poor thing spends 99% its time waiting for a pulse that never arrives.

Yep. Turn on the transmitter (even with channel 3 in the autonomous control position) and my SRF05 blinkers flash like crazy. They are being continuously triggered.

I still have a problem with response time, but it is not because the PIC is lacking sensor information.

Ken

[Kenjones1935]

I don't think I have changed anything other than remove confusing comments.

Ken

[Kenjones1935]

Part of the reason my car keeps hitting the wall is that it is responding too slowly for the speed it is traveling.

Today I carefully calibrated my HPWM 2,xxx,50 commands.

If xxx = 110 the car does not move.
If xxx = 111 the car moves forward, but only on a non-carpeted floor.
If xxx = 112 the car moves forward forcefully but not too fast

xxx = 115 is too fast for my code.
xxx = 125 is full speed which is very fast.

Ken

[Kenjones1935]

Here's a video of our car running a hall in our house.

http://video.yahoo.com/watch/7164676/18657928

I moved the front sonic sensors closer to the front of the car and I figured out how to slow down the wheels a bit.

Next thing, I think, is to build a better looking and stronger prototype using a car with more room to attach stuff. What other kinds of sensors should I try and what other kinds of tasks will they help the PIC do?

Again, thank you for all your interest and help.

Ken