Serial Protocol

T Chap

There is a device I want the Prop to talk to bi directionally

it's spec sheet says it is 8 bits, odd par, 1 stop, least sig bit first.

I am thinking this is not standard for the Full Duplex object.

I don't have the device yet, but am curious if this is going to be something that can be worked around with some tricks.

Thanks for any insight on this.

Mike Green

The only thing that's different about this situation is the odd parity. As far as the FullDuplexSerial driver is concerned, it's just 8 bit data. When you transmit to the device, you need to add odd parity. When you receive data from the device, you need to strip off the parity bit after possibly checking for correct odd parity (if you want).

Both could be done with Spin, but it would be easier to do this in the assembly portion of the FullDuplexSerial driver because the Propeller has built-in hardware for parity checking/generation, but Spin doesn't have an equivalent operation.

T Chap

Thanks for that info Mike.

I looked at the object's assembly section, not knowing the language obviously I don't understand what would need to be changed in there, but when the parts come in I will experiment with it and post back to get some ideas on how to implement the assembly revision.


A second question has come up. There will be cases where there are two of the devices connected to the Prop. Data from one device will ned to be transfered by the Prop to the other and vice versa.

said...
The received payload in a successful upload consists of 30400 bytes plus the 4 CRC bytes.

Is the best way to manage that data to put an extra 256k eeprom on board as a temp storage? Read one device and park the 30400 bytes on it, then transfer to the other device? it seems rather tricky to access one device in upload mode and the other device in download mode so that the Prop could manage the data in small chunks.

Post Edited (Originator) : 5/4/2008 7:47:19 PM GMT

Mike Green

It's really impossible to answer "best" questions with the limited amount of information you've provided. The most important pieces are the average and peak data rates since EEPROMs take time to write their data (about 5ms per write cycle which can handle from 1 to 256 bytes). Reading is faster.

EEPROMs wear out eventually. It takes a lot of writes to wear them out (100000+), but it can be done in a month or so if you write to the same location once a second. There are other devices that can be used for buffering data. Each has its advantages and disadvantages

Ken Peterson

Peter Jakacki has worked on several versions of FDS with parity, flow control, etc. He claims they are not polished enough to post on the exchange, but he might find time to clean them up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

T Chap

Thanks for the info guys. I wrote the manufacturer of the device and asked if they had any built in way to control the flow of data and am still waiting for a response.

There is already a VNC1L connected to a USB drive, so that could be used as well for a temp storage. This particular process of transferring the data from one to the other will never come close to 100k operations.

At a slow enough baud I think the EEPROM or USB drive would write fast enough. Since both devices are connected to the Prop on separate Tx and Rx pins, another thought is to simply pass through the data, set one in transmit and one to receive, and let the data pass through the Prop one byte at a time, bypassing any temp storage medium.

T Chap

TPW_man just posted this code example below in a similar thread regarding Serial Buffering:

CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

obj
ser1 : "FullDuplexSerial"
ser2 : "FullDuplexSerial"

pub main
ser1.start(<input pin>, <irrelevant>, <mode(usually 0)>, <baud rate>)
ser2.start(<irrelevant>, <output pin>, <mode(usually 0)>, <baud rate>)
repeat
  ser2.tx(ser1.rx)

I think this is the best solution if it will work, let the Prop tell one device to get ready to receive, then tell the other device to Transmit, then set the pins to route the data as shown above.

No temp storage needed.

Post Edited (Originator) : 5/5/2008 6:54:02 AM GMT

simonl

I'm probably being really 'desne' here but; what's the Prop' needed for if you're just passing the data through? Couldn't you just hard-wire the two devices?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

T Chap

The devices are simple slaves and can do nothing unless told to do so on their serial i/o. Since their serial i/o are where it gets it's instructions, as well as where the data would get transfered, there must remain the Prop to initiate every action. In this case, the Prop will first initiate the ready receive mode on one, then the start upload on another, then the Prop will at once go into a "pass through" mode and send the Rx straight out to Tc pin, to the receiving device. You can't hardwire them AND have the Prop control them at the same time, short of some digital switching which would be awkward.

I just received news from their tech. Among other blatant mistakes in the PDF of the devices, the actual data that needs to be shared is 938 bytes, not 30400 bytes as originally understood from the data sheet.