View previous topic :: View next topic |
Author |
Message |
Linuxbuilders
Joined: 20 Mar 2010 Posts: 193 Location: Auckland NZ
|
int_rda on hw and sw uart in real time |
Posted: Thu Aug 05, 2010 6:04 am |
|
|
Hi,
I am trying to get my pic using 2 uarts, first is hw dedicated RX/TX pins and
the second port I define on random pins (in my case SPI port) and create sw uart. Printing over both I do with fprintf and it works. I have a problem with rx side, I would like to fire up 2 separate int_rda for each rs232 port so I can collect data from each and process it independently. So far I am stuck.
Any work around of it? I have hw uart working but do not have an idea how to get irq kicking on on sw side.
thank you for help. _________________ Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19513
|
|
Posted: Thu Aug 05, 2010 7:12 am |
|
|
Basic answer. You can't.....
The hardware UART, has a hardware shift register, that receives the bits, and the hardware interrupt is fired, when this is full, and the contents are transferred to a separate buffer. On the software UART, the processor has to do _everything_.
The 'nearest' you can get, is to use a pin that supports hardware level interrupts (depends on the chip, but commonly B0), for the receive, and program this to interrupt when a falling edge is seen (H_to_L). Then in the handler for this interrupt, call the software getc routine. With certain limitations, this will work. Limitations are:
1) You cannot be using the software transmit at the same time. If you do, the transmitted data _will_ be garbage.
2) The two ports (software and hardware), must either be running at similar rates, or the hardware port must be running _slower_ than the software port. This is since otherwise more than one character could arrive on the hardware port, while the software receive is being handled. Since the total buffering on the hardware port is just _under_ two characters, if this happens data will be lost.
3) The software UART rate needs to be relatively 'slow' compared to the processor clock. It takes typically 30+ instructions to get into an interrupt handler. The reading of the data byte will not start till this long after the 'event' (falling edge). If this time interval starts to get tto large, data corruption will occur.
If you want a better solution, look at adding an I2C interfaced external UART (since you are already using the I2C/SPI pins....). NXP (Philips), do these, as do some other manufacturers.
A search here will find a lot more about this.
Best Wishes |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Thu Aug 05, 2010 4:23 pm |
|
|
I've once created a full duplex serial port based on a timer interrupt. Code was written in assembly and could handle 19k6 on a 16MHz PIC18. I've heard other people doing it even faster, but with hindsight I wished I hadn't done it in software. It took a _long_ time to get the driver stable and even now we have to be careful that software modifications to other parts won't break the software UART.
Why not use one of the PIC processors having 2 or more UARTs? You will be positively surprised how low the newer advanced models are priced when compared to the older models. For example the PIC18F23K22 is the cheapest model with two UARTS and costs US$1.85 (1-25 pieces) |
|
|
Linuxbuilders
Joined: 20 Mar 2010 Posts: 193 Location: Auckland NZ
|
|
Posted: Fri Aug 06, 2010 2:42 am |
|
|
I have got it working with int_rb but this is not acceptable as commercial solution. Works with slow speeds only and is very unstable. Then only way to get it done is to go for a chip with 2 hw uarts.
thnx for help. _________________ Help "d" others and then you shell receive some help from "d" others. |
|
|
Linuxbuilders
Joined: 20 Mar 2010 Posts: 193 Location: Auckland NZ
|
|
Posted: Sat Aug 07, 2010 5:30 am |
|
|
advice to anyone trying this,
it is bad.... it is so bad that can't be used. The code generation is so unpredictable that it is hard to predict when it works, int generation is totally chaotic. So if you need 2 rs ports in real time then you need a good chip with 2 hw ports. I have wasted 2 days of work on it, asm is different each time I compile.
don't try, just get good chip. _________________ Help "d" others and then you shell receive some help from "d" others. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Sun Aug 08, 2010 1:54 pm |
|
|
Linuxbuilders wrote: | advice to anyone trying this,
it is bad.... it is so bad that can't be used. The code generation is so unpredictable that it is hard to predict when it works, int generation is totally chaotic. So if you need 2 rs ports in real time then you need a good chip with 2 hw ports. I have wasted 2 days of work on it, asm is different each time I compile.
don't try, just get good chip. |
I've already been down this road with clients and have urged them to use MCU's with > 1 hardware UART.
They figure it out the hard way..
There are some nice PIC18F's w/2 UARTs onboard without having a lot of pins... like the PIC18FxxJ11 parts. (and an RTC). They come in 28pin DIPs for play and SO's for production.
They are 3.3V parts, but have 5V friendly pins. So consider trying those out.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|