Serial Ports question
[1/7] from: gschwarz::netconnect::com::au at: 27-Sep-2006 10:16
Has anyone got a good list a of the functions with serial ports?
I need to put the TX line high for one second to wake up data logger.
Below is part of the list of options, is the awake option used for this?
timeout: none
local-ip: none
local-service: none
remote-service: none
last-remote-service: none
direction: none
key: none
strength: none
algorithm: none
block-chaining: none
init-vector: none
padding: none
async-modes: none
remote-ip: none
local-port: none
remote-port: none
backlog: none
device: port2
speed: 9600
data-bits: 8
parity: none
stop-bits: 1
rts-cts: false
user-data: none
awake: none
Regards,
Greg
[2/7] from: ryan::practicalproductivity::com at: 27-Sep-2006 10:07
I dont think so, but I really dont know what the awake setting does.
Classically though, you set the dtr line to do something like that so I
wouldnt expect it in the protocol handler. As I recall, the TX is high
(+ voltage) once the serial port is activated, which btw is logic level
0 on serial ports. So, I would expect to just open the port and wait 1..
--Ryan
Greg Schwarz wrote:
>Has anyone got a good list a of the functions with serial ports?
>I need to put the TX line high for one second to wake up data logger.
<<quoted lines omitted: 26>>
>Regards,
>Greg
--
Practical Productivity Solutions
www.practicalproductivity.com
Tele: 707-274-8226
Cell: 707-245-8226
[3/7] from: gschwarz::netconnect::com::au at: 29-Sep-2006 15:05
Ryan,
Thank you for your input.
The PC com ports are in idle mode (low readly to send a start bit), opening
and closing the port does not change this level.
I can set the com port high (like a very long start bit) if I write it in C
and call it from rebol.
I have noticed the cpu use goes very high when I use call.
Has anyone else seen this?
Regards,
Greg
[4/7] from: ryan::practicalproductivity::com at: 29-Sep-2006 11:37
Hmmm, let me guess, 3 wire serial. My best shot is to try to send zeros
at the lowest possible baud rate until it eventually decides to wake
up. As you probably know, the OS breaks up your transmition, so I
wouldnt put high hopes on reliability. It all comes down to the
particulars of the design, the only way to if or how well its going to
work is to test it, or maybe analyze the schematic.
Given the ports idle state is negative (I assume your right), requiring
it high for 1 second is a bad design. It simply wasn't meant to be used
that way.
--Ryan
Greg Schwarz wrote:
>Ryan,
>Thank you for your input.
<<quoted lines omitted: 67>>
>>
>>
--
Practical Productivity Solutions
www.practicalproductivity.com
Tele: 707-274-8226
Cell: 707-245-8226
[5/7] from: moliad::aei::ca at: 29-Sep-2006 22:43
hi Greg,
There is a bug in CALL... I just logged ii on RAMBO (Public REBOL bug
database)
if you do not have the console open (doing print " ") , then it seems to
get lost after the CALL is done. and it never finishes. it just hangs
and consumes full CPU for as long as its not killed (in my experience).
someone else has logged a similar bug and says that opening the event
handler by calling view might also prevent CALL from getting lost as it
does.
-MAx
Greg Schwarz wrote:
[6/7] from: gschwarz:netconnect:au at: 3-Oct-2006 10:16
Thank you Max for the info.
I tried two DOS programs and both caused call to get lost. :-(
The serial port question can be fixed by call if it did not get losted.
Regards,
Greg
[7/7] from: gschwarz::netconnect::com::au at: 3-Oct-2006 10:23
Ryan,
It is 3 wire serial comms.
Old software used this 1 second wake state because the logger cpu goes into
sleep state for one second after being active for 40mSec. This is to save
battery life (30 days life without recharging).
Replacing old software with new can bring up some non standard ways of doing
things.
Thank you for your thoughts.
Greg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted