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!!!
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-
If I stuff value other than 0, it works well!!!
A theoretical query is,
How mega8 will understand that it has got a new value to transmit as there are two 0s to transmit?
If you put UDR = 0 ten times, then 10 zeroes will be transmitted.
Stu
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.
Perhaps a good time to monitor the TX line? Scope, logic probe or cheapo rs232 monitor with LEDs.
Try:
TransmitCharToRS232('0');
If you are trying to send the character "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.
Try:TransmitCharToRS232('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.
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.
Visovian wrote:No, ten nulls will be sent. ASCII "0" is decimal 48, hex 0x30.If you put UDR = 0 ten times, then 10 zeroes will be transmitted.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.
stu_san wrote:Visovian wrote:No, ten nulls will be sent. ASCII "0" is decimal 48, hex 0x30.If you put UDR = 0 ten times, then 10 zeroes will be transmitted.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:
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 transmit '0' is not 0x00,usart can recive it ok
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/...
Finally Its confirmed by microsoft that this is a bug in MSCommrefer 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:
APPLIES TO* Microsoft Visual FoxPro 5.0 Standard Edition
* Microsoft Visual FoxPro 5.0a
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.
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.
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.
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.
It's not obvious how to do so.
Lee
When you receive data however, it comes back in a variant array, that you must cast to a DIMed byte array.
I seem to remember something about needing byte arrays inside of variants, but it's been a while since I did any of that.
And the MSComm has no Vista support.
I have to say bye bye MSComm... :(
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.
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.
VB.net is so like C++ or C#
C# and VB.Net are very similar, though.
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.
