Microcontroller selection

I'm just wondering if anyone is aware of any > 100MHz 16 bit or 32
processors that are available in QFP packages? I need lots of GPIO as
well as SPI and UART ports. I've looked at a couple but it seems to
jump from 50-60 MHz general use processors from the likes Atmel and
Freescale to >200MHz processors on par with PDA types of duties which
are way beyond what I really need (and tend to be in BGA packages). It
will basically bring in lots of sensor data as well as do some PWM
functions. Any suggestions? I may just end up having to use 2 or 3 of
the 50MHz processors instead. Most of the operations will be buffering
up data as well bit shifting and simple logical functions like Masking,
ORing, and ANDing

Thanks!

>>I need lots of GPIO as well as SPI and UART ports.

you can use a FPGA with a Microblaze core; 

Walter;

On 2 May 2006 16:50:37 -0700, fenriswolfnews@hotmail.com wrote in
comp.arch.embedded:

> I'm just wondering if anyone is aware of any > 100MHz 16 bit or 32
> processors that are available in QFP packages? I need lots of GPIO as
> well as SPI and UART ports. I've looked at a couple but it seems to
> jump from 50-60 MHz general use processors from the likes Atmel and
> Freescale to >200MHz processors on par with PDA types of duties which
> are way beyond what I really need (and tend to be in BGA packages). It
> will basically bring in lots of sensor data as well as do some PWM
> functions. Any suggestions? I may just end up having to use 2 or 3 of
> the 50MHz processors instead. Most of the operations will be buffering
> up data as well bit shifting and simple logical functions like Masking,
> ORing, and ANDing
> 
> Thanks!

Take a look at the TMS320C28xx family of DSPs from TI.  32 bit
hardware fixed point and 16 and 32 bit integer.  The original, larger
members of the family (2810, 2811, 2812) run up to 150 MHz.  The
newer, smaller members (280x) run up to 100 MHz.

They all have SPI, UART(s), multiple PWMs, and CAN controllers on
board.  Very C friendly architecture.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

fenriswolfnews@hotmail.com wrote:
> I'm just wondering if anyone is aware of any > 100MHz 16 bit or 32
> processors that are available in QFP packages? I need lots of GPIO as
> well as SPI and UART ports. I've looked at a couple but it seems to
> jump from 50-60 MHz general use processors from the likes Atmel and
> Freescale to >200MHz processors on par with PDA types of duties which
> are way beyond what I really need (and tend to be in BGA packages). It
> will basically bring in lots of sensor data as well as do some PWM
> functions. Any suggestions? I may just end up having to use 2 or 3 of
> the 50MHz processors instead. Most of the operations will be buffering
> up data as well bit shifting and simple logical functions like Masking,
> ORing, and ANDing

  How wide are the OR/AND operations - that does not sound like
it mandates a 32 bit system ?

  Single Chip Parts thin-out above 100MHz, due to flash speed issues.
  So, you may find multiple parts is a perfectly vaild solution, 
especially if you have to merge a LOT of IO lines.
  If raw speed matters, look at devices like the BlackFin from ADi,
they have 300-500Mhz region devices, RAM based. and in TQFP.

-jg

On Tue, 02 May 2006 16:50:37 -0700, fenriswolfnews wrote:

> I'm just wondering if anyone is aware of any > 100MHz 16 bit or 32
> processors that are available in QFP packages? I need lots of GPIO as
> well as SPI and UART ports. I've looked at a couple but it seems to
> jump from 50-60 MHz general use processors from the likes Atmel and
> Freescale to >200MHz processors on par with PDA types of duties which
> are way beyond what I really need (and tend to be in BGA packages). It
> will basically bring in lots of sensor data as well as do some PWM
> functions. Any suggestions? I may just end up having to use 2 or 3 of
> the 50MHz processors instead. Most of the operations will be buffering
> up data as well bit shifting and simple logical functions like Masking,
> ORing, and ANDing

How about the Renesas SH7080 family?  100+ MIPS (YMMV) at 80 MHz, UARTs,
GPIO, PWMs, A/Ds. No SPI, but it does have a synchronous serial comm unit
which they have an app note for using as an SPI.


    ~Dave~

fenriswolfnews@hotmail.com wrote:
> I'm just wondering if anyone is aware of any > 100MHz 16 bit or 32
> processors that are available in QFP packages? I need lots of GPIO as
> well as SPI and UART ports. I've looked at a couple but it seems to
> jump from 50-60 MHz general use processors from the likes Atmel and
> Freescale to >200MHz processors on par with PDA types of duties which
> are way beyond what I really need (and tend to be in BGA packages).

Try this one, ST's first ARM9+FLASH ?
http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=266197

fenriswolfnews@hotmail.com wrote:
> I'm just wondering if anyone is aware of any > 100MHz 16 bit or 32
> processors that are available in QFP packages? I need lots of GPIO as
> well as SPI and UART ports. I've looked at a couple but it seems to
> jump from 50-60 MHz general use processors from the likes Atmel and
> Freescale to >200MHz processors on par with PDA types of duties which
> are way beyond what I really need (and tend to be in BGA packages). It
> will basically bring in lots of sensor data as well as do some PWM
> functions. Any suggestions? I may just end up having to use 2 or 3 of
> the 50MHz processors instead. Most of the operations will be buffering
> up data as well bit shifting and simple logical functions like
> Masking, ORing, and ANDing
>

AT91RM9200 is running 180 Mhz.

> Thanks!

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

Thanks for all the good suggestions. I'll look into them today. One
person asked why I wanted 32 or 16 bit processors. I'd even use an 8
bit one, however, I simply didn't find one with the numerous I/O and
features that I need. The reduced code size is always a plus for 8
bits, but a lot of architectures negate this extra with having tons of
flash, so it didn't really bother. I am currently using an 8 bit atmel,
but the new design requires a lot more I/O and speed than that little
guy can muster. Thanks to everyone, you guys are excellent.

I also forgot to mention they won't let me use an fpga here,
unfortunately. It was my first thought as well; I've used xilinx a lot
in the past.

<fenriswolfnews@hotmail.com> wrote in message 
news:1146670672.085760.252690@e56g2000cwe.googlegroups.com...
> Thanks for all the good suggestions. I'll look into them today. One
> person asked why I wanted 32 or 16 bit processors. I'd even use an 8
> bit one, however, I simply didn't find one with the numerous I/O and
> features that I need. The reduced code size is always a plus for 8
> bits, but a lot of architectures negate this extra with having tons of
> flash, so it didn't really bother. I am currently using an 8 bit atmel,
> but the new design requires a lot more I/O and speed than that little
> guy can muster. Thanks to everyone, you guys are excellent.

In such situations, I use an I/O expansion bus. You'd need:
  - one 8-bit port that you can use bidirectionally, for data
  - a read/write control line (if you need to use an external bus 
transceiver, else ignore)
  - either:
    - as many strobes as you need, or
    - as many address bits as you need to decode externally, and a single 
strobe

This has the advantage that (given enough address lines or strobes) it can 
be expanded further later.

Alternatively, if you have I2C or SPI (both of which are easy enough to 
bitbang), and you can sacrifice some speed, you could use these as GPIO 
extenders.

Alternatively again, if you have an external CPU bus (I'm guessing you 
don't), you could memory-map the I/O.

Steve
http://www.fivetrees.com