(Click the links to goto
Part 2 and
Part 3)
A friend recently gave me some TI chips,he'd sampled a long time ago.One of these,was the
TMP141.I decided to give it a spin with the PSoC3.
Heres more on it from its
datasheet(PDF),
"The TMP141 is a digital output temperature sensor that utilizes the single-wire SensorPath interface. The TMP141 is capable of measuring temperatures within 2°C of accuracy over a temperature range of −25°C to +85°C and 3°C of accuracy over −40°C to +125°C. Low supply current, and a supply range from 2.7V to 5.5V, make the TMP141 an excellent candidate for a wide range of low-power applications. The TMP141 is available in SOT23-6 and MSOP-8 packages."
The samples he had were in SOT23-6,so it was only either of 2 roads,either develop a PCB/ Breakout Board for it,or use the handy wiring pen.(While this is a popular instrument listed at various places,
heres where I came across it first.)
So the wiring pen I chose,and after some careful soldering,in "dead-bug" position,heres what I made:
With this done,I wired it according to the reference schematic with the required pullup and the optional 0.1uF bypass cap,as below:
Before I talk about the code,heres a bit about the interface.The
datasheet provides a good explanation about the "SWD - Single-Wire Data" Bus used here,(which is very similar to the
1-Wire Interface from Dallas).Typical one-master-many-slaves-sharing-the-same-data-line type of topology.
Data needs to be
bit-banged,by pulling the line down for varying intervals of time.So here is a quick explanation of a Bit Read and Bit Write on this bus.
- Bit Write(by Master):
- Delay for 11us(thats the time the bus should be inactive between signals)
- if a '1' has to be written,the master should hold the line low for ~42us.(this time is tMtr1 in the datasheet)
- Or,if a '0' has to be written,the master should hold the line low for ~15us(this time is tMtr0 in the datasheet)
- After the relevant time(either of tMtr1 or tMtr0 depending on what was "written") has elapsed,the Master should set the line back high.
- Bit Read(by Master):
- Again,Delay for 11us(thats the time the bus should be inactive between signals)
- The master should write a '0' (as per above timing,irrespective of the data to be read),and there can be 2 cases after this.
- Case 1: If the Slave wants to send the master a '0',it doesn't change the bus state,after its "realization" (of the bus having been pulled down) time of a maximum of 9.6us.So the master is supposed to check the bus state after it has finished writing the '0' ,and if its high,implies that the slave did not change the bus state,and wanted to send a '0' ,so a '0' is said to have been "read" by the master.
- Case 2: If the Slave wants to send the master a 1,within 9.6us of the bus being pulled down,the slave acts and decides to keep the bus down for a time of tMtr1,or ~42us.
- So,the scheme I thought of to read a bit,was to do a TMP141_BitWrite(0); so that a '0' is written to the bus(slave?),and then right after this call,check the status of the bus.If it is high,implies that the slave did not touch the bus state,and wanted to send us a '0' .If the bus is low, that implies its being held down(for a time of tMtr1,or ~42us) by the slave who is doing so to indicate a '1'.
So,once the bit read and write functions are in,we can look at complete data transactions,as listed on Page 9 of the
datasheet.I wont write more about those here,since the datasheet mentions the required details clearly enough.
So I wrote code to do 8-bit reads,and 16-bit reads.Heres the funny part.
While I can read 8bit registers flawlessly(i.e the expected defaults are read in consistently),the 16bit registers are giving me a headache.
If I do a 16bit read,on register address 0x01(Manufacturer ID- Expected 0x104C),all I get is 0x004C.Similarly,if I do a 16bit read on register address 0x08(Temp. Capabilities - Expected 0x014A),what I get is 0x004A.Where is half my data going?
But wait,there is more.If I do an 8bit read on a 16 bit register,like on register address 0x01(Manufacturer ID- Expected 0x104C),I do get the elusive 0x10.
It cant be an issue of the wrong drive mode(currently is Hi-Z),or pull-up resistor,since the 8bit reads come in with no issues at all.Also,since the 16bit and 8bit read functions use the same underlying Bit Read/Write functions,they cant be bad either.So whats going wrong?
I'll post as soon as I crack this mystery. Mystery solved.See
Part-2 of this post.
..and heres the bottom layer
I used the free online gerber viewer at CircuitPeople,which works great.If you want to see the whole deal(with the excellon drill data superimposed,try the viewer here.)
