TM1804 protocol on the TP3244

[jstjohnz]

Is it ok to have a short delay (500ns or so) in between the '100' or '110' sequence for each of the bits? I can generate the timing for the three bit sequence ok, but there's always a short delay when I reload the SPI port. Will that work?

My assumption is yes that's ok, but I haven't specifically tried it. 

[Tabor]

Hello Jerry

Which processor are you using, and what type os SPI port (hardware or software)?

regards

Tabor

[jmessina]

It's an 18F2520 @ 32MHz. I'm using the hardware MSSP port.

I've tried a couple of different methods, but I can't get the SPI port to transmit bytes "back-to-back". It seems like the hardware peripheral takes a few extra clock cycles to actually spit out the byte and to set the SSPIF flag when it's done.

I was hoping to just use a lookup table and convert each pixel byte into a three byte (24-bit) transmission with all of the '100'/'110' bits precomputed, but the extra time between the bytes seems to be fouling things up since the byte boundaries split up the three-bit sequence.

Is there a better method?

[Tabor]

You shouldnt have any problems.

I can tell you how I got it working on the TP3244.
My original code is on my other laptop but should give a pretty good idea.

I used three very small lookup tables.

I mask off the first three bits of the dmx value and perform the lookup. 
As the first, third, forth, sixth and seventh bits do not change, the lookup table is reduced to only a few values.
I load that to the Hardware SPI, as that is being transmitted I mask of the received DMX byte for the forth and fifth bit.
Perform the lookup, again as only some bits change the lookup is even smaller.
I go back and check for the empty transmit buffer or full receive buffer. Once the flag is good, the second byte is loaded.
I repeat the mask for the final three bit of the dmx Byte and lookup for the third TM1804 byte, check flag and load buffer.

Obviously you would then add your delays for reset etc.
This seemed a very quick way and worked fine.

I will check the code tomorrow to confirm this as accurate, I wrote it a while ago and brain is failing me lately.
   

[jmessina]

Thanks all for the hints, but I'm not having much luck getting consistent results.

The basic timing seems to be correct ('100' = 500ns on/1us off and '110' = 1us on/500ns off) from what I can tell, but all I'm getting is some flickering.

I've tried '1000' and '1100' too so that the dmx byte->24-bit translation doesn't ever end on a '1' between bytes (and extend the high time), but that didn't seem to help.

Any way I could get a code snippet or two for something that works? I'm not sure what else to try...

[ɟɐsʇǝppʎ]

what are you using to drive your lights, you say the timing looks good, im wondering if the signal is to weak due to a high output resistor value.

[jmessina]

I suppose I should have mentioned I'm doing this code for someone else, and I don't have access to a pixel string, so I have two strikes against me (the first one being I can't read Chinese, so the datasheet is pretty useless).

The hardware it's being run on doesn't have any series R on the output line. The pixel data is being connected directly to the PIC SPI output data pin, so I'd imagine there's probably a fair amount of ringing. There is a pin available that has a 100 ohm series R, but I'd have to bit-bang the output. Perhaps I should give that a try.

[jeffrae]

Tabor Is it possible to get the firmware with 1804 support

I have looked thoughout the forums and wiki and I am unable to find it

Thanks Jeff Rae

[David_AVD]

Tabor went MIA many months ago, so that effectively killed any TP3244 support.