FastSPI_LED2, now fully armed and operational, if a bit undocumented

Status
Not open for further replies.

dgarcia42

Well-known member
Throwing this here because I (now we!) have a bunch of teensy 3 users - http://waitingforbigo.com/2013/05/31/fastspi_led2_release_candidate/ - the world is still a bit sparse on documentation, but the example code shows most of the basic use cases, and I suspect many of the folks here are happy to header file dive for more (at least, until Mark and I get the documentation and examples done/cleaned up/out the door).

This is nearly as large a release/change as the preview releases were over the first version of the library. Highlights include:

* a friendlier top level interface to the controllers/drivers (the preview releases were a bit too low level for my tastes, though those are still available for thems that want them)
* high performance, color/perception/brightness corrected and normalized hsv(ish) to rgb conversion
* a wide swath of optimized 8 bit math operations geared towards the things one does with leds
* fast easing, interpolation, sin/cos, etc... functions
* (nearly) full teensy 3 support(1) - including 20mbps-ish data writes to led chipsets that can handle it
* stupid low compiled library sizes (esp. compared to FastSPI_LED)

I'm not doing any major library related code work for the next few weeks (projects to focus on! As well as documentation/examples), which should mean that I have bandwidth to deal with any bugs that come up (vs. what happened after the last preview release where things changed internally so much and were in enough constant flux that even if I fixed a bug someone had, there wasn't anything I could easily give them).

(1) why only nearly? I haven't yet put in DMA support, though i've got the beginnings of it at home. Part of the reason for that is one of the things I like about this new version of the library is the world is layered enough that the SPI classes could be useful on their own for other SPI tasks (at least for writing) that have nothing to do with LEDs. I'm giving some thought to a higher level api for accessing/using/abusing DMA systems. In part because, well, that's my brain, and in part because the due has a completely different dma infrastructure, and i'd like to write teensy specific DMA code once, and due specific DMA code once, and then use a regular library/interface for both.
 
Status
Not open for further replies.
Back
Top