Sign in
Search rabbit-semi
Subscribe to rabbit-semi
Ads
Discussion Groups
See Also
Discussion Groups | Rabbit-Semi | Re: cof_serXread, costates, and serial E and F interfering with each other. [1 Attachment]
This is a group for folks designing and programming embedded systems using the Rabbit Semiconductor C-programmable microcontroller. Rabbit Semi is a spin-off from Z-World who makes a variety of embedded modules and tools. This group is not affiliated with either Rabbit or Z-World, but is a user forum for sharing ideas, asking questions, flaunting knowledge, and other typical user group stuff. The Rabbit is a powerful uC, supported by a full-featured C-compiler.
Re: cof_serXread, costates, and serial E and F interfering with each other. [1 Attachment] - Jonathan Leslie - Nov 6 10:00:20 2009
<*>[Attachment(s) from Jonathan Leslie included below]
--- On Fri, 11/6/09, Scott Henion wrote:
From: Scott Henion
Subject: Re: [rabbit-semi] cof_serXread, costates, and serial E and F inter=
fering with each other.
To: r...@yahoogroups.com
Date: Friday, November 6, 2009, 9:21 AM
Jon L wrote:
> cof_serXread, costates, and serial E and F interfering with each other.
>
> Platform:=A0 BL4S200 Dynamic C 10.56
>
> OK, things are working quite well with the BL4s200 but here's a strange o=
ne.
>
> 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 te=
rminal at 57200 baud (see costates 'talker_E' and 'listener_E', I'll post s=
ource in the files section.)=20
>
> 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 list=
ener_E stops working after the first or second message. In the included cop=
y of my C source, I have 'listener_F' (the GPS data stream monitor) comment=
ed 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 =3D cof_serFread(gpsinbuffersz, 499, 20);
>
> Is an infinite wait somehow effecting serial E, but its not locking the e=
ntire 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 s=
erial 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 abov=
e and below the WFD statements of listener_E and listener_F.
>
> My guess is that while cof_serEread and cof_serFread appear to be differe=
nt 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.
>=A0=A0=A0
> 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.)
--=20
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
|=A0=A0=A0Consultant=A0=A0=A0|=A0=A0=A0Stone Mountain, GA=A0 |
|=A0=A0=A0SHDesigns http://www.shdesigns.org=A0=A0=A0|
------------------------------------------
OK that's good to know I started reading about he CoExec and was hoping it =
might have a solution for me. My current program is showing a :size of und=
er 60000 It shows:
Board:0x2A01 -58Mhz, BL4S200, 512K_512K SRAM, 1M serial program flash
xxxx/59392
on the loading to flash popup.=20
I don't think I'm having a size issue. I think that under the covers, the=
functions cof_serEread and cof_serFread boil down to a single generic func=
tion and are stepping on each other rather than run in separate memory spac=
e.=20
"STack use is one thing, costates mess with stacks and make assumptions
on variable sizes. You might try making the buffers in min() static."
I don't know what you are talking about here. I don't know what "min()" is.=
Could you explain a bit more/show an example?
"These type of problems are why I ported CoExec to DC" Now this seems like=
the correct solution do you have an example of this? The dynamic C User's=
manual describes uC/OS-II is that the same thing?
"like serial ports _only_ will time out after the first character and not
return 0 if no data"
yeah, this one boggles the mind, although I've bypassed this issue with the=
costates of talker_x and listener_x. HOWEVER, I was not expecting that an =
infinite wait on serial E would suspend the read on serial F. That isn't r=
ight, I must be doing something wrong.=20
<*>Attachment(s) from Jonathan Leslie:
<*> 1 of 1 Photo(s) http://groups.yahoo.com/group/rabbit-semi/attachments/f=
older/1023118290/item/list=20
<*> screencap02_size.jpg
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
--- On Fri, 11/6/09, Scott Henion
From: Scott Henion
Subject: Re: [rabbit-semi] cof_serXread, costates, and serial E and F inter=
fering with each other.
To: r...@yahoogroups.com
Date: Friday, November 6, 2009, 9:21 AM
Jon L wrote:
> cof_serXread, costates, and serial E and F interfering with each other.
>
> Platform:=A0 BL4S200 Dynamic C 10.56
>
> OK, things are working quite well with the BL4s200 but here's a strange o=
ne.
>
> 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 te=
rminal at 57200 baud (see costates 'talker_E' and 'listener_E', I'll post s=
ource in the files section.)=20
>
> 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 list=
ener_E stops working after the first or second message. In the included cop=
y of my C source, I have 'listener_F' (the GPS data stream monitor) comment=
ed 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 =3D cof_serFread(gpsinbuffersz, 499, 20);
>
> Is an infinite wait somehow effecting serial E, but its not locking the e=
ntire 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 s=
erial 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 abov=
e and below the WFD statements of listener_E and listener_F.
>
> My guess is that while cof_serEread and cof_serFread appear to be differe=
nt 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.
>=A0=A0=A0
> 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.)
--=20
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
|=A0=A0=A0Consultant=A0=A0=A0|=A0=A0=A0Stone Mountain, GA=A0 |
|=A0=A0=A0SHDesigns http://www.shdesigns.org=A0=A0=A0|
------------------------------------------
OK that's good to know I started reading about he CoExec and was hoping it =
might have a solution for me. My current program is showing a :size of und=
er 60000
Board:0x2A01 -58Mhz, BL4S200, 512K_512K SRAM, 1M serial program flash
xxxx/59392
on the loading to flash popup.=20
I don't think I'm having a size issue. I think that under the covers, the=
functions cof_serEread and cof_serFread boil down to a single generic func=
tion and are stepping on each other rather than run in separate memory spac=
e.=20
"STack use is one thing, costates mess with stacks and make assumptions
on variable sizes. You might try making the buffers in min() static."
I don't know what you are talking about here. I don't know what "min()" is.=
Could you explain a bit more/show an example?
"These type of problems are why I ported CoExec to DC" Now this seems like=
the correct solution do you have an example of this? The dynamic C User's=
manual describes uC/OS-II is that the same thing?
"like serial ports _only_ will time out after the first character and not
return 0 if no data"
yeah, this one boggles the mind, although I've bypassed this issue with the=
costates of talker_x and listener_x. HOWEVER, I was not expecting that an =
infinite wait on serial E would suspend the read on serial F. That isn't r=
ight, I must be doing something wrong.=20
<*>Attachment(s) from Jonathan Leslie:
<*> 1 of 1 Photo(s) http://groups.yahoo.com/group/rabbit-semi/attachments/f=
older/1023118290/item/list=20
<*> screencap02_size.jpg
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: cof_serXread, costates, and serial E and F interfering with each other. - Scott Henion - Nov 6 10:07:55 2009
>
> OK that's good to know I started reading about he CoExec and was hoping it might have a solution for me. My current program is showing a :size of under 60000
It shows:
>
> Board:0x2A01 -58Mhz, BL4S200, 512K_512K SRAM, 1M serial program flash
> xxxx/59392
>
> on the loading to flash popup.
>
> I don't think I'm having a size issue. I think that under the covers, the functions cof_serEread and cof_serFread boil down to a single generic function and are stepping on each other rather than run in separate memory space.
>
> "STack use is one thing, costates mess with stacks and make assumptions
> on variable sizes. You might try making the buffers in min() static."
>
> I don't know what you are talking about here. I don't know what "min()" is. Could you explain a bit more/show an example?
>
It meant to say main()
> "These type of problems are why I ported CoExec to DC" Now this seems like the correct solution do you have an example of this? The dynamic C User's manual describes uC/OS-II is that the same thing?
>
> "like serial ports _only_ will time out after the first character and not
> return 0 if no data"
>
> yeah, this one boggles the mind, although I've bypassed this issue with the costates of talker_x and listener_x. HOWEVER, I was not expecting that an infinite wait on serial E would suspend the read on serial F. That isn't right, I must be doing something wrong.
>
Did not realize you were using a 4k board. Coexec does not support the
4k chips.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> OK that's good to know I started reading about he CoExec and was hoping it might have a solution for me. My current program is showing a :size of under 60000
>
> Board:0x2A01 -58Mhz, BL4S200, 512K_512K SRAM, 1M serial program flash
> xxxx/59392
>
> on the loading to flash popup.
>
> I don't think I'm having a size issue. I think that under the covers, the functions cof_serEread and cof_serFread boil down to a single generic function and are stepping on each other rather than run in separate memory space.
>
> "STack use is one thing, costates mess with stacks and make assumptions
> on variable sizes. You might try making the buffers in min() static."
>
> I don't know what you are talking about here. I don't know what "min()" is. Could you explain a bit more/show an example?
>
It meant to say main()
> "These type of problems are why I ported CoExec to DC" Now this seems like the correct solution do you have an example of this? The dynamic C User's manual describes uC/OS-II is that the same thing?
>
> "like serial ports _only_ will time out after the first character and not
> return 0 if no data"
>
> yeah, this one boggles the mind, although I've bypassed this issue with the costates of talker_x and listener_x. HOWEVER, I was not expecting that an infinite wait on serial E would suspend the read on serial F. That isn't right, I must be doing something wrong.
>
Did not realize you were using a 4k board. Coexec does not support the
4k chips.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: cof_serXread, costates, and serial E and F interfering with each other. - Jon L - Nov 6 10:48:08 2009
--- In r...@yahoogroups.com, Scott Henion
>
> >
> > OK that's good to know I started reading about he CoExec and was hoping it might have a solution for me. My current program is showing a :size of under 60000
> >
> > Board:0x2A01 -58Mhz, BL4S200, 512K_512K SRAM, 1M serial program flash
> > xxxx/59392
> >
> > on the loading to flash popup.
> >
> > I don't think I'm having a size issue. I think that under the covers, the functions cof_serEread and cof_serFread boil down to a single generic function and are stepping on each other rather than run in separate memory space.
> >
> > "STack use is one thing, costates mess with stacks and make assumptions
> > on variable sizes. You might try making the buffers in min() static."
> >
> > I don't know what you are talking about here. I don't know what "min()" is. Could you explain a bit more/show an example?
> >
> It meant to say main()
> > "These type of problems are why I ported CoExec to DC" Now this seems like the correct solution do you have an example of this? The dynamic C User's manual describes uC/OS-II is that the same thing?
> >
> > "like serial ports _only_ will time out after the first character and not
> > return 0 if no data"
> >
> > yeah, this one boggles the mind, although I've bypassed this issue with the costates of talker_x and listener_x. HOWEVER, I was not expecting that an infinite wait on serial E would suspend the read on serial F. That isn't right, I must be doing something wrong.
> >
> >
> >
> Did not realize you were using a 4k board. Coexec does not support the
> 4k chips.
>
rats. dead end for me on the Coexec.
Someone just told me about ser_xrdUsed() anybody know if that is the solution (and the solution to the infinite wait on no characters in the receive buffer?)
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: cof_serXread, costates, and serial E and F interfering with each other. - Jon L - Nov 10 13:41:36 2009
--- In r...@yahoogroups.com, "Jon L"
>
> --- In r...@yahoogroups.com, Scott Henion
> >
> > >
> > > OK that's good to know I started reading about he CoExec and was hoping it might have a solution for me. My current program is showing a :size of under 60000
> > >
> > > Board:0x2A01 -58Mhz, BL4S200, 512K_512K SRAM, 1M serial program flash
> > > xxxx/59392
> > >
> > > on the loading to flash popup.
> > >
> > > I don't think I'm having a size issue. I think that under the covers, the functions cof_serEread and cof_serFread boil down to a single generic function and are stepping on each other rather than run in separate memory space.
> > >
> > > "STack use is one thing, costates mess with stacks and make assumptions
> > > on variable sizes. You might try making the buffers in min() static."
> > >
> > > I don't know what you are talking about here. I don't know what "min()" is. Could you explain a bit more/show an example?
> > >
> >
> >
> > It meant to say main()
> >
> >
> > > "These type of problems are why I ported CoExec to DC" Now this seems like the correct solution do you have an example of this? The dynamic C User's manual describes uC/OS-II is that the same thing?
> > >
> > > "like serial ports _only_ will time out after the first character and not
> > > return 0 if no data"
> > >
> > > yeah, this one boggles the mind, although I've bypassed this issue with the costates of talker_x and listener_x. HOWEVER, I was not expecting that an infinite wait on serial E would suspend the read on serial F. That isn't right, I must be doing something wrong.
> > >
> > >
> > >
> > Did not realize you were using a 4k board. Coexec does not support the
> > 4k chips.
> >
> rats. dead end for me on the Coexec.
>
> Someone just told me about ser_xrdUsed() anybody know if that is the solution (and the solution to the infinite wait on no characters in the receive buffer?)
>
Ok, the serXrdUsed() was an ~~OK~~ workaround, as I no longer waited indefinitely, but while one serial port was reading the other was still suspended.
I spoke to Rabbit support about this and there is definitely an issue with their library about it. The were very helpful and have supplied me with an updated RS232.LIB that resolves the issue.
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )