Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

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 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 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

  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted