Driver for TSL3301 line sensor (spin and asm)

Lawson

Finally got around to objectifying this driver code for the Taos TSL3301 digital interface line sensor. All of this code is based off the "Using the TSL3301 with a Microcontroller.pdf" that can be found on Taos's product page for the TSL3301

"TSL3301_driver_spn_v1" is a spin driver that directly translates the pseudo code from the Taos .pdf.

"TSL3301_spn_demo" is a short spin program that will use the spin driver to capture line images from a TSL3301

"TSL3301_driver_v1" is a high speed assembly driver for the TSL3301. It can trigger off of an external pin and get the electronic shutter of the TSL3301 open in <500nS. (fully configurable) The minimum line integration time for the assembly code is ~2uS. (again configurable) Data readout from the chip takes ~172uS. The spin interface to assembly driver is different than to the spin driver. This driver is optimized to quickly grab individual lines. The maximum lines per second could be doubled (within limits) if the code was re-written to overlap data readout time and line optical integration time. I'd also say code optimizations should be able to get at least a 10% speed up in serial speed and response times. The assembly code could likely also be made much smaller.

I'd like comments and edits from the forum before I .zip all this up and submit it to the Object Exchange.

Lawson

Phil Pilgrim (PhiPi)

Laswon,

Congrats! That's quite the tour de force! The TSL3301 is not an easy chip to drive and, frankly, I wasn't sure the Prop could do it as well as the SX. One thing that definitely helps is your clever use of phsa to generate the clock pulses.

Now that you've mastered it, what do you have planned for the TAOS sensor?

-Phil

Tubular

Brilliant, Lawson.

Seems like it might be able to easily handle 3000 lines/sec which is what I'm chasing. I've ordered a 3301, will look at it in a week or so when it gets here.

keep up the great work!
tubular

Lawson

Oh it's not that hard to drive I made the spin driver by carefully following the .pdf from TAOS and it worked the FIRST time I ran the code. (that NEVER happens!) The serial interface basically looks like RS232 with a clock. After that it was a day or two to get a direct translation of the assembly running. (can't read INA from the destination...) And finally about a day speeding up the code using tricks I've snagged off the forum. That last bit was a lot of fun as each improvement would hack off 10s-100s of microseconds from the readout time which was easily tracked using CNT. If I wanted to spend another day chasing timing, I could get the read loop to 10MHz (from 6.67MHz) by having PHSA free run while I read bits. This would probably knock 20-30uS off the readout time, but it's plenty fast right now. And yes, I LOVE that PHSA trick. Lets me generate whatever the heck pulse I want with just one instruction, and it works from spin too.

What this TAOS sensor is doing is controlling a laser. The ability get a 2uS exposure ~500nS after a sync pulse is critical for this. Something the analog interface TAOS chips can't do.

Lawson

Lawson

Tubular wrote: »

Brilliant, Lawson.

Seems like it might be able to easily handle 3000 lines/sec which is what I'm chasing. I've ordered a 3301, will look at it in a week or so when it gets here.

keep up the great work!
tubular

I think the limit is over 5000 lines/sec if you re-arrange the commands sent to the chip. (just shy of 6000 lines/sec would be reasonable if the read loop is accelerated to 10MHz) I.e. instead of starting an integration, waiting, ending the integration, and reading out data you would send the "READHoldNStart" macro command to end the integration, start data read out and start a new integration period. Or for a bit more elegance, you could re-write the code with a combo read/write function, and use the "READhold" command to start readout with the integration start command sent during the chip readout with a call to the read/write function. After that I wonder if the TSL3301 will overclock well if we run the Propeller on a 6.25MHz crystal?

Lawson

Phil Pilgrim (PhiPi)

Lawson wrote:

Oh it's not that hard to drive. I made the spin driver by carefully following the .pdf from TAOS and it worked the FIRST time I ran the code. (that NEVER happens!)

I'm glad to hear that the article helped!

-Phil

Tubular

So anybody know what the situation with availability is? Some websites seem to have them as obsolete parts, but no such indication on the Taos website.

My local rep appears to be located in the "Cayman Islands" - surely that can't be right?

Phil Pilgrim (PhiPi)

It may just be the DIP package that's going away. The same is happening with the TSL1401, which is transitioning to a new SMD package.

-Phil

Tubular

I think you're exactly right, Phil.

thanks
tubular

Lawson

Ug, it looks like it's going to be a lead-less surface mount package too. (why not a 14-pin SO package?) I'll have to figure out a good foot-print as I'm likely to use 5-10 of them.

Lawson

Lawson

I finally got around to uploading this to the OBEX. TSL3301 drivers

Lawson

Tubular

Lawson

Thanks for your excellent work on the driver. Got it running in no time.

For the benefit of anyone else, here's how I broke out the (SMD) TSL3301 to a standard DIP8 socket, using fine 0.25mm wire on the back

Next step is to link it to the 160x120x64 greyscale driver

Lawson

Huh, Tubular, if you were going to attach a photo, I think you forgot I'm expecting that a suitable surface mount footprint (with extra wide pads) and adapter can be made as the TSL3301 still has a 0.1 inch lead spacing.

Is that 160x120x64 greyscale driver for VGA?

Lawson

Tubular

d'oh here's the photo

Yes, the 64 grey is for VGA, using Kye's 160x120 driver (1 byte per pixel), with some different resistors. Details here

Tubular

Lawson

Had more play time with this and got the ASM version working nicely with Kye's 160x120x64 grey driver over the weekend. It was producing really nice images at 2500 lines/second (96MHz prop), and seemed to run at least to 4200 lines/second. These figures include copying the line scan across to the video buffer using spin to initiate CaptureFrame and GetFrameData(@videobufferoffset). So it could go even faster still.

I took some video, will post it when I get a moment.

I put a note in the obex because setting the external trigger pin > 31 doesn't do it (it still hangs on the WaitPEQ), but commenting it out frees things up.

Next is to integrate FSRW for dumping the video stream to uSD card. I figure it should be able to dump a good 60~110 minutes of video before hitting the 2GB fsrw limit.

cheers
tubular

Tubular

Don't appear to be able to post a video, so here's a screen shot from the video.

The test subject is a music scale. Illumination is by 4 ultra bright white leds which are not very even (no diffuser).

I am moving the music past the sensor quickly and the music sheet is not necessarily flat so some parts of the image are out of focus some of the time, and in focus at other times.

Scan rate is something like 3000 lines/second

Tubular

When prototyping the TSL3301, I borrowed a lens from Phil's TSL1401DB. It worked well.

One advantage of the new compact TSL3301 in SMT form rather than DIP, is that it is much narrower, so I thought it may be worth trying 3 side by side under the same lens. With some red-green-blue filters on top colour may be possible. There may be some fade-out in the corners, we'll see.

Lawson

Tubular wrote: »

Lawson

Had more play time with this and got the ASM version working nicely with Kye's 160x120x64 grey driver over the weekend. It was producing really nice images at 2500 lines/second (96MHz prop), and seemed to run at least to 4200 lines/second. These figures include copying the line scan across to the video buffer using spin to initiate CaptureFrame and GetFrameData(@videobufferoffset). So it could go even faster still.

I took some video, will post it when I get a moment.

I put a note in the obex because setting the external trigger pin > 31 doesn't do it (it still hangs on the WaitPEQ), but commenting it out frees things up.

Next is to integrate FSRW for dumping the video stream to uSD card. I figure it should be able to dump a good 60~110 minutes of video before hitting the 2GB fsrw limit.

cheers
tubular

Thanks for that note. I guess the "|<" operator only looks at the lower 5-bits of it's input. My intention was to set the "Q_sw_mask" variable to zero which should make the WAITPEQ effectively a NOP.

GetFrameData uses a BYTEMOVE, if you expand the destination buffer by 2 bytes and make sure it's long alligned a LONGMOVE might be slightly faster. The return value of CaptureFrame is the address of the line buffer.

If you upload a video to YouTube, etc. you should be able to insert a link into your post.

Nice scan of that sheet music! Hopefully you can fix the focus with a fixture to more accurately feed the sheets. Interesting idea with the parallel RGB array, love to see how that works out! Wonder how much of a speed hit reading from three chips in parallel will be?

Lawson

Tubular

I am aiming for 3 parallel cogs, but with 1 master controlling the clock/si commands, so should still keep the same rate. And there was plenty of speed available from FSRW, so dumping to SD card should be able to keep up, albeit a kind of interleaved data format that would have to be sorted at display time.

I think the only thing that would need to slow is the real time display - which is color limit anyway.

The alternative would be to rewrite the pasm to grab data from the sensors round robin, formatting it into color pixels as it goes (2x2x2 bits of color for each pixel). That would allow the display to keep up, since it would be a direct copy without translation, but not sure how much spare time there is in your pasm routines.

Lawson

Since all the clocking to and from the chip is synchronous, there are few locations in the code that would break if instructions were added but the code will slow down. My guess is that using a single cog to read all three output pins would take about 3x longer unless you get sneaky with pin assignments. In that case, reading 3 pins might only take 2x the time. (i.e put the three data output pins on pin P0, P8, and P16, read the whole INA register then mask, OR and shift the data in a long. could get nicely byte packed xRGB longs this way). Using a master cog and two slave cogs certainly should work at full speed. I expect synchronization will careful coding since the readout bursts at a 6.6 MHz clock and synchronizes with the hub every four bytes.

The alternative would be to rewrite the pasm to grab data from the sensors round robin

I think round robin readout per pixel would require independent clock lines due to how the chip works. Specifically, once the pixel readout is started, one clock gets you one bit of data or a stop/start bit. The chip allows pixel readout to be aborted early, but you loose the rest of the data.


Lawson

Tubular

Yeah that pin arrangement could really work nicely. Perhaps I should keep separate clock and SI lines for flexibility.

Thinking some more, this arrangement could work really well with a 18 bit RGB LCD for live display. P0/8/16 could be the inputs from the TSL3301s, and P2~7/10~15/18~23 could be set as outputs to drive the LCD. Once 24 bits of data has been shifted in, you just clock the LCD's DotClock to latch the data. Many LCDs can happily run at dotclocks in the low MHz.

Pins would run tight especially if SD card is also required, might be necessary to sacrifice some color depth.