Shop OBEX P1 Docs P2 Docs Learn Events
BS2 SERIN-Problem with long protocols — Parallax Forums

BS2 SERIN-Problem with long protocols

ProPinballProPinball Posts: 3
edited 2007-10-05 06:23 in BASIC Stamp
Hello,

we are trying to use the BS2 module to access a LCD display and a RFID reader. The LCD display part is completed and works perfectly, but we have some problems with the RFID reader. The reader has a seriell protocol which is in fact very easy, if·you use a PC. But with the basic stamp it gets something more difficult. I have to set the reader into "reading mode" (13 Byte protocol from BS2 -> RFID, 9 Byte ACK from RFID -> BS2, 11 Byte Status from RFID -> BS2 and again an ACK from BS2 -> RFID). This works. But now the reading result from a RFID card is more complex.
This can be a result protocol in a length of 19 up to more then 50 characters.
How can I get such long protocols with variable length (embedded between a START $31 end END $4 character)·into the BS2? As the BS2 has only 26 Bytes var·memory, I tried it with 2 or more SERIN commands. And always after·the SERIN command I wrote the received data into the EEPROM.
But it seems that the BS2 is too slow to do the write-process. As after the next SERIN I don't get the·whole·missing protocol.

Is there any way to do this with the stamp? Maybe another type, like the BS2E where I have scratch pad RAM. Would this be fast enough?
We are using 2400 Baud (normally 19.2k, but lowered to 2.4), No Parity, 8 Databit,·1 Stopbit. And we have to use this RFID reader, no other one smile.gif.
Any ideas?

Thanks in advance,
ProPinball.

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2007-10-02 07:35
    The BS2p, BS2px, and BS2pe allow you to read up to 126 bytes using SERIN with the SPSTR formatter. You need either to know ahead of time how many characters to expect or to set an upper limit and a timeout in case fewer than the max are received.

    -Phil
  • JSWrightOCJSWrightOC Posts: 49
    edited 2007-10-02 19:59
    I have used SPI UARTS (such as the MAX3100, UART only, or the 3110, has integral RS-232 drivers) with relative success. The advantage is that the UART will buffer up to 8 bytes FIFO and if you can spare 5 pins on your Stamp you can even periodically check the state of the IRQ line to see if it has any data for you - otherwise you'll need 4 pins, MOSI, SOMI, SCLK, and CS. (The alternative is to clock a 16-bit word out of the UART and check the state of a bit - time consuming.) This only gets you 8 hardware-buffered bytes, but at 2400 baud a BS2 might be fast enough to clock the data out of the UART and put it in memory somewhere (really what you need is at least a BS2e or BS2SX, which have SPRAM). EEPROM writes will take much longer (a write cycle is up to 5mS) and subject the EEPROM to wear, resulting in eventual failure. The advantage of having a UART at your disposal is that the Stamp can be off doing other things when data starts to come in, and when it finds that there's data in it, go fetch it. If your IRQ scan loop is fast enough you can catch the data before it starts to overflow. Barring that, you'd need the BS2p series to use the SPSTR formatter, as PhiPi suggested...but using the UART means you can receive arbitrary length strings easily, and you don't have to anticipate the serial data coming.

    What there needs to be is a serial interface product designed for hobbyist needs like this, when we have to look at a large string of data with a slow micro. I think something like this used to exist, in the form of the "Ram Pack B" by solutions-cubed (and once upon a time sold by Parallax). I forget the specs, but it would continuously monitor for input data, and then regurgitate it at request.

    If you decide to use the 31xx UART, let me know and I'll provide some example code to communicate with it.
  • Mike GreenMike Green Posts: 23,101
    edited 2007-10-02 20:18
    There are also serial buffer ICs available like www.protean-logic.com/tickit/rsb509B_HTML_Cutsheet.htm which can buffer up to 32 bytes, then supply them as needed to the Stamp. They're really specially programmed PIC (?) processors. For this kind of task, they are much simpler to use than the MAX3100.
  • ProPinballProPinball Posts: 3
    edited 2007-10-03 08:49
    Hello and thanks for all the information! We·have now ordered a BS2p module and will try to solve it with this one.
    If this alone is not satisfying, we will check for a serial buffer. And maybe then I come back here, if I encounter any problems.

    Thanks,
    ProPinball.
  • JSWrightOCJSWrightOC Posts: 49
    edited 2007-10-03 15:34
    Mike,

    That's neat that someone still makes a device like that. The only problem I see with it is it's limited to 9600 baud, I have some applications where I need to do 19.2Kbaud. The 32 byte buffer is good, though. I also wonder how it handles concurrent requests - can you be receiving data with it at the same time that you are transferring data to the micro?

    ProPinball,

    Yes, the BS2p should do what you need, as long as you can anticipate the serial data coming. Remember, the BASIC Stamp is a single-task machine; if you present serial data to it while it's not listening, the data gets lost. I have run into problems where I send a serial command and then have to listen for a response to come back, and because the turn-around time on the Stamp isn't fast enough, the first several bytes get lost. At this point you would need a buffer or a UART.

    Have fun with your project!
  • Mike GreenMike Green Posts: 23,101
    edited 2007-10-03 16:28
    Apparently, Protean Logic has a new website (proteanlogic.com/product_periph_rs232.shtml) with newer devices. They show a draft spec of a serial buffer that can handle higher Bauds and buffers 64 bytes. It doesn't seem to be for sale yet, but you might give them a call and ask how it's doing.
  • ProPinballProPinball Posts: 3
    edited 2007-10-05 06:23
    Short update. Yesterday I got my BS2px24 module and after rewriting my complete reading procedures, everything is now working perfectly!
    It handles large protocols with up to 66 Bytes @2.4 baud without any problem. Today I will try with higher baudrates to optimize the whole thing.

    Thanks again,
    ProPinball.
Sign In or Register to comment.