Redirecting serial data at runtime

[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.

[skimask]

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.

[Charles Linquis]

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

[rmteo]

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!

[sougata]

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.

[Charles Linquis]

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.

[sougata]

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