The perfect part except ...

Greetings.

I have a small embedded application to develop that needs 1) a UART, 2)
SPI (or other interface for flash-based card memory, SD preferred), 3)
A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.

The Microchip PICs 18F2550 or 4550 would appear to be a great fit
(performance, memory and cost too) except ...

They put the UART receive data input (RX) and the SPI data
output (SDO) on the same pin.  Arrrgh!

Workaround possibilities I have thought of / am considering:

1) Multiplex the pin (requires external hardware, may be impossible to
multiplex, given data flow / timing / performance requirements (or at
least a real PITA)).

2) Make a software UART out of a generic I/O port instead of using the
on-chip hardware (i.e. "bit-bang.")

3) Make a software SD card interface out of generic I/O ports instead of
using the on-chip hardware (perhaps using the 4-bit SD card bus to make
up for an undoubtedly slower clock?).

4) Push one or the other functions off to external hardware entirely.

5) Find another micro that can do the job. (I haven't found this
particular on-chip I/O combination anywhere else yet, though.  No hints
on Microchip discussion boards either.)

All (except the last, of course) offend my sense of engineering
elegance.  I would love to hear other opinions and suggestions.

-- 
Silvar Beitel, known to small children and USENET as Silver Beetle.
To respond by email: change "minus" to "plus" in address

Silver Beetle wrote:

> I have a small embedded application to develop that needs 1) a UART, 2)
> SPI (or other interface for flash-based card memory, SD preferred), 3)
> A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.

Sounds like a USB-connected media player or voice recorder. There are
ASICs for this.

> 2) Make a software UART out of a generic I/O port instead of using the
> on-chip hardware (i.e. "bit-bang.")

I'd go this route.

> 3) Make a software SD card interface out of generic I/O ports instead of
> using the on-chip hardware (perhaps using the 4-bit SD card bus to make
> up for an undoubtedly slower clock?).

Consider how many bytes you're going to be pushing through the media
interface vs. the number you're going to push through the UART.
Consider that the UART will probably be running at <120kHz vs - the
SD/MMC interface will be (hopefully) running much faster.

"Silver Beetle" <silverbeetle@net1minus.com> wrote in message
news:43C2BF7A.3040605@net1minus.com...
> Greetings.
>
> I have a small embedded application to develop that needs 1) a UART, 2)
> SPI (or other interface for flash-based card memory, SD preferred), 3)
> A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.
>

SiLabs C8051F320 with 8- or 16 -bit PWM as DAC, maybe?

- Dejan

larwe wrote:
> Silver Beetle wrote:
>
> > I have a small embedded application to develop that needs 1) a UART, 2)
> > SPI (or other interface for flash-based card memory, SD preferred), 3)
> > A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.
>
> Sounds like a USB-connected media player or voice recorder. There are
> ASICs for this.
>
> > 2) Make a software UART out of a generic I/O port instead of using the
> > on-chip hardware (i.e. "bit-bang.")
>
> I'd go this route.
>
> > 3) Make a software SD card interface out of generic I/O ports instead of
> > using the on-chip hardware (perhaps using the 4-bit SD card bus to make
> > up for an undoubtedly slower clock?).
>
> Consider how many bytes you're going to be pushing through the media
> interface vs. the number you're going to push through the UART.
> Consider that the UART will probably be running at <120kHz vs - the
> SD/MMC interface will be (hopefully) running much faster.

Lewin's right about the speed tradeoff, but doing a uart in software is
a lot harder than doing a SPI interface in software.

I'd think about using the hardware uart and do the SPI interface by bit
banging. That way you can get something up and running in pretty short
order. My back of the envelope estimate is the SPI code would run at
about 1/16th the speed of the hardware interface. If it turns out to be
too slow you can look at a the tradeoffs of using a different chip, or
maybe split the functionality between 2 chips.

Mark

On 2006-01-09, mhahn@hvc.rr.com <mhahn@hvc.rr.com> wrote:

>> Consider how many bytes you're going to be pushing through the
>> media interface vs. the number you're going to push through
>> the UART. Consider that the UART will probably be running at
>> <120kHz vs - the SD/MMC interface will be (hopefully) running
>> much faster.
>
> Lewin's right about the speed tradeoff, but doing a uart in software is
> a lot harder than doing a SPI interface in software.

Yup.  SPI in software is dead simple.  There are no timing
constraints the way there are with a bit-banged UART.  Unless
you're shoving a lot of data through the SPI link, I'd start
out doing things the easy way and do SPI in SW and use the HW
UART.

-- 
Grant Edwards                   grante             Yow!  One FISHWICH coming
                                  at               up!!
                               visi.com            

mhahn@hvc.rr.com wrote:
>
> Lewin's right about the speed tradeoff, but doing a uart in software is
> a lot harder than doing a SPI interface in software.

"Harder" in the sense of "more difficult" or in the sense of "occupying
more resources on the uC"?

Yes, it's "harder" to write an asynchronous soft-UART than it is to
implement synchronous serial protocols. However, if one can't get it
working inside one, perhaps two days at most, then someone else should
be writing the code :)

Considering the data volumes, the uC is going to spend a lot more time
executing SPI code vs. soft-async-UART code.

Silver Beetle wrote:
> Greetings.
> 
> I have a small embedded application to develop that needs 1) a UART, 2)
> SPI (or other interface for flash-based card memory, SD preferred), 3)
> A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.
> 
> The Microchip PICs 18F2550 or 4550 would appear to be a great fit
> (performance, memory and cost too) except ...
> 
> They put the UART receive data input (RX) and the SPI data
> output (SDO) on the same pin.  Arrrgh!

Shame.... rather silly mistake ?!

USB Port is the most restrictive, choices of low end Generic USB uC are

SiLabs C8051F320
( larger ones have been real-soon-now for a while...)

STm's new uPSD3400 series, have more memory, more IO

Then there are also low end ARMs, - Philips, Atmel... etc

-jg

Jim Granville wrote:

> Silver Beetle wrote:
> 
>> Greetings.
>>
>> I have a small embedded application to develop that needs 1) a UART, 2)
>> SPI (or other interface for flash-based card memory, SD preferred), 3)
>> A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.
>>
>> The Microchip PICs 18F2550 or 4550 would appear to be a great fit
>> (performance, memory and cost too) except ...

> Then there are also low end ARMs, - Philips, Atmel... etc

Checked on availability of the LPC214x
The LPC2141 looks better resourced (DAC, 2 x SPI, 2 x UART), than the 
PIC, _and_ is cheaper/in stock at Digikey  - plus it has many larger 
brothers, so you (almost) never need worry about ROM/RAM ceilings .

These 32 bit devices also tend to have 'better' SPI ports, with proper
FIFOs etc, so can sustain much higher streaming rates.

-jg

Silver Beetle wrote:
> Greetings.
>
> I have a small embedded application to develop that needs 1) a UART,
> 2) SPI (or other interface for flash-based card memory, SD
> preferred), 3) A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.
>


Look at the AT89C51SND1/2/3 chips.
Alternatively you can check out the AT91SAM7S series.
Will run SPI at 25 Mbps using DMA support.
The AT91SAM7A3 has a real SD-Card controller onchip (MCI)
which will run in 4 bitmode.

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

I wrote:

> I have a small embedded application to develop that needs 1) a UART, 2)
> SPI (or other interface for flash-based card memory, SD preferred), 3)
> A/D, 4) D/A (PWM OK), and 5) a USB 2.0 port.
> 
> The Microchip PICs 18F2550 or 4550 would appear to be a great fit
> (performance, memory and cost too) except ...
> 
> They put the UART receive data input (RX) and the SPI data
> output (SDO) on the same pin.  Arrrgh!
> 
> Workaround possibilities

Thanks to all who responded to this.

I was rather hoping someone would say, "Look, stupid, all's ya gotta do 
is thus-and-so and you can easily get around the problem."  In fact, I 
still hope someone does.  However, your responses at least make me feel 
like I'm not missing something trivially simple.

Meanwhile, I will look into doing a software SPI (or 4-bit SD port) and 
evaluate the other processors mentioned.  I also haven't given up on the 
idea of actually multiplexing the pin and functions (UART and SPI), 
given that there are likely known gaps (both in time and in data of 
interest to the application) in the UART data stream on input where I 
might be able to slip in SPI transfers and I, of course, control UART 
transmits.

Thanks again.

-- 
Silvar Beitel, known to small children and USENET as Silver Beetle.
To respond by email: change "minus" to "plus" in address