MCU mimicking a SPI flash slave

Hi folks-

I'm hoping to tap into your various experiences to see if what I'm thinking is practical.

Our customer has a device into which a Datakey is plugged to extract data stored in the device. The Datakey is a really just a trade name for a SPI flash with ergonomic features that resemble a real key (see datakey.com). Our customer would like to replace the Datakey with a new design that will transmit the data wirelessly instead of storing it to the Datakey SPI flash.

We're proposing a design based on an MCU which will appear as a SPI slave flash device, store the data pumped to it from the customer's device, and forward it wirelessly. I'm wondering if it's practical to accomplish it. The firmware would have to be totally responsive temporally and in data content. That sounds like a tough hill to climb that requires getting the interface just right, nearly perfect. I see a lot of pitfalls that could make the effort a dead end.

Does anybody have any success or failure stories to relate that would help us gauge the feasibility of the proposed design?

Thanks - John Speth

Reply to
John Speth
Loading thread data ...

So, the "device" is the SPI master (the Datakey being the first downstream slave)

But, the customer owns the IP for the "device"? I.e., in the best case (in terms of making YOUR job easier), they could redesign the device (or its firmware) to be compatible with your new gizmo. In the worst case, they would want to make no changes to the "device" and expect your gizmo to take up the challenge of behaving like a "real" Datakey.

Regardless, as they own(?) the IP for the device, it is possible to understand EXACTLY how the device expects to interact with a genuine Datakey and your "replacement" gizmo. I.e., you don't really have to emulate a Datakey but, rather, emulate a Datakey AS ACCESSED BY their device.

[This could give you considerable leeway in your implementation without requiring a change to the "device".]

Again, thinking worst case...

Your new device would have to be able to emulate the FLASH device (Datakey) irrespective of the wireless link's functionality. For example, if the "device" pushes data into the Datakey at a particular burst rate, you have to ensure you can accept AND RETAIN that data in the face of a dubious wireless link.

What happens if the link *never* comes up? Does the wireless link protocol include acknowledgements of received data? What if the data (or some portion of it) is not acknowledged in a particular timeframe (see below)?

Does the device do a read-back of the Datakey to verify the contents written? Can you use (abuse) this to indicate a confirmation that the link is up and/or the wireless transmission has completed successfully?

The first hurdle is looking at the (peak) data rates (and frequencies) from the "device" and characterize the "typical" and "worst case" traffic. With access to the sources (and schematics), you should be able to opine as to their likely values. Else, you're stuck with a protocol analyzer (or, a 'scope) and a hopeful attitude that you will actually *see* worst case examples of these transactions.

From that, you can determine if you can tackle it with a bit-banging interface. Or, an SPI tricked to behave as a slave. Or, as some amount of hardware assist (external shift register?).

Until you can confidently claim that you can reliably behave as a *local* SPI slave, the rest of the problem isn't worth evaluating. Once that's assured, you can start exploring ways of fitting some sort of acknowledgement into the existing device's expectations of the Datakey.

(I.e., presumably, it has to deal with defective Datakeys *and* Datakeys that are withdrawn while a communication transaction is in progress. Can a Datakey be *bodged* by incorrect usage? How does their "system" accommodate this? etc.)

[You've not mentioned costs, etc.]
Reply to
Don Y

John Speth wrote on 6/14/2017 1:44 PM:

I have no experience in building such a product, but why not use an actual SPI data flash as the intermediate storage while the MCU monitors the action and forwards the data? This would require periods when the MCU could read the data flash. Is that possible or practical?

I had a design that needed a 30 MHz SPI like interface (not entirely compatible though) which was designed to read/write registers. I considered using a fast CPU to emulate the interface in software, but it just couldn't meet the timing. Even with a 700 MIPS processor I wasn't sure it could receive the command to read a register and then get the data onto the output fast enough. I'm not sure of the timing of the SPI interface you have, but it will likely be hard to emulate the SPI in software.

--

Rick C
Reply to
rickman

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 
 Click to see the full signature
Reply to
Tim Wescott

That sounds easy for the XMOS processors: - multicore (up to 32 100MIPS cores) - FPGA-like i/o, e.g. SERDES, buffers, programmable clocks to 250Mb/s, separate timer for each port - i/o timing changes can be specified/measured in software with 4ns resolution - guaranteed latencies

Reply to
Tom Gardner

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

Reply to
Tom Gardner

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.

Reply to
David Brown

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.

Reply to
Tom Gardner

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.

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

Reply to
David Brown

Just grabbing this thread.

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

--
Reinhardt
Reply to
Reinhardt Behm

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!

Reply to
David Brown

Agreed. But then there are cliffs in /everything/ so it is unsurprising if this toolset also has them :)

A more interesting question is whether the limitations are significant in a given context - and that's less easy to quantify.

XMOS does provide some techniques (e.g. composable and interfaces) to reduce the sharpness of the cliffs, but not to eliminate them. But then the same is true of ARM+RTOS etc etc.

I wouldn't regard XMOS as being a replacement for a general-purpose processor, but there is a large overlap in many hard-realtime applications.

Similarly I wouldn't regard an ARM as being a replacement for a CPLD/FPGA, but there can be an overlap in many soft-realtime applications

The XMOS devices inhabit an interesting and important niche between those two.

Yes, but the learning curve is very short and there are no unpleasant surprises.

IMNSHO "thinking in CSP" will help structure thoughts for any realtime application, whether or not it is formally part of the implementation.

My only contact with him was via his Elliott 803 Algol-60 compiler - and thanking him for it ~30 years later :)

Reply to
Tom Gardner

Good, very usable, but I'm still exploring the degree of perfection :)

Eclipse + LLVM + GDB based.

Yes.

Download it and have a go. In the "run configurations" you choose between "hardware" and "emulator". I haven't tried "emulator", but I guess it means you don't need a devkit.

Key documents are:

- 30000 ft overview:

formatting link

- outline of concurrency:

formatting link

- very readable xC tutorial:

formatting link

-boards (also Farnell, and DigiKey):

formatting link

-app notes:

formatting link

Reply to
Tom Gardner

I suppose I have a bias...

I don't like creating a system then finding /a late stage/ during testing that it fails due to /occasionally/ missing timing constraints, or having livelock issues.

I prefer a toolset that alerts me to those problems at the /earliest/ opportunity. If there's a cliff, then I can choose another route, or carefully walk along the clifftop or simply jump off :)

The XMOS toolkit falls into the latter category.

Reply to
Tom Gardner

Absolutely.

One point to note is that when I worked with XMOS, one of their big features was that their architecture was so fast it could make a USB interface and an Ethernet interface in software. And yes, it /could/ work - but the cost in hardware threads and memory space (code and data go in the same ram) meant that there was very little left to do anything useful with the device. Since then, XMOS have realised that the big blocks are much more efficient in hardware - they now have devices with hardware Ethernet and USB rather than making them in software. The devices also have much more ram.

I think XMOS should go further, and include hardware peripherals for common features - in particular, UARTs, I2C, SPI, timers. A simple hardware UART peripheral is a small and easy part to make in a chip design. With the XMOS, you can do it in software - you can write a nice, clear UART software block, without much coding space. But it takes two hardware threads - a quarter of your chip's power if you have a small device. Turned into cash, that's about $2 for a UART. On a chip microcontroller, you have lots of UARTs and they don't take significant resources - it's a "cost" of perhaps $0.02. For peripherals that you often need, it is /much/ cheaper to have dedicated hardware than to have them in software.

Yes, there are learning curves everywhere. And scope for getting things wrong :-) XMOS gives a different balance amongst many of the challenges facing designers - it is better in some ways, worse in other ways.

Agreed.

Agreed.

At the end of my degree course, I had the chance to stay and do a doctorate with Professor Hoare as one of my supervisors. But I choose to emigrate to Norway, get married, and try to find a job. It was the right choice.

Reply to
David Brown

Sounds very plausible, and answers one of the questions that was on my "to be answered" list. I don't think either of us are surprised.

Hmmm. I understand why you are saying that, but dayOfWeek%2==1, so I'll disagree. The questions with such peripherals are:

- where do you stop

- switch matrix connections

- apis The last is an extra learning curve, especially w.r.t. configuration.

Agreed. Horses for courses.

I feel comfortable with XMOS for bit-banging, DSP and similar. I am unclear about having non-trivial ethernet protocol stacks and similar.

Curiously I made similar choices, although the University (Southampton) and destination were different.

Reply to
Tom Gardner

I am not sure you really /are/ disagreeing - because I agree that there is a balance here, and "where do you stop?" is an important question.

The answer is somewhere between "I use this peripheral a lot, it is cheap in hardware but expensive in software" and "I use this peripheral occasionally, it is expensive in hardware but cheap in software". I.e., no, there is no clear dividing point, and different developers will have wildly different opinions. And different hardware designers have had different opinions too - from FPGA, through XMOS, PSoC, 68332/MPC5xxx with TPUs, to microcontrollers with configurable pin selections. A common theme is that while the more flexible systems let you make marvellously complicated peripherals that fit just right for a specialised need, most of the time they are used for simple UARTs, SPI, timers with capture or PWM, etc., and they are mostly very inefficient for those uses.

And I agree that a simple peripheral is easier to use than a complicated one, and gives an easier interface. So if you want an 11-bit UART, and you have an XMOS UART, it is an easy matter to change the "NUMBER_OF_BITS" from 8 in the sample code to 11. But a hardware UART that is that flexible is likely to have scores of pages of register definitions to wade through to find the right options.

When you are the kind of nerd that is likely to end up in an ivory tower doing all your "programming" as symbolic manipulation on a blackboard, you don't let the chance of a lifetime with a good woman pass you by!

Reply to
David Brown

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
Reply to
Reinhardt Behm

Any yet the XMOS can't run fast enough to return a result in the time available. What a pity, all dressed up an nowhere to go.

Can you output a result before the next input transition?

Not a very good processor to use in cost conscious applications. The lowest price at Digikey is $3 at qty 1000. They can't make a part in the sub-dollar range?

--

Rick C
Reply to
rickman

You'll have to explain that, because I don't understand what you are referring to.

Yes and no.

Yes: the output (to a host processor and/or LCD) proceeds in parallel with the next capture phase.

No: in the current incarnation there is a short gap between capture phases as the results are passed from one core to another and the next capture phase is started. While it isn't important in my application, I may be able to remove that limitation in future incarnations.

Don't presume everybody has your constraints.

Reply to
Tom Gardner

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.