Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26803
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: MCU mimicking a SPI flash slave |
| Date | 2017-06-16 02:27 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <ohvthp$cuh$1@dont-email.me> (permalink) |
| References | (4 earlier) <q3z0B.72490$wG6.62543@fx38.am4> <ohurrv$bbq$1@dont-email.me> <zWD0B.48374$y7.37664@fx15.am4> <ohvi3e$gm6$1@dont-email.me> <5zK0B.74636$%h1.49112@fx11.am4> |
Tom Gardner wrote on 6/16/2017 2:05 AM: > On 16/06/17 04:12, rickman wrote: >> Tom Gardner wrote on 6/15/2017 6:33 PM: >>> On 15/06/17 21:52, rickman wrote: >>>> Tom Gardner wrote on 6/15/2017 1:01 PM: >>>>> On 15/06/17 17:13, rickman wrote: >>>>>> Tom Gardner wrote on 6/15/2017 3:01 AM: >>>>>>> >>>>>>> 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 <100ns >>>>>>> - *excellent* programming model based on CSP >>>>>>> (summary: of "Occam in C") >>>>>>> - Eclipse-based dev environment >>>>>> >>>>>> 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. >>>>> >>>>> You'll have to explain that, because I don't understand >>>>> what you are referring to. >>>> >>>> Maybe I don't understand the speed of the XMOS. >>> >>> A 30000ft opverview: >>> http://www.xmos.com/published/xcore-architecture-flyer?version=latest >>> >>>> Nothing you write above says to >>>> me it is any faster than the 700 MIPS processor I considered. Nothing >>>> written >>>> above would allow it to perform the task any differently than the bit >>>> banging >>>> approach I initially considered. >>> >>> 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. >> >> I know this is clear to you, but I'm not sure what processor you are >> talking about. >> >> >>>> So what are you confused about? >>>> >>>> Maybe you don't understand the problem. A bit serial data port (two bits >>>> wide >>>> actually, but that is not relevant) provides data, address and a two bit >>>> command >>>> word serially. The last bit of the command work is indicated by a >>>> "command" >>>> signal going high during that bit. Data is clocked in on the rising edge >>>> of the >>>> clock. When the command word is a read, the read data is provided serially >>>> starting on the subsequent falling edge. This provides 15 ns from rising >>>> edge >>>> to falling edge. It is possible to prefetch the read data based on the >>>> shifted >>>> address on each rising edge until the command signal is asserted. This >>>> helps >>>> with timing of the memory fetch, but still, that data has to be presented >>>> to the >>>> serial port output in 15 ns and updated every 30 ns. >>>> >>>> I'd like to see code that will make this work. Or maybe you weren't >>>> addressing >>>> my previous application? For the OP, can the XMOS emulate a 30 Mbps SPI >>>> port? >>> >>> 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. >> >> 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. > > 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?component=17653 > > 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 > > > >>>>>>> Currently I'm managing to count transitions in >>>>>>> software on two 50Mb/s inputs, plus do >>>>>>> simultaneous USB comms to a host computer. >>>>>> >>>>>> Can you output a result before the next input transition? >>>>> >>>>> Yes and no. >>>>> >>>>> Yes: the output (to a host processor and/or LCD) >>>>> proceeds in parallel with the next capture phase. >>>> >>>> I'm referring to bit I/O using the same 50 MHz clock. >>>> >>>> >>>>> 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. >>>> >>>> That's a lot more than a "short" gap in the context of a fast clock. >>> >>> 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. >> >> 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. >> >> >>>>>>> Processors plus £10 devkit available from Farnell >>>>>>> and DigiKey. >>>>>> >>>>>> 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? >>>>> >>>>> Don't presume everybody has your constraints. >>>> >>>> I don't, but not everyone has *your* constraints. If a processor can't be >>>> sold >>>> in a low cost product, it cuts off the largest volume parts of the market >>>> including the app I am looking at presently. >>> >>> I don't think there are any surprises there. >>> >>> But, again, your (current) requirement is only one >>> perspective. >> >> 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. > > 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. A threat??? That makes no sense. -- Rick C
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-14 10:44 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-14 16:30 -0700
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-14 21:54 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:01 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 12:13 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 18:01 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 16:52 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 23:37 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:15 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 09:25 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 13:52 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-18 22:56 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:21 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 09:02 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 08:36 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 14:47 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:23 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 15:34 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:16 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 09:49 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 22:44 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 12:10 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:40 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 18:19 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 14:34 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:41 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 17:14 -0400
Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 13:54 -0700
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 23:33 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 23:12 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-16 07:05 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 02:27 -0400
Re: MCU mimicking a SPI flash slave Tim Wescott <seemywebsite@myfooter.really> - 2017-06-14 23:17 -0500
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:03 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 09:14 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:25 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:02 +0200
Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 16:25 +0800
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:32 +0200
Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 21:48 +0800
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:09 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 09:41 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 13:04 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 12:31 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 14:20 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 17:46 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 13:21 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 13:55 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 16:34 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 15:40 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 00:47 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:47 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:15 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:50 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:16 +0200
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 18:00 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-22 11:24 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 12:12 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 14:22 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 03:15 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:54 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 10:30 +0200
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 12:54 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 13:49 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:28 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:19 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 16:23 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 23:57 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:36 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 08:20 -0400
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-19 14:44 +0000
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 21:39 +0200
Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-19 14:59 -0500
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-20 09:25 +0200
Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-20 11:50 -0500
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:37 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 22:59 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:12 -0400
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 10:25 +0300
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 10:44 +0200
Re: MCU mimicking a SPI flash slave dp <dp@tgi-sci.com> - 2017-06-20 02:36 -0700
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 11:25 +0100
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 13:49 +0300
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 12:54 +0100
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 16:09 +0300
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 15:24 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 17:46 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 22:28 +0200
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 00:58 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 13:08 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:28 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:58 +0200
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:57 +0200
Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 14:19 +0300
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:19 +0200
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:12 +0000
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:48 +0200
Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-20 21:16 +0100
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 23:15 +0200
Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-21 07:30 +0100
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:54 -0400
Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:29 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 15:05 -0400
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:34 +0100
Re: MCU mimicking a SPI flash slave "Elizabeth D. Rather" <erather@forth.com> - 2017-06-21 18:04 -1000
Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-22 10:26 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:56 -0400
Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-22 09:20 +0000
Re: MCU mimicking a SPI flash slave Wasell <from_usenet@wasell.eu> - 2017-06-22 14:02 +0200
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:59 -0400
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:58 -0400
Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-22 08:19 +0000
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-19 09:53 +0100
Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:16 +0100
Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 13:56 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-15 14:41 -0700
Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 15:08 -0700
Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-16 11:34 -0700
Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:20 -0400
Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 07:58 -0700
Re: MCU mimicking a SPI flash slave Walter Banks <walter@bytecraft.com> - 2017-06-19 12:23 -0400
csiph-web