CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

RS232 "Tunnel"

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
cerr



Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC

View user's profile Send private message

RS232 "Tunnel"
PostPosted: Mon Mar 14, 2011 1:40 pm     Reply with quote

Hi There,

I'll need to update a second PIC on the board that doesn't have a direct rs232 interface to the outside world but it does to my first pic thus my idea was to send a certain command to the first pic which puts it into a "tunnel mode" and there i would forward whatever comes in on (number stands for USART) Rx1 to Tx2 and whatever comes on Rx2 goes to Tx1. That should work I think but my question is, would i rather wait in an infinite loop to route packets thru kinda like this:
Code:

while (in tunnel mode)
{
  if (kbhit(PC))
    {
    fputc(fgetc(PC),INSIDEPIC);
    }
  if (kbhit(INSIDEPIC))
    {
    fputc(fgetc(INSIDEPIC),PC);
    }
}

Or should I make this interrupt controlled?

Thanks for opinioins and suggestions!
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Mar 14, 2011 2:16 pm     Reply with quote

Interrupt driven may be best. Easier to handle data buffers, maybe error checking, PC connection (USB or real comport) ? , if USB you'll need buffering and INT for sure. Be sure to have a failsafe 'escape' to drop the link !!
Is this just 'data' (tables, setpoints,etc) or actual program code requiring bootloader task ?
cerr



Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC

View user's profile Send private message

PostPosted: Mon Mar 14, 2011 2:31 pm     Reply with quote

temtronic wrote:
Interrupt driven may be best. Easier to handle data buffers, maybe error checking, PC connection (USB or real comport) ? , if USB you'll need buffering and INT for sure. Be sure to have a failsafe 'escape' to drop the link !!
Is this just 'data' (tables, setpoints,etc) or actual program code requiring bootloader task ?

It is program code and i'lll be using a bootloader on the second cpu.
How do you think I should implement a failsafe escape other than a hard reset? Do you think I should escape in case a certain character combination comes or so?
And what kind of buffering for INT are you talking about in case of USB? It's gotta work with either connection option...
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Mar 14, 2011 4:05 pm     Reply with quote

As for the failsafe, you should know how long it'll take to download the program into the second PIC through the first from the (assume) PC. Simple background timer..tic,tic,tic... if download not completed assert failsafe and abort.

If the first PIC had enough RAM, you could stuff it, then transfer to PIC #2, but I assume that's not an option.

Useless Serial Bus is nondeterministic, IE: you can't count on it , so you'll have to buffer your data, use checksums, etc. to be sure data is correct.
InterPIC communications will be fast and reliable.
cerr



Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC

View user's profile Send private message

PostPosted: Mon Mar 14, 2011 4:19 pm     Reply with quote

Yes, the failsafe option should be implemented - agreed. This however will have to wait for now as I don't have the hardware available yet.
There's not enough room available to buffer the whole application but if the PC is sending with (let's assume) 9600bps, there should be enough time (I think) in between #int_rda calls to send out the buffered data from the main "tunnel mode" loop or am i wrong? I could run a parallel buffer that i would increase in size as bytes are being received and decrease ion size as they're sent out again using realloc(). Or just set the baudrate from the PC the same as the one between the two MCUs, then it should work without buffering, shouldn't it?
Thanks!
cerr



Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC

View user's profile Send private message

PostPosted: Mon Mar 14, 2011 5:12 pm     Reply with quote

I went ahead and iplemented something like this now:
In the main loop() - I'm aware of the fact that I will need to get rid of the infinite loop once I can start testing my stuff...

buffer is a global pointer of type int8* and
buffersz is a global int16.
Code:

         fprintf(DEBUG,"MCU2 in Passthrough tunnel mode - reset to return!\r\n");
         enable_interrupts(INT_RDA);
         buffer=calloc(++buffersz,1);
         while(true){
           if(buffersz>1)
           {
             fputc(buffer[--buffersz],MCU1);
            if (buffersz%1024==0)
              fprintf(DEBUG, "Buffer %LdKB\r\n",buffersz/1024);
           }
         }

And in the ISR:
Code:
#int_rda
void RDA_isr()
{
char ch=0x00;
  if (kbhit(DEBUG)){
   if(realloc(buffer,++buffersz)!=NULL){
       if(buffersz>0)
       buffer[buffersz-1]=fgetc(DEBUG);
     else
       printf(DEBUG,"ERROR: invalid buffer size(%d), cant receive data!\r\n",buffersz);
   } 
   else
     printf(DEBUG,"Out of memory, allocated %Ld Bytes\r\n",buffersz);
   if (buffersz%1024==0){
      fprintf(DEBUG, "%LdKB allocated\r\n",buffersz/1024);
   }   
  }
}
//------------------------------------------------------------------------------

This seems to work so far, i don't have anythingconnected to the MCU1 port yet but a text file of 38KB went through fine and I never saw a buffer debugging message showing up. But I also have tried how far I can fill my 4K SRAM and it stops at about 3KB but won't print my error message, instead the PIC just stops executing anything... :( Don't know why that would be...? Sad


Last edited by cerr on Mon Mar 14, 2011 5:16 pm; edited 1 time in total
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Mar 14, 2011 5:13 pm     Reply with quote

Hmm..rethinking it again... If you already have working 'bootloader code' in PIC 2, then PIC one could be 'viewed' as a simple controllable digital switch. One position is 'running main task', other is 'transparent comunications glue'.
Similar to the 'wedges', 'key convertors', keyboard stroke recoders, etc. Upon receiving the correct command sequence it goes into a simple loop. rcv fro PC, send to PIC2, rcv from PIC 2, send to PC. Either the PC or the PIC2 sends an 'all done' command to break the loop and return to the original program.

Heck the KVM switches do something similar, tap scroll lock twice to 'flip' which PC system gets the keyboard, video and mouse.

Done this way the added code to PIC1 is trivial, a function of maybe 10-20 lines of code ?
cerr



Joined: 10 Feb 2011
Posts: 241
Location: Vancouver, BC

View user's profile Send private message

PostPosted: Mon Mar 14, 2011 5:39 pm     Reply with quote

Yep, the KVM switch i'm using here is twice scroll lock so i might wanna choose something else for this Wink - Num Lock-minus_on_numkey-Num Lock e.g. if i get appropriate ascii chars for these keys... or i just use the F keys....i need to look for some ascii characters here but that should work, thanks for that hint buddy! Smile
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group