Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

VB serial comm... toooooo slow

Status
Not open for further replies.

Ascari

New Member
Hi. How are you? I made an interface with VB to interact with a 16F877A via serial port.

I used MSComm and the uC works at 4 MHz.

What I have is the next:

1 pot connected to 1 ADC channel. 0 - 5 V.
The uC makes the Analog to Digital conversion.
uC sends the result of the conversion to PC on RS232 format.
PC receives the data and shows it on the screen.

The problem is that PC is working very, very slow....

I can turn the pot from 0 [v] to 1 [v] (for example) and 30 seconds after, you see the transition on the PC from 0 to 1 [v].

What can be the problem?

For MSComm I used:
Settings >> 9600,n,8,1
Handshaking >> 0

Buffers:
InBuffSize >> 1
OutBuffSize >> 0
RThreshold >> 0
SThreshold >> 0
InputLen >> 1

I changed RThreshold to 1 but nothing changed.

Hardware:
Unmarked all

I hope you can help me.

Thank you.

Ascari
 
It sounds like you are assuming that this delay is due to the PC software, because you don't mention anything about the PIC program. How often is it sending data? and have you verified how often it sends data, using hyperterminal or some other terminal? None of the settings you have listed for the PC side configuration would have any effect on how often the PIC sends data; if it is communicating at all, then the settings are okay. If you try it with hyperterminal first, you can rule out whether it's your PC software causing the problem. If your PIC is only sending data every 30 seconds or so, it sounds like a problem with your code, because the PIC is fast enough to do that hundreds of times per second.
 
Hi. I'll try the hyperterminal but I can tell you... I have a button to connect or disconnect from serial port.

I have a Pset... to make the graphic of the voltage from the Pot.

In the moment I connect serial port and the my device (uC, Pot, serial, etc..) is off, nothing happens in the graphic.

In the moment I start my device, the graphic starts showing the voltage from the pot ( let's say 3 volts.) then, as soon as my hand moves from switch to pot, I change the position (to 1.5 v. maybe) and that change occurs 30 seconds later.

I mean, the uC is sending information all the time. If I turn off my device, the graphics keeps drawing until (I think) the buffer is empty.
 
that sounds odd because you said you set your input buffer size to only 1, so having the thing keep drawing from a buffer for a while after the device is off doesn't make much sense.

In any case, I would still recommend you try hyperterminal and make sure your PIC is sending the updated data immediately, then you will know if it's your PC program causing the delay. If that is the case, you might have better luck asking your question on a forum dedicated to programming and/or visual basic specifically, it's not really an electronics or microcontroller problem if the PIC is sending the data like it's supposed to but the PC software isn't working correctly.
 
Ok... I tried the hyper terminal... Because the therminal is text.. I see characters...

Well, all the time I change the pot, the characters change... As soon as I move the pot, I can see different characters.

That means that the uC is sending data everytime right...?

What do you think?

thanks...

ascari
 
if the data coming into hyperterminal is getting updated immediately when you turn the pot, then I would say that the problem must be with your VB software.
 
just a guess but how many bytes does your read ask for? try making it 1. of you are reading a line which looks for an end of line character before it returns or fills up the buffer.
 
I think I found the problem, I will not write it because it's not solved. But I need help on this:

There are two ways to know that there is something in the buffer; inBufferCount, the one I used making polling(I guess) becuase I put it inside a Timer and I have: if (MSComm1.InBufferCount>0)....

Do you know another way?? Not polling....

If you do, please help me and I'll write if it worked...

Thank you,
Ascari
 
It Worked

Yes!!!! Yes!! Yeeeeeeeeeeeeeeeeeeessssssss!!

:D ;) :p :mad: :eek: :eek: :confused:


IT WORKED !!!! Thank you PENOY BALUT. That was it.... YES!!!

THANK YOU ONCE AGAIN....... YUPI!!!! me voy a echar un TEQUILA !!!

I'll drink a TEQUILA...

In the next topic I'll explain it.
 
I put the code to see what is in the buffer (MSComm1.Input) inside a Timer.

The fastest Timer is reloaded every 1 milisecond. The uC sends information every 1 us. so you can see where is the delay. When the Timer says: 'Ok... it's time to see what we have in the buffer, he has a lot of information. Correct me if wrong, but I think it has 1000 bytes waiting.

If I pass the control to :
penoy_balut said:
try MSComm1_OnComm event
Then when something is in the buffer, it puts the Timer to True and shows the data on screen.

That's the solution. I hope I made myself clear because right now I'm very excited... YUJU!"!!!!!

Thanks to all and I hope this helps to somebody else.

ASCARI
 
Ascari said:
The fastest Timer is reloaded every 1 milisecond. The uC sends information every 1 us. so you can see where is the delay. When the Timer says: 'Ok... it's time to see what we have in the buffer, he has a lot of information. Correct me if wrong, but I think it has 1000 bytes waiting.

Well, if your PIC is running at 4MHz, then each instruction takes 1us, so there's no way you're sending one packet every 1us. In addition, 9600 baud is a max of 960 packets per second, which is a little over 1ms per packet. And, (unless you changed it) you said in an earlier post that your buffer size was only 1, so I don't think there could be a ton of packets waiting each time. However, I do agree that WHATEVER the problem was, using the OnComm event is a much better way to look for incoming packets than repeatedly polling, and I'm glad you got it figured out.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top