This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28069: TMS320F28069

Part Number: TMS320F28069

Hello

Our application uses a 28069 to control a printhead @12Mhz using SPI.  Works great, but now we need 7 SPIs @12MHz.  There just isn't time to send out all the data using a single SPI, just wondering if this might be possible using the CLA.  Perhaps setting up a pwm at 12MHz to trigger the CLA, which would modify PWM signals every cycle to emulate SPI?  The CLA and the main CPU really do run in parallel, correct?

This would be easy peasy with an FPGA, but the 28069 is just so nice for everything else we're doing, so we want to give it a shot.

Any ideas?

  • Hi Stewart,

    stewart prince said:
    Perhaps setting up a pwm at 12MHz to trigger the CLA, which would modify PWM signals every cycle to emulate SPI?

    I'm not sure whether you would be able to emulate SPI using ePWM module. I've tried emulating  SPI using the bit banging method through GPIOs. Something like this:

    stewart prince said:
    The CLA and the main CPU really do run in parallel, correct?

    Of course Yes!

  • Hi Stewart,

    It's going to be tough to get 7 SPIs on this chip.  There is going to be a lot of overhead trying to emulate the SPIs.  I assume you are using both SPIs on the chip already.  Make sure you use the McBSP also which has a SPI mode.  That leaves 4 to be emulated.

    My first thought is the data is going to be much easier to replicate using other serial comms, but if you are able to service the PWM(s) each PWM period then it should be do-able.  You'll also need to plan for a way to stop the PWM after the transmission is completed.  This is where another serial comm would be beneficial.

    Regards,

    Kris

  • I didn't describe the clocking correctly. It is 1 clock signal and 7 serial data lines, a latch and a strobe. All data lines share the same clock, no data returned from printhead.

    Each print head (7 print heads in parallel) expects 96 bits. Send the clocked data bits, then latch and strobe.

    Currently, I'm using a single SPI at 12 MHz and sending 6 16 bit words, works perfectly, as expected.

    But now, to control 7 clocked data signals in parallel, it looks like the only way is is bit manipulation. Actually the best way would be to write a byte to the GPIO all at once. But the CLA on the 28069 cannot write directly to GPIO, and there is no real way to write a byte to a port, only bit manipulation using set and clear. Plus at 90 MHz there is only 7 clock cycles before I need to interrupt the CLA again to perform the next task.

    If I was doing this on an 8051, I would set up a pwm at 12mhz, then every interrupt I would move a byte of data to the data/address port, just like a parallel data write to memory. But here there is no way to move an entire byte of data to the port in 1 clock cycle, and 7 bit writes would take 7 cycles. I wouldn't have time, even in the CLA, to do anything else like set up the pwms for the strobe, latch.

    I don't think this is going to be possible.
  • Stewart,

    Can you show us a diagram or waveform of what you're looking to accomplish? I think that may help clarify the objective.

    I agree that GPIO would be a better solution that the PWM. You may be able to use the GPADAT.all write to do what you're looking for but this would have to be through the C28x. I remember there are some precautions that must be taken when using that route though. I'll see if I can track them down.

    Regards,
    Kris
  • Sure. Here's the timing diagram for a single printhead, there are 7 in parallel with 1 clock source.
    But since I can't seem to insert a graphic into this reply box, please see the print description at:

    global.kyocera.com/.../controlling.html

    and BTW, thanks for helping
  • Stewart,

    Thanks- and just to clarify. Are you looking to use the CLA and PWM because the C28x does not have enough MIPS remaining to handle the SPI emulations (it's busy running the application)?

    Regards,
    Kris
  • Correct. Only reason for CLA was to emulate 7 SPIs. Now that I realize this is impossible, I'm going to move up to the 2807x that has 3 spi and 2 mcbsp and try to coordinate them using a single clock. There is a 5 channel version of the printhead as well.

    The rest of the processor is busy doing comm with a pc and controlling 4 motors.
  • Hi Stewart,

    Two notes:

    Where the F2806x's CLA does not have the ability to directly access to the GPIO data registers, the F2807x does have this capability.  This may make implementation of what you wish, solely utilizing the CLA & bit-banging with the GPxDAT register, feasible.

    If you try to synchronize multiple SPI/McBSP, my recommendation would be to configure one peripheral as a master and have the others configured as slaves.  I believe this will allow everything to be synchronized - just write to the master when you want to have everyone send.


    Thank you,
    Brett

  • Brett

    I haven't tried the mcbsp yet, because I'm doing this in Matlab/embedded coder and they don't support a mcbsp block.  But I tried your suggestion of spia as master, spib as slave and it worked with the clocks tied together.  I loaded 8 words in each, and when master (spia)sends, slave (spib) starts to send,  they are sync'd perfectly, only 3 clock cycles off, or around 37 nanoseconds off.

    But at 12 MHz the spi clock looks horrible....all sorts of ringing, barely a square wave.  Data is only slightly better, and I have to get to 20MHz.

  • Hi Stewart,

    From memory, the status of the internal pull-ups can play some impact on the output quality (GPxPUD).  I think disabling the internal pull-up was typically better (and this makes sense logically too). 

    Please also note that the quality of the signal will vary with load - especially since, according to the datasheet, you are near the maximum frequency that can be output by a GPIO.


    Thank you,
    Brett