Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Letting the SPI generate an interrupt after every byte sent/read in an array

  1. #1
    Junior Member
    Join Date
    Oct 2019

    Letting the SPI generate an interrupt after every byte sent/read in an array

    The SPI library lets you send and receive data to and from an SPI device.
    I want to send and read a lot of data to and from devices without putting too much load on the core, so I'd like to do this via DMA.
    But the devices also need specific signals from pins so is it possible to send or read an array of bytes and get an interrupt for every byte that is sent/read? The interrupt can't be tied directly to an output pin because the pin toggle has to have specific timing.
    Any suggestions?

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Sorry I have no idea of exactly what you are trying to do? Nor which Teensy you are talking about or ???

    In particular what is the relationship of the other signal pins? That is do these pins influence how the device you are connected to use the actual bytes being sent to it?

    Example: take a display like the ILI9341. There are two main other IO signals associated with it. The Chip select (CS) and the Data/Command(DC).
    With these the drivers MUST have the CS asserted through the whole time of the communication and the DC pin must be asserted when a command byte is sent, but not asserted when the data bytes are sent...
    Is this something like you are talking about? If so you might want to look at some of the different display drivers like the ili9341_t3 (or my version _t3n), which does this.

    But how to do this again depends on which Teensy.
    With the T3.x the code is setup to need the DC to be on an hardware CS pin (and in some drivers the CS must also be). The SPI FIFO queue has 32 bits per entry, and the upper 16 bits has fields in it that allow you to specify the state of the different hardware CS pins for that transfer.....

    For T4, there is only one hardware CS pin example on pin 10 for SPI object. If you use that for DC, there are some tricks I do in the _t3n to make use. But again it is different, in this case again the FIFO is 32 bits, but you can send 32 bits, but there are Commands and Data entries that can be on queue...

    But if you are not using the hardware CS support AND your device requires specific signals changing between transfers, the only real way to do this, is to have to wait until the FIFO queue is empty and the last bits have transferred and then change the state and start the next transfer...

    However again this may be a big issue or maybe not... Example if you are wanting to update a display by DMA, you can do like I did in some of the drivers and first output the stuff to set up the display output often something like:
    <ROWS> r r r r r <Cols> c c c c <write memory> ....
    Where the Rows/COls/Write memory are commands and need DC asserted, I then unassert and then start the DMA operation to send out all of the data for the screen...

    Now if you are simply wanting for some random reason an interrupt for each byte, you might be able to setup a DMA chain and have an interrupt on each of these chain items... But you are not talking about low load!

    Again sorry I am not sure if this helps or not

  3. #3
    Junior Member
    Join Date
    Oct 2019
    Thank you, this clears up the issue. I'm using the Teensy 4.0.
    The single hardware CS pin is not enough and the other pins do influence how the device uses the actual bytes (it's a digital-analog-converter).
    I don't think it's that big of an issue, I just won't get to produce a suitable sine signal with a frequency of 500 kHz, only 200 kHz...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts