A software implemented UART doesn't work

20 views
Skip to first unread message

Gowan

unread,
Dec 13, 2010, 3:09:41 PM12/13/10
to RuggedCircuits
I'm in the process of hooking up a sd memory chip/card/slot to the
Gator board to use as a data logger.
To that end, I'm installing the " Petit FAT file system module R0.02
(C)ChaN, 2009"
and using the SPI on the ATmaga324p to communicate with the sd device.
As a tool in debugging the setup, a "Software implemented
UART module;
(C)ChaN, 2005 (http://elm-chan.org/) " is provided.

I do not receive anything on RealTerm.
When I push the reset button on the Gator, RealTerm status light for
the TXD signal comes on breifly.
Which indicates that there is some communication happening (as TXD
coincides with reset)
In the past I could have sworn that the CTS status light came on, but
I havn't been able to replicate that for awhile.
Here is some code near the beginning of main(): (<< & >> enclose code)
<<
//Modified to run on ATmega324p at 20Mhz
PORTB = (1<<PB4); // SS high
DDRB = (1<<PB7 | 1<<PB5 | 1<<PB4); // !SS,SCK and MOSI outputs

//Modified to use USART0 pins
PORTD = 0xff; // all pullup
DDRD = (1<<PD1); // PD1 output
>>

Shortly after this, it writes :
<<
xfunc_out = xmit;
xputs(PSTR("\nPFF test monitor\n"));

for (;;) {
xputc('>');
>>
So upon pushing the reset button, RealTerm should receive "\nPFF test
monitor\n" and should show a ">" prompt after a send.

I wonder if the bootloader somehow restricts communication through the
USB fitting to using the USART feature on the ATmega324p.
Thanks

Gowan

unread,
Dec 14, 2010, 12:09:17 AM12/14/10
to RuggedCircuits

Hmm, yes. That was pretty incoherent. My apologies.

I have a "software implemented UART module"
Meaning that it directly accesses the USART0 receive pin PD0
and the USART0 transmit pin PD1.

It doesn't use the USART0 capability that is built-in to the
ATmega324p. Which would involve writing to and reading from the UDR0
data registers.

Upon start-up (reset), it sends a message and then a '>'
prompt. I havn't been able to receive anything on RealTerm.

I notice that with the Gator, PC7 is used for USB hardware
handshaking.
So I bet I have to include that somehow if I'm going to "bit bang"
to PD0 and PD1.

Any insights into how I might do this would be appreciated.
Thanks

Rugged Circuits

unread,
Dec 14, 2010, 12:47:01 AM12/14/10
to RuggedCircuits
On Dec 14, 12:09 am, Gowan <peterstew...@telus.net> wrote:
> Hmm, yes. That was pretty incoherent. My apologies.
>
> I have a "software implemented UART module"
> Meaning that it  directly accesses the USART0 receive pin PD0
> and the USART0 transmit pin PD1.

How are you connecting this to the Gator? Pins PD0 and PD1 are not
brought out to connector terminals. They are used for communication
over USB and you will have trouble receiving data in this way since
the USB-to-serial converter on the Gator is going to be always driving
the PD0 input pin.

>    It doesn't use the USART0 capability that is built-in to the
> ATmega324p. Which would involve writing to and reading from the UDR0
> data registers.
>
>           Upon start-up (reset), it sends a message and then a '>'
> prompt. I havn't been able to receive anything on RealTerm.
>
> I notice that with the Gator, PC7 is used for USB hardware
> handshaking.
>   So I bet I have to include that somehow if I'm going to "bit bang"
> to PD0 and PD1.

No, that's only required if you open up the serial port on the PC to
require hardware handshaking.

>
> Any insights into how I might do this would be appreciated.

Ensure you disable the USART before going into software-serial mode.
The USART is enabled by default in the bootloader and remains so
enabled when your application starts.

> Thanks

Gowan

unread,
Dec 14, 2010, 9:36:58 AM12/14/10
to RuggedCircuits
Yes!
I set the USART0 status and controle registers (A, B and C) to their
default values and It worked!
Thankyou for the solution.

Gowan

unread,
Dec 14, 2010, 9:50:15 AM12/14/10
to RuggedCircuits
Woops, I was too quick. The gator board sends the initialization
characters but does not respond to sent characters.
Which is as you predicted would happen.

>you will have trouble receiving data in this way since
>the USB-to-serial converter on the Gator is going to be always driving
>the PD0 input pin.

Is there a way that I can monitor PD0 through the USB-to-serial
converter?

As I'm connecting to the PC and RealTerm through the USB, I don't
think that I can use another pin for input.
Thankyou in anticipation.

Rugged Circuits

unread,
Dec 14, 2010, 8:22:28 PM12/14/10
to RuggedCircuits
On Dec 14, 9:50 am, Gowan <peterstew...@telus.net> wrote:
> Woops, I was too quick. The gator board sends the initialization
> characters but does not respond to sent characters.
> Which is as you predicted would happen.
>
> >you will have trouble receiving data in this way since
> >the USB-to-serial converter on the Gator is going to be always driving
> >the PD0 input pin.
>
> Is there a way that I can monitor PD0 through the USB-to-serial
> converter?

I don't understand what you mean by "monitor PD0 through the USB-to-
serial converter".

> As I'm connecting to the PC and RealTerm through the USB, I don't
> think that I can use another pin for input.
> Thankyou in anticipation.

It sounds like you want to talk to the PC through the USB yet you
don't want to use the hardware UART??? This would seem to be the
easiest solution.

Gowan

unread,
Dec 14, 2010, 11:00:39 PM12/14/10
to RuggedCircuits
That's right. I'm trying to talk to the PC (RealTerm) through the USB.

So, it seems like it should be working.

Ryan Lush wrote " if you are trying to receive over USB through the
FTDI chip then the FTDI chip will be driving the RX pin appropriately.
Did you set up the data direction register for RXD0 correctly? "
yes, the code is:

//Modified to use USART0 pins
DDRD = (1<<PD1 | 0<<PD0); // PD1 output, PD0 input
PORTD = 0xff; // all pullup

I'll have to keep looking. Thanks a lot for the help.

Gowan

unread,
Dec 16, 2010, 8:12:41 PM12/16/10
to RuggedCircuits
Well, I think it's been working for awhile. I didn't realize it. Not
until I put some xputc()'s (send chr to PD1) here and there in the
code so that I could follow the flow.

Thanks for the help and specially to Ryan for
< if you are trying to receive over USB through the
< FTDI chip then the FTDI chip will be driving the RX pin
appropriately.
That cleared things up for me.
Reply all
Reply to author
Forward
0 new messages