Logging a serial datstream.

[bigandy]

Evening folks.

I am trying to figure out a method of logging a serial datastream, and I was hoping someone may have heard of something similar before.

I have one clock line that is a 1MHz square wave. On another line is the serial datastream. everytime there is a rising edge on the clock line, the serial needs to be read (0 or a 1). I have been using my 'scope to log some partial data streams, but I am limited to the sample size of the scope (2.5k points) and the fact it doesn't output a binary data stream that I can easily work with.

So, I was thinking of rigging up a micro (PIC if possible) to somehow sample this data, and save it to memory. However, I am suspecting that although processing speed may be an issue, choosing a memory type and writing to it quick enough will be more of a problem. Ideally I would like to be able to store around 0.5 seconds of data that is a continuous stream, which I can then upload to a PC to process after the sample has been taken.

Has anyone ever heard of this being done before? Is there a bit of equipment designed to do this sort of thing available off the shelf (I'm on a hobby budget here though!)? What sort of memory should I be looking at?

Any advice/pointers would be most helpful thanks!

Cheers
Andy

[andrewm1973]

a 74HC595 on the parallel port of your computer will do it. Throw a counter like a 393 at it as well and you will know when the 8th clock is so you can read the 8 bits from the 595.

Alternatly get any micro with an SPI port (I of course would recomend an Atmel AVR) and then it can resend it out to the parrallel or serial port (or via a FT232 thingy)

[Mr.RC-CAM]

You could do this with just a static RAM chip and counters; No need for a MCU. A 4M-bit (512K x 8) would give you .5 secs of recording at 1Mhz. In effect, you would have up to eight "channels" of data recording.

The clock would go to the CE input of the RAM (ensure logic polarity is correct for the chip you choose) and some counters for the Ram address. DIP switches could be used to select read/write and output enable.

[andrewm1973]

You could do this with just a static RAM chip and counters; No need for a MCU. A 4M-bit (512K x 8) would give you .5 secs of recording at 1Mhz.

1Mhz is slow enough for a parallel port to read in without the need for a static RAM or ANYthing to store the data as long as you deserialise it. Your hard drive has a LOT of seconds of recording then :D

The HC595 can do that deserialising for you. OR proabably easier to find is a little microcontroller. Everyone has an ATtiny2313 or a PIC16F84 lying around the house somewhere. Not everyone has a HC595 handy. A 4mbit SRAM most certainly sounds like a special purchase.

[xorcise]

PIC's have an edge-triggered interrupt pin (or 2) which can work nicely for your application. You can select which edge you want to catch, high-to-low or low-to-high. Even the small 8-pin P12's have this feature on the GP2 pin.

[MatC]

xorcise: You'll struggle to do this with a naked PIC, at 20 MHz you only have 5 instructions between each sample, which is barely enough time to write to internal ram.

So you're probably looking at a little interfacing, as suggested. Shift register ('595 or '164 at a push) will give you 8bits at 125 KHz, much easier to work with. Parallel memories will easily work at this speed an higher, and you only need 64Kx8.

If you're uploading to the PC anyway, you might as well try the parallel port, in EPP or ECP mode.

If you want to go the PIC route, use a 64kx8 SRAM, a '595 to grab the data, the PIC to set up address lines, and interface the '595 straight onto the data bus. Then get the PIC to read out the data at its leisure later. Although not the simplest way to go, it's very flexible if you want the PIC to do some analysing, or replay the datastream etc.

[xorcise]

xorcise: You'll struggle to do this with a naked PIC, at 20 MHz you only have 5 instructions between each sample, which is barely enough time to write to internal ram.

:o ... You're correct. It might serve me to look at that at the first post a little closer.

[andrewm1973]

Or you could use an ATMEL AVR. At 20Mhz they will do 20 instructions per serial clock . I would use one with a hardware shift register (SPI/USI port) in it though - so the CPU only actually had to do something every 160 clock-cycles/instructions.

Though I did first mention the 74HC595 straight to a parallel port option. I did say you would want a counter so the PC knew when 8 clocks was up on the serial line. That makes for two 14 pin chips. With an ATMEL ATTiny2313 you could do it with one 20 pin chip and have more flexibilty. You could actually set up the 2313 to do the ECP/EPP handshaking if you liked. Maybe a ring-buffer/FIFO in its internal RAM so if the parallel port was busy you don't miss anything. (though just use DOS instead of windows and you will never have latency)

Either ways. The only two options I would consider are a 595 straight to the parallel port or an MCU (my pref for an AVR) going straight to the parallel port. RAM buffers and what ever are just not needed for 1Mhz (125 Kilobyte)

Oh - and as MatC said - make sure the parallel port is a bidirectional one. Something I forgot to say the first time :D

[bigandy]

Good evening folks,

thanks for the replies, it has certainly given me something to think about. I have a slight problem with the parallel port though, in that my PC doesn't have one! I have serial ports though, and USB to serial converters which work well.

I have a slight correction to my first post too, in that the 1MHz squarewave, is in fact a 500kHz squarewave, so the datastream has 1 bit every 2µs. Coupled with a PIC running at 40MHz, that would give 20 instruction cycles to play with.... I have an 18F452 that can run at that clock speed (I think! The datasheet is a bit sketchy on whether it can run that fast reliably...), perhaps something can be done with this?

I quite like the idea of having a Serial in, Parallel out shift register on board though, as that would free up the processor, perhaps enough to relay the received byte over to a PC through a Rs232 connection, thus alleviating the need for storage space.

Hmmmm.... many ways to skin a cat!

Cheers
Andy

[andrewm1973]

Your FT232 UART to USB bridge chips can do 1 mega bit.

One of them and a micro with a shift register and you are home.

And go on - check out the AVRs :P

[xorcise]

If you use an 18F2550 you can run at 48MHz which will allow 24 instructions every 2us. Also, it is USB capable. Swordfish and the mikroElektronika compilers all have a HID USB library which works right out of the box.

Here is another recommendation that will incorporate a 74HC595 and the 18F2550. Clock your data into the 74HC595 and every 8th clock read a PIC Port that is connected directly to the output of the '595. You can store each byte in one of the 2048 RAM available in this PIC....8 readings per byte. Since you need some RAM for USB use 1500 RAM, for example. That's the equivalent to 120,000 bit readings. When finished load into your PC for analysis.

Cascade a couple '595's and read 2 Ports every 16th clock. This works too.

This can be done and also have the advantage of being to upload easily to the PC via USB.

[xorcise]

Your FT232 UART to USB bridge chips can do 1 mega bit.
Can AVR do 1Mbit UART?

[andrewm1973]

AVR can do a 2.5 megabit UART on a 20Mhz clock.

Pick the right AVR and you have an SPI and a UART. A 20Mhz clock on an AVR is getting more instructions done per second than a 48Mhz PIC - so you should be right for getting things done between times too.

I have just started using USB enabled AVRs. However I would not recomend Andy get into that kinda thing as he is just after a quick simple solution (I think) so an FT232 is proabably quicker and easier.

I am sure that there must be PICs with SPI ports as well. That would alleviate the need for a HC595 (which I only was suggesting when I was assumign that Andy had a parallel port).

[jeffs555]

Since you need some RAM for USB use 1500 RAM, for example. That's the equivalent to 120,000 bit readings.
You slipped a decimal point, 1500 bytes is only 12,000 bits. That is not enough for Andy's .5 seconds of data (250k bits at 500kbps). It would be a good buffer if he could work out the high speed serial or USB transfer to the PC.

Andy,
If you wanted to store it all in memory, you might consider Atmel's DataFlash. http://www.atmel.com/dyn/resources/prod_documents/doc3500.pdf
This one is 16 megabits, in an 8-pin SOIC package, and a single piece price of about $3.50. The interface is SPI. It has a page write time(528 byte page) of 6 mSec if the page has already been erased. It has dual 528 byte ram buffers, so you can be filling one buffer while it is writing from the other buffer to the flash. By flip flopping the buffers, you can write to flash at your 500 kbits per second.

Jeff

[bigandy]

Hi folks,

I have been looking at the datasheet of the 18F452 that I have, and I think I might be able to use the SPI feature to read in the serial data (using it in place of the HC595), as andrewm1973 suggests. I have not really played around with the SPI feature before though, and I have a quick question. Attached should be a timing diagram (cribbed from the datasheet, and trimmed a bit to remove the unwanted stuff). This shows the clock (SCK) in the right conifguration, i.e. the SDI line is sampled on every rising edge of SCK.

After 8 samples (bits) have been recorded, they are transferred to the SSPBUF register, and an interrupt flag raised. I have read the datsheet a couple of times, and I think there is an option to allow the next byte to be received, but the data in the SSPBUF register is held. This would allow the MCU to sit idle (or doing other stuff) until 8 bits have been received, then take these 8 bits and save them in RAM (either on or off the MCU chip). I think this is exactly what I am looking for, and the idle time between the SSPBUF register needing to be read/saved should be enough to transmit it out through the USART to a PC.

My one question (at the moment! :) ) is regarding the SDI line. Does anyone know if there has to be a pause between each 8 bits, or can the data be continuous? I hope that question is clear. The timing diagram only shows 8 bits, and I am not 100% certain that it can cope with continuous serial data.

regarding the AVRs then in the future I would consider looking at them. For now, I am still tinkering with the PIC chips, and I would prefer to stick with them. Mainly because I have a bit of experience with them, but also because they are cheaper for me to get hold of :) having said that, they do look like a better choice if I ever pull my fing out and learn C :)

Cheers
Andy

[xorcise]

You slipped a decimal point, 1500 bytes is only 12,000 bits. That is not enough for Andy's .5 seconds of data (250k bits at 500kbps).

You're correct....I've been on a real roll with this thread so far.... :o

[xorcise]

AVR can do a 2.5 megabit UART on a 20Mhz clock.
That's impressive. Maybe it's time for me to get interested in what AVR's are doing these days.

I have just started using USB enabled AVRs.
I did not know that AVR's now have a hardware USB. I saw that someone had written a software HID for AVR a while back.

[andrewm1973]

Xorsize,

The non-mega AVRs can do 1/16th the clock out the UART. The mega can do 1/8th the clock. (so that is 1.25Mbaud or 2.5Mbaud respectivly)

There have been hardware USB AVRs for almost a year. They have just released a low-cost low pin count hardware AVR that is not available at digikey yet as well.

The hardware USB in them is also very tidy. It has its own dual port RAM for the end points and the USB does not interfere at all with the CPU until it sends an interrupt saying its done.

Andy,

SPI should not need ANY pause between bytes. SPI is not really a byte oriented thing. It is bit oriented and not all devices are 8 bits long. As long as you can read the byte from the receive buffer before the next one comes in you are ok.

How long you have to read that byte depends if it is double buffered or single buffered. (look for those words in the data sheet).

Single buffered - you need to read the byte in ONE SPI clock (2uS in your case) after the 8th bit arrives.

Double Buffered - you need to read within eight SPI clocks.

Either way should be an easy task as you can do something else (or nothing and just wait) for 7 out of every 8 clocks while the SPI does all the nice shifting into a register for you :D

If you are interested in AVRs you can pop over the micro planes forum and have a look at my AVR programmers/tute thread. You can see some ASM code for the AVR and see how much more fun you can have with 32 registers :D

[bigandy]

The 18f452 has a double buffered register when receiving in SPI slave mode, so it sounds like I will have a bit more time available to read out the 8 bits and save them/do something with them.

One last question that I haven't had much luck finding any documentation on, is the clock input for the SPI to work correctly. Is there any limitations on what the clock input can be to the SPI port on the PIC chips (or AVRs for that matter)? I'm wondering if it matters if the main MCU clock is completely different to the SPI clock...

Cheers
Andy

[andrewm1973]

Again there are magic words to look for in the datasheet.

In the area that is talking about the SPI clock - look for the words Synchronous and Asynchronous. If the clock is said to be synchronous then it will have a maximum speed some multiple slower than the system clock (1/2 or 1/4 or something).

If it is said to be asynchronous it can run faster than the system clock.

I beleive all AVR ones have to run slower than the system clock. Don't know about PICs

[bigandy]

Just done some more digging on the datasheet (it's 332 pages long, bigger than the last book I read!). Apparently the minimum "high" and "low" times for the SPI clock are 1.25Tcy+30ns.

So by my calculations, for a 1µs high and low time, the Tcy has to be 776ns. Tcy is equivalent to one instruction clock cycle, so the main clock is running four times as fast as that, so that gives a main clock cycle time of 194ns. This equates to a shade over 5MHz, so running a 10 or 20Mhz clock should be well on the safe side for using a SPI clock of 500Khz.....

Just have to hope my numbers are right now :)

Cheers
Andy

[xorcise]

Set up your PIC for SPI Slave mode then check the 'BF' flag (receive buffer is full when set) for when you should read the SSPBUF register. Also, set up your USART for 500K Baud (BRGH=1 mode) or faster (if possible). Get SPI byte and dump the SSPBUF register into the TXREG register with one instruction:
btfss SSPSTAT, BF ' test SPI receive buffer
bra $-1
movff SSPBUF, TXREG ' dump SPI byte into USART
bra $-3 ' do it all again
With this method you are using the PC as your data storage device.