PBP projects for R/C models

Its really cool!! It has come a long way, in a very positive way. :)

When its stuck, I see 2 distinct possibilities. the first time when the car was perpendiculer to the wall, my guess was it was too close, therefore the front sensor missed the echo. the second and third times, when it was trying to go forward into the wall, my guess is the angle was just right so as the reflection of the sonar bounced off the wall and kept going forward so the car thought it was all clear ahead.

One time towards the beginning it ran head on into the wall. it went straight back, I am not sure if it bounced or if the car said reverse.

Overall it seems like response time may be the issue. are you able to slow the car when the front is blocked and needs to turn? If so, maybe cut the speed to half when the front is blocked. then on the all clear go back to full ahead. I don't think the car is able to make the turn, check the front, check the side and continue forward.

I suppose an echo has a significant energy distribution pattern which is a function of the angle on incidence. I do not know the physics but it certainly seems reasonable.

Thank you!

Ken

I don't know about all that, but if you stand at 1 focal point of a room made in an ellipse shape and wisper, someone standing at the other focal point can hear you clearly. Sonar is just sound, so it stands to reason it has to reflect like a pool ball. :)

BATS
Bat navigation....
you are building a bat-car.

Friction is sure a problem with your car along with others...

Try to increase the friction with this simple idea.

Cut from a kitchen glove the fingers and place the cut parts on your wheels. I think these will last for a test run, at least.

With the increased friction you will get over the overturning of the car.

Ioannis

1. I cobbled together the working parts of two DELL 8600 lap tops and created one that works!! I installed the PBP tools and have a strong new battery. I will be able to modify my code in the building - sans electricity and heat - where I test.

2. I found that putting a cardboard right up to the front SONAR makes it behave as if there is nothing within range. Sooo up real close is far away as far as it is concerned.

Got a new video to show you all. The code is much the same as the last time. I included it below.

The video speaks for itself. Would this be a good context for a public school engineering project? It certainly shows the real world as I know it. The kids could see whether they can make the car go around the room staying outside traffic cones which define the inside of the course.

http://www.youtube.com/watch?v=V2ZjYw9MOz0

Code:

---

'*************************************************  ***************
SYMBOL trigright = PORTB.0 ' Define output pin for Trigger pulse
SYMBOL trigfront = PORTB.1 ' Define output pin for Trigger pulse
SYMBOL trigleft  = PORTB.3 ' Define output pin for TRigger pulse
SYMBOL echoright = PORTC.6 ' Define input pin for Echo pulse
SYMBOL echofront = PORTC.5 ' Define input pin for Echo pulse
SYMBOL echoleft  = PORTC.7 ' Define input pin for Echo pulse
SYMBOL radiotransmitterON = PORTC.4 ' Define input pin for Signal
      'inside radio receiver indicatin that the transmitter has
      'been turn on. Used to stop the car by turning ON the xmitter.
TRISC = %11110000
DATA $1C,$B5'This version's checksum goes here.
' Speed of sound echo is about 2mS per foot distance.
' define pulsin_max 2800 '28mS  SF05 spec says it drops at 30mS. 
' don't forget channel 3 every 20mS or 50Hz.
'--------------------

frontdanger CON 180 'about 12 inches. Was 450 about 30 inches
stopreversing CON 390' about 26 inches
frontfree CON 1080 'about 72 inches.  Was 800 about 53 inches.
desiredtrack CON 540 'about 36 inches. Now only one line.
'outertrack con 450 'about 30 inches. Was 360 about 24 inches

SYMBOL turnon = PORTC.3 ' the signal that if HIGH makes the car steer straight
SYMBOL steerto = PORTC.2 ' the signal that if on turning is on, then decides
  'the direction
SYMBOL stopgo =PORTC.1 ' the signal that if HIGH makes the car go
SYMBOL forrev =PORTC.0 ' the signal that if on and is not on stop makes
  'the car reverse

'---------------------------
rangeleft VAR WORD  'experimental timing.
rangeright VAR WORD
rangefront VAR WORD
oldrangeright VAR WORD
oldrangefront VAR WORD
CNTR VAR WORD
CNTR = 0
CNTL VAR WORD
CNTL = 0
steeringstate VAR WORD
steeringstate = 0 ' 0=straight,1=left,2=right,3=skid left,4=rightback,

'--------------
'Looks like I need to kick the steering back into straight.
LOW stopgo 'stop
HIGH turnon
'pause 2000 'Wait so I can put the car down and get out of the way.

main:
GOSUB triggers

CheckIfInDanger:
IF (rangefront < frontdanger) AND (steeringstate <> 3) THEN
 HIGH stopgo  'go
 LOW forrev 'back
 LOW turnon  'steer
 LOW steerto 'right
 steeringstate = 4
 GOTO reverseoutoftrouble
' loop till this is secured
ENDIF

tryleftturn:
IF rangefront < frontfree THEN
'something ahead - turn hard left.
 'gosub leftforward
  IF (steeringstate <> 3) THEN
    HIGH stopgo    'go
    LOW forrev    'reverse
    LOW turnon    'steer
    HIGH steerto  'left
    steeringstate = 3 'skid left
    PAUSE 150
  ENDIF
  HIGH steerto  'left
  HIGH stopgo  'go
  HIGH forrev  'forward
  GOTO main 'Loop until secured
ENDIF
 
goingforward:                         
keepgoingforward:

IF (rangeright < desiredtrack) THEN
'steer left
  CNTL = (CNTL+1)
  IF CNTL = 2 THEN
    LOW turnon  'steer
    HIGH steerto 'left
    steeringstate = 1
    HIGH stopgo  'go
    HIGH forrev  'forward
    CNTL = 0
  ENDIF
  PAUSE 150
ENDIF

IF (rangeright > desiredtrack)THEN
'steer right
  CNTR = (CNTR+1)
  IF CNTR = 2 THEN
    LOW turnon  'steer
    LOW steerto  'right
    steeringstate = 2
    HIGH stopgo  'go
    HIGH forrev  'forward
    CNTR = 0
  ENDIF
  PAUSE 150
ENDIF

IF steeringstate = 1 THEN 'left
  LOW steerto 'right
  PAUSE 100
ENDIF
IF steeringstate = 2 THEN  'right 
  HIGH steerto  'left
  PAUSE 60
ENDIF 
HIGH turnon
steeringstate = 0
GOTO main

'-------------------------
 reverseoutoftrouble:
' below seems reduncant except for the pause.
LOW turnon  'steer
LOW steerto  'right
steeringstate = 4 'new steeringstate
HIGH stopgo  'go
LOW forrev  'back
PAUSE 200 'added to do some reversing. We have a problem of bumping
'against the wall and not backing up.  This pause should fix that.

keepreversing:
WHILE (rangefront < stopreversing) OR ((oldrangefront = rangefront) AND (oldrangeright = rangeright))
' We have not reversed far enough
  HIGH stopgo  'go
  LOW forrev  'back
  PAUSE 250    'maybe this will get car to back off wall
  GOSUB triggers
WEND

'------------------------------------
'done reversing.  Go straight or turn left depending on right
'ping. If > outertrack then out in the middle.  If < desiredtrack
'then stuck on wall. This did not work.  See TOY_CAR_KICK_TURN_3.wmv
'Try no IF statement.
'if rangeright > desiredtrack then
'steer left
  LOW turnon  'steer
  HIGH steerto  'left
  steeringstate = 1
  HIGH stopgo  'go
  HIGH forrev  'forward
  PAUSE 250
'hpwm 2,Forward,50  --Already going Forward
'endif
GOTO main
'--------------------------

triggers:  ' Check two sonars and xmitter ON signal.
oldrangeright = rangeright
' produce 10uS trigger pulse (must be minimum of 10uS)
LOW trigright
HIGH trigright
HIGH trigright
HIGH trigright
LOW trigright
'zero could be legal below
PULSIN echoright,1,rangeright 'measures the range in 10uS steps
PAUSE 10 'Wait for ringing to stop - read SF05 spec.

'pulsin echoleft,1,rangeleft  'see if this slows the triggers to one
'per second.  That it did, but it crashed straight into the wall.

pulsf:
oldrangefront = rangefront
LOW trigfront
HIGH trigfront
HIGH trigfront
HIGH trigfront
LOW trigfront
PULSIN echofront,1,rangefront ' measures the range in 10uS steps
PAUSE 10
 
radioON:
' make ON = LOW for 1/10 toy car to radiotransmitter
do WHILE radiotransmitterON = 0
LOW stopgo
loop
HIGH stopgo 'get going again
RETURN 
     
END

---

Since you will have a Laptop with you, how about getting telemetry data from your car to analyze them? Like echo, steering acceleration/braking.

Ioannis

The code is a very simple state machine. I shall post a flow diagram if I can figure out an appropriate CAD tool.

Can (should?) middle school kids be asked to deal with the uncertainties of the real world? I think this TOY level car demonstrates that ambiguity in an appealing and dramatic fashion.

The code consists of a set of hardware related constants which need not be changed.

11 Variable definitions and the following four car behavior constants.

frontdanger - 12 inches
stopreversing - 26 inches
frontfree - 72 inches
desiredtrack - 36 inches

A routine that triggers the SONARS and puts the code in a tight loop when the radio transmitter has been turned on.

Six IF statements. These are each state machines. They evaluate the SENSOR data and tell the wheels what to do. Their labels are:

CheckIfInDanger
TryLeftTurn
TooCloseToWall
TooFarFromWall
ReverseOutOfTrouble
Keepreversing

At one level all the students need to modify are the constants. At another level they can modify these six IF statements. An advanced student could add more states.

Ken

It's a race. Which car wins? Depends......

http://www.youtube.com/watch?v=YtDu5S1XNh8

I suspect a major resistance to getting my robocar into public education is insecurity and uncertainty on the part of the teachers. We are talking about 'how things work' in 2011. My 2004 General Motors automobile contains upwards of 20 PICs. Each tire air valve has a pressure sensor and enough of a computer to maintain a presence on the car's internal wireless network. How did I discover this? I could not make sense of the little tire pressure warning messages on the dash board. A previous owner had rotated the tires. How many public school teachers could explain that in a hands-on way?

Ever tried to explain to a thirteen year old how a microwave oven works?

My robocars are very hands-on and available. All the components are visible including the hook up wire. The little cars react dramatically to programming changes. How do I communicate that to adults schooled in Education, not Engineering or Computer Science.

Ken

Quote:

---

Originally Posted by Kenjones1935

....Ever tried to explain to a thirteen year old how a microwave oven works?

Ken

---

How Microwave Cooking Works

Do not under estimate their ability, the kids that is.
One example.
http://www.picbasic.co.uk/forum/showthread.php?t=10200

When YOU take the attitude that something is going to be difficult for someone to learn, then as long as YOU are doing the teaching it will be hard for them to learn.

Children are much easier to teach new concepts to than adults are. Adults "think" they know how things work. Remember the trouble you had with BASIC? That was because your understanding was based on pre-conceived notions from what you learned in the past. Children will not have that problem.

However, the only way to reach the students in a public school is through the teachers and the administrators. My question is what is the best way to communicate to them. It is a marketing issue. A teach-the-teacher issue.

Ken

Quote:

---

How do I communicate that to adults schooled in Education, not Engineering or Computer Science.

---

I do not think that should be a problem, many of the users on this forum do not have a formal background in Engineering or Computer Science. I will bet there are plenty of teachers that have RC or some other gadget related hobby. Do they have a "shop" class.

Market to the school district... How many school board members are in local industry? A google search makes me think that Parker has a lot going on in your area, New England Dairy Association, and of course the famous secondary schools in your area should make it easy to convince the schools of the importance.

I am getting closer. This video shows a 'real' car that can parallel park itself. Using bits from old videos plus some voice over I try to show that making radio control vehicles autonomous is relevant, practical, and fun. I believe there is great potential here for our public schools which are struggling with STEM.

http://www.youtube.com/watch?v=pZCdYcvYgM8

I've actually made three robots. new

* Reply
* More
o edit
o You can't chill your own stuff :)
o Report Spam

This morning I realized that I have actually made three different robots. Three different RC cars with three different physical charcteristics dictated this.

First I built the 1/10 scale model level car based on an HPI SPRINT. It has detailed miniature suspension and handling features, great speed, and proportional control systems based on pulse width modulation. My PIC kit for this car is simple because the controls are digital signals. All that is needed is the PIC and a DPDT switch. The switch - under PIC control - selects which PWM signals (those from the PIC vs those from the radio receiver) go to the steering and driving electronics. The PIC code is quite simple because of the car's capabilities. At $200 - $300 for the car and my kit this seems too expensive for our public schools.

Second I built a 1/12 scale toy level car. This car has bang bang controls. It requires the PIC, the SONARs and four DPDT relays to steer the DC current into the correct connections. It runs slowly enough for the PIC and the SONARs to keep it within reasonable behavior limits. It can be stopped in mid 'flight' by turning ON the radio transmitter. The price is right for our schools, but I feel the car is not fast enough nor exciting enough. It is also too small to carry my KIT under the car skin.

Third I built the 1/10 scale toy car. This car is much faster than the 1/12 scale toy. It too has no proportional controls. The added electronics kit is the same as the 1/12 car, but the code needed adjusting. ie the 150millisec pulses. I think the $50 car price is within budget. My KIT is complex because of the four relays, but hopefully doable by a dedicated teacher and class. The engineering is interesting because, as one of my videos shows, the behavior is a bit unpredictable. Maybe if I had some local help and a more sophisticated program ------

Ken

Happy New Year all.....

I have added another video It shows the performance of the 1/10 scale TOY car and two versions of the 1/10 scale MODEL car.

It shows the TOY and a MODEL racing. The lap counter (me) is lacking, but I think the excitement and the attendant appeal to middle school kids is evident.

http://www.youtube.com/watch?v=swYQBZSgtJg

Ken

Hello friends! Could someone please tell me how to do the PicBasic control two servo motors at the same time, a 100 by sending a pulse and another 50 using PIC16F628A

Quote:

---

Originally Posted by Magoga

Hello friends! Could someone please tell me how to do the PicBasic control two servo motors at the same time, a 100 by sending a pulse and another 50 using PIC16F628A

---

How about up to 9 servos? http://www.picbasic.co.uk/forum/cont...th-2-I-O-lines

Folks, I had an opportunity to show off my robocars on Fitchburg Access Television. I am in the second half of the show. If you like skip the first twenty three minutes twenty seconds.
http://prometheus.fatv.org/media/127...tchburg_10511/

Folks,
I have some grande ideas to improve the robotics of my robocars. Trouble is I need what in C are called functions.

Any hope in PICBASIC PRO for my 16F887? You all got any suggestions? My guess is that In order to translate my PICBASIC code to C I will need to learn PIC Assembly so that I can better understand what is really happening.

Has anyone done this? Did he/she create a mid-range PIC set of C libraries?

Ken

While any C compiler does certainly support functions, there are at least 3 dialects of BASIC for PICs that not only support functions but features such parameter passing, global/local variables, etc. that allow structured programming.

The code in my little cars is, in fact, very little. It only deals with distance. It does not calculate rates of speed, of approach, of turn. It does not calculate angles. It does no mapping.

Maybe my 16F887 based kit is not up to that task. I am not sure and I do not know how to find out. Maybe I could architect better in C, but it has been literally twenty five years since..... and I used to have a very extensive (corporate supplied) library.

Suggestions?

Ken

mbed is a tool for Rapid Prototyping with Microcontrollers mBed

Microcontrollers are getting cheaper, more powerful and more flexible, but there remains a barrier to a host of new applications; someone has to build the first prototype! With mbed, we've focused on getting you there as quickly as possible.

Huge library (check out the Handbook, Cookbook and Code pages), free IDE and C compiler. 100MHz 32-bit MCU, 512kB Flash, 64kB RAM.

mbed is ARM = RISC. I remember RISC from my days at DEC. For my robocars I chose the Microchip 16F887 because I stumbled upon and bought the PICkit 2 bread board system. Had the PICkit board come with 0.1" centers I would probably stayed with it. Now I use the PIC stand alone and solderless protoboard.

I am afraid to leave Microchip and associated vendors. I bought two UBW32 BITwackers then found that I could not program them with my version of PICKit 2. Also the UBW32 does not come in a 0.1" DIP package. I am also a bit confused where to go for help other than this forum.

Maybe I can stick with PICBASIC PRO if I can teach myself more about doing simple mathematics and array structures for data storage. I surely would like subroutine calls that accept parameters and return values.

Suggestions?

Ken

MicroChip also = RISC

Quote:

---

I surely would like subroutine calls that accept parameters and return values.

---

Just write a sub routine that will do what you want and GOSUB. Pretty much the same thing. Yes, the "C" folks will flame this. But it is true.

Quote:

---

Originally Posted by Kenjones1935

The code in my little cars is, in fact, very little. It only deals with distance. It does not calculate rates of speed, of approach, of turn. It does not calculate angles. It does no mapping.

Maybe my 16F887 based kit is not up to that task. I am not sure and I do not know how to find out. Maybe I could architect better in C, but it has been literally twenty five years since..... and I used to have a very extensive (corporate supplied) library.

Suggestions?

Ken

---

Hello Ken.

Sure, there are more powerful chips to use. There are also more powerful languages. But, the question is, what are you going to be doing, and do you really need to change chips, and or languages? So far, the use you have made the chip perform, is probably the equivalent of an old man walking with a walker. You have not taxed your current environment whatsoever! Sure, a lot more could be done, but I think, if it was done right, the most required might be an 18F device.

Currently, your PIC18F887 can handle 5 million assembly instructions per second. Your hardware (servo) can handle at maximum, 50 instructions per second (pulse width control at 50 hertz, or 20ms frames). So, with every chance to change your direction, your program can perform 100,000 assembly instructions. A lot of PBP code can fit into 100,000 instructions. That can basically go through every available code location (14k program space) on the chip seven times, during the 20ms it has to make a decision.

Seeing as you are hardly putting a dent in the 14k, shouldn't you at least try to do something more, before saying you don't think the chip can handle it?

Let's take a look at the items you mention:
Speed : This is relatively easy to do and will hardly take any code. Put a sensor on a wheel and away you go!

Approach of turn: You have all the distances measured, why not use them to in your control for turning. Calculate at what point in time will you be x length to the wall, and at this time turn, instead of saying "if my measurement is less than 4 feet, etc etc. Since you are only taking front measurements every 60ms?? or so, you might well be beyond the 4 feet by the time you measure.

Calculate angles: Cool idea. But with what sensors are you going to determine that? And how? PBP has SIN, COS, Hypotenuse and ATAN built in. Sure these are rough calculations, but I don't know that with your current sensors you will need (or be able to use) anything more advanced. Add a magnetometer http://www.sparkfun.com/products/9371 , and perhaps this could get more complex. If it does need to be more precise, there is a PBP compatible CORDIC include file to calculate SIN, COS, ATAN, Hypotenuse. See http://www.picbasic.co.uk/forum/showthread.php?t=10528 . On an 18F, you can do this 9,000 times per second while still using PBP in our program.

As for mapping, with your current set up, I would go out on a limb, and say that is impossible with any language. To map, you need to know where you are. You will need more sensors! A GPS (and a large outdoor "track"), or magnetometer, or light sensors that find at least a reference beacon, or barcode like strips on the floor, just to figure out where it is. Lots of ways to do it, some better than others.

So, from what you have vaguely mentioned, I see no barrier using your current chip, or using PBP. Can you be more specific about what function libraries you are talking about? What ever language you choose, you are going to have to decide how you are going to perform these functions, and what sensors you are going to use to do them.

I have not been planning on adding sensors. I might change the SONAR for IR. I know nothing about the details.

For speed I was planning on dividing distance traveled by time between measurements. For angles, I agree, the SONAR's have a vague and varying pattern. Hence the 'speed' calculations may be inconsistent.

With the hobby level car I have complete proportional control of both steering and wheel power. If I could get a PWM system that is truly 50htz (my present system is not. It was calibrated by trial and error) then I would have a great deal of flexibility - the better to speed up the car. Then a parameter passing GOSUB would be very convenient.

Ken

Quote:

---

Originally Posted by Kenjones1935

I have not been planning on adding sensors.

---

Then it sounds like PBP should be plenty powerful for your application. Only, I don't think you will be able to get into mapping, as there is no reference to where the car currently is. You could count turns, but once you miss or rather add a turn, then you are off. The only angle you could calculate, is the angle between the front location sensed, and the side position sensed in reference to being parallel with the car. You would not know whether this angle is being measured on a corner, or a straight away.

If you want to use accurate servo, you could use some of the code already pointed out to you.

(Ok, this one is kind of new, so no one suggested it yet)
http://www.picbasic.co.uk/forum/cont...th-2-I-O-lines

Back on post #336 of this thread:
http://www.picbasic.co.uk/forum/show...1961#post91961

Somewhere way back on this thread:
http://www.picbasic.co.uk/forum/cont...e-Servo-Driver

And suggested back on post #80 of this thread (though these later examples a lot better)
http://www.picbasic.co.uk/forum/cont...-encode-decode

I would like to read a TIMER immediately after sending a trigger pulse to my SONARS. Then immediately reset it for the next cycle. (Which TIMER am I not using with PAUSE or HPWM.) Anybody?

I want to calculate velocity. I plan to subtract two SONAR distance readings and divide by the time elapse between triggers. Units of distance sound travels in a millisecond (13.2 inches) divided by the number of milliseconds. (Could do no translation: Use the distance sound travels in a 4Mhz tick divided by the number of those ticks between SONAR triggers.) Could I explain that to middle school students?

I have not been translating SONAR echo pulses to inches. Instead I learned how to translate inches into SONAR echo times. That is how I set up my distance parameters. At 1100 feet per second that is 13.2 inches per millisecond. (When measuring distance the PIC must divide by two. It is measuring time for an echo response.)

Any simple code snippets you know of?

Ken

I would like to use the 4 Meg counter to measure time in seconds and the SONAR responses to measure distance in inches.

I could then set up CONstants that would be recognizable
and measurable by middle school students with a yardstick and a watch with a second hand.

How?

Ken

This displays the sonar distance in inches. Using the "ping" module from Parallex.

Code:

---

'  18F6680
    DEFINE OSC 20
    @ __CONFIG    _CONFIG1H, _OSC_HS_1H
    @ __CONFIG    _CONFIG2H, _WDT_OFF_2H & _WDTPS_128_2H
    @ __CONFIG    _CONFIG4L, _LVP_OFF_4L
    INCLUDE "modedefs.bas"
    DEFINE LCD_DREG    PORTG
    define LCD_DBIT    0
    DEFINE LCD_RSREG    PORTE
    DEFINE LCD_RSBIT    0
    DEFINE LCD_EREG    PORTE
    DEFINE LCD_EBIT    1
    DEFINE LCD_BITS    4
    DEFINE LCD_LINES    4
    DEFINE LCD_COMMANDUS    3000
    DEFINE LCD_DATAUS  150
    PAUSE 500
    PAUSE 1000
   
    INCONSTANT  CON 890
    INDISTANCE  VAR WORD
    TIME        VAR WORD
   
    START:
    HIGH PORTB.3
    PULSOUT PORTB.3,2
    PULSIN  PORTB.3,1,TIME
    INDISTANCE = INCONSTANT ** TIME
    LCDOUT $FE,1,DEC3 INDISTANCE," INCHES"
    PAUSE 100
    GOTO START

---

My robocars have no LEDs. They have no debugger and no break points. Using PICkit 2 I can read EEPROM. My code can write in that area using the WRITE command.

When I have my car on blocks connected via the PICkit2 USB cable, I would like to do a READ and see in the EEPROM section some words that the code placed there while it ran represented as decimal numbers.

hex includes the digits 0-9. Is there a library routine or a command to which I can give a WORD containing a positive hexadecimal number (for example the response from a SONAR) and it will return that number in decimal format represented with the digits 0-9 in least significant (as read by PICkit2) to the right?

Ken

You mean something like post# 649? http://www.picbasic.co.uk/forum/show...6577#post96577

But since you have a Pickit2, it would probably be nice to put your car on a bench, leave your Pickit2 tethered, and use the Uart Tool. You can give all kinds of info from your pic out to your computer screen. You can have it tell you pinged distances for both sensors, etc. It can be a really handy tool for trouble shooting. All you need is some debug statements giving you the right data.

Walter

At the time of that posting last November I did not understand it. Upon rereading I will try it. Where is the modifier "dig" mentioned and defined? I do not see it. Must be in one of the 'include' files. Yes?

I never figured out how to use the MPLAB debugger. I thought it was only good for simulation running on my PC. I will give it a try.

thanks again...
Ken

Hi Ken,

DIG is for digit. Nothing in there needs any include file. Dig is covered in the manual, but you have to look around a little bit for it. DIG returns the value of a decimal digit.

C var byte
D var byte
C=123
D = C DIG 0 ; Makes D = the lowest digit of C (3)

When I mentioned debug, I meant the DEBUG command. It lets you send serial out of any one of your PIC's pins. Then you can use the Uart tool on your Pickit2 to read any value you want. Much simpler than Mplab debugger if you ask me.

Attachment 5121



http://www.picbasic.co.uk/forum/images/misc/pencil.png

Hi Walter.

I saw this picture of Pickit2 with UART connection. Does the PIC connect to Pickit2 as TTL level serial link?

Ioannis

Hi Ioannis,

Yes, it takes TTL True, so Ken can do debug something like this for his setup:

Code:

---

DEFINE DEBUG_REG PORTB      'This is set to match the ICSP pins
DEFINE DEBUG_BIT 7          'PIC sends data to the PC on this pin
DEFINE DEBUGIN_BIT 6        'Can be used to receive data from the PC
DEFINE DEBUG_BAUD 38400    'This is the highest baud rate Pickit2 can handle
                            'It seems to work ok with my 8 mhz stuff and higher
DEFINE DEBUG_MODE 0        'Sets debug to True levels (1 for inverted)

---

My PICkit2 communicates with my PIC on its pins 4 and 5 already. Are you saying that after it is downloaded and running, my code can use the same USB wire to talk back to the PC? And I can display what it says using the DEBUG tool.

Ken