| View previous topic :: View next topic |
| Author |
Message |
John Morley
Joined: 09 Aug 2004
Posts: 97
|
| Baud Accuracy Calculations..... |
 Posted: Thu Oct 27, 2005 1:54 pm |
 |
|
Hi All,
I'm updating an old design with a text-to-speech voice synthesizer. Originally, the product was programmed in .asm and had no voice output. The new version is programmed in CCS C and uses a 2400 baud serial interface to the voice module. The old design uses a color burst crystal (3.5795 MHz) for the PIC, and I'm more or less stuck with it because it is shared with another chip (DTMF decoder). The problem I'm having is that everything works properly except the voice module, and I think it's a baud rate issue. I know I've seen it before, but I can't seem to locate the document on estimating baud accuracy based on different crystal frequencies?
At 2400 baud, I measure a bit time of 416 uS which varies from theoretical (436 uS) by 20 uS or about 5%. Is that far enough off to be a likely culprit??
Thanks,
John
| Code: |
//-----< Include Files, setup fuses >-----
#include <16f628.h>
#fuses XT, NOWDT, NOPROTECT
//-----< Compiler use statements >-----
// Tell compiler clock speed is 3.5795 MHZ Crystal
#use delay(clock=3579500)
//-----< Serial Port Definitions >-----
#use rs232(baud=2400, xmit=Voice_Out, ERRORS, BRGH1OK, STREAM=Speech)
|
_________________
John Morley |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Oct 27, 2005 2:13 pm |
|
|
| Quote: |
At 2400 baud, I measure a bit time of 416 uS which varies from
theoretical (436 uS) by 20 uS or about 5%. Is that far enough off
to be a likely culprit?? |
How do you get 436 us as the theoretical bit period ?
1/2400 = 416.66 us |
|
|
John Morley
Joined: 09 Aug 2004
Posts: 97
|
|
| Posted: Thu Oct 27, 2005 6:43 pm |
|
|
PCM,
Duh....... For some reason I had it in my head that that bit time at 9600 was 109 uS and thus 2400 would be 436 uS........ Sigh! Stupid in = Stupid out!!
Well, that still doesn't solve my problem  . This design differs from my "normal" designs in two ways:
The use of an MCP-100 voltage supervisor on MCLR instead of a plain old 50K pull-up resistor. The MCP-100 is connected through a 50K resistor so I can use ICSP with the ICD-U40.
The use of an external oscillator source attached to OSC1 instead of a crystal.
Now, I've got to see which one is causing me fits! Strange, it seems like the design is periodically resetting, so I'm going to look hard at the MCLR issue...
Thanks!
John
_________________
John Morley |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
John Morley
Joined: 09 Aug 2004
Posts: 97
|
|
| Posted: Fri Oct 28, 2005 3:57 pm |
|
|
Hi,
I got rid of the voltage supervisor on the MCLR pin and replaced it with the usual 50K resistor. I also added a dedicated 20 MHz crystal to the PIC. Neither of these "solutions" completely cured the odd behaviour I am seeing. This is the first time I've used CCS with the 16F628 device, and my version of the compiler is somewhat dated, so I wonder.......
Compiler Version: 3.162
Here is a small test program:
| Code: |
//-----< Include Files, setup fuses >-----
#include <16f628.h>
#fuses HS, NOWDT, NOPROTECT
// Tell compiler clock speed is 20.0 MHZ Crystal
#use delay(clock=20000000)
//-----< General Program Defines >-----
#define PTT_Out PIN_B1 // PTT Output (active hi)
#define Relay1_Cntl PIN_B5 // Relay 1 Output (active hi)
Main()
{
disable_interrupts(GLOBAL); // all interrupts OFF
setup_comparator(NC_NC_NC_NC);
setup_ccp1(CCP_OFF);
// Here we setup the initial state of variables and the digital I/O.
Output_low(PTT_Out);
Output_low(Relay1_Cntl);
delay_ms(2000);
Output_high(PTT_Out); // be sure to turn the PTT ON!
delay_ms(2000); // delay 2 seconds
Output_low(PTT_Out); // be sure to turn the PTT OFF!
while(1)
{
Output_high(Relay1_Cntl);
delay_ms(2000);
Output_low(Relay1_Cntl);
delay_ms(2000);
} // while
} // end Main
|
Both outputs are connected to LEDs. The code seems to execute for a while, but periodically will reset and the first LED that is supposed to only blink once, will blink again. Also, if I touch the crystal or wave my hand near my board it will spontaneously reset. I suppose it could be a hardware issue, but this design has been in service for a long time (running a program written in assembly), so I don't know? Is there some feature of the 628 that I'm not using that is ON by default that is causing this behaviour??
Thanks!
John
_________________
John Morley |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Oct 28, 2005 4:05 pm |
|
|
I'll look at the .LST file, but the first thing to do is to add
BROWNOUT, PUT, and NOLVP to the fuses.
Also confirm that you're running at +5v.
----------
OK, I looked at the .LST file and I didn't see anything wrong with
the code generated by your version of the compiler. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Oct 28, 2005 5:07 pm |
|
|
| Quote: | | Also, if I touch the crystal or wave my hand near my board it will spontaneously reset. |
Sounds like a hardware issue to me.
| Quote: | | I suppose it could be a hardware issue, but this design has been in service for a long time |
The design is old but you are making modifications to the hardware, this makes me think you are using a new PCB.
Do you currently have any unconnected pins on the PIC?
The response to your hand sounds like an open input picking up noise. By default most PICs start up with the I/O pins set as inputs. Open input pins are sensitive to environmental changes (finger touch, etc) and in undefined state can start oscillating, easily consuming 10+mA currents (not dangerous to the chip). Depending on the quality and decoupling of your power supply this could reset the CPU resulting in the described behaviour. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Oct 28, 2005 5:55 pm |
|
|
| Quote: | | Strange, it seems like the design is periodically resetting, so I'm going to look hard at the MCLR issue... |
| Quote: | | Open input pins are sensitive to environmental changes (finger touch, etc) |
If he has those, it should be corrected (set to them outputs, and set
them low).
But the most likely reason for the random "resets" is the PGM pin left
as a floating input with the LVP fuse enabled. (which is the factory
default from Microchip). Add NOLVP to the fuses to fix this. |
|
|
John Morley
Joined: 09 Aug 2004
Posts: 97
|
|
| Posted: Mon Oct 31, 2005 3:12 pm |
|
|
Hi PCM,
Well, the proper Fuses declarations have my hardware working like a champ  !! Man, I probably would have solved that eventually, but you sure did save me a lot of time!! I also learned an important lesson to carefully check the Fuses when moving from device to device!!
Thanks Again!!
John
_________________
John Morley |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
