ccaammaaccaazzii

Howdy all

I need to make a rs232 serial output from a pabx to be stored in memory[like a buffer] then i need another rs232 serial port to connect to via a modem to download the data. Need at least 1 meg of memory preferably more though. It doesnt sound hard but with my basic knowledge I dont know where to start. Can anyone help with this? All help appreciated.
oh 1 more thing , it also needs to keep the data buffered if it looses power.

TIA
Cheers
Cameron

evandude

well you can use one PIC, and one MAX232 chip... the max232 lets you have 2 bidirectional serial ports... and just use a PIC with a UART on it and you can receive data and transmit it later. just need to store incoming data to an external EEPROM as it is received. this may or may not be feasible depending on how fast the data is coming in from the source. if it comes in one byte at a time, with at least 5 or 10 mS between bytes, then you can probably write it to the EEPROM as it comes in. if it comes in in bursts of a few bytes, with some time between bursts, then you can receive the bursts and store them as an array in the PIC, and then write them all to the EEPROM when there is a pause. the only problem will be if the data is coming in constantly for that whole time; you would need to be able to write to the EEPROM faster than you can get serial bytes in, which may or may not be possible depending on the EEPROM write speed, and the serial baud rate.

ccaammaaccaazzii

re evandude's post .... thanks for that info Evandude...... well the baudrate is generally really slow and the calls are sporadic.. But some pabx's dump about 50 lines of text in one burst [probably 1024 characters]. So i have to use an array. Couldnt i get like a modest amount of data in my array , then send DTR as not ready , then the pabx stops sending , then write to the EEPROM , then turn DTR back to ready?

re... speed of incomming data ... I dont think the speed of pabx data is an issue most times its at 9600 baud and its speed is not an issue because its capable of going/or programmed togo lower.

Is this out of scope for a first time/newby pic/uart project maker? I have never done anything this technical before with cb's. But i know how to read a circuit diagram and i know programming.

Cheers
Cameron

evandude

it wouldn't be too bad with a PIC. personally I use the CC5X C compiler and it would be a very short, simple program with that.

as long as the PABX supports "pausing" its output data with the DTR line then yeah, you ought to be able to do that no problem. that will probably work out very well since EEPROMs can generally be written to much faster in sequential write (ie- send it a start location and then just dump a stream of data, rather than addressing every single byte you send it) so dumping an array to it would be pretty simple.

as a matter of fact, i'm rather interested in this myself, as i can think of a LOT of uses for a serial data logger like this in my own projects. I may have to make one right alongside you

evandude

the things i don't have experience with yet are writing/reading from an EEPROM, and interfacing with hardware handshaking on a serial port (i use no handshaking in all my projects)

i know i can learn about the EEPROM stuff from a bunch of places (ie- nigel's tutorials) and the hardware handshaking for the serial is probably rather simple too... but if anyone else could suggest some things, such as a good external storage method? i recall that EEPROMs have rather slow write times, on the order of a few mS... and that flash memory is faster.. would it be possible to execute a full write of one byte in less than the time it takes to receive one 9600 baud byte with flash memory? (about 1 mS) not to mention needing something on the order of 1MB or more of storage space...

looks like the best i can come up with is 128k or 256k right now, within reason... more than enough for most all of MY project needs but probably not enough for yours...

williB

i found the perfect chip..it is a 2 meg non volital static ram., 8 bits.

http://pdfserv.maxim-ic.com/en/ds/DS1270AB-DS1270Y.pdf

evandude

nice. gonna require a lot of I/O on the PIC... and the code overhead will be larger... but it's doable, especially if you use one of the 40-pin PICs.

the actual code for it won't be too bad though... considering the bulk of the I/O pins required is just for addressing... just going to need your PIC to deal with a 21-bit variable for addressing, which is doable... so basically
receive byte
output byte on 8 pins
output address word on 21 pins
execute write (probably strobe write pin)

and that's pretty much it. be equally easy for reading and outputting.

hey, read/write as fast as 70nS looks like you can write it as fast as it comes in after all, shouldn't need any software buffering at that speed.

williB

to write to it all ya gotta do is
1) bring Chip select low..
2) set up the address
3) bring write enable low :: on the rising edge of write enable have your data available to the data pins ..and viola..

to read
1) bring chip select low
2)set up the address..
3) bring output enable low :: on the rising edge of output enable out pops your data..

williB

and it is all static ..no need for colum /row strobing and all that nonsence..

i would just use a resetable counter , and two pic pins
1) pin one resets counter.
2) other pin counts out to the desired address..

williB

make that four pic pins in total..

1) write enable pin
2) output enable
3) reset counter
4) address select pin

you could allways use another pic pin for chip select , but why bother..

evandude

but think you could count up to over 2 million (for addressing up to 2 megs) in the time it took to receive one serial byte at 9600? that's 2 million pulses per millisecond, or about a 16GHz clock speed if my math is correct :-P

you could probably do it rather easily with 3 8-bit counters NOT cascaded... it would require 3 i/o pins instead of 1 but each one would only have to count up to 255 at most... you might be able to squeeze that into 1mS but it would be tough.

depends on what approach you go with.
the way i see it, why not just use the PIC's IO pins to address the memory? the PIC doesn't need to do anything but receive, store, retrieve, and send data so you dont really need I/O for anything else... and it will save space, because all those counter ICs would eat up more space anyway.

williB

Your right if the data he was looking for was at the end of memory...
but look at it this way
1) data comes in to pic from serial "whatever it is"...
2) pic increments counter
3)pic toggles write enable pin:: RAM latches data

1) more data comes in...
2) Pic increments counter
3) pic writes data....
i guess it all depends on when he wants to get the stored data...???