So, does that mean that numbers are always "invisible" to the hyperterminal by default?Quote:
Originally Posted by matsp
Printable View
So, does that mean that numbers are always "invisible" to the hyperterminal by default?Quote:
Originally Posted by matsp
Not at all, but you're sending ASCII code 2 and 8, which are (End of Text) and (Backspace) respectively. For two and eight you need to send ASCII codes 50 and 56 or 0x32 and 0x38 in hex.Quote:
Originally Posted by reemaambekar
QuantumPete
I don't have to send ASCII 0x02 and 0x08. 0x02 and 0x08 are just the data which i need to send.Quote:
Originally Posted by QuantumPete
Yes, and unless you have a better way to "see" what you are doing, such characters will be INVISIBLE - even of 0x02 is visible (it possibly is - on a PC it's a smiley face, I think), 0x08 will be a backspace and go back so that the NEXT character written writes over the 0x02.Quote:
Originally Posted by reemaambekar
At this point, you may want to find a program that can log from a serial port to a file or some such, so that you can see what is ACTUALLY going on. I've written applications to do this more than once - including one that logged the traffic between a ISDN modem and it's controlling computer in both directions at once when browsing a web-site. Unfortunately, it was written for OSE, which is an embedded OS, so it's probably not much use to anyone here (should I find the source code somewhere).
--
Mats
Hello again !!!Quote:
Originally Posted by matsp
Just to check that my function is running fine, I am now using the hyperterminal and ASC0 port.
My code is as follows:
When I run the code, it only displays 'WP' and doesn't consider 'N'.Code:void ASC0_send()
{
int i,data = 0;
unsigned char sd[] = {'W','N,'P'};
for(i=0;i<3;i++)
{
data = sd[i];
ASC0_vSendData (data);
}
}
Am I missing something here?
Is your ASC0_vSendData() not waiting if the port is busy, perhaps? Otherwise I don't know.
--
Mats
Quote:
Originally Posted by matsp
This is the actual full ASC0_VsendData function. Does it make more sense now?Code://****************************************************************************
// @Function void ASC0_vSendData(uword uwData)
//
//----------------------------------------------------------------------------
// @Description This function writes a send data initialization word into
// the transmit buffer register.
//
// Note:
// In a multiprocessor system the master with this function
// has the possibility to send data to the selected slave. To
// achieve this, the 9th bit must set on zero.
//
//----------------------------------------------------------------------------
// @Returnvalue None
//
//----------------------------------------------------------------------------
// @Parameters uwData:
// Data to be send
//
//----------------------------------------------------------------------------
// @Date 26/11/2008
//
//****************************************************************************
// USER CODE BEGIN (SendData,1)
void ASC0_send()
{
int i,data = 0;
unsigned char sd[] = {'W','O','P'};
for(i=0;i<3;i++)
{
data = sd[i];
ASC0_vSendData (data);
}
}
// USER CODE END
void ASC0_vSendData(uword uwData)
{
ASC0_TBIC_IR = 1; // reset transmit buffer interrupt request
ASC0_TBUF = uwData; // load transmit buffer register
} // End of function ASC0_vSendData
Looks like you need some sort of "wait for completion" before you send the next data item. Since I have no idea what OS you are using, etc, I can't really comment on how you should go about doing that.
I expect this would mean that you get an interrupt at some point later, when the transmit is "ready" to send the next char.Code:ASC0_TBIC_IR = 1; // reset transmit buffer interrupt request
--
Mats
I managed to display 'WNP' entirely on the hyperterminal. The problem was with the predefined ASC0_vSendData function. New function is as follows:Quote:
Originally Posted by matsp
This code prints 'WNP' properly now.Code:void ASC0_vSendData(uword uwData)
{
ASC0_TBIC_IR = 0; // reset transmit buffer interrupt request reset=0; set=1
ASC0_TBUF = uwData; // load transmit buffer register
while (ASC0_TBIC_IR == 0); //wait till transmission finish
} // End of function ASC0_vSendData
Thanks for your help.
That is a possible solution, but I would ask someone who knows more about the OS/runtime environment, because there may be a better way to "wait for an interrupt" than to poll the bit for the interrupt control.
--
Mats
But, will the way I am doing it, affect my code/hardware in any way?Quote:
Originally Posted by matsp
If you have a RTOS that supports multiple tasks/processes/threads, then you waiting like that will eat time off other tasks(etc) that may want to run. If the processor has power-management it may want to "go to sleep" if there's no activity going on, so again, your solution will affect the power-consumption in that case.Quote:
Originally Posted by reemaambekar
--
Mats
I would agree, that waiting till the transmit queue is ready to accept more data is a bit overkill. Halting the OS a bit to wait is much more efficient, but a bit slower. Coming up with an optimum wait in ms's will require some testing.
This might be a stupid remark but why would you want to learn c programming when you can learn C++..... Isn't C++ better then C ? I'm really not sure so don't attack me :)
Well, in this case, the target system is a single-board micro-computer, so it is not necessarily a good target for the heavy tools of C++. And the code being discussed here would be marginally different either way - or do you know something that I do not know in the particular project?Quote:
Originally Posted by Sshakey6791
--
Mats