We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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;
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; ... }
if(actualSerial == &Serial2) { if(i < 20) Dump[i++] = ucByte; }
I'm quite sure this has nothing to do with your Subject: line. If the problem was caused by pointer manipulation, you'ld be hit every time. It wouldn't work most of the time, but fail for particular values, and then only by flipping some bits. This feels much more like a hardware problem, to me. Flaky signal lines, incorrect timing, you name it.
I've made the following substitution:
void getByte(uart *serialAtual) reentrant { uchar ucByte; uchar ucCrc; uchar ucAux; ucByte = *serialAtual->ucBuffer; ucAux = ucByte; ... }
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.
I assume the *serialAtual is used in the UART interrupt as well. In that case that is your problem. ANY handling of pointers and anything longer than a char in the body of the progtam MUST be done with interrupts disabled if such are used inside ISRs as well. Why:
;in the body ; a see below mov, r0,HIGH pointer ;b see below mov R1,LOW pointer
Well, I've found something today... I was not initializing the reentrant Stack... After initializing it it works perfectly... Well, about the problem been hardware, I discarded it. It's not a time problem, because the acess time of the UART is 84ns, and I'm using a 89C52 with a 11.0592MHz Crystal. If it was the data bus, and I'd considered it, this problem will occur frequently, with all kind of data. The substitution that I'd made was put a attribution after loading data from the UART. It worked... About the pointer, I really didn't know about it, and from now, I'll observe it. But in this project, I'm not writing to these pointers. I'll check if I'm doing something similar... Thanks a lot for the help!!! A last question... What hapens exactly if you don't initialize the reentrant Stack??