Odd Parity Device and Hex Strings
Hey guys. I just got a device in that uses odd parity.
Quite some time ago Mike mentioned that to communicate bi-directionally using odd parity, the ASM section of FDS would need tweaking.
Anyone know if there is an existing obj that has a switch on it to manage odd? I went through the whole list today of objects and don't see a description of anything that relates.
Ideally, I want to use the 4xport Full Duplex object to save cogs as there are other serial coms, but would settle for anything just to get testing right away.
8 bits, odd par, 1 stop, least sig bit first.
Thanks
Quite some time ago Mike mentioned that to communicate bi-directionally using odd parity, the ASM section of FDS would need tweaking.
Anyone know if there is an existing obj that has a switch on it to manage odd? I went through the whole list today of objects and don't see a description of anything that relates.
Ideally, I want to use the 4xport Full Duplex object to save cogs as there are other serial coms, but would settle for anything just to get testing right away.
8 bits, odd par, 1 stop, least sig bit first.
Thanks
Comments
If it is 8bit odd par then the PASM will need changing. The tx code sends 10 bits - 1start, 8 bits, 1 stop. If you want to take a look at moding 4port serial, you probably can't mod all the ports, there isn't enough cog memory left.
This is the code you need to change. in particular txdata needs the 9th bit set to odd parity, before the shl instruction shown. This code is for the first port, similar code exists for each other port. Then change the last instruction to 12 bits.
For the receive side
Change the 9 in the first and last instruction to 10. This will not check partiy but just ignore it.
If you try to change the settings to even or none, the communication goes dead.
I will try to make sense of the changes you pointed out, thanks for posting that.
To transmit oddParity do: ser.tx(oddParity(char))
To check a received character for validity you can do: IF oddParity(char & $7F) == char
First instruction sets c if there is an odd number of 1's in txdata, next 2 shift carry·to 9th bit·temp variable, last instruction or's it with txdata
Regards,
Ken
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
and txdata, #$ff wc 'generate odd parity
muxc txdata,$100 'set the 9th bit to parity
The receive path also checks the parity rather than just ignoring it.
02 D2 00 00
This is the string the devices debug test app uses to send to an inquiry to see if the device is working, and the device responds with another string
So I assumed I could do this:
serial.ser(string($02, $D2, $00,$00))
Yet I get the error on Run that says "string characters must range from 1-255" regarding the $00
What am I missing here?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
The basic commands contain $00 mixed in between other hex values.
Is it just the fact that FDS will not allow $00's, or the Prop in general?
So far I am not getting a response without the complete string being sent 0x02 0xD2 0x00 0x00
When I do this with the PC terminal they supply, the unit responds. But when I sent the truncated version 0x02 0xD2 there is no response.
Here is an example code:
//CommandStructure: Startbyte 0x02, index 0 , command 0x80, no payload
·m_CommandArray [noparse][[/noparse]0] = 0x02;
·m_CommandArray [noparse][[/noparse]1] = 0x00;
·m_CommandArray [noparse][[/noparse]2] = 0x00;
·m_CommandArray [noparse][[/noparse]3] = API_CAPTURE_IMAGE; //0x80;
·m_CommandArray [noparse][[/noparse]4] = 0x00;
·m_CommandArray [noparse][[/noparse]5] = 0x00;
·if (checkFingerPresent) m_CommandArray [noparse][[/noparse]3] = API_CAPTURE_IMAGE_FINGERPRESENT;
·if (!WriteFile(m_hComm, m_CommandArray, 6, &nWritten, NULL))
·{
··return FALSE;
·//CommandBuffer: Startbyte 0x02, no index, command 0x90, no payload
·m_CommandArray [noparse][[/noparse]0] = 0x02;
·m_CommandArray [noparse][[/noparse]1] = 0x01; //Will skip the CRC generation if set to 1.
·m_CommandArray [noparse][[/noparse]2] = 0x00;
·m_CommandArray [noparse][[/noparse]3] = API_UPLOAD_IMAGE; //0x90;
·m_CommandArray [noparse][[/noparse]4] = 0x00;
·m_CommandArray [noparse][[/noparse]5] = 0x00;
·//CommandStructure: Startbyte 0x02, no index, command 0x81, no payload
·m_CommandArray [noparse][[/noparse]0] = 0x02;
·m_CommandArray [noparse][[/noparse]1] = 0x00;
·m_CommandArray [noparse][[/noparse]2] = 0x00;
·m_CommandArray [noparse][[/noparse]3] = API_CAPTURE_AND_ENROL_RAM; //0x81;
·m_CommandArray [noparse][[/noparse]4] = 0x00;
·m_CommandArray [noparse][[/noparse]5] = 0x00;
// Response byte values·····HEX value
#define API_FAILURE······· 0x00
#define API_SUCCESS······0x01
Is there a substitute that may work to fill in the blank sections of the array on tx?· I will deal with the Rx as a secondary issue, since I just want to get the thing to respond via it's own debug for starters.·
Thanks for any suggestions
Post Edited (Originator) : 9/18/2008 4:14:48 AM GMT
PRI send(arrStr, len) | i
repeat i from 0 to len-1
serial.tx(byte[noparse][[/noparse]arrStr+i])
send(@m_CommandArray,6) will send 6 bytes of any value
Ok this is really messy test code but after many hours I have some steady response from the device back to the prop.· The responses aren't what I am expecting, but thats ok, at least they are talking.
The device wants hex in and out, I have no idea what I am really sending and receiving in the above code.·Since are just a few routines I need to send to it, I was thinking of setting up Arrays as shown that get loaded with the hex for each requirement, with corresponding names for the arrays.·
I feel that the parity must still be an issue, the device uses ODD.· I am testing with the FDP parity version that was posted earlier in the thread.
I think it's time to roll up my sleeves and figure this out myself so I can know the fundamentals, but assembly is out of the question at the moment, so bit banging is the only thing I'll have time to deal with.
Can someone point me towards some learning resource to learn this serial comm stuff in a fast and practical way that applies to spin, so I can get an understanding and get this handled.
Thanks
The·first I have seen the Hardware Test OK·response so far!
02 08 00 00
02 is the response start byte, 08 is HWare·OK
There is a pattern:
success
fail
success
fail
fail
success
repeat
Very close though.· Thanks Tim for that mod.
Post Edited (Originator) : 9/19/2008 8:02:05 AM GMT
2 things to look at about the failures.
1. Are you always sending the same message. If no calculate the parity by hand. Does the parity change, if so it could mean theres a problem with the parity generation
2. Is there a terminating char when you send, e.g. are you meant ot send a CR or LF or both after sending the command sequence?
No, there will be maybe 10-15 standard messages. I am send the test as just one string that never changes.
2. Is there a terminating char when you send, e.g. are you meant to send a CR or LF or both after sending the command sequence?
No there are no terminations sent, just 4 bytes starting with 02
Thanks for taking a look at it.
Post Edited (Originator) : 9/19/2008 7:38:03 PM GMT
What exactly is printed out when it fails, if the device sends CR,LF then its going to affect the next response. i.e. teh next response will have the 02 offset and a different hex printed out for the first hex number
I found the error!
This is what I was really doing to produce the inconsistent response after the parity issue was finally resolved with adapted 4port:
PRI send
Repeat
ser.tx(0,$02) 'start byte
ser.tx(0,$00) 'unused
ser.tx(0,$00) 'unused
ser.tx(0,$D2) 'HW test
ser.tx(0,$00) 'unused
ser.tx(0,$00) 'unused
The 'repeat' is the problem, remove it and 100% accuracy.
I had modified the PUB Send from earlier that used the repeat and forgot to take out the repeat line.
For some strange reason, only when I use the 6 separate lines of TX does it respond, no variation of ser.tx, ser.hex, ser.str works, only the 6 separate lines.
In any case, this is working.
The following should work as well, if you fill the array how you did before.
Thanks for the 4 port serial object - it works great.. Just wondering if you can help me with a small problem though. I'm playing with a Lassen iQ GPS receiver which uses 9600,8,ODD,1. I am using your modified version of the serial object which has port 0 as default ODD parity. This works great for receiving data from the GPS but I cant seem to get it to work TXing to the GPS. I think the problem may be that when TX completes a byte, the TX line stays LOW - as compared to the GPS output which leaves the TX line HIGH. See attached picture - the upper trace is the propeller output to the GPS and the lower one is the output from the GPS. I have spent a fair amount of time looking at your code to see where it can be modified without much success unfortunately. The other possibility is that I am missing something entirely obvious of course! Help with this problem would be much appreciated.
Thanks in advance,
S
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
News Flash!... Energizer Bunny arrested and charged with battery.
I am guessing it is something else being overlooked.
Post Edited (Originator) : 11/9/2008 8:43:55 AM GMT