Redirecting serial data at runtime

I wrote an enormous program that has an awful lot of RS-232 text out (and user response IN). Now I need to send and receive that data to the second (hardware) serial port - sometimes. I can't possibly have double the number of routines for I/O (one for HSERIN1/HSEROUT1 and another set for HSERIN2/HSEROUT2) ,the extra code wouldn't fit. I'm using an '8723.

I'm pondering trying to write a new assy routine with the function of HSERINx/HSEROUTx where "x" is the port I want to send/receive data from at the moment. Before I even attemp such a feat, I was wondering if anyone else has tried this or knows a simple way.

Wow, that is some application to have used up 128K device. The largest app that I have managed ended up being just under 36K. It include a 240x128 GLCD, touchscreen, 4x4 keypad, SD card storage with FAT filesystem, UART comms, etc.

Yes, I have been "up against the wall" program space wise for quite a while. I have been begging MChip for a 256K part - because I could really use it. No luck so far.

Hi Charles,
Would it work to use 2 PICs, one to run the program and the other as a display server, where it only has to fetch from program space or eeprom the strings and display them ? At least you would get your 256k. You could drive them both from and EXT OSC so they would clock together.

It would work - but it would require a lot of recoding. Unfortunately, my code doesn't have the outgoing strings in arrays. That would make life a lot easier and I should do that some day.

I have managed to compact the code to fit in 119K. Believe it or not, that gives me a fair amount of "breathing room", since all the little code blocks have been written, and now I can just call them up when I need something new.

If I could just get that elusive "Hserinx/Hseroutx" routine running it would solve a whole bunch of trouble. It looks like I'm going to have to modify PBPPIC18.LIB - AGAIN!

I don't think you will ever see anything larger than 128K (they do go up to 256k with the 24-bit core) in a PIC18. Probably has to do with die size. Since you are using a 80-pin device, could you possibly use external program memory in the extended microcontroller mode to get up to 2MB of program space?

No chance. That takes pins. I'm using all of them already.

Without knowing more about you application, I would say that you are running out resources with a PIC18. May be time to look at more powerful hardware and/or software.

Quote:

---

Originally Posted by Charles Linquis

No chance. That takes pins. I'm using all of them already.

---

What if...and this is a big ol' what if...
Since you're already using the first UART for serial, that pin is taken up...
The 2nd serial port is 'free' for the moment but you want to use it, but can't because there's not enough space for the code.

How about you use that second serial port pin as an I/O and use it to 'steer' the 1st UART's output (and/or input if need be).
I think the code impact would be minimal, just set a pin high or low depending on where the serial has to go...

You won't believe this, but I do that trick already. I use a 74HCT125 as a data selector to switch between an RS-232 port, and a Lantronix XPORT (which does telnet).

What I really need is HSERINx/HSEROUTx !!!

Quote:

---

Originally Posted by Charles Linquis

You won't believe this, but I do that trick already. I use a 74HCT125 as a data selector to switch between an RS-232 port, and a Lantronix XPORT (which does telnet).

---

Oh...I believe it...

Quote:

---

What I really need is HSERINx/HSEROUTx !!!

---

Sounds like you're into messing with HSERIN in the libs then!
Maybe you could throw a 'PORT QUALIFIER' as the first character of every HSEROUT statement which would trip another I/O select pin into said library function.
I.E.
HSEROUT ["1", data, data, data]
would always go to the first port
HSEROUT ["2", data, data, data]
would always go to the second port

I would think it wouldn't be that hard to modify the libraries to do recognize the first character in the output stream and switch ports accordingly.
In fact, I'm going to have a look at the libraries right now...

Just had a quick look see at the library and it's immediately obvious that modifying the library to do what I suggested above will add a lot more code than just using HSEROUT2.
I don't support you could post the source...maybe we could find a few places to save some code space for you. I'm up for it...

Sorry, can't post the code (it is the property of the company I work for).

But, you are probably correct in stating that the extra assy structures needed to switch between TX/RX REG1 and TX/RX REG2 would add too much code also.

I'll have to look into this more.

I really appreciate the offer, though. I just saw where I can do some "compacting" myself.

One part that takes up too much space - I have a complete SNMP agent running. I'll start there.

Quote:

---

Originally Posted by Charles Linquis

I really appreciate the offer, though. I just saw where I can do some "compacting" myself.

One part that takes up too much space - I have a complete SNMP agent running. I'll start there.

---

One big thing I've found is with variables. You use a word when a byte will do. That right there uses up a lot of code space.

I try to be careful. The program has over 6500 lines of PBP. There is some asm code involved, too.

Quote:

---

Originally Posted by Charles Linquis

I try to be careful. The program has over 6500 lines of PBP. There is some asm code involved, too.

---

Yikes!!! 6,500 lines of PBP code. I sure do not envy you. Good luck! :D

Hi Charles,

I don't know how you are processing the input string from one USART. Possibly you are using some form of interrupt. If you are using DT's instant interrupt and in PBP then there might be a way. I haven't gone through DT's routines so well that I know all about it. But it does allow the use ASM and PBP interrupt routines for a same source at the same time. So here is the idea.

Keep a flag of yours which you set when a re-direction is necessary. Now say you have a PBP interrupt handler. Create another handler for the same Rx interrupt in ASM. If your flag is not set then just return from it by testing the bit. If set then execute your redirection code. Read the byte from one RCREG and put it to the other TXREG testing the hardware flags.

Now clear the interrupt flags manually and any of DT's flag to make II believe that all has been done. This would possibly prevent the PBP handler in the second priority list to be invoked. You may need some tweaking though for example if

DT's interrupt routine backs-up the PBP (reuse pbp) vars even when processing the ASM int. I am not sure about it. You need to go through them.

Now you can tweak DT's routine to add a few defines for the port redirection.

Since you are using a SNMP agent I believe it is some sort of round robbin multi tasking. So if you second USART is having its buffer full and busy TXing. And you cannot afford to block the code This all depends on the amount of traffic and if your application has scope. You may set-up small redirection ring buffer that gets triggered on successful transmission to find out if you have some more bytes left to be sent from the re-direction handler.

These are great ideas. I'm already processing HSERIN interrupts using both ASM and PBP (at different times).
The project (as you would guess) is quite complicated. It does SNMP, telnet ,SSH and RS-232 protocols simultaneously. In some cases the RS-232 port must be connected directly to the telnet port of the network device (a Lantronix MatchPort AR) A whole lot of switching goes on in both hardware and firmware.

It still amazes me that it all works at all. But I'm need a bit more functinality.

Thanks.

Hi,

I tried C18 and C30 but couldn't even make out for the investment. PBP is comfortable cause it lets you use the resources in a native way and does not come in your own way. I am still a bit shaky with the 16F parts due to limited resources and lack of functionality. But I haven't found an occasion (or my projects were not complex enough) where an 18F couldn't do the job. Did I mention over-clocking ? Yes 16x4 HSPLL = 64 MHz.

Writing 6500 lines is not what you plan when you start MCSP. It piles up and the best part is, it works as intended.

One word of caution for newbies, comment your code well. I mean really well.

It took me 2 days to figure out what I did 2 years back. So now-a-days I write comments like this:

'/ Always comment your code well '/ This is a comment only

There is something to be said for a structured approach (functions and procedures, local variables, parameter passing, etc.) with more complex applications, though. :D