I am writing a terminal emulator in tcl/tk which communicates via a serial link with a microcontroller development board. it is unusual because of the microcontroller monitor programme comtrolling the other end of the serial link. When the terminal sends a character, the monitor expects the terminal to *wait* until the monitor has echoed the character before sending another. The monitor may also send streams of data to the terminal. The logic of this is not hard to deal with but it would be simplest if I had an event triggered whenever a character is received. A simple flag set by sending a char would allow the event handler to differentiate between and echoed character and one in a stream. The problem is I don't know how to set up the event. Read does not do what I want AFAICS.
Ian Bell wrote: > ... > The logic of this is not hard to deal with but it would be simplest if I > had an event triggered whenever a character is received. ...
Ian Bell wrote: > I am writing a terminal emulator in tcl/tk which communicates via a serial > link with a microcontroller development board. it is unusual because of > the microcontroller monitor programme comtrolling the other end of the > serial link. When the terminal sends a character, the monitor expects the > terminal to *wait* until the monitor has echoed the character before > sending another. The monitor may also send streams of data to the terminal. > The logic of this is not hard to deal with but it would be simplest if I > had an event triggered whenever a character is received. A simple flag set > by sending a char would allow the event handler to differentiate between > and echoed character and one in a stream. The problem is I don't know how > to set up the event. Read does not do what I want AFAICS. > Any help appreciated.
This is not very unusual at all. Basically, you've defined the microcontroller as the master in the network protocol, most likely because it's resources are limited, and you use the echo feature to prevent overloading it with interrupts, but the computer is presumed to be able to handle receipt and buffering of streaming data, right?
Here's a loose description of how it could be done, sprinkled with example code from one of my serial device comms programs, and some more mocked up:
proc closecomm {} { global cid fileevent $cid readable {} close $cid
}
proc rxchar {} {
global cid wait_echo echo_char set c [read $cid 1] #binary scan $c H* hval
if {$wait_echo} { if {$echo_char!=$c} { # handle echo error } } else { # do something, like appending the streaming data # into another global, and evaluate the contents of # that buffer, e.g. for message completeness, checksum, # etc. }
if {[eof $cid]} { # handle a suddenly-closed com port }
}
proc txchar {c} { global cid wait_echo echo_char if {[catch {puts -nonewline $cid $c} res]} { # couldn't write to serial # handle the error here, perhaps by: # catch {closecomm}; opencomm } set echo_char $c set wait_echo 1
>> I am writing a terminal emulator in tcl/tk which communicates via a >> serial >> link with a microcontroller development board. it is unusual because of >> the microcontroller monitor programme comtrolling the other end of the >> serial link. When the terminal sends a character, the monitor expects the >> terminal to *wait* until the monitor has echoed the character before >> sending another. The monitor may also send streams of data to the >> terminal. The logic of this is not hard to deal with but it would be >> simplest if I >> had an event triggered whenever a character is received. A simple flag >> set by sending a char would allow the event handler to differentiate >> between >> and echoed character and one in a stream. The problem is I don't know >> how >> to set up the event. Read does not do what I want AFAICS.
>> Any help appreciated.
> This is not very unusual at all. Basically, you've defined the > microcontroller as the master in the network protocol, most likely > because it's resources are limited, and you use the echo feature to > prevent overloading it with interrupts, but the computer is presumed to > be able to handle receipt and buffering of streaming data, right?
Pretty much spot on. The monitor prog is given by the manufacturer of the microcontroller development board so in that sense We are forced to consider it as master.
> Here's a loose description of how it could be done, sprinkled with > example code from one of my serial device comms programs, and some more > mocked up:
Just a quick note of thanks to all who helped me with my rather specialised terminal application for use with an 8051 single board computer. It is up an running now thanks to help from the members of this group. If anyone is interested you can find a link to the code on this page:
|
