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.
I'll answer what I can at the moment, without being at my desk. > > 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. Seems that in order for me to fix a bug or update a lib, I must re- write it from scratch. > You have three functions, which return an sbyte, and sword and an > sdword. This is all celsius? You just throw away all lower bits > behind the decimal point? For sbyte, I do throw away some decimal places since they do not fit. Larger variables contain decimal places. It works the same as yours via format library. > 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? > 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. 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. What do you think? > 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. > You might want to add a "raw" function, which just returns the raw > data from the TC77. I use this function a lot during debugging and > when I get very weird temperatures. Converting to a nice floating > decimal number on a display is not easy and it helps to know that the > hardware is good. If the sensor returns FFFF or 0000, that conveys > much more info than a weird Celsius value. Sure, I'll add. > P.S. There is indeed assembler in my TC77 lib, but it is only a > single statement. This was hastily ported from JAL 4.60, which had > much more assembler (and no 16 bit variables!) 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. Thanks, Matt. -- 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.
