MOSFET/circuit troubleshotting :-\

Do you have them configured as open-drain outputs with weak pull-up? Are you even sure you have them configured as outputs?

Sanity check: what does the voltage on the Vdd pin measure? Is that 4.5V??

Yep.

Wha?! :-\ I know about weak pull-ups for inputs, but didn't realise there was anything for outputs...

Nope.

I've checked the datasheet (PIC12F629) re Q2, and can't find any mention of what you suggest - aand weak pull-ups it says are for inputs, and are disabled for outputs...

If I tie the inputs high (to Vdd), instead of leaving them unconnected (with pull-ups, they're high anyway), the voltage on both output pins doubles when high (around .6 and 1.19)

I'm *totally* confused!

I had S and D the wrong way around (my diagram was drawn from the bottom, and I was looking at the top of the MOSFET).

I'm still stick on the output voltage being too low :-(

Got a simple circuit, I've even tied MCLR to Vdd via a 1K resistor as the datasheet says...

I think Anthony has spotted the problem. You're switching the outputs on and off in a loop! Your meter is reading the average value of a high-frequency square wave.

The motor failed to turn at all, it wasn't just slow (this is after I got the rest of the stuff the right way round ;))

I did (10K), but it made no difference. Internal pull-ups are enabled, and I now leave the pins unconnected.

My current circuit is 4.5V to Vdd, with a 1uF cap across Vdd to Vss. Vdd and MCLR are connected with a 1K resistor. GP4 and GP5 are unconnected (outputs - I'm putting my meter on these), and GP0, GP1 and GP2 are left unconnected (I've connected these to ground to test "low" output readings).

I've changed this. I used the drop-down boxes in MPLAB and set the options, and it generated 3A4. After posting that code, I checked everything in the datasheet, and changed it to 1A4 after coming to the same conclusion!

Updated code is below. Setup is as described above...

You're right!! My output is reading really low on my meter, because it's off for *most* of the time! Stupid fool! I'll change the logic to "buffer" it (like further down, or I'll call the delay after turning the motors on).

Don't I feel stupid!

Thanks - it's really appreciated!

ground?

to be

Some PICs (many actually) have some open collector output pins. They are not configurable, you just have to know that they exist and deal with them appropriately. I checked the datasheet and your PIC (12F629) does not appear to have any open collector outputs. Open collector means that the output pin cannot output a 5V driving signal, it can only pull low. This means that the pin cannot *source* and current, it can only *sink* it. If the pin is being used as an output pin and you wish to drive say an LED, you would use an external pull-up resistor to supply the positive voltage to illuminate the led and then turn it off by driving the pin low. Open collector outputs are common in the micro world.

mention

are

Never leave input pins unconnected, always have some kind of pull-up or pull-down resistor applied, be it internal or external. The code I saw in a.m.8 has the internal pull-ups disabled, so I hope you have external pull-ups applied to the input pins.

I'm not getting 2-3V (with delays added after the motors are turned on). This is only on the pin with my LED though (measuring voltage in parallel with the LED).

The time spent "high" is more than enough to make the LED look like it's lit constantly, but obviously wasn't enough to drive the MOSFET.

I'll re-write my code later, before re-connecting the motors and see how it goes!

Thanks all! :)

I don't know what particular MOSFET he's using, but if it has an internal protection diode and is put in backwards, wouldn't this happen?

Buffer it. Don't just put in a delay. You'll needlessly create glitches if you rapidly switch it on and off; even if it's only off for a micro-second. That would be sloppy. You shouldn't need a delay if you're doing it right.

Yes, they're *definately* outputs. I don't understand what open drain or weak pull-ups are. The only reference to either of these are weak pull-ups for inputs, which are disabled for outputs :-\

As you've probably seen elsewhere, I've got it sorted now, it was down to the logic of my programming. The pin was high less than half the time, so although enough to light an LED constantly, it wasn't enough to drive the MOSFET. Thanks for your help, sorry I didn't post enough info in this group to show what was wrong!!

It did :)

Ok, I'll change this. Does it really make that much difference, it's only one wires length from ground anyway? :-\

I don't remember what I posted then, but bit 7 of my INPUT register is current set to 1, to allow pull-ups. The individual pull-ups are enabled on power :)

I agree, I meant for testing. It worked, and I'll write it properly now :-)

Thanks again,

I've changed my code, it now looks like this:

Start clrf TMPOUT ; Clear temp output btfsc GPIO,2 ; If left sensor is high bsf TMPOUT,4 ; Right wheel on! btfsc GPIO,0 ; If right sensor is high bsf TMPOUT,5 ; Left wheel on! btfsc GPIO,1 ; If front sensor is high clrf TMPOUT ; stop all! movf TMPOUT,0 ; Move output movwf GPIO ; To GPIO GOTO Start ; Start again

My question is... If I had a third output, the "Stop all!" line would turn it off. Is there any way to clear two bits and leave the other 6 unchanged, without having to do:

btfsc GPIO,1 ; If front sensor is high bcf TMPOUT,4 ; stop left! btfsc GPIO,1 ; If front sensor is high bcf TMPOUT,5 ; stop right!

Since this wouldn't necessarily be consistant (if the sensor switches between those lines), which probably means reading from GPIO onto a temp register, then processing here. Writing bytes with unchanged bits would be much better!

I've corrected that, the front sensor is low to say stop, whereas the other sensors are the opposite

to

turning

glitches if

micro-second.

right.

I completely agree.

or

saw

external

enabled

Bit 7 of the OPTION register is /GPPU (active low). Setting it

Doh!

Been a long few days... Corrected now - setting my option register to 0h.

Ta :)

glitches if

micro-second.

right.

That should work better. ;-) Now stop using 0 and 1 when you should be using 'W' and 'F'. Not all PICs are consitant on the values, that's why you should use the include file.

LIST P=12f629 INCLUDE "p12f629.inc"

Put that near the top of your program and then use STATUS, RP0 instead of STATUS, 5 etc... You would also not have to define all those constants yourself.

Instead of this:

TMPOUT EQU 20h ; Temp output for motors COUNT1 EQU 21h ; Delay counter1 COUNT2 EQU 22h ; Delay counter2

try doing this:

cblock 0x20 TMPOUT COUNT1 COUNT2 endc

temp

would

Writing a byte to the GPIO port that doesn't change the values will not cause any glitches.