cof_serXread, costates, and serial E and F interfering with each other.

Platform: BL4S200 Dynamic C 10.56

OK, things are working quite well with the BL4s200 but here's a strange one.

I've got serial C port working (the RS485) in transmit mode only at 19200

I've got the serial E port working as a talker-listener pair to a dumb terminal at 57200 baud (see costates 'talker_E' and 'listener_E', I'll post source in the files section.)

I've got serial F designed to read a GPS RS232 output (4800 baud) but no GPS unit hooked up to it, so no data is received on the port.

What is strange is if I activate the costate listener_F, the costate listener_E stops working after the first or second message. In the included copy of my C source, I have 'listener_F' (the GPS data stream monitor) commented out and everything works fine. If I activate the code, listener_E stops working. I haven't seen if hooking up a GPS data stream helps things yet, I'm suspecting that the line :

258: wfd nread = cof_serFread(gpsinbuffersz, 499, 20);

Is an infinite wait somehow effecting serial E, but its not locking the entire system, as the LED heartbeats, the talkers and speed_checker are all working fine. Its only the 'listener_E' that seem effected.

Any ideas?
ok, some more info. these guys are mutually exclusive.

when I hook up the gps receiver to the serial F serial E works fine but serial F is suspended as serial E is sitting in its WFD state.

I checked this by hooking up the gps receiver and adding print lines above and below the WFD statements of listener_E and listener_F.

My guess is that while cof_serEread and cof_serFread appear to be different functions, they are under the covers calling one function and these two co_states are actually mutually exclusive.

These serial ports are definitely alternating their read cycles.
The log of stdio is below.

You can see the program starts off fine with the "top of" print statements appearing, but you notice that despite an active GPS data stream coming in on port F, the speedchecker is reporting a timeout and the listener_F never gets past the ser_Fread statement. That is UNTIL I type on the dumb terminal set to talk to port E.

I typed "test" on the dumb terminal port, and low and behold, listener_E is Satisfied, AND THEN LISTENER_F gets satisfies for ONE AND ONLY ONE burst of data.

Here's the stdio log from the run of the code that I attached:
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++
Hello: bl4s200 - gps,matrix_orbital 091104_01
top of listener_E
top of listener_F
speed_checker:128: current speed: >-6<
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
talker_E:00001: no response.
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
after wfd of listener_E
listener_C:got 4 chars: >test<
top of listener_E
after wfd of listener_F
top of listener_F
speed_checker:15: current speed: >-14<
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
after wfd of listener_E
listener_C:got 5 chars: >2test<
top of listener_E
after wfd of listener_F
top of listener_F
speed_checker:15: current speed: >-14<
talker_E:00002: received answer >2test<
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
speedchecker: no response, abort
++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++
A possible solution is would be if I can force a wfd(cof_serXread...) statement to abort (abandon?) or somehow release? The timeout functionality only works AFTER the first character is received, but does nothing for me if there is no data coming. I need away for the program to know its not going to have its read satisfied.

TIA

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

Jon L wrote:
> cof_serXread, costates, and serial E and F interfering with each other.
>
> Platform: BL4S200 Dynamic C 10.56
>
> OK, things are working quite well with the BL4s200 but here's a strange one.
>
> I've got serial C port working (the RS485) in transmit mode only at 19200
>
> I've got the serial E port working as a talker-listener pair to a dumb terminal at 57200 baud (see costates 'talker_E' and 'listener_E', I'll post source in the files section.)
>
> I've got serial F designed to read a GPS RS232 output (4800 baud) but no GPS unit hooked up to it, so no data is received on the port.
>
> What is strange is if I activate the costate listener_F, the costate listener_E stops working after the first or second message. In the included copy of my C source, I have 'listener_F' (the GPS data stream monitor) commented out and everything works fine. If I activate the code, listener_E stops working. I haven't seen if hooking up a GPS data stream helps things yet, I'm suspecting that the line :
>
> 258: wfd nread = cof_serFread(gpsinbuffersz, 499, 20);
>
> Is an infinite wait somehow effecting serial E, but its not locking the entire system, as the LED heartbeats, the talkers and speed_checker are all working fine. Its only the 'listener_E' that seem effected.
>
> Any ideas?
> ok, some more info. these guys are mutually exclusive.
>
> when I hook up the gps receiver to the serial F serial E works fine but serial F is suspended as serial E is sitting in its WFD state.
>
> I checked this by hooking up the gps receiver and adding print lines above and below the WFD statements of listener_E and listener_F.
>
> My guess is that while cof_serEread and cof_serFread appear to be different functions, they are under the covers calling one function and these two co_states are actually mutually exclusive.
>
> These serial ports are definitely alternating their read cycles.
>

Did not look at the code much. You can use multiple ports with no problem.

It might be just DC bugginess with costates. I have seen once code
reaches a certian size, one of the costates will stop operating properly.

STack use is one thing, costates mess with stacks and make assumptions
on variable sizes. You might try making the buffers in min() static.

These type of problems are why I ported CoExec to DC. I now refuse to
write code for costates. Just too buggy and DC's code is a mess (like
serial ports _only_ will time out after the first character and not
return 0 if no data.)

--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------

today's fortune
If you don't drink it, someone else will.

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )