BS2p serial buffering

NeilB

Hello,
My company is using a BS2p40 as the brains of a PC controlled power supply. Our Stamp both accepts commands from the PC, and sends back information entered from the front panel display. All of this works fairly well, except when we attempt to send multiple commands from the PC quickly. I mean that I have to put a wait state of say 100 msec, between commands or I get what appear to be data collisions between the PC sending and the Stamp sending data. I understand that some of this could be alleviated by using the flow control Fpin of the SEROUT command and some clever coding to wait and send the data at a later time. However, we would rather reduce the amount of waiting in all cases. What I am wondering is if there are any resources for an external serial port FIFO that might store the serial data and allow the Stamp to handle the data from the buffer? Such a FIFO could be written on a second BS, so my question is primarily is there an easier way to do this?

Thanks for any suggestions.
Neil

steve_b

You're stamp is probably busy doing it's 'STUFF' while you are trying to send the 2nd command.

right after your 'serin' line, send a pin high.· Then connect that pin to CTS/DSR.· Any terminal program automatically monitors that line for state.
Honestly not sure what happens to the info when it can't send...

THe BS2P's do have polling/interrupts, but the coding is a bit trickier for sure.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·

Steve
http://members.rogers.com/steve.brady
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."

Jon Williams

I find it easier to implement flow control. Using a second Stamp is a bit impractical as it would require flow control so that it could stop the PC from sending things while it is talking to the master Stamp.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

NeilB

Thanks steve_b.

Your're right, the stamp is off doing all it's other work when the next command is sent. I have the Nuts and Volts article on flow control, and I'm sure I can get that to work better than what I have. However I thought it was worth asking about a serial FIFO that works with the BS. It would free up all that processor time that I spend waiting for serial input from the PC. I would just check the FIFO and see if there is anything waiting. If there isn't one out there, I can use a dedicated Stamp to do the job. In fact, the more I think about it, using a dedicated Stamp for this makes sense because I can parse and validate the packets before send them on to the main processor.

NeilB

Thanks Jon.

Flow control will be my first step, and we will see how much that helps. On the subject of using two processors: All of my packets are very small, 7 characters max, so the down time of the I/O handling Stamp to talk to the main processor would be very short. I think the problem comes because my main processing stamp has ALOT to do between calls to SERIN. Alleviating the main processor of it's duty of waiting for PC communications seems like a promising solution.

steve_b

Take a look at the Javelin stamp for rs232 buffering.

It runs it's "uart" functions in the background so that you can do things and still not miss data.

Take a look at it on Parallax's website.· Programmed in java/C....I'm just playing with it myself and I have a lot to learn.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·

Steve
http://members.rogers.com/steve.brady
"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."

Jon Williams

Break your program into small tasks such that you can service the serial input (with flow control and timeout) at a reasonable rate.· Structurally, you program could look something like this (pseudocode):

Main: 
  Handle_Serial 
  ON task GOSUB Task0, Task1, Task2, ... 
  Update_Task_Pointer 
  GOTO Main

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

NeilB

Jon,

We do just that in our main function. However, we have crammed the Stamp full, and two of those tasks are long processes filling up an entire program slot , and a third task takes up two slots. I wouldn't ever say there is no way to make it run a task loop faster, but we have looked and tried. I could call the SERIN task more often in the task queue, but then I have to buffer the serial input anyway.

NeilB

steve_b,
Thanks for the suggestion on the javelin stamp, I wasn't aware of that feature. I will take a look.

Tracy Allen

I've used the MAX3100 for this purpose, and it could certainly buffer your 7-byte packets.

www.emesystems.com/BS2IrDA.htm
That goes into the IrDA capabilities of the chip, but it also works with plain RS232 lines. The MAX3110 has a charge pump and line drivers instead of IrDA. There are also options using an SX or other microprocessor as a serial buffer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Bruce Bates

NeilB -

Here is a 32 byte serial buffer chip that you may want to consider using:
information - http://www.protean-logic.com/tickit/rsb509B_HTML_Cutsheet.htm
purchase - http://66.165.144.248/search_result.asp?CATEGORY=ALL&MANUFACTURER=ALL&DESCRIPTION=&PRODUCT_ID=RSB509B

Sorry it's from a competitor, but I don't know of anyone else who offers one. The "why" of that is something I've asked myself time and time again, over the last 8-10 years!

Regards,

Bruce Bates

NeilB

Thanks a ton Tracy and Bruce! I'll look into those parts.

Tracy Allen

There is also the SX chip that people have used to buffer data. There is an example with a complete tutorial and code by Al Williams from his book, for free dowload at...
www.parallax.com/sx/projects/ssib.asp

You need the SX-key to program the chip, but then you can modify the code to get exactly the smart RS232 buffer you want. Even use the SX/B compiler to do it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com