From pll22@drexel.edu Mon Apr 29 16:23:00 2002 Date: Thu, 25 Apr 2002 02:32:13 -0400 From: Phil Leithead To: Paul Oh Subject: Re: Week 04 grades on-line [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] Dr. Oh, Sorry, I've missed Wednesday by about 2 1/2 hours, but let me give you a quick update on what I've accomplished. The VB version of rxData is now functional (or mostly, I"ll explain below). The issue is that under Windows (whether your using VB or C++) you do not have direct access to the COM port interrupt routines. Instead, you set up events that are triggered by the interrupt as well as some other parameters. I had basically tried to directly adapt our routine from Turbo C to VB, but because this routine was being triggered by an event rather than an interrupt I had to experiment and make some adaptations to get things working correctly. In short, in Turbo C under a non-multitasking environment, I was able to count on being able to service the interrupt immediately. In contrast, in Windows the event has to propagate through the event queue and by the time I am able to service this event I have to do some additional things to make sure that I am properly handling the receive buffer. There are two issues that I am seeing with our data transmission. The first is that under Windows I can get a buffer overrun and lose data. I have to provoke this error by stressing the system (i.e. grabbing the window and dragging it around real fast or anything else that might hog the processor). I am going to experiment with turning on hardware flow control to alleviate this issue. The second issue is the synchronization of data based on our protocol. Under both DOS and Windows, when sending data continuously from the SBC at the full speed of the link I am seeing errors because of byte alignment. So I think we probably have to rethink our protocol a little bit and see if we can come up with something to modify it and make it a little bit more robust. When we demo it to you Thursday I can show you better what is happening and see if you have any thoughts. I asked Igor and Lil on Monday if they could possibly spend some time looking at this, but I haven't heard from either of them so I don't think that we'll have a solution to this by our meeting. Phil ----- Original Message ----- From: "Paul Oh" To: "Phil Leithead" Sent: Wednesday, April 24, 2002 2:08 AM Subject: Re: Week 04 grades on-line > > Phil, we're both up late :-) > > > I just wanted to inform you that I might have some trouble demoing the VB > > version of rxData to you at this Thursdays meeting. I am having an issue > > where it seems as though the app is not able to keep up with the data coming > > into the receive buffer and the buffer overflows. > > I suspect you're talking about the data transfer under Windows. The baud > rate should be managable under Windows. It sounds like you (or Bharat) > did not handle the buffer properly i.e. allocate enough memory and flush > the buffer and monitor interrupts. I know how this is done in Unix and C, > but not in Windows and VB. > > Also, email Bharat and Rares (bunty@drexel.edu, ris22@drexel.edu) - they > have my book Serial Port Complete (from lvr.com Jan Axelson). Perhaps a > quick read will get you up to speed. > > Perhaps a more fruitful approach is we acquire software (e.g. ActiveX or > DLL). The candidate software should give you enough examples for you to > build upon. http://www.lvr.com/serport.htm is a good resource for serial > ports. If you find software that will help you with your deliverablces, > I'll purchase it. http://www.GreenleafSoftware.com/ looks like a > potential... > > Lastly, perhaps give http://www.taltech.com/ a phone call. I'm curious > what this person is doing. He appears to have an office in Philadelphia. > A phone call may reveal some suggestions e.g. software to purchase etc. > > Please bring me up to date by Wed. > -paul > > > > Once I am able to > > reliably receive the data, putting it into a graph in the GUI shouldn't be > > too difficult and I already have a working sample of the graph that just > > displays dummy data. I am going to investigate this issue a little bit > > further, and if I am not able to resolve it I will be forced to port my work > > to C++ and MFC, which will not be a simple task. Serial port programming > > under VC is completely different from both DOS and VB, so I will essentially > > be starting from scratch for the serial communications. > > > > Phil > > > > ----- Original Message ----- > > From: "Paul Oh" > > To: "Paul Oh" > > Sent: Monday, April 22, 2002 11:53 AM > > Subject: Week 04 grades on-line > > > > > > > Your work folder can be found on > > > http://www.pages.drexel.edu/~pyo22/students.html. The weekly grading > > > helps you to assess your progress and anticipate your final grade. > > > > > > Note: Your weekly "Demo" is to be treated like homework! This means: > > > > > > 1. It is DUE by meeting time. DUE means you show or run it for me. > > > You don't use the meeting time to debug or ask for help. > > > > > > 2. Grading will be scaled into the follow. If the demo: > > > * Works completely = Full grade > > > * Works partially and successfully demoable by extension time = 75% of > > > full grade > > > * Doesn't work but effort's been put it = %60 of full grade > > > * Little to no effort = 50% > > > * Not done OR student absent from meeting = 0% > > > > > > 3. Like homework, you can always submit EARLY. > > > 4. Like homework, LATEness incurs penalties > > > 5. Like homework, EXTENSIONS can be requested. This will be > > > judged by case-by-case basis, including grading penalties. > > > Extension must be requested 48 hours before deadline > > > 6. Like homework, if you have questions or problems, request > > > a meeting BEFORE the deadline. I will not meet on Thursdays however. > > > > > > Adhering to the above buttresses the weekly schedule. This ultimately > > > ensures accountability to your team, you deliver on-time and receive the > > > grade you deserve. > > > > > > -paul > > > > > > > > > > > > > > > > > > >