Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26796
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: MCU mimicking a SPI flash slave |
| Date | 2017-06-15 17:46 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <ohuv1i$nlc$1@dont-email.me> (permalink) |
| References | (1 earlier) <ohtbt5$vh5$1@dont-email.me> <9Eq0B.74561$7A4.41458@fx19.am4> <ohtena$7s5$1@dont-email.me> <gLr0B.74079$O06.57510@fx43.am4> <ohtpct$91f$1@dont-email.me> |
David Brown wrote on 6/15/2017 7:04 AM: > On 15/06/17 10:41, Tom Gardner wrote: >> On 15/06/17 09:02, David Brown wrote: >>> On 15/06/17 09:25, Tom Gardner wrote: >>>> On 15/06/17 08:14, David Brown wrote: >>>>> On 14/06/17 19:44, John Speth wrote: >>>>>> 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 >>>>> >>>>> 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. >>>> >>>> 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 :) >>>> >>> >>> 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. >> >> 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. > > 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. I think that depends on the design. Perhaps you are familiar with the GA144 with 144 processors at a cost of around $0.10 per CPU. They took a similar route with NO dedicated I/O hardware other than a SERDES receiver and transmitter pair. It is expected that all I/O would be through software. Along that line the chip boots through one of three I/O ports, async serial, SPI serial, a 2 wire interface and I believe there is a 1 wire interface but I'm not certain. Three of the CPUs can be ganged to form a parallel port/memory interface, two CPUs with 18 bits of I/O and the third 4 bits. All of this is controlled by software. I find the device has significant limitations overall, but certainly with a peak execution rate of 700 MIPS there is a lot of potential. Much like no one focuses on the idea that using the 4 input LUT of an FPGA as an inverter is excessively wasteful, the GA144 with its 10 cent CPUs gets us out of the thinking that using a CPU as a UART is wasteful. Not trying to be negative, but I see the $2 cost of an XMOS CPU as being excessive and wasteful. Heck, you can buy complete MCU devices for a fraction of that price. >> 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. > > 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. > >> >> 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. > > Agreed. The question is whether it is worth investing the time and energy into learning the chip if you don't focus your work in this realm. Personally I find the FPGA approach covers a *lot* of ground that others don't see and the region left that is not so easy to address with either FPGAs or more conventional CPUs is very limited. If the XMOS isn't a good price fit, I most likely would just go with a small FPGA. I saw the XMOS has a 12 bit, 1 MSPS ADC which is nice. But again, this only makes its range of good fit slightly larger. >>> 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, 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. >> > > Agreed. I prefer Forth for embedded work. I believe there is a Forth available. I don't know if it captures any of the flavor of CSP, mostly because I know little about CSP. I did use Occam some time ago. Mostly I recall it had a lot of constraints on what the programmer was allowed to do. The project we were using the Transputer on programmed it all in C. -- 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