Question:When the Read_str subroutine encounters CR is that CR generated by user input or by the program where it would be stored at the second last byte in the string?
Answer: CR is generated by the user.
Question: wouldn't you only call Read_str once to initialize the interrupts and then if anything is put into the terminal a interrupt would happen echoing the character and loading it into the string?
Answer: No, you can call Read_str at anytime, so as an example, you may call after 1 min, at which time 40 characters have been received, so during this time, your sci_isr in addition to app_recv should keep storing the incoming bytes in a location in memory (e.g. in a buffer or queue)
Question: is it the main application requesting the string generated by read_str?
Answer: The main program requests the string by calling subroutine Read_str, and Read_str essentially reads from the received bytes till it hits the end of the received bytes, or it hits CR, or it hits the limit 253 bytes.
Question: do we need to save the string to memory or just transmit it?
Answer: Read_str's main purpose is to write the received bytes into IX (that is pointing to an array);
so as an example, if you do the following:
ldx #recvstr
jsr read_str
;; read_str should have at this point filled the recvstr memory with the previously received bytes
;; where recvstr is define like:
recvstr ds !255
So in short, read_str reads from received bytes that have been previously stored (perhaps in a buffer or queue) as they are received using sci_isr & app_recv subroutines.
Now, in addition to the above this question also asks for the bytes to be echoed as they are received (perhaps in the app_recv subroutine[?]), and this can be done by calling write_str with two bytes string, where the first byte is the character to send and the second byte is NUL, does that make sense? So one could write an additional subroutine called write_ch that essentially takes one byte and creates a nul-terminated string and pass it to write_str, which will echo it to screen.
Answer: CR is generated by the user.
Question: wouldn't you only call Read_str once to initialize the interrupts and then if anything is put into the terminal a interrupt would happen echoing the character and loading it into the string?
Answer: No, you can call Read_str at anytime, so as an example, you may call after 1 min, at which time 40 characters have been received, so during this time, your sci_isr in addition to app_recv should keep storing the incoming bytes in a location in memory (e.g. in a buffer or queue)
Question: is it the main application requesting the string generated by read_str?
Answer: The main program requests the string by calling subroutine Read_str, and Read_str essentially reads from the received bytes till it hits the end of the received bytes, or it hits CR, or it hits the limit 253 bytes.
Question: do we need to save the string to memory or just transmit it?
Answer: Read_str's main purpose is to write the received bytes into IX (that is pointing to an array);
so as an example, if you do the following:
ldx #recvstr
jsr read_str
;; read_str should have at this point filled the recvstr memory with the previously received bytes
;; where recvstr is define like:
recvstr ds !255
So in short, read_str reads from received bytes that have been previously stored (perhaps in a buffer or queue) as they are received using sci_isr & app_recv subroutines.
Now, in addition to the above this question also asks for the bytes to be echoed as they are received (perhaps in the app_recv subroutine[?]), and this can be done by calling write_str with two bytes string, where the first byte is the character to send and the second byte is NUL, does that make sense? So one could write an additional subroutine called write_ch that essentially takes one byte and creates a nul-terminated string and pass it to write_str, which will echo it to screen.
No comments:
Post a Comment