> was the exact character sequence we transmit from our message.c > On the cover page of the fax I sent you, >This would ensure that I solve your problems. >This would be the "raw log file" that your application generated. >escape codes, that we could have, I would be much obliged. >If you had a screen dump, that used the status bar >"Can you help us write an acceptance test?" >The question I should have asked you is, After pestering a few of our support people,
#Buy tinyterm upgrade#
(after he sent me a free license upgrade while working on the problem :-) Here was my last communication with Michael Wing on the matter: I have checked every version of SecureCRT since then, including the However, the Wyse60 bottom message line problem was never resolved.
#Buy tinyterm software#
On another matter, I had a lot of communication with VanDyke Software in 2003 re: a Wyse60 cursor display problem that was eventually resolved. Here is the text of my last email sent November 9, 2006: I raised this issue but received no acknowledgment. This still appears to be the case in the new SecureCRT 6.ĭuring the SecureCRT 6 Beta period, I received an email requesting feedback. A persistent problem has been that the Wyse60 bottom message line (25th line) was not supported. Also, the user can poke the buttons any old time, so I can't think of a way to get the input synchronized with something else going on.My company has been using SecureCRT, and recommending it to our clients, since Windows XP was first shipped. I don't want to block the program from cycling too long, or it will seem unresponsive to the user. I've got standard inputs to burn, so I will see how serin works. You are right about it not being reliable. The user will only try to change this word now and then, so it seems like a blocking input with a fairly small timeout might be better. So lets start with short version first.Ĭlick to expand.Thanks for the suggestion, but I still get the right answer only about 1/10 tries. I just found the other code insertion thing, so here is the whole works, I hope this works.It didn't.
If you want to see all the code, it is about 100 lines. I think I need some continuing education.
#Buy tinyterm serial#
I wish there was a better explanation on how the inputs for serial ports work.
#Buy tinyterm update#
So, My next tack will be delaying the Nex update so there is at least a cycle between inputs. The time to get a new reading from the altimeter is about 1/2 second, so updates from the Nex can come at anytime in the cycle. I could receive the flag just fine if I didn't try to read both the flag and the barometer at the same time. To try to sort this out, I wrote a short program to receive data from the Nex and then printed it out on the terminal.
'hserin b26 'this is where I try to get the flag Note: only need one bit, may use more bits later for some other options Hserin b10 'first byte of new kolls (w5) Kolls is the local barometer x 100, typical is 2992 If I hard code the flag, it all works fine, but I cannot get a flag send back to the Picaxe from the Nex. I use a flag set to 0 for relative readings, and 1 for absolute. Then I got the bright idea that for some kinds of uses, it would be handy to zero the reading and go by relative changes instead of absolute. I used hserin because I could not get regular serin to work at all. I use serout to send the altitude to the Nex and and hserin to read two bytes that represent the barometer reading. My first implementation used the Nex to display results and set the local barometric pressure. I have used the program from rq3, on this forum, as the beginning point. I am working on an altimeter project using an 18M2, an MP元115 altimeter board from Sparkfun, and a 240x320 enhanced display from Nextion.
0 kommentar(er)
