Using a new PIC part no. for the first time is always such an adventure.

I need to provide 32 logic outputs based on a serial transmission from a PC so I chose a PIC16F747. Serial output (status) from the PIC is also read by the PC. The 16F747 it would seem was a good choice. Up until now, I have been successfully using a PIC16F628A to do the same thing just with too few outputs for this project.

I am confident that the circuit board is correct. The PIC has duplicate Vdd and Vss which I have tied together and placed a .1u axial ceramic cap across. It is setup for ICSP and I have verified the existence of code and configuration in flash memory.

I cannot as yet get the PIC to blink an led on one or two of the pins. This is my initial way of checking for intelligent life in these little buggers. Since I am using the internal RC clock and I have no circuit traces on the board to support an external oscillator it is pretty difficult to see if there is a clock signal.

As an alternative test, I changed the configuration word to provide internal Osc with Focs/4 out on pin OSC2. When I use my logic probe (in pulse mode) to check OSC2 the pulse indicator appears to remain lit rather than pulsing which I don't understand unless the signal there is so fast that the probe indicator is flashing too fast for me to detect. (Yes I could use my old beater scope but it is borderline unreliable and a bear to set up.)

I have searched around in the documentation and have not found the default speed at which the internal RC oscillator runs. If it is remarkably fast, then what I am seeing at OSC2 in the test might make sense. In any case I need to know what this default is. Does anybody know what the default internal RC osc. speed is?

Secondly, as I have found with the 16F628A that the comparator module has to be specifically set OFF or PortA pins will misbehave. Are there any other modules which start by default which prevent any of the I/O pins from functioning as strictly I/O?

Attached are 3 photos of the board, the configuration as read from the PIC after programming, and the PicBasic code listing.

Default value is set to 32.xxx KHz, see
http://ww1.microchip.com/downloads/e...Doc/30498c.pdf

pdf page 40, OSCCON register

That's pretty slow. Just change OSCCON value and you can run it up to 8MHz

Next step, ADCON1 register, PDF page 155.

HTH

I spent 6 hours studying the docs. It didn't take long to get the oscillator right but disabling all the special purpose pins is a real bear.

Anyway, I got the USART working, partly anyway, I can get the PIC to output text to the PC via my serial cable and RS232-9 pin connected to TX pin, but sending characters back to the PIC into the RC pin, is really not working. I have set BRGH high (1) and SPBRG for 9600 (25) for the 4Mhz Fosc. Enabled receive and set all the other bits I can determine to be necessary. Still no go.

Maybe the internal RC clock is not precise enough. I am going to retrofit an external oscillator ext and see if that works, otherwise I've hiot another wall.

Anyone out there used this animal in USART implementation?

I know it's a long debate and some have success, some not, but i never suggest to use internal osc for reliable serial comm. BUT you can reduce the baudrate, say 2400 baud, and do some tests.

Use PICMultiCalc to get the USART settings for you.
http://www.mister-e.org/pages/utilitiespag.html

Yours seems to be the good one... just post your code here and maybe we could suggest you few things.

Pretty cool calculator. Looks like you have a pretty good handle on DataComm.

I'm going to retrofit the external osc. tonight and see what happens. I only have two osc. right now that run at 4Mhz. That has always been fast enough on my 16F628A's to get 9600. In my real time application though, 2400 might be enough.

I refined the code last night and will work on it again tonight, so I could attach it as a .txt file tomorrow.

I found and 8Mhz osc. laying around and put it into the circuit. With the specs. from the baud calculator inserted into the code the code ran first time out giving me accurate I/O from the PC. Now I'm just one pin short of getting 32 outputs. I'll probably be forced to use the input only MCLR as a DebugIn and another one for DebugOut instead of the hardware serial. That would free up C6 & C7 for outputs.

Thanks for the pointers.

well, there's always pros and con for using external OSC, if you have many push buttons, you may use the ADC and read from it. a r2r network and ADC can work with at very least 16 push buttons. many many stuff can be multiplexed as well.

You could also waste your time and try to tweak the internal osc using OSCTUNE... as i said... a REAL waste of time knowing the cons of internal RC osc for reliable timing needs.