C Version of the TSL230 Sensor Driver in OBEX

tellurian

In-keeping with Ken Gracey's call for more C objects I uploaded a C version of the driver for the TSL230 light to frequency sensor. More or less a simple port of the SPIN one but with functions and commentary more appropriately discussing sensitivity (not scaling). A new function ( GetSampleSens() )returns both the current sample and the sensitivity setting in effect for it. Also SetSensitivity() ( formerly SetScale() in the SPIN version ) now allows you to toggle the auto sensitivity mode on and off as well as set it manually.

-tellurian (Allen)

jazzed

Hi Allen.

Kudos! I have some of these sensors but never found time to use them.

It is very good that you prepend the module name to functions to avoid name collisions (I hope everyone else does).
I've started putting the ASCII-BYTE COG array into a .c file just as a matter of style ... doesn't really matter.

BTW: modules can be made into libraries so that you don't have to include the source; use the ICC "ilib-elf.exe" or GNU "ar" to make libraries. Having function API comments in headers rather than .c files makes libraries easier to use. I suppose we should create libraries to commit to obex so users don't have to worry about library archiving details.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

tellurian

Thanks Steve, it is just a port mostly. However I am having some issues with the auto sensitivity. it is not very accurate due to some large jitter when changing the sensitivity so I am poking around with that and will post an update when I am OK with it. Also ascertaining the sensor saturation is tricky (to determine when to lower the sensitivity). It seems to be when the output is somewhere around 1.6Mhz (@vcc=3.3v) but I don't have an optical bench on hand or calibrated light sources (thus the tricky) ... googling and rooting through the literature has not helped.

You are right, the ASCII-BYTE COG array really belongs in a .c file, it does not matter here (ICCV7) but some compilers (older ones mostly, as I am guessing you know) will reject code or declarations in header files (.h) thus it is traditionally put in .c files. Funny I was just following your lead ... you are not a lemming are you?

I am aware of the ICC librarian, and I decided against using it in favour of including the source so that people can modify it as may suit their needs (and learn something too if they are new to C), and to debug problems. But that is a personal choice perhaps and not everyone may do the same, although I hope they do include the sources.

I always have put my documentation in the .c file (an expediency preference), but if it isn't included then the header file (.h) it must be, or use a tool to extract the info from the C file into a quasi-formal document. In general I find that if the documentation is not right in front of developers, the vast majority of them will not update it ... especially so if they are kludging / changing someone else's code.

So I guess I would say I am not in favour of libraries with no source in OBEX. I often customize things and the source is needed.

regards,
-allen

jazzed

Hmm, makes me wonder if this device is fast enough for some kind of Optical DWM communications ... have to read the spec.

Ya, sources must be committed to obex ... libraries are just for convenience. I use Doxygen for sharing module documentation; it doesn't care where the comments are and can be run on PC or Linux. I'm not advocating any code standards. I feel so furry now [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Need a Propeller PC logic analyzer?
Try Propalyzer http://www.brouhaha.com/~sdenson/Propalyzer
http://forums.parallax.com/showthread.php?p=788230