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
>
>
>
--- 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.