 |
 |
| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 Posted: Fri Sep 15, 2006 9:21 pm |
 |
|
| Quote: | #define RS232_OUT PIN_A4 // RS232 Output to Terminal
#define Aerocomm_Tx PIN_B4 // TTL serial data to Aerocomm
#define Aerocomm_Rx PIN_B0 // TTL serial data from Aerocomm
#use rs232(baud=9600, xmit=RS232_Out, stream = Console, Restart_WDT)
#use rs232(baud=9600, xmit=Aerocomm_Tx, rcv=Aerocomm_Rx, stream = Aerocomm, Restart_WDT) |
Why do you have to run two soft UARTs ? The whole problem with
a soft UART is that the processor must "camp on" the UART pin while
it's receiving or transmitting a byte. It can't be interrupted, or in
the case of receiving, it can't be delayed from gaining access to the
pin, or you might lose the byte.
You have a hardware UART in the 16F73 on pins C6 and C7. Use it. |
|
 |
John Morley
Joined: 09 Aug 2004
Posts: 97
|
|
| Posted: Fri Sep 15, 2006 9:56 pm |
|
|
Hi PCM,
Actually, in the final implementation of my system, wireless data will be received by one software UART using the B0 pin for reception, and then retransmitted over an RS485 network using the hardware UART on C6 and C7. The other software UART that is being shown now is only being used for diagnostics. At the moment, everything is stripped from my program except the wireless reception module which I am now trying to get working.
BTW, this is part of a distributed lighting control system, for lighting control in 5 buildings. A base unit sends commands wirelessly to five possible remotes. If addressed, the remote then communicates via RS485 to switch on/off the appropriate light. There will never be any simultaneous data transmission on the soft and hard UARTs.
I've got all the individuall pieces of code, except the wireless data reception, working flawlessly. Once I solve this dilemna, I'll combine all the pieces to complete the final system.
Thanks for the input!
_________________
John Morley |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sat Sep 16, 2006 7:22 am |
|
|
Something totally different, but why are using the old PIC16F73 in a new design? Something funny in the Microchip product line is that the newer chips have more features and are cheaper. My main problem with the PIC16F73 is that it has no breakpoint register for the In Circuit Debugger (ICD) which makes debugging a lot more difficult.
For example you could consider the PIC16F690 which is cheaper and as a bonus has Data EEPROM, larger RAM, 10-bit ADC instead of 8-bit, 2 comperators and 1 ICD breakpoint. Problem could be that with 20 pins it has not enough I/O pins, in that case have a look at the 28-pin 16F916 or 40 pin 16F917.
Using the Filter options on the Microchip website it is easy to compare all features of the mentioned chip versions. |
|
|
John Morley
Joined: 09 Aug 2004
Posts: 97
|
|
| Posted: Tue Sep 19, 2006 8:02 pm |
|
|
Hi All,
Well, after being away from this problem for a few days, I took a look at it again today. First, I did what I should have done from the beginning. I'm trying to get two PICs to communicate wirelessly using a pair of Aerocomm AC4490 wireless modems. These modules can be configured a direct serial cable replacement. Anyway, I disconnected the modems and connected the PICs directly together. Voila! Perfect communications! Now, I reconnected the Aerocomm modems and found that I'm receiving only the first couple of characters of my receive string. Another thing I should have done earlier was to put a scope on the Rx pin of the receiving PIC. What I found might explain the problem I am seeing: The AC4490 is a 3.3V part but it can be powered with +5V as I am doing. The I/O of the module (including the Tx and Rx pins) are all 3.3V out max however. The only difference I see on the scope between the working condition (PIC to PIC directly) and the non-working condition (PIC to PIC with wireless modem) is the 0 to 5V swing of the direct connect, versus the 0 to 3.3V swing of the modem connection. I could not find anything in the datasheet that addressed this issue, so I'm not sure if this could be an explanation for why I am not receiving all the characters with the wireless modems in place?
Finally, I am using the 16F73 for code development as I have some prototype boards left over from a previous project. The final version will probably use a more modern PIC.
Thanks,
John
_________________
John Morley |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Sep 20, 2006 2:21 am |
|
|
Tie a diode, to the 3.3v rail, with a pull up resistor to the 5v rail, to generate a nominally about 3.9v rail. Then tie a pull up resistor to this new rail, onto the signal. 3.3v outputs, are normally able to be pulled up to 0.6v above the internal supply without problems. A 3.3v output, is adequate to drive a TTL 5v input, but not a 'schmitt' 5v input. The serial inputs on the PIC, have schmitt input buffers (actually require 4v, to be 100% guaranteed to work when running from a 5v supply). Aternatively, just stick a TTL buffer between the signal and the PIC.
Best Wishes |
|
|
John Morley
Joined: 09 Aug 2004
Posts: 97
|
|
| Posted: Tue Sep 26, 2006 8:02 pm |
|
|
Hi All,
I finally had a chance to look at this problem again, and actually made some progress toward a resolution. To review, I'm trying to get two PIC's to communicate wirelessly using Aerocomm AC4490 modems. The transmitting PIC sends a string (example: #N00:04:00<CR>) and the receiving PIC receives the string. The receiving PIC uses an interrupt drive receive routine using INT_EXT and Pin B0 (the hardware UART is used for something else).
| Code: |
#INT_EXT // Interrupt driven RS232 routine
void rs232_isr(void)
{
char temp; // local data storage
temp = fgetc(Aerocomm); // get rx data
output_toggle(Relay2_Out);
ISR_Loops++;
// If we got a '#', then the command is beginning.
if (temp == '#')
{
Serial_Index = 0;
RxBuffer[Serial_Index] = temp;
Serial_Index++;
return;
}
// If we got a CR, then the command is completed.
if (temp == CR)
{
RxBuffer[Serial_Index] = temp;
RX_Command_Ready = TRUE;
return;
}
// Save the character to the receive buffer.
RxBuffer[Serial_Index]=temp;
// Check for buffer overflow.
if ( Serial_Index >= (RX_SIZE - 1) )
Serial_Index = 0;
else
Serial_Index++;
}
|
The problem I was having is that the ISR appeared to be receiving all garbage characters. I then connected the two PICs together directly without the wireless modems (no software changes) and the code worked perfectly. Then I connected the receiving modem data output directly to a MAX232, and found that I was receiving the transmitted string 100%. These two facts appear to confirm that my software and the wireless link are fine! The only configuration that didn't work was when the wireless modem was connected directly to the PIC. I looked at the data output from the receive modem on a scope and found it was only swinging to 3.3V (the modem is a 3.3V part with 5V tolerant I/O). I added a two transistor buffer to the PIC input to boost the levels up to 5V but did not see any improvement in the garbage characters that were being received.
Finally, I started analyzing the data that was actually being received and noted that it was not random. In fact it was the same for each data transmission (the same transmission was being sent continuously). Next I added a counter increment inside my ISR and found that the ISR was being entered the same number of times (11) for each data transmission. Now, here is the strange part. Inside of Main, I wait for a flag that marks the receipt of a complete receive string. If this flag is true, I print the receive string.
| Code: |
while(1)
{
// Here we have some serial data to process
if ( RX_Command_Ready == TRUE )
{
// Just to be safe, first things first...
disable_interrupts(GLOBAL);
RX_Command_Ready = FALSE;
fprintf(Console, "%s\n\r", RxBuffer);
// Serial command has been processed so we re-enable RS232
Serial_Index = 0;
enable_interrupts(GLOBAL);
}
|
The strange thing is that this code works fine when the PICs are directly connected, but prints garbage when they are connected using a wireless modem.
If I change the code to do this instead:
| Code: |
while(1)
{
// Here we have some serial data to process
if ( RX_Command_Ready == TRUE )
{
// Just to be safe, first things first...
disable_interrupts(GLOBAL);
RX_Command_Ready = FALSE;
for (Loop_Index=0 ; Loop_Index<ISR_Loops ; Loop_Index++)
fprintf(Console, "%c\n\r", RXBuffer[Loop_Index]);
ISR_Loops = 0;
// Serial command has been processed so we re-enable RS232
Serial_Index = 0;
enable_interrupts(GLOBAL);
}
}
|
Each character is printed correctly even though the hardware configuration hasn't changed at all - when the wireless modems are connected!
So, what am I missing here? Printing the receive string at once using "%s" works for some hardware configurations and not others, and printing using "%c" is the only thing that seems to show me the proper receive characters when I'm using the wireless modems.
I admit this has me stumped. I did upgrade to the latest version of the compiler v3.249.
_________________
John Morley |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
