Soft UART and Int_Ext

John Morley · Joined: 09 Aug 2004 Posts: 97

Hi All,

I need to add a second serial port to a project that uses the PIC16F73. I can't get this to work using the Int_EXT interrupt and pin B0 as my receive data input. I have an interrupt service routine for buffering incoming serial data that works quite well with Int_RDA, so I've modified it a bit but it does not work with Int_EXT.

Here is the ISR:

mmprestine · Posted: Wed Sep 13, 2006 1:32 pm

You may need to add the invert option to the #USE RS232 statement.
Matt

asmallri · Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia

You did not say what was actually wrong. Are you receiving garbage characters?

Are both ports meant to be receiving concurrently? - If so as a minimum you will have to ensure the ext int has higher priority or the bit timing will be screwed up.

You can optimize the ext_int handler. You do not need the tempory character.

Ttelmah · Guest

Actually though, the version with the extra temporary store, will be faster.
Accessing an array variable, involves reading the index, adding this to the origin of the array, putting the resulting 16bit value, into the table address registers, then accessing the value through the indirect addressing register on the PIC. Typially about 10 instructions. Accessing an integer at a fixed location in memory, involves just one instruction.
Raising the priority of INT_RDA, will only help this 'pre-empt' the other interrupt. If the code is already in the INT_RDA handler, the timing will still go to pot.
It might be worth trying the option 'SAMPLE_EARLY' on the software serial setup. The problem is that the software serial, when 'fgetc' is called, checks to see if the signal is low (or high with INVERT), and then waits half a bit time, before reading the bit. It then repeats at bit time intervals, to get all the bits. Now with the interrupt based handler, when fgetc is called, the signal has already been in this low (or high) state, for perhaps aout 30+ instruction times, and the sampling is then 'late' all the way through the character. Sample early, makes the routine start reading immediately.
You also don't show the setup line for the external interrupt. The interrupt needs to be set to interrupt on the falling edge of the start bit (int_h_to_l), for normal serial (or the rising edge with inverted serial).

Best Wishes

John Morley · Joined: 09 Aug 2004 Posts: 97

Hi,

Thanks for the suggestions Asmallri and Ttelmah!

The problem is that the complete string is never received. I sit in a While loop inside Main looking for Rx_Command_Ready to be true, but it never happens. I've been reluctant to put much extra code inside the ISR for fear of adding too many extra machine cycles in case timing is critical. When I add this code to the ISR:

asmallri · Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia

Hi John,

What other interrupts do you have enabled in the application?
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

John Morley · Joined: 09 Aug 2004 Posts: 97

Hi Andrew,

Actully, no other interrupts. I've reduced my code to a while(1) loop inside of Main checking for the RX_Command_Ready to become True, and the ISR itself. Still, no luck. The ISR is firing, and I get the first character, but nothing else.

I guess I'll try other baud rates and see if that is a factor?
_________________
John Morley

asmallri · Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia

Do you have a LED you could toggle for testing? If so inside the ISR toggle it each time on entry. You should see it toggle each time a character arrives. This will narrow the probem down for you.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

Ttelmah · Guest

How are the characters being sent?.
You are printing a _string_ from the printf, which requires the character buffer to be null terminated. Unless this is true, the print, will carry on printing other things, and may take ages to do so. Also, even if the buffer is properly terminated, you are printing three characters minimum (the line feed/carriage return, plus the single character present from the first receive). This will delay the code for one character time, meaning that a second character will now be missed (there is only 1.9999 characters of buffering in the transmit hardware). So even if the code was working OK without the printf, it now won't be...
Toggle the pin as Asmallri suggests. This only takes a few uSec, and will avoid introducing timing problems.
Your compiler is very old. I didn't really feal that it worked properly for the '18' chips, till the mid 200's, however for the 16 chips it generally did get going OK earlier. Sample early is probably about 50 versions latter.

Best Wishes

John Morley · Joined: 09 Aug 2004 Posts: 97

HI All,

OK, I've added a couple of lines of code inside my receive ISR to toggle an LED. It blinks sporadically, but only when data is being sent to the receiver. Based on this I'm pretty sure that the ISR is being triggered at least once for each time the transmitted data is received.

I am sending data from a second PIC using this code:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

John Morley · Joined: 09 Aug 2004 Posts: 97

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

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

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

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