Is there an object for getting access to the 9th bit, parity bit in Serial objects?

waltsailing

Hi,

I would like to have a serial object that can easily let me get the serial data, all 8 bits, and then the next bit which is typically called the parity. I want to make use of the parity bit in my program but after reading the various serial port reading objects for the propeller, they all seem to skip this feature and do not provide any access to it. I am not looking for a object that checks the parity, but returns it in an array along with the serial data, or returns the serial data perhaps in a word, where the high byte would be the parity for each low byte as received. For my application, the parity bit is used as an extra data bit and access to it is important, so it is not being used as an error check.

I have been reading the example objects on the OBEX but cant find one that does this.

Does such a thing exist?

Thank You,

Walt,

Duane Degn

Walt,

I don't know of one myself. I've played around with some of the serial drivers. What you want doesn't sound too hard.

You want the data to be written to an array of words instead of bytes right? I might be inclined to give this a try if no one else comes up with a solution.

The object just needs to receive the extra bit right, it doesn't need to send nine bits?

Duane

waltsailing

Thanks You,

I am just looking to receive the parity bit along with the data. Exactly how is tbd.

I guess it would best if it were in the high byte of a word, where each word had the 8 lower bits filled with the 8 data bits.

I dont need to transmit or create the parity bit right now. Maybe later at some point. My system is running pretty slow, 4800 baud for the input data.

I was thinking i would write it myself, but if i missed the 'right' object that received the serial data and provided access to the parity that would likely be the safest way to move forward. I would have assumed this would exist and maybe it does but i have not located it yet.

Regards
Walt,

Mike Green

First of all, it's very unusual to have 8 bits of data plus a parity bit (a total of 9 bits plus start and stop bits). More commonly, you have 7 bits of data plus a parity bit for a total of 8 bits plus start and stop bits. The existing serial drivers are written for 8 bits of data which does accommodate 7 bits plus parity although you have to do the parity generation / checking yourself. It's fairly easy to modify any of the existing drivers for 8 bits of data plus parity, but there are no existing drivers that I know of nor am I aware of any that manage the parity for you.

Duane Degn

Have you found a serial object that uses a parity bit?

Was just looking at a couple. I expected to see a parity option in the mode setting but there wasn't any.

I think it still shouldn't be too tough. Read one extra bit, write a word instead of a byte, increment the buffer head by two instead of one.

The rxcheck method will also need to changed.

Is this something you can do yourself? I'm still willing to give it a try if no one else has a solution.

One problem I'll have is I don't have a way of testing it without also writing a version that sends a parity bit.

Duane

Edit: I just read Mike's reply. He makes it sound a little easier.

Mike Green

There's very little to adding a parity bit for transmission. If you're using assembly, all of the logic instructions as well as MOV will compute parity for you (into C). The parity can be added just before starting to shift out the data one bit at a time. Reception is another issue. The problem is where to keep the parity error information. Normally the buffer stores bytes. With parity, you have to store the received data plus a parity error bit. You'd probably do best with a word buffer (16 bits per entry). That's not hard to do, but it's different from what's normally done with 8 bits / no parity.

Mike G

Hopefully, someone else can clarify but I was taught the the parity bit was used as a CRC check. That way you have the ability to handle a transmission error. Like stop bit(s), the parity bit is not saved, it is consumed. You want 9 bit serial data that's a little different. Anyway, the FullDuplexSerial object can easily be modified to read 10 bits as apposed to 9 bits. The problem is where to store the extra bit. I'd probably go with a parallel array indexed with the receive buffer. That way the 8 bit data is intact and normal.

Duane Degn

Mike Green wrote: »

The problem is where to keep the parity error information.

I don't think Walt is using the extra bit for error checking. As I understand, he just wants to be able to receive nine bits instead of eight.

Duane Degn

Mike G wrote: »

I'd probably go with a parallel array indexed with the receive buffer.

I guess it depends on how the ninth bit is being used. A parallel array might be easier to code for but I think it would would limit the max speed more than using a word array.

Mike G

I guess it depends on how the ninth bit is being used. A parallel array might be easier to code for but I think it would would limit the max speed more than using a word array.

At 4800 baud, I'd rather view this as an interface policy over moving from a byte buffer to a word buffer. Whatever is clever...

waltsailing

Hi All,

Thanks for all the responses.

First, let me try to explain further. The interface I am using is a binary use of RS232. The data is not ASCII, but rather binary data. Typically on RS232, the interface has 7 or 8 bits assigned as the data. The serial data is a start bit, N data bits, followed by framing bits such as parity (optional) and stop bits (optional). Sometimes the parity will be in the 8 bits of the byte. Othertimes it will not be. In this case, it is not.

Typically parity is used for error checking. Most of the time people use it for this purpose. However, somewhere along the way, someone decided to use it as a command/data indicator bit.

In my case the interface uses this 9th bit as a command. If the 9th bit (Typically parity) is a one then the interface treats the 8 bits as a command. Otherwise it is data. The interface protocal i am working with goes something like this. Command byte, with the parity set to one. Then the next byte contains the length of the remaining bytes needed contained in the first nibble, so there is a limit to the message size. Then data bytes are sent. The parity bit for the data and the message length bytes are allways set to zero. It would be great if these were strings, but not this time, it is raw binary data.

Thanks,
Walt

dMajo

Mike Green wrote: »

First of all, it's very unusual to have 8 bits of data plus a parity bit (a total of 9 bits plus start and stop bits). More commonly, you have 7 bits of data plus a parity bit for a total of 8 bits plus start and stop bits. The existing serial drivers are written for 8 bits of data which does accommodate 7 bits plus parity although you have to do the parity generation / checking yourself. It's fairly easy to modify any of the existing drivers for 8 bits of data plus parity, but there are no existing drivers that I know of nor am I aware of any that manage the parity for you.

Mike I think it was a misunderstanding. Waltsailing is not searching for parity but for 9bit data transmission. All(most?) 8051 core compliant mcu have uarts that are capable of 9 bit data transmision. This is used in multipoint rs232 data transmission where with the 9 bit usually the master send to the bus the slave address for which the data are for.

This is not parity because you can still have 9 bit trasmission with even/odd/non parity

Mike Green

At the kind of Bauds you're talking about, you'd do best with an unbuffered serial routine like Simple_Serial, modified to use 9 bits of data instead of 8 bits.

PUB rx: rxByte | t
{{ Receive a byte; blocks caller until byte received. }}

  if rxOkay
    dira[sin]~                                          ' make rx pin an input
    waitpeq(inverted & |< sin, |< sin, 0)               ' wait for start bit
    t := cnt + bitTime >> 1                             ' sync + 1/2 bit
    repeat 9
      waitcnt(t += bitTime)                             ' wait for middle of bit
      rxByte := ina[sin] << 8 | rxByte >> 1             ' sample bit 
    waitcnt(t + bitTime)                                ' allow for stop bit 

    rxByte ^= inverted & $1FF                           ' adjust for mode

and

PUB tx(txByte) | t
{{ Transmit a byte; blocks caller until byte transmitted. }}

  if txOkay
    outa[sout] := !inverted                             ' set idle state
    dira[sout]~~                                        ' make tx pin an output        
    txByte := ((txByte | $200) << 2) ^ inverted         ' add stop bit, set mode 
    t := cnt                                            ' sync
    repeat 11                                           ' start + nine data bits + stop
      waitcnt(t += bitTime)                             ' wait bit time
      outa[sout] := (txByte >>= 1) & 1                  ' output bit (true mode)  
    
    if sout == sin
      dira[sout]~                                       ' release to pull-up/pull-down

Just substitute these for the routines in Simple_Serial and you'll have 9 bits of data instead of 8. You'll have to add whatever control logic you need for the multipoint control.

waltsailing

Hi Mike,

Thank you for this approach. I have been messing with the assembly in the fullduplexserial routines and have not figured that out yet. I was getting some of the bytes in using this, but then i think i was dropping bytes for some reason. May have to do with the timing between the data bytes coming in. Your answer is is very simple compared to that. I will give it a try this weekend when i get back to the project again. I'll give this a go. My next biggest concern is the time between the bytes... not much time from what I can tell, looking on the scope between the incomming words. The packets are few and far between, but not much room between the individual word transmissions. This seems much easier to make work than trying to do this in assembly.

The comment from dMajo above is right on, some of this data was generated from an 8051 operating in this exact manner.

Again, thank you for the assistance.

Regards,
Walt

Cluso99

FullDuplexSerial_rr006ep.spin

Here is a modified FDX that has 8+E parity inplemented and it is working. Note the buffer size is configurable in this version.

Ariba

Here is a modified FullDuplexSerial for 9 databits.

I have made this to communicate with a PIC, the 9th bit selected between data and command bytes.
I just had to delete all the additional methodes for the PIC functions for the attached version.

There is a little Testcode at begin which can be deleted after testing.

Andy

waltsailing

Hi Andy,

I spent the day messing around with this stuff.

FDserial_9bit.spin works!

I tried this and it worked, in about 10 minutes I had my real data coming in with it!

This is exactly what I needed. The 9 bit serial data was easily brought into the pc with this, and then right into VB and into the Parallax serial terminal for initial debut and understanding!

Data came out exactly as expected. 9th bit was there, and the commands and data made sense. This was interfaced to the real hardware.

You should post this on the object exchange. Others might find it useful.

Thank You,
Walt,

Phil Pilgrim (PhiPi)

'Late to this thread, I guess. Anyway, using a ninth bit in a multi-drop master/slave network for addressing is pretty common. However, for command vs. data matters, I prefer the following, which uses eight bits only:

1. For commands, send a DLE (data link escape = $10), followed by the command.

2. For data, just send the data. If the data byte happens to be a DLE, send two in a row.

3. For reception, if a DLE is received, look at the next byte. If it's also a DLE, just delete it and continue processing data. If it's not a DLE, process it as a command.

One big advantage to this protocol is that it can also be handled by any PC program that's used in a host or monitoring capacity without exceeding the bit capacity of the typical PC UART.

-Phil

waltsailing

In this case I was using the propeller to interface to some existing hardware with a defined protocal. The advantages are that the propeller can be connected directly to the VGA for displaying. Most cheap monitors and TV's support VGA input these days so it really simpliies displaying some data. The other is that it is directly connectable to the PC via the USB download cable and data can be shipped into the PC at pretty high speeds. The debug port is well behaved in that you can switch between the serial terminal, the development download and VB custom programs without much trouble all over the same cable. So for this the propeller worked great. What I am doing was bringing in seatalk data from the Raymarine system on our boat into the PC to make a logging system to track wind, speed, wind angle etc., Maybe some graphics or plots of this. Some of data is not put out onto the NMEA interface via the system I have. The seatalk to propeller protoboard interface consists of a couple of resistors and a FET.

Thanks,
Walt,

Phil Pilgrim (PhiPi)

Walt,

'Got it. Thanks for clarifying. For anyone interested, here's a document that explains the Sea Talk protocol that Walt is using:

http://www.caracolyachts.com/technical/t_seatalk.pdf

-Phil

Cluso99

Walt: Nice work.

I took my NMEA data on my boat and passed it to VB for displays using the prop. Didn't complete the project however as I found other things to do with my prop. I built opto isolated interfaces to my prop. Plan was/is to use Bluetooth to send to the PC, and that has now changed to sending WiFi to an iPad. In this case, isolation is not required. I also want to get the engine info (temp, oil, revs) and the tanks (fuel, water, blackwater) too. Then one last thing is to control my autopilot (simply at first with just a heading). But alas, no time at present... too many other prop projects and no sailing time at present.

BTW I have Navman gear and I understand they use CAN.

waltsailing

Hi,

http://www.youtube.com/watch?v=nGGVK2JuE_M

It will be on with our other videos.

http://www.youtube.com/user/waltsailing2009

Here is a short video of some of the initial testing. The interface seems to work just fine using the propeller as an interface. Very simple thing to do using the 9 bit serial routine. I started off this thread looking for which object to download and got the answer and had a couple of really great solutions.

The circuit is a 2n7000 FET with a couple of resistors, one bringing the seatalk into the gate, the other to tie the output of the ckt to the 3.3 volts. The seatalk is 12 V high and 0 volts low. Don't hook this up directly to the propeller unless you buffer it. The FET and resistors inverts it, but that doesnt matter, the key thing is to get the voltages safe for the prop. I suppose a single series resistor might work as is often done with serial data and a stamp, but i decided not to do that here.

I had not seen that link. Will have to check it out. Might answer the couple of sentances i am seeing that dont make sense yet.

My interest in this came from the fact that the NEMA - Seatalk bridge I have in the chart plotter doesnt spit out wind for some reason. Stupidest thing, it puts just about every thing else out, but the wind info. This resolved that!

Thanks,
Walt,

Cluso99

Walt: You can use a simple resistor divider to shift 12V to 3v3 (eg 3K3 and 1K2 would work nicely, as would 33K and 12K but not as much noise supression - depends on length of cable, etc). But a buffer of any kind adds protection to the prop.

BTW What chart software are you using? I use SOB (Software On Board)

waltsailing

Hi

The chart plotter program running on the PC is the OPEN CPN program. I also have seaclear. And, one which i wrote myself. The open CPN is the best. In the US, the charts are all free and they can be downloaded pretty easily. This does not take in the data i am messing with, that is custom running VB.net (I know some of you think .NET is no good, but it works just fine for me).

You are right, that a couple of resistors could divide the voltage down, but i figured that a FET in line would be better protection for the propeller should it not be powered when the seatalk was on. I didnt want to have somethng out there with power availble on a data pin without power on the power pin of the propeller. I likely would be ok, but that might not be a good thing in the long term. Maybe ill have to check the data sheets again for this condition. Ether way, what i have seems to work ok.

my next project is to run the wires under the deck floor so that it is not running accross the cockpit out in the open where people can trip and pull tht propeller off the shelf!

http://home.comcast.net/~waltschn4/australia1/Catamaran_sidney_harbor.jpg

I took this picture in sidey harbor a few years ago, is this you?

http://home.comcast.net/~waltschn4/australia1/IMG_0663x.JPG

The above cats are in freemantle.

http://home.comcast.net/~waltschn4/australia1/cropped_jelly.jpg

Then here is the picture of the famous deadly australian box jelly fish that i managed to photograph while in australia once.. Stay away from these.

Now off to figure out some scrolling chart code for my program.

Regards,
Walt,

Cluso99

Nice pics Walt. The one at dock could just as easily been taken at Manly, Brisbane.

If you are worried about interfacing then use an optocoupler (IIRC I used a 4N36) and it works quite well for NMEA. Unfortunately my circuit is on the boat so I cannot post today. You can use the opto to do inversion or not. The circuit is quite simple. A resistor in series to the led on the opto. Tie the other respective led pin high or low (this is how to get inversion). The other side is a transistor with the emitter to ground and a 10K? pullup to 3v3 on the collector, with the collector to the prop input pin. This is a typical NMEA isolation circuit but the 4N36 does a better job than 4N27, etc. http://media.digikey.com/pdf/Data%20Sheets/Fairchild%20PDFs/4N25-28_35-37,%20H11A1-A5.pdf

waltsailing

THanks, i have to check that out. What i have is now working from an electrical point of view and signals looked good on the scope so i'll likey leave it alone or maybe solder up the circuit and box it up rather than the bread board. It's pretty simple and maybe i'll switch it around to a opto isolated version. Might get back to it later this week again. its just a hobby project here.

That dock photo is taken right behind the mcdonalds in fremantal. Fremantal had a water front mcdonalds!!!

Regards,
Walt,

waltsailing

Hi,

http://youtu.be/XHJnQscSXxU

For those of you who have help, the results are working great! The above video shows the latest state of the display program for the seatalk data. The way this works is the propeller is reading the seatalk data and transmitting it to the PC. Then the PC running visual basic "dot" net, which is used to receive the raw data and produce some plots, ,graphics and to implement a chart plotter. The graphics are crude, and the layout is rather random, but it works. The program logs the data and displays it, and can then go and play it back in fast forward to allow me to debug it. Writing code while driving the boat is not a good idea, better to just set it to collect data and do that later. So today, i finaly got the boat away from the dock, and got the propeller running, this time with the program in prom rather than having to download it.

Regards,
Walt,