single pin bi-directional serial IO
Ok, I've been reading posts and downloading objects for about 12 hours now and am more confused than when I started.· I'm trying to communicate with a RC-4 relay board from EFX-Tek.· I can send messages to the board and the relays turn on fine.· So I know that I'm on the right pin, and that the format of my strings is correct.· There are 3 pins going to this board, power, ground and signal.· Every example I find shows serial communication over 2 pins ( rx and tx ).· But that would make it to easy.· When I send the commands to get the status of the board, or the firmware version, etc, all I get back is an echo of the command I sent.· Now just for grins, I decided to try this with another serial device I have ( one of Parallax's GPS units ).· I think I have the same problem there, but since it only responds to commands, I can't tell if anything is getting through to it.· Can someone give me an example ( spin only if possible my assembly is rusty ) of bi-directional communication on a single line.· Also, can it be done using the fullduplexserial object??· It's probably something simple and basic I'm doing wrong, but it's just not clicking.
Thanks
Thanks
Comments
something like
t:=cnt
repeat until ( ina(port)==1) or ((cnt-t) / (clkfreq /1000)) > ms ' where ms is the milisecond timeout on the wait
if ina(port)
'read it
Thanks
Keep in mind that anything you transmit from the prop Tx pin will also be received on the Rx pin as well as possibly being echoed by whatever is at the other end.
This object is based on FullDuplexSerial but allows you to have 4 serial ports so I am sure you could use FDS if you only need one port.
Thanks again
There's no queuing for cogs. Either one is available in which case it's started or none are available in which case the COGNEW fails and returns -1 for the cog number used.
In Spin, there's no way to generate a pointer to code, so it's impossible to have queues of routines to be executed. It's possible to cheat if you know the internal structure of the Spin interpretive code and the various control tables used, but I wouldn't recommend doing that except as a demonstration of concept. It's quite possible to have an overlay manager written in assembly.
The way this sort of thing is done is by starting up a cog that continually looks in a queue for actions to be performed. When it finds one, it does the requested operation, then goes to wait again. Essentially it's a sort of high level interpreter. Things like the floating point package work this way.
PUB rxtime(ms) - like the fullduplexserial version, calls rxcheck until it returns something or the timeout expands ( copied directly from fullduplexserial )
PUB rxcheck checks ina. if it's 1 then it calls the rx function
PUB rx is unchanged , it uses waitpeg but since we already know it's set, we don't have an issue with blocking.
It works great with the RC4. But then I got ambitious and tried it with my parallax GPS in smart mode. It seems to work great when I'm only expecting 1 byte back, but if I'm expecting more than one byte back, the subsequent bytes are not right ( unless we suddenly have more than 60 minutes in an hour ). I've played with type casting to byte since the variables are defined as local variables in a function, the are longs, but either I did that wrong, or that's not the problem. I'll clean up the code some tomorrow and post it unless you have a duuuh you stupid kid do this answer off the top of your head before then.
Thanks
Regarding your multibyte input attempts ... It must be something you've added or changed because Simple_Serial works well for what it does. When you have a chance to post your changes and your test program, we can take a look at what you've done and see if we can find what's not working. Please use the Attachment Manager to post your source file (use the Post Reply button to access that).
· Here ya go.· I've beaten my head against this for to long now.· I'm affraid I can't see the forest for the trees any more.· At one point I was using rxtime·( my code ) but just to eliminate that, I commented out the·"time" part·so I'm·just using the basic rx command from simple_serial.· In order to make simple serial a little more compatiable with fullduplexserial, I added a start function that calls init but leaves out the mode which init doesn't care about.· I also·added a stop which calls·finalize.···It may just be chance, but the first byte ( hour ) that gets returned seems to be correct.· But the minutes ( 164 ) and Seconds ( 254 ) aren't·valid.· At this point I need another set of eyes.
Thanks
I think what's going on is that the calls to debug are taking just enough time for the next "rx" call to miss the leading edge of the start bit and mess up the timing. The rx routine waits for the midpoint of the stop bit before exiting which leaves only 1/2 bit time before the next start bit begins. I would try moving your debug statements to after the last rx call or leaving them out for now. Alternatively, you could drop the Baud for the GPS module to 2400 Baud.
I'm guessing that was the problem since at one time, my rxcheck basically looked the same as yours except with the else instead of setting rxByte to -1 as an initial value and falling through. But, with serial IO, the timing is so critical that the delay for the else could cause problems I guess. Is it really that close on the timing? I would think the else would essentially be another if as far as timing goes and you have another if in the command. Wouldn't the timings between the two wash then???
Now I just need to get the rxtime working right <lol>
At 4800 Baud, 1/2 bit time is around 100us. A couple of calls for debug I/O can take that long.