MCU mimicking a SPI flash slave - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/20/2017 3:49 AM:
Quoted text here. Click to load it

You are missing a lot.  The original PSOC devices had a simple MCU which was  
not any standard device.  It had truly programmable digital blocks and  
programmable analog blocks.  So they were *much* more functional than other  
MCUs with fixed peripherals.  If those fixed peripherals met your need, then  
the PSOC was still better in situations where you had modes where you would  
need these peripherals in this mode and those peripherals in other operating  
modes.  I think an example they promoted was for making measurements in one  
mode and reporting the results in another mode.

The newer devices offer both 8 bit 8051 CPUs and ARM CM0, CM3 or CM4  
devices.  I have not looked hard at them lately, but the 8051 based PSOC3  
has up to 24 digital blocks,

16 to 24 universal digital blocks (UDB), programmable to
create any number of functions:
? 8-, 16-, 24-, and 32-bit timers, counters, and PWMs
? I2C, UART, SPI, I2S, LIN 2.0 interfaces
? Cyclic redundancy check (CRC)
? Pseudo random sequence (PRS) generators
? Quadrature decoders
? Gate-level logic functions

That totally blows away the totally wimpy XMega E programmability.

The Cypress web site has always been a PITA to find the info you want, but  
in searching this I see they have come out with a very wide range of new  
devices including other custom CPUs including 128 MHz RISC as well as a line  
of ARM CR4 and 240 MHz CR5 devices.  These seem to be more conventional  
devices with no mention of the programmable hardware, analog or digital.  
But then that is not surprising.  The programmable hardware allows a very  
cost competitive product.  As mentioned in the Wikipedia article, they use  
PSOC in toothbrushes and Adidas sneakers.  They have to be cheap to be used  
in sneakers.  The CR5 devices are much higher cost parts.


Quoted text here. Click to load it

I assume it can do a NIC in software because of the hardware assist for the  
I/O?  Still, that's pretty good.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 21/06/17 04:44, rickman wrote:
Quoted text here. Click to load it

No, they were not much more useful.  They had a few points where they
were particularly good (I remember they were a good way of doing
capacitive touch sensing when they were new).  But you needed so many of
the programmable digital blocks to do anything.  If you wanted a UART, a
16-bit timer and an ADC, you had to get one of the bigger devices with
more blocks - and that is for basic stuff that every other
microcontroller had had for a decade.

Quoted text here. Click to load it

Nope.

It is much easier and cheaper to have dedicated peripherals for the
standard tasks.  /Then/ you can make use of the interesting programmable
blocks to make specialised peripherals.

Quoted text here. Click to load it

The AVR in the XMega will do things like CRC and PRS in software - it is
a much more powerful cpu than the 8051 of the early PSoC's.  (But not
nearly as fast as the Cortex-M cpus.)  And since you have all these
other peripherals in hardware already, you don't /need/ programmable
blocks to implement them.  (I am not suggesting that the XMega E has
/programmability/ to compare with the PSoCs' - I have never suggested
such a thing.  I /am/ suggesting that they are more /useful/ than the
early PSoC's because those PSoC's were far too limited.)

Now the PSoC's have enough blocks to be useful - they did not
originally.  And the newer devices (Cortex based) have finally got
things right - they have a proper cpu rather than a core that was
outdated 30 years ago, and they have a full selection of normal fixed
peripherals.  The programmable blocks are an /addition/ to a solid
microcontroller base, rather than instead of it.

You see this process again and again.  When the PSoC came out, the
marketing was all about claims like yours - you don't need fixed
hardware peripherals because you can use the flexible programmable
blocks.  Now modern PSoC's have lots of fixed hardware peripherals as
well.  When the XMOS came out, marketing talked about how their
deterministic SMT and I/O blocks meant that you could make Ethernet and
USB in software.  Now you can buy XMOS chips with an Ethernet MAC or a
USB interface.  When FPGAs were younger, you apparently did not need a
hard processor because soft processors could do such a good job.  Now
FPGAs with hard processor cores are much more common - even when the
speed (such as SmartFusion2's 166 MHz Cortex-M3) would be achievable in
a soft processor.  And guess what?  These devices come with a range of
dedicated fixed hardware peripherals such as CAN controllers, I2C, SPI,
Timers, etc.  And that's on an /FPGA/ - making a timer block on an FPGA
is about as simple a task for programmable logic as you can get.

Again and again it is shown - a selection of dedicated hardware standard
peripherals is important, and vastly more efficient than doing
everything in programmable blocks, programmable logic, bit banging, etc.


Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

Yes, you basically have a SERDES system for each of the I/O pins, and a
whole array of hardware timers that can trigger the transfers.


Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/21/2017 6:10 AM:
Quoted text here. Click to load it

I'm calling applesauce on this one.  Again, you are talking in vague terms  
that mean little and trying to make comparisons without specifics.  The PSOC  
1 parts were designed for *very* low cost.  They had two advantages over  
other devices.  They could use the same die for a wide range of peripheral  
combinations making the part cost lower from higher production volumes.  The  
other advantage is the peripherals could be changed on the fly being used  
for one set of peripherals in one mode of operations and another set of  
peripherals in another mode, again keeping the part cost low because you can  
use the smallest possible part.

If you think there are other parts that can reach the same price point with  
the same capabilities, please point them out.  Apple has used the PSOC 1 in  
their iPod Nano as well as other companies using them in high volume low  
margin applications where performance vs. cost is critical.

Your criticism regarding the peripherals just doesn't hold water.


Quoted text here. Click to load it

The fact that you said "Nope" doesn't make it true.  Dedicated peripherals  
are just that, dedicated.  They can't be anything else.  If you aren't using  
them they are wasted silicon.  They tend to be added in proportion.  Chips  
with more UARTs are likely to have more I2C and SPI as well, often wasted.  
PSOC 1 devices sold well enough to markets that needed to save every last  
penny.

The only real issue with PSOC 1 was the design software.  I scheduled a live  
remote class once which turned out to be me and the instructors.  lol  They  
were willing to teach the tools one on one in the early days because they  
hadn't gotten things working well enough to convey the knowledge any other  
way.  That's why they revamped the line to PSOC 3 and 5 and now all the  
others with all new tools.  Personally I don't care for the tools because  
they isolate the designer from what is going on, but they work at least.


Quoted text here. Click to load it

The "early PSOCs" didn't use an 8051, it was a custom M8C core.  I don't  
recall the speed relative to other 8 bitters, but it runs at 24 MHz with a  
built in multiplier.  To say the AVR blows it away I expect is rather an  
exaggeration.


Quoted text here. Click to load it

You keep talking about devices purely from your perspective.  The market  
says your criticisms are wrong.  The original PSOC devices are still sold  
and are very cost effective.  They offer a range of combinations that are  
much, much wider becoming optimal for a much wider range of applications.


Quoted text here. Click to load it

None of this makes the XMega E a useful part.  Programmability is highly  
useful allowing devices to reach an optimum price point.  The XMega E would  
have only a very, very tiny niche.


Quoted text here. Click to load it

I think we are starting to see why the XMOS devices are so expensive, very  
extensive dedicated hardware.  Too bad they don't have a few programmable  
digital blocks that can actually do something useful.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 21/06/17 17:40, rickman wrote:
Quoted text here. Click to load it

The SERDES and timers are very simple, so I'm unconvinced
they are the reason for any perceived expense.

Have a look in the "ports" reference I previously gave you
https://www.xmos.com/published/xs1-ports-introduction?version=latest
You will see that the
   - SERDES is only a shift register plus buffer register,
   - each /port/ timer is only 16 bits and is constantly
     ticking, plus a register and comparator to enable
     timed i/o
   - there's a pinseq/pinsneq register and comparator

Scarcely enough to dominate the chip area, especially when
you consider the memory and xCONNECT switch fabric.

Without knowledge, my guess is that the switch fabric will
have a far larger area than the port logic, just as in FPGAs
the interconnects are far larger than the IO cells.

Re: MCU mimicking a SPI flash slave
Tom Gardner wrote on 6/21/2017 1:19 PM:
Quoted text here. Click to load it

So there is the equivalent of three 16 bit  
counter/timer/comparator/shifter/whatever for *each* port pin?  That may not  
dominate the chip area, but it is going to add up fast.  I'll bet it is  
larger than a set of fixed peripherals in low end MCUs that can be sold for  
$1.  Just how much logic do you think is in an SPI port?


Quoted text here. Click to load it

Xilinx used to say they sell you the routing and give the logic away for  
free.  What's your point?  How do FPGAs come into the cost basis of the XMOS?

The real issue is that they just can't compete in the low price end of MCUs  
where I feel they would be most useful.  But they have their niche and I  
guess they aren't going anywhere soon.  I wonder what it would take for the  
XMOS concept to be scaled up to cover more at the high end?

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 21/06/17 19:34, rickman wrote:
Quoted text here. Click to load it

No.

Read the reference supplied; the relevant bits are
only 9 pages - and are in clear and simple English.


Quoted text here. Click to load it

It is the same principals and cost drivers at work. Your
comment indicates you/Xilinx see the similarity.


Quoted text here. Click to load it

... to you.

Quoted text here. Click to load it

A key decision for /all/ businesses is where /not/ to compete.


Re: MCU mimicking a SPI flash slave
Tom Gardner wrote on 6/21/2017 4:41 PM:
Quoted text here. Click to load it

So what you wrote is not correct?


Quoted text here. Click to load it

This gets tiring.  I don't know what "comment" of mine you mean and I  
*don't* see the similarity.  The interconnect in an FPGA is at least an  
order of magnitude more complex than the I/O routing in an MCU.


Quoted text here. Click to load it

Ok, I'll spell it out.  At the low end the multiple processors can implement  
separate tasks on separate processors.  This works great simplifying the  
otherwise complex issues in emulating parallel processing on a sequential  
processor.  Fine.  A more complex set of tasks will typically require a more  
powerful processor although complexity is not synonymous with performance  
requirements.  Once the XMOS device is fully utilized with one process per  
processor additional tasks require adding back in the complexity of  
emulating parallel processing on a single processor.  So the primary  
advantage of the XMOS processor end once the tasking is complex enough, i.e.  
high end.

So clearly the XMOS is less useful at the high end and more useful at the  
low end.  If they make some adjustments to the design/architecture to allow  
low *cost* units to be sold, that would only open more markets for them.  
One nice thing about the low end is that while you don't make tons of money  
on even a fairly large number of units sold, it pays to keep the doors open  
and the machinery running.  Then they can pursue other products that have  
different economics and may be less stable financially, good one year and  
not so good the next.


Quoted text here. Click to load it

So a processor company shouldn't try to compete in the processor business.  
Good thing ARM didn't try that approach.  They definitely started at the  
small end and worked upward.  I understand they are making significant  
inroads to servers these days.

I am feeling that this horse has been flogged quite enough.  It's not going  
to get much deader and I don't think we are expressing much in the way of  
new thoughts.

--  

Rick C

Re: MCU mimicking a SPI flash slave

Quoted text here. Click to load it

I added the command port to my test code.  In a real spi device, there should only be one serial chain, instead of three in mine.  But i don't need to follow the standard spec.  However, resource ultizations should be similar.  Using elements:

Max II:  67 / 240 ( 28 % )
Max 10: 154 / 8,064 ( 2 % )

I am using 60 cents of a $2 Max II, since i don't need anything else.  Realistically, around 20 cents of a $10 Max 10.

----------------------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

  
entity ram is
 port(
 P7: in std_logic;                            -- preserve upper 9 bits for next shift
 P6: in std_logic;                            -- preserve upper 10 bits for next shift
 P5: in std_logic;                            -- preserve upper 11 bits for next shift
 ACLK, clear, pass : in std_logic;            -- Address serial clock
 ASI: in std_logic;                           -- Address serial in
 ASO: buffer std_logic;                       -- Address serial out
 A: buffer std_logic_vector(16 downto 0);     -- Address register
 AA: in std_logic_vector(16 downto 0);        -- Address parallel in
 DCLK: in std_logic;                          -- Data serial clock
 DSI: in std_logic;                           -- Data serial in
 DSO: buffer std_logic;                       -- Data serial out
 D: buffer std_logic_vector(7 downto 0);      -- Data register
 DD: in std_logic_vector(7 downto 0);         -- Data parallel in
 CCLK: in std_logic;                          -- Command serial clock
 CSI: in std_logic;                           -- Command serial in
 CSO: buffer std_logic;                       -- Command serial out
 C: buffer std_logic_vector(7 downto 0);      -- Command register
 CC: in std_logic_vector(7 downto 0)          -- Command parallel in
 );
end ram;
  
architecture arch of ram is

begin
  
 process (ACLK, clear)
 begin
 if clear = '1' then
  A <= "00000000000000000";
 elsif (P7 = '1') then
  A(9 downto 0) <= A(16 downto 7);
 elsif (P6 = '1') then
  A(10 downto 0) <= A(16 downto 6);
 elsif (P5 = '1') then
  A(11 downto 0) <= A(16 downto 5);
 elsif (pass = '1') then
  A <= AA;
 elsif (ACLK'event and ACLK='1') then
  ASO <= A(16);
  A(16 downto 1) <= A(15 downto 0);
  A(0) <= ASI;
 end if;
 end process;

 process (DCLK)
 begin
 if (pass = '1') then
  D <= DD;
 elsif (DCLK'event and DCLK='1') then
  DSO <= D(7);
  D(7 downto 1) <= D(6 downto 0);
  D(0) <= DSI;
 end if;
 end process;

 process (CCLK)
 begin
 if (pass = '1') then
  C <= CC;
 elsif (CCLK'event and CCLK='1') then
  CSO <= C(7);
  C(7 downto 1) <= C(6 downto 0);
  C(0) <= CSI;
 end if;
 end process;
  
end arch;

Re: MCU mimicking a SPI flash slave
On 15/06/17 21:52, rickman wrote:
Quoted text here. Click to load it

A 30000ft opverview:
http://www.xmos.com/published/xcore-architecture-flyer?version=latest

Quoted text here. Click to load it

What are the *guaranteed* timings and latencies?
Include all possible disturbances due to cache/TLB
misses, branch predictions and interrupts.
Include simultaneous USB comms to a host PC.

N.B. "guaranteed" /precludes/ measurements to see
what is happening. "Guaranteed" requires accurate
/prediction/ *before* the code executes.


Quoted text here. Click to load it

Each i/o pin can be clocked at up to 250Mb/s.
That clock can come from an internal clock
(up to 500MHz) or an external pin. The latter
sounds relevant for your case. (Strobed and
master/slave interfaces are also directly
supported in hardware and software).

Each I/O pin has SERDES registers, so the data
rate processed by a core can be reduced by a factor
of 32.

So yes, it does look like a /small/ fraction of an xCORE
device could very comfortably support that speed.


Quoted text here. Click to load it

Sigh.

My application only stops for a few microseconds when
it is convenient for my application, i.e. once every
1 or 10seconds at the end of a measurement cycle.

At other times it chunters away continuously at full
rate without interruption - as guaranteed by design.




Quoted text here. Click to load it

I don't think there are any surprises there.

But, again, your (current) requirement is only one
perspective.


Re: MCU mimicking a SPI flash slave
Tom Gardner wrote on 6/15/2017 6:33 PM:
Quoted text here. Click to load it

I know this is clear to you, but I'm not sure what processor you are talking  
about.


Quoted text here. Click to load it

You still are not addressing the issue at hand.  You are talking about raw  
I/O speeds and the problem is not about raw I/O speeds.  The issue is  
interactivity.  Stimulus followed by response in very short order.  I have  
seen nothing to indicate the XMOS will work for this problem.  That's why I  
asked for a code snippet.


Quoted text here. Click to load it

Fine, but the fact that it will work for your needs does not mean it will  
work for mine.  Again the requirement is to read the inputs looking for a  
command strobe, on finding that retrieve the appropriate word from memory  
and outputting it.  The clock cycle is 30 ns and the total I/O time from  
command strobe read on the positive edge of the clock to the input of the  
device monitoring the output pin (with a 5 ns setup time) 15 ns.  You  
haven't even addressed the output delays in the I/O pins.



Quoted text here. Click to load it

I can't argue with that.  But that is the need I have and low cost is not a  
very minor requirement.  Processors are sold at much higher volumes for the  
low cost products.  The higher cost, lower volume products often can be  
built with a wide range of solutions, again the selected device is often  
chosen as the one that meets the requirements at the lowest price.  So  
shrugging off the cost issue of *my* current need is rather disingenuous.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 16/06/17 04:12, rickman wrote:
Quoted text here. Click to load it

There are many interesting snippets, plus a description
of how they fit together in the /very/ lucid xC tutuorial.
https://www.xmos.com/support/tools/programming?component17%653

You might care to look for the "pinseq/pinsneq" attribute
of i/o ports, in conjunction with the ways of combining i/o
pins, and port timers.

For more details of some i/o structures, see
https://www.xmos.com/published/xs1-ports-introduction?version=latest



Quoted text here. Click to load it

Quoted text here. Click to load it

Of course I will shrug them off; they are of no direct
interest to me.

You have a choice...

You could look at the XMOS devices see where they
might complement the existing design options
(principally FPGAs and conventional MCUs), and
blur the boundaries between them.

Or you could find ways in which the devices
couldn't /possibly/ do what existing options
can do (cf the way h/w designers reacted to
early microrocessors).

I can imagine that FPGA designers might see them as
a /bit/ of a threat, and react accordingly.


Re: MCU mimicking a SPI flash slave
Tom Gardner wrote on 6/16/2017 2:05 AM:
Quoted text here. Click to load it

Quoted text here. Click to load it

A threat???  That makes no sense.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On Wed, 14 Jun 2017 10:44:00 -0700, John Speth wrote:

Quoted text here. Click to load it

Do you know the clock rate of the data, and how fast the turn-around  
needs to be?

Maybe a CPLD or a small FPGA, if you don't like Rick's (probably spot-on)  
suggestion of using an EEPROM as an intermediate device.

--  

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 14/06/17 18:44, John Speth wrote:
Quoted text here. Click to load it

If you want guaranteed timing and FPGA-like io,
have a look at the XMOS processors. See my other
post.

Re: MCU mimicking a SPI flash slave
On 14/06/17 19:44, John Speth wrote:
Quoted text here. Click to load it

If you make sure you have a MCU with good slave SPI support and DMA,
then the actual SPI transfers should not be an issue (assuming a sane
SPI clock speed).  The cpu would then not be involved in the
back-to-back SPI moves at all.  Pretty much any Cortex M3/4 device
should cope fine.

The key challenge is how to deal with the commands - the bits that need
some processing.  That will probably mean fast response to the first few
incoming SPI bytes via an interrupt function.  Your requirements here
will depend on the protocol, the clock speed, the processing time
required, etc.

Write-style SPI commands are no problem - just buffer up the SPI command
and data with DMA as it comes in.  It's the read-style ones that are the
killer.  For very fast SPI interfaces, it is not uncommon that with a
read command, the first byte returned is a dummy byte - that gives you
the time to fill your DMA buffer with the real data for the reply.  But
not all SPI protocols use that, and they might have some reads that need
immediate response.  If you can get that under control, the rest should
be (relatively) easy.

If you can't build this from a normal microcontroller because you need
too fast response, your options are FPGA (either as an assist to a
microcontroller, or with a processor in the FPGA) or perhaps an XMOS
microcontroller.  XMOS programming is a bit different from normal
microcontroller programming, but it will handle tasks like this easily.


Re: MCU mimicking a SPI flash slave
On 15/06/17 08:14, David Brown wrote:
Quoted text here. Click to load it

I'll just say that I find XMOS programming to be *very*
easy compared to C+RTOS -- doubly so for a hardware engineer.

The "RTOS" is in hardware => very low API learning curve :)

The programming model (CSP) is *very* simple and also
comprehensive. It was invented in the 70s, and has stood
the test of time.

Re: MCU mimicking a SPI flash slave
On 15/06/17 09:25, Tom Gardner wrote:
Quoted text here. Click to load it

XMOS programming is very easy for some things, but hard for other
things.  In particular, there is a limit to the scalability.  It starts
off easy splitting your work into lots of parallel tasks, putting them
each in threads, and everything is fine - until you run out of hardware
threads.  Then you end up destroying your structure to get a several
logically parallel tasks running in the same hardware thread, or running
a software RTOS in one hardware thread.  And when you have your multiple
high-speed interfaces working, you find you don't have enough ram left
for buffers.

XMOS devices can be a lot of fun, and I would enjoy working with them
again.  For some tasks, they are an ideal solution (like for this one),
once you have learned to use them.  But not everything is easy with
them, and you have to think in a somewhat different way.

Quoted text here. Click to load it

Yes, CSP is a great tool.  I was taught it by some of the folks behind
it.  (Tony Hoare himself was head of the department, but I didn't have
him as a lecturer.)



Re: MCU mimicking a SPI flash slave
AT Thursday 15 June 2017 16:02, David Brown wrote:

Quoted text here. Click to load it

Just grabbing this thread.

XMOS sounds like something interesting to play with.  
How good is the development environment?  
Runs on Linux?

--  
Reinhardt


Re: MCU mimicking a SPI flash slave
On 15/06/17 10:25, Reinhardt Behm wrote:
Quoted text here. Click to load it

Yes, it runs fine on Linux.  When I last worked seriously with XMOS
(which was when it was a relatively new company), I had a a fair number
of issues with the tools and, in particular, with the sample code.  My
understanding is that it has improved a good deal since then.  And there
is certainly no doubt that they are interesting to play with!



Re: MCU mimicking a SPI flash slave
AT Thursday 15 June 2017 16:32, David Brown wrote:

Quoted text here. Click to load it

Thanks David and Tom.
I will give it try. Unfortunately today my latest shipping from Digikey has  
arrived.So it has to wait 'til the next time, but I am busy enough.

--  
Reinhardt


Site Timeline