• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 1214 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Pointer to Structure with pointer.

Gustavo Adolpho Souteras Barbosa

I'm having a problem with a pointer to struct. I'm working with the PC16552 UART, (it has 2 UARTs), and I created a struct for each UART like this:

typedef struct _uart
{
 uchar xdata *ucBuffer;
 uchar xdata *ucLineCt;
 uchar xdata *ucLineSt;
} uart;
Each uart is conected to a different external interrupt, and when that interrupt is generated, it calls a function getByte that have a pointer to a uart struct as parameter:
void int0(void) interrupt 0
{
 ...
 getByte(&Serial1);
 ...
}

void int1(void) interrupt 1
{
 ...
 getByte(&Serial2);
 ...
}

void getByte(uart *actualSerial) reentrant
{
 unsigned char ucByte;

 ucByte = *actualSerial->ucBuffer;
 ...
}
It works fine, but sometimes, I receive a wrong character. I was thinking that could be hardware, but I decided to make a dump of the block, and the dump solved the problem. I'm asking help, because I don't know what is it, if it's hardware or firmware... The problem occurs when I receive a 0xFF from the serial 2... Sometimes, it turns in 0xF7 or 0xF3. In the dump, I simply do this:
 if(actualSerial == &Serial2)
 {
  if(i < 20)
  Dump[i++] = ucByte;
 }

Parents
  • 0 in reply to Gustavo Adolpho Souteras Barbosa

    Sorry, but that "substition" is far from clear. The only actual change visible, compared to the original source fragment, is that ucByte is now "uchar" instead of "unsigned char", and that you now have new variables --- but those might as well have been silently omitted in the original posted fragment. And uchar is just an alias for unsigned char you defined for your own use, I'm sure.

    So, what did you actually change?

    An error pattern that is affected by the choice of data bytes, as you described it, points rather strongly at the hardware as the culprit. Software hardly ever cares about the actual bits it moves around.

Reply
  • 0 in reply to Gustavo Adolpho Souteras Barbosa

    Sorry, but that "substition" is far from clear. The only actual change visible, compared to the original source fragment, is that ucByte is now "uchar" instead of "unsigned char", and that you now have new variables --- but those might as well have been silently omitted in the original posted fragment. And uchar is just an alias for unsigned char you defined for your own use, I'm sure.

    So, what did you actually change?

    An error pattern that is affected by the choice of data bytes, as you described it, points rather strongly at the hardware as the culprit. Software hardly ever cares about the actual bits it moves around.

Children
No data