Matching your MCU to your sensors - Page 1
Forum section: electronics / general

author: CoffinDodger
author_rank: Regular Contributor
timestamp: June 23, 2019, 05:58:38 pm
content: So I've got a project, trying to make a nixie tube thermometer. Something that could look pretty classic with some good wood working and brass inlay scale, etc. Anyway, not here to discuss all that. It's simply something I want to design from the ground up as an exercise in the design process, component selection, data sheet interpretation, etc.Now, I wanted to make this thermometer fairly accurate and came across the TI TMP117 IC (datasheet attached). I've never dealt with a digital sensor before (I2C, data widths, etc) so trying to figure out how to appropriately choose an uC to handle the task.Data width is what I'm curious about. How does the sensor's data width effect the minimum requirements of your uC. For instance the data width from the TMP117 is 16-bits. Does this mean I need a 16-bit uC, or do I need a 32-bit? However I was certain the amount of bits a uC is rated is how much data it can crunch in a single instantaneous calculation. So does the width of incoming data necessarily dictate the size of the uC?For the ouput stage I'm between using the uC's DAC to control a BJT/FET or a digital pot to control the biasing of a transistor in the nixie circuit. Then how would that effect my choice. Should the DAC's ENOB match the sensor's data width, etc?I feel like there's a really great paper, PDF, blog, or something on this but my research skills can't seem to write the google search correctly.

author: cur8xgo
author_rank: Regular Contributor
timestamp: June 23, 2019, 06:18:06 pm
content: Quote from: CoffinDodger on June 23, 2019, 05:58:38 pmData width doesn't matter. Can do 24 bit floating point on an 8085 it just takes alot of instructions and is slow."matching" isn't really a thing here....figure out what you need your system to do (high level specifications..things the user needs)....put together a skeleton of how you think you will accomplish it..then see what specfications get in the way or are critical by doing the math and seeing if things are the resolution you want at the speed and accuracy you want

author: GromBeestje
author_rank: Frequent Contributor
timestamp: June 23, 2019, 07:01:56 pm
content: 8 bit, 16 bit, 32 bit, doesn't really matter for that. One thing you might consider are the debugging options. Does the microcontroller support in-circuit-debugging? In that regards, many 8051-based parts do not have debugging support.AtmelMicrochip AVR does support a proprietary protocol debugWire. Microchip PIC also has some debugging support. And the 32-bit ARM Cortex-M microcontrollers have industry-standard JTAG and/or SWD support. My take, don't bother with 8 or 16 bit MCUs unless you've a specific reason for to use them. Cortex-M or RISC-V are the way to go.I'd say get any microcontroller that does (hardware) I²C. Most of them do nowadays. Another thing you say you need is a DAC. Well, that's something that's not present in every microcontroller. Do you need a voltage DAC or a current DAC?If you need a current DAC, I'd look at the Cypress PSoC4 series. For a volage DAC, the part that comes to mind is something in the STM32F3 range.

author: CoffinDodger
author_rank: Regular Contributor
timestamp: June 23, 2019, 10:11:47 pm
content: So I only have one sensor and one output. My thought then was, go small or go home. Find the smallest, cheapest uC that fits the bill and learn how to make do. I honestly considered using a thermocouple and trying to do the whole control circuit analog. Buffer, amp, feedback, output, etc. Then found the IC, which outputs digital, so I got cemented into uC's. Which isn't bad, the world is ran by them now anyway, so good educational project.ANYWAY. So when does incoming data width mater? It's in the data sheet, and even though they can tend to be over indulgent in details, it seems like it has to mater at some point. Unless it's just for programming considerations.QuoteWhat kind of instruction? I'm pretty fresh with uC programming. Talking about bit shifting, etc? I'm sure this is something best learned by experience and experimentation.QuoteI am leaning towards FETs so I would say voltage DAC.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 23, 2019, 10:28:03 pm
content: Program in C, and the compiler figures it all out for you. The compiler knows how to work with the instructions available, even if you only had a 1-bit CPU.You can use int64_t, or double precision floating point if you want. It's only a performance issue then.Note that floating point types can be very slow (milliseconds!) and also require more program memory. A fixed point int32_t or int64_t will be much faster and still offer a massive numerical range.For a thermometer, the speed probably doesn't matter the slightest. You can use the smallest and cheapest MCU you can find and use double or int64 just for the sake of it if you want to.(It is possible that some of the world's smallest MCUs have so little program memory that you can't use floating point, the library might need a kilobyte or so.)

author: cur8xgo
author_rank: Regular Contributor
timestamp: June 23, 2019, 11:27:36 pm
content: Quotehttps://stackoverflow.com/questions/31149925/assembly-32-bit-floating-point-instructions-on-an-8-bit-chipA _great_ way to make a quick quantum leap in understanding here is to get a compiler for an 8 bit cpu (that does NOT have hardware floating point instructions) and also has a floating point library in the high level language of your choice, write a short program that does some things with floats, then look at the disassembly and see how it does its magic.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 24, 2019, 01:14:27 pm
content: Any MCU will do, preferably with hardware I2C module. The only thing you need to match is voltage. Since your sensor can run anywhere from 1.8 to 5.5V, this won't be a problem.I2C is a 2-wire serial interface which allows you to connect multiple slaves (sensors if you will) to the MCU using only 2 wires. I2C uses 8-bit words, although this doesn't affect the MCU selection in any way.

author: Rerouter
author_rank: Super Contributor
timestamp: June 24, 2019, 01:23:35 pm
content: most common tools to write software for MCU's have most of the hard math baked in, so even a little 8 bit micro can happily crunch 64 bit numbers, all you have to do is tell your software they are that data type, and you would like A = B + C * D^E and it will return it without you having to fret over the specifics of how it does itFor I2C and other digital IO, if its for a common dev board micro it should have a library already built for reading and writing data on I2C,I2C / SPI are generally just address and data systems, you write an address to the device for the register(s) you want to read from, you then read off the contents until your happy and end the connectionIt varies a little device to device, but that is the most part,

author: schmitt trigger
author_rank: Super Contributor
timestamp: June 24, 2019, 01:43:31 pm
content: A comment not related to electrical/software issues, but to thermal issues.These recommendations may or may not apply to your project, but it is useful to be aware of them.When you have such a high sensitivity sensor, it is best to detach the sensor from the main board, by using an independent small board which are connected together with a small ribbon cable.When you mount the small board in your enclosure, give it a some thought how the air will be flowing around it. Needless to say, keep it well away from any power supply components.You may want to add a pair of Mosfets in the SDA and SCL lines as level translators, and operate the sensor from 3v instead of 5v.

author: CoffinDodger
author_rank: Regular Contributor
timestamp: June 24, 2019, 03:43:03 pm
content: So shcmitt that actually is some things I've been trying to consider, particularly how to conceal the sensor while still exposing it to ambient air. Not quite difficult but just not at that stage yet. I've also settled on 3.3v supply for the control and sense circuit. So that may play a small roll in uC choice.What now makes a pretty big hit is I can't do any immediate PCB prototyping where I'm at for the moment (On "deployment" playing political games). So I'm thinking DIP packages (which brings my sensor choice into question). Actually best route may be to use perf boards to make modules and hook them to a development board for prototyping till I get back. More a statement to collect my thoughts. More stuff to write in my project notes now. Funny how you can find the answer to some questions and find new ones in the process of responding on forums.

author: ejeffrey
author_rank: Super Contributor
timestamp: June 24, 2019, 04:16:59 pm
content: To be clear, a 32 bit MCU will be *dramatically* more efficient at doing 32 bit math than an 8 or 16 bit MCU. If you were doing any sort of high performance data processing, I would definitely suggest you match your MCU register width to be at least as large as your sensor data or whatever intermediate values you were processing. Often digital filters are run at higher bit depth than the raw sensor data to avoid accumulation of rounding errors. So if you were talking about processing 24 bit audio data in realtime you would definitely want a 32 bit processor. Of course there would be a lot more to making sure that your CPU could keep up than just the bit width. Likewise, if you wanted to to high performance floating point calculations, you would probably only look at processors with hardware floating point units.But all of these can be emulated in software using whatever computation your CPU has. The way this normally works is that the compiler simply turns the appropriate math operations into function calls, and then you link in an emulation library. For instance, a floating point division might be turned into a call to __aeabi_ddiv(). Then you link in a floating point math library which implements that function and knows how to (slowly) implement floating point division in terms of integer math operations.For a thermometer, the response time is approximately infinite, so even taking 1000s of integer operations to implement a single floating point or high precision integer is almost certainly fast enough.One more thing to keep in mind: the soft floating point libraries are actually quite large, and will increase you code size by several kilobytes. So if you are using a tiny processor with small flash you may have to be more careful about what wide operations you include in your code or do it by hand.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 24, 2019, 06:01:01 pm
content: Quote from: CoffinDodger on June 24, 2019, 03:43:03 pmUse a breadboard. It's a lot faster, easier and is sufficient to see if the thing works, so that you could order PCB(s). Or even, given that the circuit is so simple, order the PCB right away.

author: CoffinDodger
author_rank: Regular Contributor
timestamp: June 26, 2019, 02:50:24 pm
content: So made the decision to go the stereotypical Arduino route to get a better handle on the C programming aspect. They uC may only be 8-Bit, slowing things down quite a bit but the rate of change of a room's temperature is pretty slow so that shouldn't be a problem, and again, focusing on the programming aspect. For the actual project I'm thinking a 16 bit PIC or MSP from TI (they made the sensor so ought to already have library functions for it right?). Also, arduino based boards/kits are just so damn cheap and found a kit fromDFRobotwith a real convenient PSU/peripheral hookup shield for hooking up with a three pin JR style connectors. I'm a fan of bread boards but the convenience better fits my situation and helps focus on the programming aspect.ANYWAY, my biggest enemy now is the APO/FPO system. There doesn't seem to be a timely/affordable means of receiving packages without a physical address where I'm at. DigiKey wants to send through UPS, Mouser wants to charge around $30 to go the snail way from the States, and i'm talking with DFRobot's store now that I find out he hard way DHL won't do it either. May just find something else or have to wait till I get back to the states. In the future just gonna put together a travel ready lab kit. Digilent recently came out with a pretty neat though not necessarily powerful kit incorporating their Analog Discovery II with a rather large breadboard, power supplies, BNC connectors, etc. Though the price seems pretty high.Thank y'all for the input. If i can get a hold of a board i'll most likely be back here with coding/register questions.

author: marty
author_rank: Contributor
timestamp: July 03, 2019, 03:10:13 am
content: Why not have it sent to a friend or family member then they just send it USPS? mouser can 2 day stuff for like 9.00 conus. It shouldn't be a big package and since you say deploy and APO/FPO your allowed care packages.Timely well you know how that system is already.

author: CoffinDodger
author_rank: Regular Contributor
timestamp: July 03, 2019, 07:25:51 am
content: Quote from: marty on July 03, 2019, 03:10:13 amRight? That's honestly the issue. It's a short tour is the actual problem. Packages from home take 2+weeks to get here. A package from Ranger Joes took 20 days from the day USPS received it. Lucky me, the contractors I work alongside let me use their freight address. So it's coming, under their name, etc., in the next few days.