1. Home
  2. Embedded Programming
  3. The perfect part except ...

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
Reply to
Silver Beetle
Loading thread data ...

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

I'd go this route.

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

Reply to
larwe

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

- Dejan

Reply to
Dejan

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

Reply to
mhahn

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
Reply to
Grant Edwards

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

Reply to
larwe

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

Reply to
Jim Granville

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

Reply to
Jim Granville

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
Reply to
Ulf Samuelsson

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
Reply to
Silver Beetle

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.