New to Propeller- Looking for some guidance for start of serial data logging pr

Don M

I am looking to monitor serial communications between some devices and log (store) the data. These devices communicate using 9 bits at 9600 baud. I am just starting on the educational side of the Propeller with some of the materials online here to get my feet wet. I am wondering if anyone knows of any specific spin code that may already be on here that would apply or I could modify to suite my application.

The data can be stored on a SD card or USB stick doesn't matter to me as long as it is portable and can be read via PC.

Thanks.

Don

MagIO2

ObEx is your friend.

http://obex.parallax.com/objects/340/·allows 4 serial ports in one COG
http://obex.parallax.com/objects/402/·something like that is needed to write to SD card.

I don't know of a USB driver. It's simply not worth the efford, as the propeller would have to be the USB-master.

You can simply setup 2 serial interfaces on the propeller and connect the RX pins to RX and TX of the serial·interface that you want to listen to. The TX pins of the propeller are not needed. (Currently I don't know if this particular serial driver also allows to setup a serial port without TX at all ... others do).

What might be a problem is to write the data to the SD-card in the same order than it arrived on the serial port.

Don M

I am guessing that I would need to buffer some of the data while it is being written to memory. What may confuse me is the 9 bit data versus 8 bit data stream.

MagIO2

You need a 512 byte buffer for the SD-card driver. So, you could have 2. While one is written to SD card, you fill up the other one with the data coming from the serial interface.

Ok ... I see ... 9 bits is out of scope for that driver, but at 9600 baud running 2 simple serial interfaces would work as well and this can be changed easyly.

kwinn

You could store 3 9 bit values per long or 7 values per 2 longs in the prop. The serial routines would have to be modified to deal with 9 bits of course.

Although I have seen 9 bit serial data before it is rather unusual. Are you sure it is 9 bits and not just 8 bits plus parity?

Mike Green

9-bit asynchronous serial is very unusual these days. There's little if any hardware on the market capable of handling anything but 8-bit asynchronous data (one start bit + 8 data bits + 1-2 stop bits). The Propeller, since it handles asynchronous serial data in software, could easily do it. It's probably easiest to use the Simple_Serial object from the Object Exchange and modify it to handle 9 data bits. It's designed to handle up to about 19200 Baud and can be configured for half-duplex (either transmit or receive). You'd use one cog to receive the data and put it into a buffer using 16-bit words for elements and one cog to retransmit the data from the buffer. The receive cog would also put the data into one of several 512 byte buffers for writing to the SD card and the SD card routines would be running in a pair of cogs (one to handle the FAT file system and one to do the low level data transfer to the SD card). Look at the FSRW object in the Object Exchange for this.

You'd have to decide how you want to format the data, particularly since you'd need to pack the 9-bit data into 8-bit bytes for storage on the SD card. You could use 2 bytes per value or pack 3 values into 4 bytes or 7 values into 8 bytes if you're concerned about space.

Don M

Attached please find the specs for this communication protocol. Maybe someone here understands this better than I.

Leon

It uses the ninth bit to indicate an address, instead of data. That technique isn't used much these days.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM

Sapieha

Hi Don M.

It is not simple You describe in first post.

Yes it communicate with 9 BITS but only 8 BIT's are DATA else ADDRESS+COMMAND.
If 9bit is 0 then BYTE is data
If 9bit is 1 then byte is Device addres + command.

BUT you must monitor not only that and spare DATA because it can be resend data with communication problems.

For that You must monitor entire COMMUNICATIONS protokol and decide if it is DATA You must save else discard.

Regards
ChJ

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

Don M

So can this 9th bit be screened out somehow so that it can be determined if it is data or command? If so how does one do that?

In terms of what is already available in the OBEX library how would the simple serial be modified to look at this 9th bit?

Mike Green

In the receive routine (rx), there's a constant 8. Simply change it to 9. There's also a mask ($FF) in the last line of that routine for inverting the bits if requested. Change that to $1FF.

In the transmit routine (tx), there's a similar constant 10. Change that to 11. There's a mask ($100) for providing the stop bit. Change that to $200.

You probably should discard the string transmit routine (str) since it doesn't make sense for 9 bit data and you wouldn't be using it.

With these changes, the receive routine will provide a 9-bit value and the transmit routine will take a 9-bit value and send it.

You're going to have to learn enough about programming in Spin to answer your own question about screening data vs command information. That sort of question has nothing to do with the Propeller or Spin ... it's a basic programming issue ... "how do I do what I want to do with the data that I have?".

Post Edited (Mike Green) : 11/6/2009 4:10:37 PM GMT

Sapieha

Hi Don M.

Yes with bit 9 You can determine if it is DATA else COMMAND .... BUT not only it --- You can even with that BYTE + 9 = 1 determine with of DEVICE's send that DATA

and store DATA in arrays that have DEVICE index to separate data for every device

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

David B

If you plan to collect hundreds or thousands of megabytes of data, you probably would want to take care to pack the values tightly into storage.

But if you just need a small amount, like several minutes of logging then I don't think you need to be concerned about 512 byte SD buffers. Using the SD card FSRW routines, you could open a file, start writing characters to the file for as long as you wanted, close the file, power down the propeller, move the SD card to your PC and read the file of logged data.

You could convert the nine bits to ASCII hex and write the hex characters to the file, and let the PC application be concerned about how to decode the data.

Depending on what will be processing the file, maybe you could follow each value with a comma and insert CR/LF characters every few dozen values to make the file human-readable with a text editor, which can be quite valuable for debugging this sort of thing.

I don't think that you will need any more buffering than is already in the serial object and the SD card object. All you'll need to do is start the receiver object, open the file then for as long as you needed, poll the receiver for incoming values and write them to the file.

Be sure to have a way to set a stopping point, maybe by time, maybe by character count, maybe by monitoring another IO pin, so you can close the file properly or else the file can get corrupted.

Don M

If I want to time and date stamp this I assume I will also need to use a clock chip such as the DS1302?

Leon

Yes, if you want them to be accurate.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM

Don M

Ok. Thanks everyone thus far. I wll play around a bit and if I have any further questions you'll be hearing from me. [noparse];)[/noparse]