3

I have not yet used ARM Cortex uCs, only AVRs

Firstly, how fast can they:

  1. Stream 1024+ bits (serially, from bytes in RAM) out of a pin, with no pauses/jitter
  2. Stream 1024+ bytes (parallel, from RAM) out of 8 pins, with no pauses/jitter

I'm expecting answers in the form of X clock cycles per bit/byte, but I could be ignorant of how the ARM chips work. Are there non-deterministic timing issues with e.g. the L1 cache (if it even exists on those chips)?

Secondly are one or both of these jobs done better by some integrated peripheral (SPI, USART) commonly found on ARM uCs?

I'm particularly interested in the LPC1114FN28/102 if that makes any difference. I am not uC electronics professional, it's just a hobby.

unwind
  • 121
  • 7
fadedbee
  • 994
  • 9
  • 24
  • It would be helpful if you would explain exactly what it is you are trying to accomplish. How do you intend to synchronize the data stream with the outside world? That's a pretty important point that you haven't mentioned. Does the microcontroller also provide a clock? – Joe Hass Feb 24 '14 at 12:13
  • 1
    @JoeHass the thing that would require the highest performance would be abusing an ARM to generate a monochrome composite video signal (or 8 bit colour VGA). The synchronisation would be an interrupt per scanline which started the bitbanging of a few hundred pixels. – fadedbee Feb 24 '14 at 12:41

3 Answers3

4

If I read the SPIO0/1-with-SSP chapter correctly using the TISS format (fig 36 in my rev 12 copy of the user manual, link to newer version) can send out a continuous bit stream. The maximum clock rate seems to be PCLK / (CPSDVSRx(SCR+1)), for 48 MHz, CPSDVSR=2 (seems to be the minimum) and SCR=0 (default) this would give 24 MHz.

Were are you going to find the data to clock out at that speed? This poor chip (OK, it is my favorite!) has only 4K RAM and 32K FLASH.

Wouter van Ooijen
  • 48,407
  • 1
  • 63
  • 136
  • Thanks, that's just the sort of answer I was looking for. @JoeHass intimated that SPI wouldn't meet the "no pauses" requirement due to framing. Is this true? – fadedbee Feb 24 '14 at 12:57
  • The data will be RLE. There may be only a few dozen transitions in the 1024 bits. I could use timed interrupts for the transitions, but I have read that they can take a non-deterministic time to start if the CPU is in the middle of executing a long instruction. – fadedbee Feb 24 '14 at 12:58
  • 1
    I questioned JoeHass's statemnet in a comment. As I read the document there are no framing bits required in SPI, and the TISS format has an FS signal (that you will porbably ignore) in parallel to the LSB, not in the 'between frames' time as with normal SPI. – Wouter van Ooijen Feb 24 '14 at 13:04
  • 1
    Fig 37 in http://www.nxp.com/documents/user_manual/UM10398.pdf (ch14, p228) shows no gap with TISS. I'll order the parts and update this question if I can/can't make it work. – fadedbee Feb 24 '14 at 13:39
2

I'm assuming you're not actually sending serial data, but you want to do something 'unusual' like generate a television signal using either GPIOs or a serial peripheral.

This isn't available on the LPC1114, but the high end LPC4300 (Cortex M4) microcontrollers have SGPIO, which is basically series of programmable shift registers that you can control through registers or DMA. You can emulate just about any serial protocol, and you can do it without pauses as it is all done in hardware.

http://www.element14.com/community/docs/DOC-52445/l/nxp-an11275--application-note-for-sgpio-on-the-lpc4300

Zuofu
  • 4,168
  • 2
  • 21
  • 36
  • Thanks, that's useful answer. Yes, I'm looking at TV out, etc. SGPIO looks ideal, but I am trying to see what I could do with the only DIP ARM I've found. – fadedbee Feb 24 '14 at 12:47
  • 2
    Keep in mind that peripherals on ARMs are sort of up for grabs. While they all use the ARM core, different makers add different peripherals, and place them on the bus in different ways. SGPIO does not exist on every M4 – Scott Seidman Feb 24 '14 at 13:09
  • Yes, I mean that the LPC4300 as SGPIO and happens to be a M4 core, not that all M4 cores have SGPIO. – Zuofu Feb 24 '14 at 17:36
1

The LPC1114 is a Cortex M0, an entry level ARM, so isn't particularly fast (as far as ARM CPU's go) and doesn't have DMA capability. DMA would substantially improve both performance and the CPU load required for either scenario, and would reduce or entirely remove jitter. You may need to go to a Cortex M3 or M4 if you want to use DMA.

There is no cache at all, so all timing is deterministic.

A 1-bit wide stream is definitely better done with an SPI or USART, including the ones on the LPC1114. It's what they're designed to do. The parallel stream is a different matter; I can't think of a specific comms peripheral off the top of my head that you would use to do that. However, with the right ARM MCU, you could use DMA to stream 1 byte at a time to a GPIO port, with the CPU involved only during the setup phase.

markt
  • 4,936
  • 2
  • 15
  • 13
  • I don't think SPI or UART will meet the requirement of "no pauses" since they both insert framing bits. – Joe Hass Feb 24 '14 at 12:11
  • 4
    Why should SPI insert framing bits?? – Wouter van Ooijen Feb 24 '14 at 12:43
  • SPI implementation on these chips requires defining a frame size, anywhere from 8-24 bits. If you're using a chip select pin, then the hardware will toggle this pin between frame transmissions. – Kevin H Feb 24 '14 at 22:53
  • 2
    @JoeHass the USART in synchronous mode inserts framing bits; SPI does not. Also, that particular part has an 8-byte FIFO that can be kept topped up via interrupts, so no pauses is entirely achievable. – markt Feb 25 '14 at 08:30
  • @markt: Some chips which uses the same shifting circuitry for SPI master and slave operation may not always be able to handle continuous data without pauses due to a synchronization layer between the CPU bus and the shifter. The SPI on the PIC 18F series seems to have such a limitation. Blindly sending data every 11 cycles works; blindly sending every 9 fails (I forget whether 10 was the fastest that worked or the slowest that fails). – supercat May 25 '16 at 18:42