CCS/TM4C123GH6PM: Suitable Chainable Temperature sensor for reading from TM4C123GH6PM as alternative to DS18B20

Dear Can - 

the Tiva C Driver Library does support 1-wire (see page 401)

http://www.ti.com/lit/ug/spmu298d/spmu298d.pdf 

That said, the TMP117, TMP1075 and similar might be good alternatives for you - these are I2C based devices

Are you using RTOS or non-RTOS? (your comment about the main loop indicates perhaps you are using non-RTOS)

The TivaWare library supports 1-wire because it is on the TM4C129XKCZAD device. Unfortunately the TM4C123GH6PM does not have this peripheral.

Greetings - we (past) interacted here (w/some success as I recall) several times.   I've a bit different take than those arriving earlier - may prove of use and/or interest to yourself/others.

My small firm has been increasingly involved in the Control & rather intense Data Acquisition of (relatively) 'Small, land, sea & submersible', autonomous & semi-autonomous vehicles.   And just as you've noted - 'Motor(s), Lithium Battery Packs, and the Semi-based Power Stages' - all require regular & robust temperature monitoring.    (And the implementation of quick & effective  'temperature reduction methods'  - if the craft is to (both) meet performance goals and (even) survive.)

My group would 'never' consider 'One-Wire' for such task.    While I2C - and its 'too often 'Missing ACK' - often challenge & dismay - that protocol was/is, 'very well designed' - one-wire cannot 'hope' to compete.   Thus I2C enables your expressed, 'Need for device chaining' - while sensing temperature and (many) other vital parameters.

I do detect a 'flaw' in your (seeming) desire to, 'Chain multiple sensors' and then bus them back to the (assumed) single, Controlling MCU.   As you know - I2C is a short-distance bus - and 'range-extenders' add to your device's Size, Cost & Power demand.

You note (both) that your 'Main loop is 'already' too busy - and that you plan to measure motor temperature.    Does this not (somewhat) fly in the face of your 'Multiple, chained, I2C bus implementation - and the 'proper' measure of motor temperature?    My group has (earlier) 'bumped against both' and has resolved via:

• We 'freed' the Main MCU from the (excessive) demands imposed by multiple (we had 7) I2C sensors.    We employed a 'low pin count, (& low cost) ARM Cortex M0' - as the Sensor Manager - and then employed UART rather than I2C - between Sensor & Main MCUs.   Very notable 'Main Loop' improvement.
• Good as these 'semi-conductor based' temperature sensors are - they (usually) prove challenging to (properly) embed w/in a smaller sized motor.   Our solution saw '06-03 RTDs' and even 'thermocouples' - which were far easier to attach to the 'motors' (more than one motor) hot-spots.'    The 'extremely' low level signals from these devices (surely) demanded the 'close proximity' of our Sensor MCU - which managed the Data ACQ. and communication back to the Main MCU.

You appear to be 'averse' to the use of SMD.   That's hard to justify today - and to gain the full benefit of your IC temp. sensors - you should not 'heat sink them' (even accidentally) via a (large) DIP style IC and mated pcb.   Those sensors must be placed as close as possible to the 'expected' hot spots - and then well-secured.    Large mass installations (DIP ICs) will sink heat & be more difficult to 'robustly secure!'

For the record - our (near) autonomous vehicles employ 2 (or more) ARM Cortex M7 MCUs (>200MHz) which 'exchange' w/3 or more ARM Cortex M0s.    Tasking (just one) MCU has (surely) No Chance in our arena... 

I suspect that you've 'misread or misunderstood' my brief edit.   (issued earlier today)

That  'edit' was directed to the original poster - as he has been 'silent' - for 3+ days now.

My writing was motivated by the 'keen response' he's received - from  you, Bob & myself.    Is it your opinion that such bulk & focused effort should receive no comment (good or bad)  and the thread (then die) through 'disinterest?'

You ask, 'If i have some knowledge or advice' - was that not in evidence?    As such Robotics designs grow smaller, and faster, and more precise - higher performance is (always) sought.    And it was that 'reality' which my posts targeted!

Again - my edit was (rather clearly) aimed at the O.P. - not to those whom,  'Rose to the Aid'  of the inquiring (yet now silent) poster!

The fact that 'first you' - and then Bob - responded so quickly - provided my motivation to, 'Offer up my firm's experience.'    (We have done such design work for many years now - and (may) have 'some' capability.)

My 'edit' was deliberately formatted as 'question-based' - not as declarative statements.    Thus - there was no 'hint' of force - instead a (fair) reaction (due to disappointment) was registered.   The poster remains free to 'Do as he/she chooses' - my long history here sought, 'Forum Efficiency.'   (for the benefit of all...)

I visit this forum only 'rarely' now - and today was my last chance to 'check-in' - and see if this poster had responded.    My 'edit' was as gentle as UCLA Law taught.    As an alternative - as I (always) teach staff - "Provide the client (and/or forum helper) some response and brief thanks - sooner rather than later."  

Clients especially become concerned when they do not hear back from (usually) small firms.    And that is among the 'Easiest & Least Costly' (defects) to correct.   Clients always wonder:

• Did they receive our message?
• Are they interested?
• Are they capable?
• Who ELSE can we turn to?

Clearly - none of the above proves good.   Instead:  "Dear Client,    Thank you - we are in receipt of your request - are presently, 'Up to our ears in alligators' (insert reptile/animal of choice) - require a bit more time to (properly/skillfully) resolve 'complications' w/in your project - and shall be back to you w/in (x number) of days/hours."    

This strategy - along w/many long days/nights - and (some) smarts - enabled me to co-found, serve as VP Engineering - and then take (past) Tech Firm from Start-Up to PUBLIC.     Young Staff thought such detail proves 'helpful'  ... (even) here!  ...  (we shall see.)

hello cb1_mobile: thank you for your recommendations. I had a neck sprain, and I resisted to go to doctors, so I ended up in the emergency room, but now I am fine. that's why I have been silent for few days.

your recommendations do contain real world operational knowledge. I understand trying to fit everything in a main loop, and even for critical things like motor temperature could be problematic, this is exactly what I am doing. I need to monitor two motors and one battery, and battery is absolutely critical.

thank you.

Thank you guys for all the answers, the amount of support that I get from this forum is enthusiastic over the years. I started coding with energia/tivaC and now I am building my custom design robot boards and coding using ccs and gcc-arm for ros. It all happened thanks to your support.

Here is a picture of the custom board that I have been asking questions about. It attaches to a raspberry pi over usb, and shows up as /dev/ttyACM0 on the RPI,

and it provides odometry data, Imu data to the raspberry pi, which uses robot_pose_ekf package in ros to localize the robot, meanwhile accept a speed/direction command, and execute the required motor speed to the pid algorithm.