Sonsivri

Hello everyone,

This is High Speed & Efficient Software+Hardware RS-232C implmentation for PIC.
It's features are,
 1] Like other Soft-Serial comm. it does not depend on software-loops
 2] It is NOT limited to low speeds only. I've tested it upto 38400 Baud.
 3] It is completely interrupt driven.

Uses:
 1] 2nd UART channel to CPUs having only 1
 2] Adding Half-Duplex UART to CPUs having no built-in UART.
 3] RS-485 (No direction change has been implemented yet).
 4] With enough resources, 3rd or 4th UART can also be added.

Hope you will find this useful.
Any comments/suggestions are welcome.

regards,
sam_des

Thanks, sam_des,
  It sounds very good. But,..., do I miss something in your post. I could not find your code.

Hi!
I tried to compile the CC5X program with MPLAB but it gave up with macro "RRF"(need more argument). I have another "RS232 echo" program(9600 baud, pic 16F628) that is somewhat easier. sam_des says he use Jen's editor, but I don't like that. Maybe the fault is there. You'll find the "RELOC.INC" in the CC5X folder and the linker script for pic 16F628 in MPASM Suite/LKR

well, well... I'll take the time(sometime) to put inline asm in the main module since the linkerscript needs modifying when it comes to interrupt, and I really don't know how to modify the *.inc files.

Hello robban,

I guess you are forgetting to add the cc5x path in all the fields in Project Setup of MPLAB. If you still get problem, then you can use "sw232.mak" file provided in rar.
Just create a batch file with command --

x:\cc5x Dir\cc5x.exe +sw232.mak main.c & it will compile ok. Just substitute x:\cc5x dir with your cc5x installation path.

Well, now I've tested this code for Baud 57600bps. ;D
Of course, all my testing is done in Proteus. Has anyone tested this on real hardware ? I will be very glad to hear about it.

regards,
sam_des

where is the party?
where is the code? ::)

At the top of this topic....

I upload the file into several mirrors:

turbouplaod link : http://d.turboupload.com/d/2147147/sw232.rar.html
rapidshare link : http://rapidshare.com/files/69702749/sw232.rar.html

I hope sam_des dont mind if I made mirrors of his excellent work.

hello,

Your codes is cool, I have a request, can you port it to CCS C ?

Thank you,
PIC Flash

Hello,

I am posting a enhanced version of my sw232 comm. driver. Nothing new in the basic, just few additions--
1] Automatic configuration on Baud Rate selection.
2] String Print
3] Unsigned/Signed 8-Bit number print.

Also, I am posting port of this driver to CCS PIC compiler as requsted by PIC Flash.
But there is one serious problem. Right now only upto 19200 bps is possible. Higher bauds are NOT possible with current code-structure.  :-[
I think, "custom interrupts" for CCS must be used  :-\
I will try when I get enough time.
Also, CCS requires much more code & RAM compared to CC5X.

As always any suggestions/comments/error reports are welcome.

regards,
sam_des

Hello sam_des.
What you mean under "custom interrupts" for CCS ?

Hello setoy,

By "custom interrupts", I mean - global interrupts (#int_global) directive for CCS. Actually that means you've to write all the context save-restore code for interrupts as well as any interrupt dispatching needed.

Though it is not as easy as it seems. My code have used 2 built-in functions  label_address() & goto_address() which does use compiler's internal storage for temp. variables. Since Compiiler can use any of the addresses for temp. vars. we can not guess which locations we need to save.

Another problem is that we can't get the address of label using inline asm like --
  #asm
      movlw    high(lab)
      movwf    PCLATH
      movlw    low(lab)
      movwf   PCL
  lab:
  #endasm
So we are forced to use compiler's built-in functions. That's what CCS is famous for - a lot of built-in functions !!  >:(

Still, I haven't used CCS after v3.242. Newer versions may have work-arounds. It will be nice if there are work-arounds & someone implement them for this code.  ;)

BTW, I've also ported this code to PBP v2.50. If anyone is interested, I'll post it in the Basic section of our forum.

regards,
sam_des

As most of old hosted files are corrupted then would someone please reupload sam_des work?

I am looking for a good non-blocking software uart (interrupt driven), buffered full duplex would be the best.

TIA - Ichan

I have this copy in my archive

Koky, thanks for the help uploading it again.

After reading the code quickly, both putc and getc are blocking, so the interrupt use is not very useful here.

Time to scratch my head now..

-ichan

First PIC's very often have hardware UARTs so use them. For those PIC's that don't there are software emulations many of which are blocking as the main code must wait while a char is received and further the main code is restricted to a very tight loop since it must be ready at all times to receive an inbound bit. A solution is to wire the inbound bit onto a pin that can trigger an interrupt. Rb on change or ext_interrupt. As far as CCS goes there are good working examples in their forum library. Now typically rs232 is sampled at 16 times the baud rate this is what the PIC hardware UART does.This 16x sampling is how the timing of middle of the bit is found. The middle is useful for tolerance since the real timing can advance or slip almost 1/2 a bit time. A PIC interrupt requires the saving of the main program state and then restoring it. That's several dozen instructions. This then restrains the maximum baud rate for special interrupt code written to detect an incoming bit. This is often corrected somewhat by a sample early on the bit but may also sacrifice some tolerance. In contrast the PIC hardware UART interrupts when a full char is received and immediately buffers the next one. This gives much higher baud rates than any bit banged code using another interrupt on change pin. Again the CCS library has good working code.

Gan_canny, thanks for the info.

I need it because there is no microchip PIC (excluding PIC32) has ECAN port and more than 2 UART that I needed.

I am now working on it, the TX part is done - still working with the RX part, it is harder.

Attached a test with proteus, 2 HW uart + 1 SW UART all ring buffered interrupt driven. Data received at UART1 sent to UART2, UART2 to SW UART, there will be SW UART to UART1 if I can make it. Three led continuously blinking at 0.1, 1, and 10 second cycle to test the non-blocking feature.

In the .rar file there is the .dsn and .hex of it.

-ichan

Do not want to hijack others thread, i put my last work on a new thread:

http://www.sonsivri.to/forum/index.php?topic=41756.0 (http://www.sonsivri.to/forum/index.php?topic=41756.0)


-ichan

Hello,

Sorry for replying so late. I just missed this  :-[ and It's been nearly 4 years  ::)


Yes, as far as I remember my original code blocked in getc() and putc() since it was meant for test-purpose not for real work.

It is very easy to make them non-blocking using seperate rx/tx buffers and any attempt to rx/tx while buffer is full can be flagged to caller as error without blocking, i.e. without waiting for space in buffer.
Caller can take the action as required.

Also, since my original code was basically intended for half-duplex comm., it is not possible to rx and tx simultaneously. This limitation is due to fact that both rx and tx use same timer to time the bit-period and can be overcame by using two seperate timers. But it is very rare case, where two timers are available for soft. comm and in such case I would prefer using external UART IC or use 2nd uC for just that purpose.

I may have mis-understood your words about blocking nature of soft comm. If you can give more details, may be I can help you.

regards,
sam_des

Thanks for your over to help, but I already have solutions of my own.

-ichan