 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Paul E. Schoen
Guest
|
 Posted: Thu Feb 02, 2006 5:22 pm Post subject: Re: Serial Communication Problems |
 |
|
Thanks to Hans-Peter and Alan for your replies.
I made a mistake in the OP. The data is sent LSB+MSB, and uses bits <0:1>
for the data check and bits <2..7> for the data. So, the data is shr 2 for
LSB, and the MSB is shl 6. I am always treating the data as 12 bit, but the
A/D is only 10 bit, so I mask off the two lower bits. I made this change
after writing the original system spec, so the software matches the hardware
and PIC code. Sorry about the wild goose chase there.
| Quote: |
In any case I'd move all string handling (error messages...) into
dedicated subroutines, to remove the related (hidden) try-finally blocks
from the mainstream code.
|
I added that as a last minute idea for debugging. It does create a lot of
overhead, but the problem existed before that.
| Quote: |
4 I would tend to take each two input bytes as they come, combine /flag
them, and put them in the final buffer. Rather than putting them in a
buffer as they come, and then doing the combining/flag on all in the
buffer. But that's maybe detail, OTOH a simpler program design often
helps in identifying problems.
ACK. I'd remember a "first" byte, and combine it with the immediately
following byte when the sync fields match, or discard the old byte and
replace it by the new character, and possibly generate an "data lost"
value. The resulting value is stored in a buffer of words, with no gain
in byte size, but with only 50% of the buffer operations.
|
I am also considering a modification where the LSB flag would be even, and
the MSB flag would be odd, so a valid sequence would be (0,1,2,3,0..). Then
I would know which of the characters was missing, and I could always sync on
the even flag (bit 0 = 0). Then bit 1 should always be the same for each
pair. I would have to miss four characters to have an undetected error. In
my application, it would not be a major problem to replace a missed sample
with a zero, or even better, a copy of the previous sample. The most serious
problem is when the LSB and MSB are switched and sometimes I get a "spike".
This is because the raw data is shifted by 2048 counts, so a zero is
actually a -2048, which triggers an overrange detector and invalidates the
test.
I can see room for improvement here. I just wanted the OnCluster event
handler to be as fast as possible, so I could do the more time intensive
processing in the 5/sec update loop.
One possibility for error I am considering is that the OnCluster event
(which is generated by a separate thread) could fire while the handler is
still executing, and may cause corruption of the pointers. Maybe I need to
make that code a critical section.
Also, maybe I need separate buffer pointers for my update routine, which may
be reading data from the secondary CommBuffer while the event handler is
writing to it.
| Quote: |
5) Make sure that no software handshake will be triggered by possible
XON/XOFF values, i.e. software handshake must never be used on such
binary data!
|
Yes. XON/XOFF is turned off.
| Quote: |
6) Even a "slow" machine should not be overloaded by the given code and
interrupt frequency. But the application, or possibly a "real time"
thread, should be given the highest runtime priority, to reduce the
impact of concurrently running applications.
|
Is there a way to boost the priority of the main Application thread?
Thanks!
Paul
|
|
| Back to top |
|
 |
Hans-Peter Diettrich
Guest
|
| Posted: Thu Feb 02, 2006 7:44 pm Post subject: Re: Serial Communication Problems |
|
|
Paul E. Schoen schrieb:
| Quote: | I am also considering a modification where the LSB flag would be even, and
the MSB flag would be odd, so a valid sequence would be (0,1,2,3,0..).
|
Do so, if you have control over the data format.
| Quote: | One possibility for error I am considering is that the OnCluster event
(which is generated by a separate thread) could fire while the handler is
still executing, and may cause corruption of the pointers. Maybe I need to
make that code a critical section.
Also, maybe I need separate buffer pointers for my update routine, which may
be reading data from the secondary CommBuffer while the event handler is
writing to it.
|
The write pointer is under control of the writer, and the read pointer
is under control of the reader, no corruption problem so far. The writer
can detect an buffer overrun by a comparison of both pointers
(read-only), so that a critical section, or InterlockedIncrement, could
be used in the interruptable read procedure, for updates of the read
pointer.
| Quote: | Is there a way to boost the priority of the main Application thread?
|
The same way as for other threads? I couldn't find useful information
about priority settings, besides for drivers or .NET :-(
DoDi
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
