On 10 Oct 2011, at 05:14 , mattschinkel wrote:
Thanks, I'll review these suggestions. Will you be trying these new
libraries in the future? It may only take you a few minutes to
implement. I hope you will give it a chance.
Yes, I will. But most of my TC77 buses are not connected to the SPI
pins, because of routing problems.
The name of the library file will be different from yours,
therefore there will be 2 TC77 libraries (unless someone other then
myself removes the old library).
That is very good, so I can keep compiling my old stuff.
You still could have compiled your old stuff anyways. I still feel it
is better to uprade/replace the current file. As I said before, I
could keep API the same. I suppose it is not up to me what files get
put in the final package.
All my development is from the raw jallib depository. I've never
downloaded a package. I wouldn't even know how. Sometimes, on an old
PC I grumble at Rob for refreshing all the blink samples, which makes
updating the jallib somewhat time-consuming.
Seems that in order for me to fix a bug or update a lib, I must re-
write it from scratch.
Well, not really. See my other post. Some editing should be allowed.
If the sdword function returns something else than celsius, don't
call it that. Call it xx_hecto_celsius if it returns celsius * 100.
Yes, my library has that mistake as well. I can't change that,
because then I'd have to change hundreds of files that use my
library. But you can.
I'll think about it. How are other libraries procedures named in a
case like this?
From the same folder, in mcp9800.jal:
-- temperature, in degrees Celsius * 100, as a signed-word
function mcp9800_centicelsius() return sword is
var sword x
var sdword temp
x = mcp9800_12bit()
temp = sdword(x)
temp = temp * 625
temp = temp / 100
return sword(temp)
end function
Hecto_celsius would return 5 for 500ºC, centicelsius would return
50_000. To be honest, I have no idea what your functions return.
There is no comment at all.
Most temperature measurement systems will have more sensors, I have
PICs that control 32 of them. Incorporating TC77_CS = LOW inside the
library makes it impossible to use with several sensors.
All SPI libraries are setup like this, however we could think about
making it optional via a constant. I find it more user friendly to
have it in the lib, but of course I only use one of them.
At the moment, you could actually alias TC77_CS to a variable that you
don't use, then control CS on your own. I wonder if the compiler would
then remove the unused variable.
I don't think so, because it is changed. Is Kyle so smart that he
removes a variable that is assigned different values but never read?
One flaw I noticed for your original files was that It did not support
SPI which allows you to connect other types of devices to the same
bus.
I do support it! If you keep the CS lines high, you can do anything
on the SPI bus.
You should explain the maximum speed of the sensor in the library and
how to set up SPI.
This is in the datasheet. I can reference the datasheet & a SPI
tutorial. If you feel more info is needed, feel free to edit my
library.
The user should know if there is a speed limit, and if so at what
speed. My lib has a speed limit build-in.
The sensor returns 16 bits data, so you have to have 1 two byte vars
or 2 one byte vars. Last I checked, my library uses 1 byte less ram &
less code. It should be faster because of this, but I can check speed
for you.
This lib was used a lot in old JAL and was quickly ported to JALV2. I
could have done a better job at that.
---
ir EE van Andel [email protected] http://www.fiwihex.nl
Fiwihex B.V. Wierdensestraat 74, NL7604BK Almelo, Netherlands
tel+31-546-491106 fax+31-546-491107
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
