Reply by "Felipe de Andrade Neves L." January 8, 20112011-01-08
Also, do not forget to enable the RX buffer, (you should enable the TX too),
the RX Buffer can store 16 (or 14, dont remember) bytes. It is very useful
to give the main program extra time to do its stuff if required.

2011/1/8 rtstofer

> --- In l... , "flashzr"
> wrote:
> >
> > > On Fri, Jan 7, 2011 at 2:28 PM, flashzr wrote:
> >
> > > Q: Can I disable the modem control signals in UART1
> > > that I don't really need?
> >
> > --- In l... , David Smead
> wrote:
> >
> > > Don't enable the modem control signals.
> >
> > How do I enable/disable those?
> > From table 111 you can see how to disable hardware flow control. Software
> flow control only works if you write the code. Don't write it!
>
> You are under no obligation to even set the pin modes for flow control. You
> can simply configure them for GPIO - table 59.
>
> Richard
>
>
>

An Engineer's Guide to the LPC2100 Series

Reply by rtstofer January 8, 20112011-01-08
--- In l..., "flashzr" wrote:
>
> > On Fri, Jan 7, 2011 at 2:28 PM, flashzr wrote:
>
> > Q: Can I disable the modem control signals in UART1
> > that I don't really need?
>
> --- In l..., David Smead wrote:
>
> > Don't enable the modem control signals.
>
> How do I enable/disable those?
>

From table 111 you can see how to disable hardware flow control. Software flow control only works if you write the code. Don't write it!

You are under no obligation to even set the pin modes for flow control. You can simply configure them for GPIO - table 59.

Richard

Reply by flashzr January 8, 20112011-01-08
> On Fri, Jan 7, 2011 at 2:28 PM, flashzr wrote:

> Q: Can I disable the modem control signals in UART1
> that I don't really need?

--- In l..., David Smead wrote:

> Don't enable the modem control signals.

How do I enable/disable those?

Reply by Donald H January 8, 20112011-01-08
--- In l..., "flashzr" wrote:
>
> --- In l..., "zoran.mijanovic" wrote:
> >
> > UART0 can be used for both: as programming port and to communicate with another CPU.

If your programming one of the two CPUs, then the other one must not do anything to hinder the programming process.

So put the other CPU into RESET.

If its in RESET, all the IO pins are tri-stated and can not bother the programming process.

hamilton

>
> And how do I prevent another CPU from listening and responding
> to ISP commands issued to LPC?
>
> Also, TXD from another CPU and TXD from ISP programmer will be in
> short circuit, if I don't add some complexity (a jumper, at least),
> which I'd rather not.
> > You can also use UART1. If you need not modem signals RTS, DRT, etc, just don't use them. Read carefully LPC user manual and set USART1 registers appropriately.
>
> Simple as that? Should I assign them as regular I/O pins?
>
> Using UART1 as simple UART would be best, as this guy wants:
> http://embeddedrelated.com/groups/lpc2000/show/3285.php
> just that I wish to use RXD and TXD only.
>

Reply by David Smead January 8, 20112011-01-08
Don't enable the modem control signals.

DaveS

On Fri, Jan 7, 2011 at 2:28 PM, flashzr wrote:

> Hi, I'm new here and new to LPC2101.
>
> I'm reading the PDFs and creating the PCB at the same time,
> and I need some pointers.
>
> I know that:
> The chip is programmed through UART0.
> UART0 has RX/TX only, while UART1 has full modem control lines.
>
> My problem is that the LPC will also have to use
> the UART to communicate with another CPU.
>
> The simplest thing would be to use UART1 for that purpose,
> but UART1 uses RTS, CTS, and such.
>
> Q: Can I disable the modem control signals in UART1
> that I don't really need? I need only RX and TX to communicate
> with that other CPU.
>
> Or should I connect both ISP hardware and other CPU to UART0?
>
> Or.. what?
>
>
>
Reply by Timo January 8, 20112011-01-08
On 01/08/2011 10:12 PM, flashzr wrote:
> Timo wrote:
>> When you start, you'll notice that UARTs typically doesn't use
>> handshake signals for anything. You can read and write them from
>> your program and that's pretty much all.
>
> Thats great news, then I'll just use UART1 for CPU comm. Wondering
> why did they include it then?

Include what? The handshake signals? Users' manual says in UART
features: "Register locations conform to 550 industry standard". They
try to keep it compatible in some sense with 16550 which itself is
reminiscence of 8250 from IBM/PC era.

--

Timo
Reply by flashzr January 8, 20112011-01-08
--- In l..., Timo wrote:
> You might use some kind of protocol between the CPUs so that the
> other CPU doesn't respond to ISP commands.

Can't do that. The other CPU (AT91SAM9260) may be in BootROM
and expecting commands through UART.
> So you have not yet done any programming on bare metal for UARTs.

Not with handshake signals.

> When you start, you'll notice that UARTs typically doesn't use
> handshake signals for anything. You can read and write them from
> your program and that's pretty much all.

Thats great news, then I'll just use UART1 for CPU comm.
Wondering why did they include it then?

Reply by flashzr January 8, 20112011-01-08
--- In l..., "rtstofer" wrote:
> Or just use UART1 for inter-processor comms.

Yes, thats what I would like to do. Much easier.

Just don't know if its doable with RX & TX only, w/o CTS, RTS, DTR...

Not sure if I could just connect
RTS to CTS
DTR to DSR to DCD
that is how I saw on a standard PC serial port.

I'm creating my own board, so I'll give it a try.

Reply by Timo January 8, 20112011-01-08
On 01/08/2011 08:28 PM, flashzr wrote:
> And how do I prevent another CPU from listening and responding to ISP
> commands issued to LPC?
>
> Also, TXD from another CPU and TXD from ISP programmer will be in
> short circuit, if I don't add some complexity (a jumper, at least),
> which I'd rather not.

Because you haven't thought disconnecting the cable as an option, I'll
assume that the two CPUs are on the same board and communicate in TTL
levels. Then I'd add a couple of ideas after Richard's:

You could put a resistor into the TXD signal of the other CPU so that
when you connect ISP, it wins.

You might use some kind of protocol between the CPUs so that the other
CPU doesn't respond to ISP commands.

>> You can also use UART1. If you need not modem signals RTS, DRT,
>> etc, just don't use them. Read carefully LPC user manual and set
>> USART1 registers appropriately.
>
> Simple as that? Should I assign them as regular I/O pins?

So you have not yet done any programming on bare metal for UARTs. When
you start, you'll notice that UARTs typically doesn't use handshake
signals for anything. You can read and write them from your program and
that's pretty much all.

--

Timo
Reply by rtstofer January 8, 20112011-01-08
--- In l..., "flashzr" wrote:
>
> --- In l..., "zoran.mijanovic" wrote:
> >
> > UART0 can be used for both: as programming port and to communicate with another CPU.
>
> And how do I prevent another CPU from listening and responding
> to ISP commands issued to LPC?
>
> Also, TXD from another CPU and TXD from ISP programmer will be in
> short circuit, if I don't add some complexity (a jumper, at least),
> which I'd rather not.
>
Well, you can't... I have the same problem when I use lpc21isp to program a device while I still have minicom (Linux comm program) connected to the port.

Clearly ISP will be done using a level shifter such that the signals are actually at RS232 levels. You may decide that inter-processor communications do not require level shifting. So there is the first problem; voltage levels.

On most development boards, the serial port is level shifted and brought out to a DB9 connector. No problem; plug in the cable for ISP while programming and then plug in another cable for something else.

I would install a 2 wide by 3 deep header and use a jumper plug to select whether the serial pins connect to the level shifter for ISP or to some other scheme for inter-processor comms. Or, a DPDT toggle switch.

Another choice: give up on ISP and just use JTAG for programming. This might involve giving up some pins.

Yet another: consider doing all your serial communications by way of RS485 level translation. This protocol was always intended to be multi-master. You can buy an RS232 to RS485 converter. This is just a guess, I haven't actually tried it.

Or just use UART1 for inter-processor comms.

Richard