Post by thread:[PIC]: RS232 flow control again on a 16f628

Hello PICsters, some time ago Olin suggested a Master/Slave setup for sending data between PC and PIC project for flow control. I would like any suggestions on how to implement such an approach as i cant use XON/XOFF as those values are possible sent values and I used the simple 3 wire connection so no hardware flow control. Currently I have to set up the PIC to transfere data to 96k of eeporm (6x16k chips) from the PC, then instruct the PC to send. Vice-Versa I have to set up the PC to recieve then instruct the PIC to send. I want to control it all from the PC and the command solution sounds perfect. I would like to instruct the PIC via the PC to send all 96k, or just 1 chip worth ie 16k, or 256 or 32 or 1 bytes of 1 chip. And perhaps the option to view registers, read and write to pins etc. I am curious about the details of previously implemented solutions. ie is the command just 1 byte and kept simple and complex commands made up of several simple ones, are the packets fixed length and are packets used in both directions. I could think up my own possible solutions, but time after time I have spent many many hours implementing a solution then when it all works I think up a better approach or read some clever flexible method on the LIST and end up throwing away all my previous work away and starting again from scratch. So any ideas would be most welcome regarding command structures. regards Justin PS here is the project details A 16f628 connected to the following a MAX232, 6 x 24f128 eeproms via I2C, 16x2 LCD via a shift reg, 3 pin IR demodulator, IR tx LED, and RF 433Mhz RX module. It records commands from a various IR remote stores in EEPROM as a 160 byte command and reproduces them when instructed from a RF TX hand held remote. All is basically working I am just cleaning it up. Code thou buggy and not completly commented can be viewed at http://www.users.bigpond.com/jkrichards/Pic/index.htm for any newbies or anyone interested in how I tied these bits together. No schematic posted yet. (Olin, I have tried to format my code as best I can as you suggested) -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> some time ago Olin suggested a Master/Slave setup for sending data > between PC and PIC project for flow control. > > I would like any suggestions on how to implement such an approach as i > cant use XON/XOFF as those values are possible sent values and I used > the simple 3 wire connection so no hardware flow control. The setup I use most of the time doesn't use XON/XOFF. You probably only need flow control for the stream from the PC to the PIC. For the other way around the PC has a large input buffer and many cycles per input byte, and should be able to keep up with the average rate unless you are doing something very unusual. The simplest answer when speed isn't critical is a command/response protocol. The PC sends commands, and the PIC sends some kind of response to each command. I've done this dozens of times, and it's easy to implement. The PIC input buffer is large enough to hold the longest command, and the PC is only allowed to send a new command after receiving the response from the previous. For commands that don't inherently return data, artificially have them respond with some kind of ACK byte. You can see a working example of this in the HOS_CMD.ASPIC module of the HOS project at http://www.embedinc.com/pic. The ACK per command is not used in that example, but there is a paragraph of comments explaining where the ACK would go, including commented out code to send it. > I am curious about the details of previously implemented solutions. ie > is the command just 1 byte and kept simple and complex commands made up > of several simple ones, are the packets fixed length and are packets > used in both directions. I usually use commands (host to PIC) and responses (PIC to host) that start with an opcode byte and may be followed by data bytes as defined per opcode. I don't see much advantage to fixed packet lengths for RS-232. The only restriction in the scheme described above is that the maximum length command fit into the PIC input buffer. Of course you don't need this at all if you can guarantee that the PIC can process the commands faster than they can be sent. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> > some time ago Olin suggested a Master/Slave setup for sending data > > between PC and PIC project for flow control. > > > > I would like any suggestions on how to implement such an > approach as i > > cant use XON/XOFF as those values are possible sent values > and I used > > the simple 3 wire connection so no hardware flow control. My original WISP programmer used a very simple protocol where the PC sends a character, the PIC echoes either this character or a different character, and the PC proceeds with the next character only when the echo of the previous char has been received. On DOS this was quite effective, but on windows (using windows calls) this is very slow. But when performance is not important it is still a very simple and robuust protocol. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

-----Original Message----- From: Olin Lathrop <spam_OUTolin_piclistTakeThisOuTEMBEDINC.COM> >You can see a working example of this in the HOS_CMD.ASPIC module of the >HOS project at http://www.embedinc.com/pic. The ACK per command is not >used in that example, but there is a paragraph of comments explaining >where the ACK would go, including commented out code to send it. > Thanks again Olin for your time and help Regards Justin -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics