[BUG] from Microsoft :: How to transmit 0 value?

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using mega8 at 4MHz.

void TransmitCharToRS232 (unsigned char c) 
{
	while(!(UCSRA & (1 << UDRE)));
	UDR = c;
}

I am calling it like:

TransmitCharToRS232(0);
TransmitCharToRS232(0);
TransmitCharToRS232('i');

A theoretical query is,
How mega8 will understand that it has got a new value to transmit as there are two 0s to transmit?

The process get locked at first transmission of 0.
and ignores all further transmissions.

If I stuff value other than 0, it works well!!!

Last Edited: Tue. Sep 29, 2009 - 06:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

here is my mega128 transmit code
// USART1 Transmitter buffer
#define TX_BUFFER_SIZE1 16
char tx_buffer1[TX_BUFFER_SIZE1];

#if TX_BUFFER_SIZE1<256
unsigned char tx_wr_index1,tx_rd_index1,tx_counter1;
#else
unsigned int tx_wr_index1,tx_rd_index1,tx_counter1;
#endif

// USART1 Transmitter interrupt service routine
interrupt [USART1_TXC] void usart1_tx_isr(void)
{
if (tx_counter1)
{
--tx_counter1;
UDR1=tx_buffer1[tx_rd_index1];
if (++tx_rd_index1 == TX_BUFFER_SIZE1) tx_rd_index1=0;
};
}

// Write a character to the USART1 Transmitter buffer
#pragma used+
void putchar1(char c)
{
while (tx_counter1 == TX_BUFFER_SIZE1);
#asm("cli")
if (tx_counter1 || ((UCSR1A & DATA_REGISTER_EMPTY)==0))
{
tx_buffer1[tx_wr_index1]=c;
if (++tx_wr_index1 == TX_BUFFER_SIZE1) tx_wr_index1=0;
++tx_counter1;
}
else
UDR1=c;
#asm("sei")
}
#pragma used-

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If I stuff value other than 0, it works well!!!

How do you know it isn't working with a 0? Remember that most terminal programs on a PC treat a received 0x00 as "NUL" and won't show any sign of activity. Some terminal programs (Brays?) have a mode where they'll show received bytes in hex and this includes 0x00

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
A theoretical query is,
How mega8 will understand that it has got a new value to transmit as there are two 0s to transmit?

Value 0 has no special meaning among bytes to be transmitted with usart.
If you put UDR = 0 ten times, then 10 zeroes will be transmitted.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Visovian wrote:
If you put UDR = 0 ten times, then 10 zeroes will be transmitted.
No, ten nulls will be sent. ASCII "0" is decimal 48, hex 0x30.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Serial ports are 'Asynchronous'... they resync on every start bit.... when you store 0 in the UDR, the UART sends a start bit, then 8 bits of 0, then a stop bit. The receiver sees the zero voltage level right in the middle of each of the 8 bit times if the baud rates are right.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps a good time to monitor the TX line? Scope, logic probe or cheapo rs232 monitor with LEDs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try:

TransmitCharToRS232('0');

If you are trying to send the character "0".

It all starts with a mental vision.

Last Edited: Mon. Sep 14, 2009 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If actually sending a byte with value zero, then be sure that the receiver is actually receiving with the correct speed. If the receiver is using a higher speed than the transmitter then transmitting a zero might be received and detected as a BREAK condition.

Quote:

Try:

TransmitCharToRS232('0');


We need to dstinguish between sending "raw binary coded integer data" in which the value zero is actually 0 (or 00000000 binary), and sending a numerical digit encoded as a character in which eg the character '0' is coded as decimal 48 (or binary 00110000).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, all good inputs here!!!

I am using VB program with MSComm to receive at 19200 baud and is working well with all values except 0x00h transmission.

Conclusion from all replies is, 'check the terminal program'. I will do it.

keep posting your experiences as this simple problem takes time to resolve.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have found VB serial communications to be quirky at best. Try Bray's using the hex representation to convince yourself the nulls are coming OK, then tackle VB's strange way of handling things. I seem to remember something about needing byte arrays inside of variants, but it's been a while since I did any of that.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stu_san wrote:
Visovian wrote:
If you put UDR = 0 ten times, then 10 zeroes will be transmitted.
No, ten nulls will be sent. ASCII "0" is decimal 48, hex 0x30.

Stu

Who said anything about ASCII '0'? If you write UDR = 0, you will transmit zero. It is the receiver ho decides how to intrepid that zero.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AgwanII wrote:
stu_san wrote:
Visovian wrote:
If you put UDR = 0 ten times, then 10 zeroes will be transmitted.
No, ten nulls will be sent. ASCII "0" is decimal 48, hex 0x30.

Stu

Who said anything about ASCII '0'? If you write UDR = 0, you will transmit zero. It is the receiver ho decides how to intrepid that zero.

An Alice In Wonderland excerpt:

Quote:
Then there is the passage in which the White Knight proposes to comfort Alice by singing her a song:

"Is it very long?" Alice asked, for she had heard a good deal of poetry that day.

"It's long," said the Knight, "but it's very, very beautiful. Everybody that hears me sing it--either it brings the tears into their eyes, or else--"

"Or else what?" said Alice, for the Knight had made a sudden pause.

"Or else it doesn't, you know. The name of the song is called 'Haddock's Eyes'."

"Oh, that's the name of the song, is it?" Alice said, trying to feel interested.

"No, you don't understand," the Knight said, looking a little vexed. "That's what the name is called. The name really is 'The Aged Aged Man'."

"Then I ought to have said 'That's what the song is called?'" Alice corrected herself.

"No, you oughtn't: that's quite another thing! The song is called 'Ways and Means': but that's only what it's called, you know!"

"Well, what is the song, then?" said Alice, who was by this time completely bewildered.

"I was coming to that," the Knight said. "The song really is 'A-sitting on a Gate': and the tune's my own invention."

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you transmit '0' is not 0x00,usart can recive it ok

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally Its confirmed by microsoft that this is a bug in MSComm

refer this article

BUG: All Characters Following CHR(0) are Ignored with MSComm
http://support.microsoft.com/kb/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Finally Its confirmed by microsoft that this is a bug in MSComm

refer this article

BUG: All Characters Following CHR(0) are Ignored with MSComm
http://support.microsoft.com/kb/...

Not.

If that were true, none of my production AVR apps that upload and receive chunks of binary data with a PC wouldn't work with my VB6 apps. As 0x00 isn't an uncommon byte in parameter/data info, it works just fine when the MSComm is configured properly to accept binary data.

Note the date in your link, and especially the Applies To:

Quote:
APPLIES TO

* Microsoft Visual FoxPro 5.0 Standard Edition
* Microsoft Visual FoxPro 5.0a

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem is not that the comm's library doesn't receive the bytes. The problem is that any application that assumes ASCII, will stop processing at the first NUL. When working with NUL's as valid data, you cannot use a NUL terminated structure for containing the data.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In VB6 using the serial control in TEXT mode, you cannot receive a NUL or any other special character reliably. You have to use it in BINARY mode. Unfortunately MS botched the control and its documentation, like they do so often, so it's not easy to get it working. I have however got it to work reliably, I will post some example code later on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bray's term in hex mode will show NULLs

VB6 will send and receive 8 bit binary if you use the DLL properly. It's not obvious how to do so. I've done it extensively.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok so I couldn't remember the details earlier. Essentially sending data through the control is the same in binary mode, give it a string. When you receive data however, it comes back in a variant array, that you must cast to a DIMed byte array.

' SOMEWHERE IN INIT
With MSComm1
	.InputMode	=	comInputModeBinary
	.Nulldiscard	=	False
End With


' SIMPLE BINARY RECEIVE
Private Sub MSComm1_OnComm()
	Dim InputBuffer() As Byte
	Dim i As Long
	
	Select Case MSComm1.CommEvent
	Case comEvReceive
		ReDim InputBuffer(MSComm1.InBufferCount)
		InputBuffer = MSComm1.Input
	End Select
End Sub

Note that in this case, InputBuffer is volatile, it will get reset on each Receive event. So if you need to buffer up larger chunks, you will need to create a secondary buffer and append the data to it for processing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It's not obvious how to do so.

I don't disagree (having fussed with thresholds and buffer sizes from time to time). However, I started with the VBTERM sample app that is part of VB6 Pro and all of my VB comms code is an offshoot of that. The app as provided plus the discussions in the reference material plus a mention here and there in VB reference books made using MSComm straightforward at least. I know that MSComm is much maligned; in other circles it might rank with Hyperterm and the AVR A/D. ;) But all three pretty much do the job.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
When you receive data however, it comes back in a variant array, that you must cast to a DIMed byte array.

That's the real version of what I was trying to remember (being too lazy to look it up):
Quote:
I seem to remember something about needing byte arrays inside of variants, but it's been a while since I did any of that.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And the MSComm has no Vista support.
I have to say bye bye MSComm... :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well if you're writing for Vista you should really ditch VB6 and get .NET... It's not much harder (even much simpler in some cases) and you get the benefits of a real object-oriented language.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A devoted VB6er for years, expert in MSCOMM - I am.
.NET I've tried several times. VB.net is so like C++ or C# that I wonder why bother with it? Just use C-whatever.

But for me, I don't want to waste so many brain cells on the bloated overhead of C#. That's why I liked VB6. I could just get on with it, and not spend 90% of my time on how to use the tools and MFCs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

VB.net is so like C++ or C#

:shock: C# and C++ are only superficially similar.

C# and VB.Net are very similar, though.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UNiXWHoRe wrote:
Well if you're writing for Vista you should really ditch VB6 and get .NET... It's not much harder (even much simpler in some cases) and you get the benefits of a real object-oriented language.

What about the dotNet runtime that will be must for WinXP and there are many reluctant to install it including me.

My passion for MS products is drying down.
There are some nice IDEs around to make apps for windows.

And I know there are still windows98 users around!!!
Using .Net will eliminate them.