MCUs other than ARMs

Ulf Samuelsson wrote:
> rickman wrote:
> > I am very familiar with the various ARM MCU offerings.  But I have a
> > need for an MCU with 3 or more SPI ports which is not so easy to find
> > in an ARM.  There are a few, but they have higher power consumptions
> > and that makes them poor choices for a battery powered app.
> >
> > I don't have hard requirements yet, but I think 128 kB of Flash will
> > do the job along with 16 kB of SRAM.  I may need an I2C port and of
> > course a number of I/O pins (yes, we still have to guess, but 30
> > should do the job).
> >
>
> The ATmega1281 might work if you can use external SRAM.
> (You can run the USART in SPI Master mode)

I looked at the document and I don't think this will do the job.  I
need three SPI slave ports.  I could likely live with the 8 kB.  I also
need an SPI master port to control an LCD, but I expect I can do that
in software without too much complaint from the SW people.

So the major requirement is 3 slave SPI ports.  The secondary
requirement is low power, with 100 mW a target (along with lower power
at lower speed or duty cycle).  The rest is negotialble.

Anyone work with a 3 SPI device?

rickman wrote:
> Ulf Samuelsson wrote:
> 
>>rickman wrote:
>>
>>>I am very familiar with the various ARM MCU offerings.  But I have a
>>>need for an MCU with 3 or more SPI ports which is not so easy to find
>>>in an ARM.  There are a few, but they have higher power consumptions
>>>and that makes them poor choices for a battery powered app.
>>>
>>>I don't have hard requirements yet, but I think 128 kB of Flash will
>>>do the job along with 16 kB of SRAM.  I may need an I2C port and of
>>>course a number of I/O pins (yes, we still have to guess, but 30
>>>should do the job).
>>>
>>
>>The ATmega1281 might work if you can use external SRAM.
>>(You can run the USART in SPI Master mode)
> 
> 
> I looked at the document and I don't think this will do the job.  I
> need three SPI slave ports.  I could likely live with the 8 kB.  I also
> need an SPI master port to control an LCD, but I expect I can do that
> in software without too much complaint from the SW people.
> 
> So the major requirement is 3 slave SPI ports.  The secondary
> requirement is low power, with 100 mW a target (along with lower power
> at lower speed or duty cycle).  The rest is negotialble.
> 
> Anyone work with a 3 SPI device?


You'll have hard time with timing - the slave port timing
is dictated by the master alone.

-- 

Tauno Voipio
tauno voipio (at) iki fi

Ulf Samuelsson wrote:
> rickman wrote:
>> I am very familiar with the various ARM MCU offerings.  But I have a
>> need for an MCU with 3 or more SPI ports which is not so easy to find
>> in an ARM.  There are a few, but they have higher power consumptions
>> and that makes them poor choices for a battery powered app.
>>

The AT91SAM7A3 has two SPIs and  I think there is a good chance
that one of the SPI slaves can be implemented on the SAM7A3 SSC block

256 kB Flash and 32 kB SRAM, so it is a little bit of overkill.

What speed do you run the SPI(s) at?


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

rickman wrote:
> Ulf Samuelsson wrote:
>>The ATmega1281 might work if you can use external SRAM.
>>(You can run the USART in SPI Master mode)
> 
> 
> I looked at the document and I don't think this will do the job.  I
> need three SPI slave ports.  I could likely live with the 8 kB.  I also
> need an SPI master port to control an LCD, but I expect I can do that
> in software without too much complaint from the SW people.
> 
> So the major requirement is 3 slave SPI ports.  The secondary
> requirement is low power, with 100 mW a target (along with lower power
> at lower speed or duty cycle).  The rest is negotialble.
> 
> Anyone work with a 3 SPI device?

It still sounds like a CPLD task to me :)

If these are Byte 4 wire SPI slaves, without fancy FIFO needs
(ie single byte transactions, SS controlled ),
then a ATF1502BE CPLD looks very likely to do the task.
That should (just) swallow a 3 Slave SPI to simple Parallel BUS
interface. ( the 1504BE would allow a little buffering )

In any solution, you will need to ensure the uC can respond
fast enough to avoid SPI overrun errors. That will depend on
the spacing between incomming bytes.

-jg

Jim Granville wrote:
> rickman wrote:
> > Ulf Samuelsson wrote:
> >>The ATmega1281 might work if you can use external SRAM.
> >>(You can run the USART in SPI Master mode)
> >
> >
> > I looked at the document and I don't think this will do the job.  I
> > need three SPI slave ports.  I could likely live with the 8 kB.  I also
> > need an SPI master port to control an LCD, but I expect I can do that
> > in software without too much complaint from the SW people.
> >
> > So the major requirement is 3 slave SPI ports.  The secondary
> > requirement is low power, with 100 mW a target (along with lower power
> > at lower speed or duty cycle).  The rest is negotialble.
> >
> > Anyone work with a 3 SPI device?
>
> It still sounds like a CPLD task to me :)
>
> If these are Byte 4 wire SPI slaves, without fancy FIFO needs
> (ie single byte transactions, SS controlled ),
> then a ATF1502BE CPLD looks very likely to do the task.
> That should (just) swallow a 3 Slave SPI to simple Parallel BUS
> interface. ( the 1504BE would allow a little buffering )
>
> In any solution, you will need to ensure the uC can respond
> fast enough to avoid SPI overrun errors. That will depend on
> the spacing between incomming bytes.

That is an interesting idea, but where do I get the parallel bus and
what if I don't have the space for a small CPLD?  I won't even go into
the crap I have to deal with to interface with the CPLD/FPGA people.

There are MCUs out there that have 3 SPI ports, so it would be
redundant to use a CPLD.  I know Motorola has some devices that should
meet the requirements.  I'll have to get in touch with the local FAE
and see if they can recommend something.  It would have been nice to
use an ARM as we just recently started moving our designs away from 8
bit MCUs to ARM devices.  But I have serious power constraints and the
ARMs with 3 SPI ports use way too much power.

> There are MCUs out there that have 3 SPI ports, so it would be
> redundant to use a CPLD.
...
>  It would have been nice to use an ARM as we just recently started
> moving our designs away from 8 bit MCUs to ARM devices.
> But I have serious power constraints and the
> ARMs with 3 SPI ports use way too much power.

AT91SAM7A3 draws too much power?

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

 > rickman wrote:
 > That is an interesting idea, but where do I get the parallel bus

Well, 3 SPI ports is 12 pins, no ?

 > and what if I don't have the space for a small CPLD?  I won't even
 > go into the crap I have to deal with to interface with the CPLD/FPGA
 > people.


Those are separate issues.
( Won't they let you design your own CPLDs ? )

 > There are MCUs out there that have 3 SPI ports, so it would be
 > redundant to use a CPLD.

.. but very few, which is why you started this thread ?

 > I know Motorola has some devices that should
 > meet the requirements.  I'll have to get in touch with the local FAE
 > and see if they can recommend something.  It would have been nice to
 > use an ARM as we just recently started moving our designs away from 8
 > bit MCUs to ARM devices.  But I have serious power constraints and the
 > ARMs with 3 SPI ports use way too much power.

So there is no silver bullet/one chip/low power solution - that's 
embedded design for you :)

CPLDs can slave SPI with very low powers, as their SPI is a true
shift register. All uC SPI slaves MUST be clocked higher (x4..x10)
than the fastest incomming SPI_CK, whilst CPLD SPI slave has
No Clock = Static Power, and on an ATF1502BE, that's ~2.4uA.


-jg

Jim Granville wrote:

> A quick google spits up one :  MC9S12DP256

and here is another one ;)

http://www.freescale.com/files/pr/mpc5510.html

5V operation, up to 3 SPI ports, and a few other
things as well....

Be interested in just how 'separate' those
two cores are.

-jg

Ulf Samuelsson wrote:
> > There are MCUs out there that have 3 SPI ports, so it would be
> > redundant to use a CPLD.
> ...
> >  It would have been nice to use an ARM as we just recently started
> > moving our designs away from 8 bit MCUs to ARM devices.
> > But I have serious power constraints and the
> > ARMs with 3 SPI ports use way too much power.
>
> AT91SAM7A3 draws too much power?

At 200 mW, yes, I think that is more power than I can afford.  Of
course we can use techniques to reduce that when the CPU is idle, but I
don't like to start with more than a 50% figure unless I *know* the CPU
loading up front.  With the CPU using 100% more than the total board
power budget, I don't think I can work with that.

How certain are you that the SSC will work in SPI slave mode.  Is there
an app note on this?  The SPI speed is very slow at 100 kbps.

rickman wrote:
> Ulf Samuelsson wrote:
>>> There are MCUs out there that have 3 SPI ports, so it would be
>>> redundant to use a CPLD.
>> ...
>>>  It would have been nice to use an ARM as we just recently started
>>> moving our designs away from 8 bit MCUs to ARM devices.
>>> But I have serious power constraints and the
>>> ARMs with 3 SPI ports use way too much power.
>>
>> AT91SAM7A3 draws too much power?
>
> At 200 mW, yes, I think that is more power than I can afford.  Of
> course we can use techniques to reduce that when the CPU is idle, but
> I don't like to start with more than a 50% figure unless I *know* the
> CPU loading up front.  With the CPU using 100% more than the total
> board power budget, I don't think I can work with that.
>
> How certain are you that the SSC will work in SPI slave mode.  Is
> there an app note on this?  The SPI speed is very slow at 100 kbps.

The SSC is not an SPI, it is a shift register which can work in master or 
slave mode.
In the slave mode, you have a clock input, and in promiscuous mode
the SSC will shift in everything which is clocked.
In other modes, it will read n bits, m clocks after the start of a 
framesync.
The SSC has slave  DMA support which the SPI doesn't have.

A good programmer can use his master SPI to communicate
with the SSC.

On the Power issue, you can of course run the part at lower clock frequency
to get what you want, the SAM7X also has dual SPI and SSC.

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