[mc1322x] problems with the UART
Ian Martin
martini at alum.mit.edu
Tue Jan 5 14:14:37 EST 2010
Jon,
I remember seeing this code and feeling some degree of heartburn over
the direct comparison with zero and 31, without masking out the higher
order bits. I presume the datasheet lists the other 27 bits as
reserved, but it might be worth a try ANDing the UT1CON value with
0x1F just in case one of these other bits goes high under certain
conditions (documented or not).
-Ian
On Mon, Jan 4, 2010 at 11:39 PM, Jim Paris <jim at jtan.com> wrote:
> Jon Smirl wrote:
>> Why won't this loop work without messing up the printout?
>> It gets 32 chars right and then messes up. 32 chars is the size of the FIFO.
>>
>> for (i = 0; i < 10; i++) {
>> for (j = 'A'; j <= 'z'; j++) {
>> reg32(UART1_DATA) = j;
>> if (reg32(UT1CON) == 0) { // stop when FIFO is full
>> while (reg32(UT1CON) != 31) { // wait for it to empty
>> }
>> }
>> }
>> reg32(UART1_DATA) = '\n';
>> }
>
> Your numbers "0" and "31" seem strange. The MC1322xRM says that
> 0=full, 32=empty and even mentions "if this value goes negative.." so
> there may be other values present. What it does say is "data can be
> written to the transmit buffer while this number is non-zero", which
> suggests:
>
> for (i = 0; i < 10; i++) {
> for (j = 'A'; j <= 'z'; j++) {
> while (reg32(UT1CON) == 0)
> continue;
> reg32(UART1_DATA) = j;
> }
> while (reg32(UT1CON) == 0)
> continue;
> reg32(UART1_DATA) = '\n';
> }
>
> btw. your original code can write two characters ('\n', 'A') with no
> checks of UT1CON in between. It's also not clear that UT1CON will
> necessarily show an updated value in the cycle immediately following a
> write. Best to follow their prescribed method...
>
> -jim
>
>
> _______________________________________________
> mc1322x mailing list
> mc1322x at devl.org
> http://devl.org/cgi-bin/mailman/listinfo/mc1322x
>
More information about the mc1322x
mailing list