Invisible RS232 Serial Buffering code

[cgriffin]

I am moving to 18F's, myself. The code specifies 18F only, though, and considering the compiler was designed for a variety of PIC series, I was wondering if it could be used with more of them with minor tweaking.

[cgriffin]

Oh, yeah... on top of that, there are numerous applications where you might not want your PIC as large as an 18 pin device.

[ricky]

Originally Posted by cgriffin

Oh, yeah... on top of that, there are numerous applications where you might not want your PIC as large as an 18 pin device.

I think the most difficult thing about implementing an interrupt handler within Proton is making sure that you don't clobber any of its workspace. The obvious thing to do is to use assembly language, but then you have the problem of switching banks to access any required variables and arrays (this is pretty much irrelevant on the 18F parts because of the MOVFF and LFSR instructions.) Something tells me that there are macros which you can use in your asm to switch over to whatever bank a variable is located in, but I can't remember any details.

[Tim]

Interrupts in basic are very very simple. No need for asm at all.

I write absolutely huge sections of code in interrupt routines but I then read the manual first and watch what system variables are used.

ricky why have you not registered as a licenced user and tried out the new beta and used the new interrupt handling system?

The macros system is BISVS but that is obsolete now that the new Beta is out.

[Michael_L]

Hi,
I am using the invisible RS232 Serial buffering code in a data logger application together with SD/MMC card library. In addition, besides running unattend (remote locations), the application is meant to run with a PC host program via RS232/RS422. The host program polls the data logger hardware every second for data sets. I am using a 18F6722, 20 MHz. The data logger uses the EEPROM for some internal tracking issues, i.e. writes once a minute a byte and a dword to the EEPROM. When I started testing the setup for extended periods I've notized that after a couple of hours (12 - 24 h) the total EEPROM was overwriten (which in addition to the tracking variables holds some constants for calculating physical values from AD readings as well as a serial number and other house keeping data). I've switched to the beta compiler for better interupt handling (especially saving of system variables). No good. Since Friday the system runs flawless. What I did was to switch of interrupts (clearing GIE) at times when the PIC was writting the EEPROM. The 18F6722 manual states that its strongly recommended to switch of interrupts during EEPROM write operations. If I understand the assembler produced by the compiler right that is not happening (at least not in the EEPROM write routine). I assume that an interrupt event during the EEPROM write routine leaves the PIC after the return sometimes (not always) in an undefined state (?). Any other idea would be appreciated. My other concern is: Are there other routines which require absolut hardware access which I did not find up to now (for example writting the MMC card)?
Greetings, Michael

[Tim]

Not fully correct in answer to your post but...

You do need to think about interrupts and eeprom writting and I as a matter of cause I turn off interrupts before doing so. However 5ms which is the average write time is a long time and you could miss chars coming in via USART.

The solution is to time your eeprom writes in between the data packets. I.e. If your receiving set packets of data then set the eeprom write to occur when you see the whole packet has arrived.

There are no other issues that I am aware of that are effected like the Eeprom in relation to being interrupted (hardware wise)

One last thing writing to Eeprom every 5 mins will mean that you may have burned out the Eeprom in less than a year. Something to think about.

[Michael_L]

Hi Tim,
thanks for the answer.
To clarify things: first of all, the host program requests are coming asynchronous and not predictable. For example: "Send me data", "Send me your current RTC time" etc. In between, the host program user might request something. So, no way in predicting whats and when requests are coming.
For writing the EEPROM: I am not writing the same cells every minute but instead use a range from $200 - $3FF. Where I change cells every minute.
What I've meant with potential other issues: The SD/MMC card library uses either the hardwaer SPI port or a software SPI solution. Thats something which might be affected. The other one is the second RS232 in the 18F6722. I am using that to listen to the output of a GPS modul and determine time, date and position. Is that affected?
Greetings, Michael

[Tim]

SPI port either serial or software is clock based so it can stand some clock stretching. The second rs232 your talking about is Usart based not software I take? Software based 232 timing would be damaged by the interrupt.

I would also consider not using the built in Proton context save interrupt routines as they impose an big overhead with all the system var saving it does.

However if your running at a low baud rate then it might not be an issue, say 9600.

[senacharim]

All you need to do is have a query/reply system which is flexible enough to account for missed characters in the fifo uart buffer.

Or even better, since the buffer is only 2 characters deep, have a two character query sent from the controlling computer, followed by waiting for the response. If the pic is busy (but watching the hardware uart flag) then the moment it can process the query it will do so.

[Michael_L]

Hi senacharim,
so, what you are saying is to switch off interrupt handling all together? The implementation right now is in a way that the host program sends the requests and the hidden buffer system the PIC handles the outside requests when its idle.
Tim: I agree with what you are saying about SPI. I guess the same holds for I2C, cause its also clock driven.
Greetings, Michael

[senacharim]

Originally Posted by Michael_L

Hi senacharim,
so, what you are saying is to switch off interrupt handling all together? The implementation right now is in a way that the host program sends the requests and the hidden buffer system the PIC handles the outside requests when its idle.
Tim: I agree with what you are saying about SPI. I guess the same holds for I2C, cause its also clock driven.
Greetings, Michael

If you're using an 18 series pic, it has a 2byte deep hardware fifo buffer. The interrupt flags are queryable, so as long as you regularly query the bit indicating whether or not the uart buffer is empty, you should have no need of interrupts for what you've described.

[bill9399]

Originally Posted by Michael_L

To clarify things: first of all, the host program requests are coming asynchronous and not predictable. For example: "Send me data", "Send me your current RTC time" etc. In between, the host program user might request something. So, no way in predicting whats and when requests are coming.

Can you implement handshaking between the pic and the PC?
One extra pin to drive the CTS/RTS lines (with appropriate line drivers) to the PC.
Put the pc comms on hold while writing to the eeprom.

[Michael_L]

Hi,
unfortunately, there is no spare wire for a CTS/RTS handshaking.
In any case, I abandoned the interrupt idea all together. Too much hasle and no big return value in terms of system responsiveness.
Greetings, Michael

[dolci]

Hi Les,

Since you publish this great program I use it in every RS232 communication project. Now I am planning to use it for RS485 communication (SN75176). The thing is the RS485 chip need to set the direction manually by the program. As you said it is invisible from the user, and I am no to macro. Where can I add the line for enabling the send/recieve of the chip.

Kind Regards,

[Tim]

The decision to control the direction will be in the main code, probably around the TX commands so I would place them there.

[dolci]

Thanks for the reply Tim. Thats clear my confusion. In the beginning of my code I should enable the recieve pin then while sending do the reverse.

[rcurl]

Another way you could deal with the problem would be to use an autodirection RS485 transceiver, like the Maxim MAX13410. Lots of their transceivers have this feature.

-Rick

[dolci]

Hi Tim

Can I disable interrupt in the main code then enable it again as follows?

From Les INIT_USART_INTERRUPT MACRO
INTCON = %11000000 ' Enable global and peripheral interrupts
Data Recieve

From Main Code
INTCON = %00000000 ' Disable global and peripheral interrupts
Do something

From Main Code
INTCON = %11000000 ' Enable global and peripheral interrupts
Again wait for data



Hi rcurl
Yes that was a good advice. I googled the net and I found a circuit for autodirection. It use a transistor and a few resistor. The second one use a 555IC configured as monostable.

[Tim]

Hi yes you can

However with the 485 coms set to output only then no interrupts should occur any case.

[dolci]

Originally Posted by Tim

Hi yes you can

However with the 485 coms set to output only then no interrupts should occur any case.

I think I got your point. If 485 is set to output then incoming data is block. In that way the pic is free for any task. Is that correct? Thanks!

Another question. I setup another rs communication on another pin for the serial GLCD. Is that ok?

' USART DECLARE
Declare HSERIAL_BAUD = 115200 ' Set baud rate to 9600,38400,115200
Declare HSERIAL_RCSTA = %10010000 ' Enable serial port and continuous receive
Declare HSERIAL_TXSTA = %00100100 ' Enable transmit and asynchronous mode
Declare HSERIAL_CLEAR = On ' Enable Error clearing on received characters


' GLCD Printing
Declare RSOUT_PIN PORTB.4
Declare RSOUT_MODE 0
Declare SERIAL_BAUD 9600
Declare RSOUT_PACE 200

[Tim]

Bear in mind that bit banged serial coms is timing critical and you need to prevent its being interrupted.

What speed is the USART com's?

If its = or less than the bit banged then you can find a system that will work. That involves sending 1 char at a time to the GLCD. But I would need more info on what your going to send to be able to advise on details of the system.

[dolci]

USART PIN for 18f2620
TX portc.6
RX portc.7
Speed 115200

RSOUT PIN
PORTB.4
Speed 9600

Yes TIM I am aware about the critical time of bit banged coms, it happened to me in one of my project. That is why I want to disable the interup while sending data to GLCD. As you said when the 485 is set to output no interrupt should occur, then that time I can send data to the GLCD. Or I can just tied the GLCD to tx (RC6) and set the address and set the baud of 485. Anyway I have to send only 1 character to GLCD.

If 1 sent to GLCD = GLCD will print a logo
2 = GLCD will make animation
3 = GLCD will print "Hello WORLD"
4 ...
5 ...
6 ...

All the printing will be done by the onboad PIC of the GLCD. I think that is the best way and I can free 1 precious pin.

[leisryan]

I tried to use Les's wonderful serial buffer my code compile's with feedback from PDS the actual varaiables I used up minus the total actual ram! the PIC184550 contains about 2k but when I remove the routine I get a report of only 1k total ram

Any I deas why this is happening? I appreaciate it!!!

[dolci]

Opps!

[dolci]

How much speed I can achieve at 20Mhz xtal? 30 meters distance.

Thanks,

[fefenin]

hi everyone,

i'm using Les's serial buffer for debbuging and it works great!

but like dolci i'd like to be able to use this code with the max485 drivers,i tried to thing about toggling port RB0 on the 18f1320 for example (a 10mhz 19200bds)

i'll try to do some coding after i make the board and see what's happening when i just put something like:

high portb.0
HRSOut Bytein
low portb.0

etc...

hope that works, i'm really not familiar with interrups i've done only one soft with it ...

anyways thank you for your great code!

fefenin

[dolci]

This is what I've done and tried in Proton Board & Isis

Symbol RS485_Direction = PORTB.0     ; OUTPUT
High RS485_Direction  	 	 ; Enable Send 
CLEAR_SERIAL_BUFFER
HSerOut [Str RS485Buffer,CR]
Low RS485_Direction  	 	 ; Enable recieve 

HSerIn 300,TIMEOUT,[Str RS485Buffer]  
TIMEOUT:

[fefenin]

is it working dolci?

no time for testings now but i'll try later

thank you

fefenin

[dolci]

As I said

This is what I've done and tried in Proton Board & Isis

[fefenin]

thank you dolci!
i read that

but what i meant was does it work properly in real...

i guess you answered that too!

i'll try that in "real" soon.

and i'll tell you if i have some trouble to make it communicate


fefenin