Help identifying IC/ADC on a sous-vide cooker - Page 1
Forum section: electronics / repair

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: January 21, 2021, 01:43:39 pm
content: Hoping to get some help identifying an ADC in a failed Sous-Vide Supreme cooker (labelled MCU on PCB). All identifying marks have been erased by the manufacturer. After identifying pin functions tried unsuccessfully to find a match online.Cooker is a fairly expensive item (~USD500 online currently) that was lent to me and failed after single use. Well out of warranty, no service manual or schematics online. Distributors/agents here supply no parts and don’t repair – no longer sold in Oz. Is on sale Europe but suppliers no help at all – absolutely no response to emails seeking parts/new boards.System has one PCB behind the control panel allowing On/Off, temperature/time setting and heating start. Second PCB holds on RHS an SMPS supplying single +5V rail and on LHS an 8-pin DIP ADC that converts voltage mediated by thermistor on the side of the waterbath to a digital signal fed to control panel. Heating element control is via a 3-pin SCR (under a large heatsink) that is switched on-off by signals from the control panel. After eliminating +5V rail, thermistor and passive components as possible points of failure, began to suspect the 8-pin DIP ADC on the SMPS board.Found a working unit second-hand but still hoping to resurrect and return borrowed unit. Switching boards confirmed control panel PCB is fully functional and comparative tests confirmed ADC has failed and is bleeding digital signal from output pin 6 onto the adjacent analog input pin (7) from the thermistor. Control panel reads 140C with bad ADC and correct 29C with good ADC board.ADC Pins identified as follows:1: GND2: Input from ceramic resonator Pin 3 (GND connected to resonator Pin 2)3: Input from ceramic resonator Pin 14: Vref(?) - connected to Pin 8 via 10k resistor and diode in parallel. 4.99V on bad and good boards.5: NC6: Digital output to control panel7: Analog input from thermistor8: Vdd - +5VCeramic resonator good – running at 8MHz. Attached are photos of the analog input signal and the digital output on the good and bad boards. Long collection photo shows analog T voltage on good ADC reducing, with dips periodically when ice added to bath. Expanded traces shows analog in (Ch2) and digital out (Ch1) signals on good and bad ADCs (pins 6&7).As best I can tell, the bad IC is a single channel ADC with limited functionality. I haven’t managed to dissect the communications protocol yet, but that might be feasible with more work. Hoping someone might be able to identify this IC from these details and photos.

author: fcb
author_rank: Super Contributor
timestamp: January 21, 2021, 01:56:00 pm
content: Pin out is the same as a Microchip PIC12F675 (and others in the family).#4 also doubles up as the _MCLR pin on the PIC and can be used during programming. Also they might be using it as general purpose I/O.The data shown on the 'scope looks like a fairly standard serial.

author: TheMG
author_rank: Frequent Contributor
timestamp: January 21, 2021, 02:33:09 pm
content: Definitely a microcontroller, as the "MCU" labelling would suggest.Unfortunately this means any replacement IC is going to require programming. You can try to read the program from the good unit, but chances are if the manufacturer went through the trouble to scrub the part number off the IC, they probably also set the code protection flag when programming it (making it impossible to extract read the program out of the IC).Other option would be a complete reverse engineering of the good units full functionality and write your own code.

author: Alti
author_rank: Frequent Contributor
timestamp: January 21, 2021, 04:15:46 pm
content: I think the only viable option is to replace whole module with some general purpose controller.Or you could go old-style with mechanical switch with capilary tube for remote sensing.

author: mikerj
author_rank: Super Contributor
timestamp: January 21, 2021, 09:08:21 pm
content: Are you certain it's the micro that's faulty and not some other fault on this PCB? Might be worth lifting one or both pins and checking if this crosstalk still occurs.

author: Teledog
author_rank: Regular Contributor
timestamp: January 22, 2021, 03:39:23 am
content: Was going to build a SV unit with a PID, heaters & pump.Amazon'ed a $150 Anova & a (clear) Cambro - avec floating balls..working well for years!(don't bother with the "WIFI feature" of the Anova..the WIFI is utterly useless & hack-able)G'luck!edit:PS..most restaurants are now using the "portable" SV units ....cheap, and versatile from anything from a sink to a stand-up wine chiller ..plus Anova has fantastic customer service!

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: January 22, 2021, 04:25:16 am
content: Thanks for all the quick and really helpful advice. I had hoped the IC might be a fairly simple device but looks like I grossly underestimated it. I'll try socketing the MCU and lifting pins as suggested as a check on the rest of the board. If that doesn't throw something up I think it'll have to be assigned to the spare parts locker - unless I can get a new board from the manufacturer/distributor. I have little or no experience with microcontrollers and their programming and all the coding I do is in high level languages. I've never found things like assembler code or C++ very digestible. Not possible to delve into all that for the foreseeable - interesting as it would be.Seems to me that a lot of these expensive 'user-friendly' devices are basically designed for short lifespans, limited or no repairability after warranty, and a quick trip to the waste dump. Guess it keeps the consumer goods economy churning over - at the expense of the environment. It would be nice to see some good 'right-to-repair' legislation in place.

author: geggi1
author_rank: Frequent Contributor
timestamp: January 22, 2021, 09:27:31 am
content: If you are capable of doing some programming you can look into making a new controller.There are several exsamples of PID regulators using an arduino on the internet.You got the controlboard and the only faulty part is the MCU just unsolder it and transplant in a Arduino connected to the pins where the MCU where seated.You probably have to reverse engineer the whole controll board to ensure correct modification.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: January 23, 2021, 06:11:19 am
content: Have spent a bit more time looking at this system - it has two microprocessors. The Control Panel has a Samsung 3F9488XZZ-QZ88 that drives the LCD and inputs/outputs to the SMPS board with the MCU that was subject of first post. Seemed sensible to try and work out what the MCU is doing. It does look to be a pretty good fit for Microchip PIC12F675 family as fcb suggested. However, one thing I can't figure at present is why Vpp on Pin 4 appears to be held at ca 4.5V (IIRC) when programming manually indicates low is 0.2V and high 12V (to enable programming). Control panel also has Atmel 112 EEPROM. Apart from that it's mostly push button switches and passives.I've run up a somewhat amateurish schematic of the MCU side of the board in Tina-TI (attached). For readability I've used earth symbol for 0V side of 5V SMPS supply. Main thermistor attaches to connector labelled Bot (see earlier photos). Con2 connector goes to Control Panel. MCU only has pins 6 & 7 for input/output as others are dedicated to 8MHz oscillator, Vdd, Vss and what should be Vpp. Pin 6 carries no digital signals as far as I can see - simply taking analog signals from the thermistor. Pin 7 must be carrying the digital output for temperature from the ADC - whether it's carrying other input/output from the Control Panel remains unclear at present. From the PIC datasheet that suggests Pin 6 configured as A/D input and Pin 7 as bidirectional I/O.Switching control for the SCR is carried on Pin 5 of Con2 - this goes low to turn heater element on. Rate and duration of switching pulses are a function of how close bath is to set temperature. The EL817 optocoupler appears to be monitoring temperature/overtemperature of the SCR, which has an NTC device physically attached. So it looks to me that all the fancy control and SCR switching control is being done on the control panel PCB by the Samsung and the MCU may be simply feeding a serial stream corresponding to analog temperature to the control panel. In which case, a PIC12 microcontroller might look like overkill for a fairly simple job?I've tried looking at the data stream on MCU Pin 7 with my 1630D which is good for selecting triggers, but it only has 1K memory so hard to see slowly repeating patterns. As far as I can see from manuals etc, running it via GPIB (which I've never done) will only give me a series of 1K windows into the data stream rather than the continuous stream. Perhaps time to get something more capable... Meantime, I'll try lifting pin/s on the MCU and see how we go. Thanks for the advice.PS. Link to the item in question.https://sousvidesupreme.com/products/sousvide-supreme-water-oven-11l-stainless-steel

author: Ian.M
author_rank: Super Contributor
timestamp: January 23, 2021, 08:55:36 am
content: Why did the manufacturer do this crazy thing? Well IMHO, they either bought in the main controller's code or commissioned it in-house to work with a digital sensor, then either the digital sensor was discontinued, or they found it was too expensive or it had some other problem (e.g. transients killing it or the main MCU) and they had to patch up the design without the help of the programmer who coded the main MCU's firmware. Using a slave MCU as an ADC is a valid strategy, but is usually only seen when you need multiple ADC channels electrically *ISOLATED* from the main MCU dirt cheap, as you only need a single optocoupler for a one-way serial link.Maybe its time to buy a Salae 'Logic 8' clone, which are dirt cheap and readily available on Ebay, Amazon and the usual far east marketplaces, to use with the FOSSSigroksoftware. Here's Sparkfun'stutorial. If you post dumps in Sigrok format there are plenty of users here who can help you decode them.If you are very lucky, we may be able to identify the protocol and match it to a digital temperature sensor IC that's still available N.O.S., in which case you may be able to replace the thermistor with a sensor IC, possibly with an extra Vcc wire to it, rip out the PIC and jumper pins 6 & 7 of its footprint.Once you've got enough good data to make a fair guess at the protocol, you could set up an Arduino and code a sketch to decode and log the data and also the temperature from an independent probe on the water bath, and fill the bath with boiling water then log as it cools to ambient. That will give you the temperature vs output data relationship, which you'll need to create code for a replacement PIC.Nearly *ALL* Microchip's 8 pin PICs have the same pinout. If coding up a replacement, it would make sense to use one with lots of memory and a 4x PLL to boost its clock speed, so you can get away with using the XC8 C compiler in FREE mode (which disables many optimizations so generates slow and bloated code) rather than having to wrangle with PIC assembly language.To answer your pin 4 query: on 8 pin PICs, its dual function, used to enter programming mode and also as an active low Reset pin. It may also be an input only GPIO pin so you may well see it called out in datasheets as \$\overline{MCLR}/V_{PP}/GP3\$ (i.e./MCLR/VPP/GP3 if you are having Mathjax rendering problems). On older PICs, taking this pin up to Vpp, (>>Vdd) entered programming mode, taking it down to logic '0' reset the PIC and you needed to keep it at logic '1' (<=Vdd) for the PIC to run. Newer enhanced midrange PICs got rid of the high voltage Vpp, as they use a different protocol for entering programming mode, but unless external /MCLR is disabled in their CONFIG bits so the pin can be used as an input, still need it at logic '1' to run code.TLDR: Its a *LOT* of work, not commercially viable to repair, but would be a great learning project if you want to get into sensors, comms protocols and small MCUs.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: January 23, 2021, 02:42:27 pm
content: Thanks Ian - that's really helpful advice on a range of fronts. Been wanting to look more at micro-controllers and the like for a while, so this looks like a good opportunity to pursue it. I'll take another look at the USB logic analysers and look to collect the outgoing digital data across the temperature range and make sense of it. Coding a replacement Microchip PIC had crossed my mind as a potential solution given it might be doing little more than simple AD conversion without fancy arithmetic to adjust non-linearities and the like. Can't see why the makers would do that in the MCU rather than the Samsung controller. That said, your other ideas look easier to implement - especially the sensor IC if one can be identified.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 02, 2021, 01:37:01 pm
content: Collected digital datastream in Sigrok readable form at 1MB/s from the soujs-vide MCU as suggested. Did this over period of ~500s while water heated from ~28C to 70C between 100 & 500s. I’ve extracted 100s of that data stream in a bin file but find I can't attach that file type to a post. Grateful suggestions as to what format is best to export and post it here. Meantime attached an image of a packet with green and red markers at start and end.Also dissected some of the data to try and identify repeating patterns in the stream. The stream consists of a string of ‘packets’ at intervals of 1.0055s and minimum bit length of 10.052ms. That suggests each packet contains 100 bits.Each packet appears to start with a long LO signal ~115ms long. After that there’s a string of bits, that recur in patterns of 2 or 4 bits. I’ve labelled those bits from 1 on in the Excel spreadsheet attached that shows the structure of a single packet at intervals between 100s and 450s (LHS column). Then there’s a unique single bit (an end-of-packet marker?) preceding a long HI of variable length that appears to fill the empty bits in the packet. So the variable part of the packet (carrying the temperature signal) appears to be between bits 19/20 and the presumed end-of-packet bit, which falls at positions 53-57 in my small subsample.Hoping one of the experts here may recognise this protocol or be able steer me in the right direction. I can now collect whatever data may be helpful, but have held off trying to correlate the bit pattern with temperature at this stage.

author: fcb
author_rank: Super Contributor
timestamp: February 02, 2021, 02:40:26 pm
content: My guess is that it's just standard UART (RS232). No idea what the bit rate is, but probably low.Looks like 6 bytes, the first byte always being 0x00. If you scope the data a bit closer you'll probably be able to work out the bit rate, perhaps (if its safe) be able to pipe it into a PC.

author: Ian.M
author_rank: Super Contributor
timestamp: February 02, 2021, 04:00:44 pm
content: Zip the SIGROK files and either attach them here, or if too big, post them on a file sharing site that does *NOT* require registration to download or use of a download manager, and link them here.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 03, 2021, 11:21:55 am
content: After some trial and error learning managed to export a binary file from Saleae Logic2 that imports fine into Sigrok Pulseview using "Import Salae Logic export files" with file format (auto-detect), Channel count (1), Sample rate (25,000,000) and Word size (. I've captured just 50s of data from the digital temperature output pin (7) at this stage with water bath powered up and heating. However, no change of temperature over this short duration. Data packets follow same format I posted in xls file earlier. If more or different is needed to identify protocol please let me know - data easily collected but will need to gather ca500s of data to get from 28C to 70C.A read through the Microchip PIC12F675 manual (if that's what MCU is) indicates it converts an analog input to a 10-bit binary. The GPIO pins are 6-bit wide bidirectional ports. Not sure if this helps with teasing out the signal protocol - microcontrollers are new territory for me.

author: fcb
author_rank: Super Contributor
timestamp: February 03, 2021, 11:52:52 am
content: Are you familiar with RS232?

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 03, 2021, 12:38:51 pm
content: Yes - used it quite a bit over the years and had to use breakout boxes to diagnose comms failures from from time to time. But never encountered it running over a single line.

author: fcb
author_rank: Super Contributor
timestamp: February 03, 2021, 01:06:10 pm
content: So alot of microcontrollers have UART's on them - these UARTs default configuartion is normally 8N1 (8 bits, no parity, 1 stop bit).RS232 idle condition is -ve, and TTL>RS232 drivers are often inverters, so the TTL idle level is typically +ve (logic 1). Again typically, you'll see a startbit (logic 0), 8 data bits and then a stop bit (logic 1).You can (again typically) see a stop bit (logic 1) every 9 bits.Not sure how good your scope trigger options are, but if you can trigger on a falling edge AFTER a long high (the start bit of the first byte), then you have nice stable triggering to examine the data on a scope.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 03, 2021, 01:21:54 pm
content: No trouble doing that - I'll have another look and do some background reading. Thks for the guidance.

author: fcb
author_rank: Super Contributor
timestamp: February 03, 2021, 01:38:56 pm
content: If it's something like RS232/UART you should find that the smallest logic1 and logic0 have the same length.

author: Ian.M
author_rank: Super Contributor
timestamp: February 03, 2021, 07:34:59 pm
content: Its definitely not RS232 framing.It appears to be 16 bit data words using a variable bit rate encoding.The signal idles high. All pulses are low-going. The data word starts with an extended pulse, then it uses long and short pulses for 1 and 0, (or visa-versa, don't know which is which yet), then it terminates with a very short pulse, the same length as the high gap between bits. It then returns to idling high till its time for the next data word.There's one word per second, so I suspect a considerable amount of averaging is going on to get such a stable result from a 10 bit ADC that typically has some noise in the LSB(s).I suggest as the next step, disconnect power and checking the thermistor resistance, initially at a known room temperature, then with with enough near boiling water in the tank to get a good reading (if you think it can withstand boiling water, otherwise reduce the water temperature) + measure the water temperature with a thermometer, then again with ice water + crushed ice.That will give enough data to let you replace the thermistor with a variable resistor, and run it with the heater disconnected to figure out the ADC input voltage to output code, and finally to displayed temperature, mapping, and also if the code is little-endian or big-endian.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 04, 2021, 12:55:20 am
content: Thanks Ian. IIRC the thermistor has a resistance of ca 90-135 kOhms at operating temperatures - I used a 1.5k potentiometer earlier to pin down faults. I'll set this up as you suggest and collect data. May take me a couple of days to get to it.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 04, 2021, 12:08:12 pm
content: Managed to get to this task. Thermistor out of circuit reads 232kOhm at 5C and 11.9kOhm at 85.9C, using thermocouple attached to multimeter. Substituted a single-turn 1MOhm potentiometer and took series of measurements of in-circuit resistance across potentiometer terminals and temperature as displayed on the control panel LCD (shown in cells A1-B10 of attached spreadsheet) These data are plotted in the graph with a fitted parabolic curve, which is not a perfect fit). At A13 - B14 in the same sheet I've added a reading for resistance turned down to 234kOhm (this point may be anomalous as the pot showed a sudden collapse from 496k to 224k (I may need to repeat tests with a better 10-turn pot).For each set resistance/temperature I've done a 10s LA collection - attached as zipped .bin files with the filename set out as SVttCt_rrrK.bin, where ttCt is the temperature and rrr is resistance in kOhm. I've not yet tried to dissect the LA output and relate bit patterns to displayed temperature. Perhaps this will be helpful as is.Note that the resistance across the thermistor in-circuit is very different to the out-of-circuit measurements taken in iced and boiled water (at cells A18-B27). The resistance/temperature measurements in iced and boiled water line up with the measurements using the 1MOhm pot when the thermistor is attached to the PCB and the control panel is turned on (cells A25-B27).Hope all this makes sense.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 05, 2021, 02:43:17 pm
content: Spent some time decoding the binary data in the captures I posted. It's consistent with the 16-bit words suggested by Ian M, After breaking each into 4 x 4-bit elements, turns out the 1st and last 4 bit elements (bits 1-4 and 13-16) are identical in every word at all temperatures and look to mirror the near parabolic relationship between resistance and the Control Panel display temperature that I posted previously. I suspect their decimal values represent something close to the integer part of the temperature divided by 10 - e.g. decimal 12 corresponds to 128C, decimal 8 to 89C. The 3rd 4-bit element (bits 9-12) looks as though it carries something akin to the decimal part of the display temperature as its decimal-converted values consistently vary over just 3-4 adjacent values. Element 2 (bits 5-8) I need to spend more time on.Thinking about the similar parabolic curves for decimal data and resistance versus temperature, I wonder whether the MCU is simply passing the digitised thermistor resistance through to the control panel and leaving it to the Samsung MCU to convert it to temperature. Will explore that further.Not planning to post any attachments till I make more progress in working out these protocols.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 07, 2021, 08:42:51 am
content: Took another look at the Microchip PIC12F625 datasheet that fcb suggested might be the MCU. Seems it generates a 10-bit digital output. So took the 1st 10 bits of captures posted earlier, converted them to decimal for easier plotting, and plotted against temperature (C) and thermistor resistance in kOhm (attached as docx). Turns out the digital output is linearly related to resistance and non-linear with respect to temperature. So it seems the MCU is simply translating thermistor resistance ( to a 10-bit serial signal and passing it through to the control board for conversion to displayed temperature and for feedback to control temperature. For the analysis I converted LO bits 2-cycles long to digital 0 and LO bits 1-cycle long to digital 1 - following Ian.M's suggestions. That translation scheme appears to make sense of the data stream.Presumably the calibration/conversion factors are held in the EEProm on the control board. So the task looks to be reducing down to replacing the MCU with either another PIC12F625 or some other device that will generate a 10-bit digital version of the analog resistance with the correct digital output pattern. Grateful any comments if I'm perhaps on the wrong track here.

author: Ian.M
author_rank: Super Contributor
timestamp: February 07, 2021, 09:47:35 am
content: That would make a lot of sense *if* there was a current source somewhere so the thermistor resistance could be translated linearly into voltage for the ADC. I suppose it could be done using the input's weak pullup, as IIRC its a weakly doped MOSFET that may operate as a current source in its saturation region, however I would expect considerable process variation in its ID(sat), so calibration would be needed to get a consistent result.You seem to be fairly close to having all you need to design the replacement PIC firmware.Where to go from here?Well I'd pick a PIC12F1xxx enhanced midrange part, with a 4x PLL, and plenty of RAM and Flash - Might as well run it at 32MHz and throw MIPS at the problem for a one-off as the cost of the more powerful chip is negligible compared to the savings in development time caused by not having to worry too much about an optimal algorithm, or the code sise and speed issues due to XC8 Free mode generating code that's up to a factor of two more bloated than its paid-licence Pro mode, and many times worse than carefully hand-optimised assembly code. With a fast enough MCU and enough memory, one can even be lazy and do the scaling and calibration using floating point math!I'd also want a 16 bit timer and a CCP module so the pulse timing could be off-loaded to hardware to make it possible to implement the transmit routine as a background ISR rather than having to busy-wait for each bit in the foreground.ThePIC12F1840looks like a good candidate - it has all the features you either need or that would be nice to have, and is also debug capable if you can free up its ICSP pins. Initial development could thus be done with full debug capability on a breadboard, using its internal oscillator and (to permit debugging) moving the analog input and data output to the pins used by the resonator in the final implementation. Its supported for pogramming and debugging by most of Microchip's programmer/debuggers including the low cost MPLAB Snap, PICkit 3 and PICkit 4. IIRC PICkit 2 has programming only support for it (no debug).

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 07, 2021, 11:54:57 am
content: Thanks Ian. Looks like it's time for me to take a step into microprocessor programming. Will take me some time to get set up and do a deal of reading. Appreciate your guidance.

author: Ian.M
author_rank: Super Contributor
timestamp: February 07, 2021, 02:06:09 pm
content: Yes. If you've never dabbled in embedded systems past entry-level Arduino stuff, you've got a steep learning curve ahead of you. Also, reasonable familiarity with the C programming language is pretty much essential if you want to be able to write complex application firmware, as without excellent self-discipline, and a post-graduate level understanding of structured programming theory and practice across multiple languages, and several years intensive experience with the specific assembler and the CPU or MCU family in question, assembly language development almost invariably results in write-once*spagetti code.* Write-once as in you can create it while the concept is fresh in your mind, but if you need to return to it to modify it its more impenetrable than if it had been written by a Mensa member in their native non-western language, and if someone else has to work on it, they'll probably ask if it was written by an alien deity of knowledge on a week-long LSD trip!If you want to see how bad assembly language development on a PIC can get, see the nearly four thousand lines of code I had some small part in partially reverse engineering here:https://www.microchip.com/forums/FindPost/779555The thread basically starts at post #87 as prior to that the O.P. was drowning in the 'X-Y problem' hole. Around 260 posts and a year later after a lot of help from a number of real experts, the O.P. still didn't have enough understanding of the program to make significant changes to increase resolution successfully!

author: fcb
author_rank: Super Contributor
timestamp: February 07, 2021, 02:55:10 pm
content: {Without turning this into an argument}I've been writing PIC assembler for 30yrs and I prefer it over C for the applications I do - where I'm trying to get the maximum performance for a given part. This may be less relevant now with the 32bit $1 ARM processor. It's just as easy to write unreadable spaghetti code in C as it is in assembly.For what you are trying to do (as a one off), I would probably tackle it in an arduino and then bodge wire it in. Easier to 'get to blinky' than a PIC. If you think you're going to need these skills in the future - then learn C on an STM sourced ARM, more in-demand skill I expect.

author: Ian.M
author_rank: Super Contributor
timestamp: February 07, 2021, 08:04:00 pm
content: Quote from: fcb on February 07, 2021, 02:55:10 pmGenerally, I find myself in agreement with your points. I do however have a few slight differences of opinion:Although its far too easy to write badly structured C, it generally lets you create an order of magnitude more complex program than in assembly language before that really starts to bite. e.g. by hiding the implementation dependent details of working with non-native-sized data types, arrays, and especially on 8 bit processors with extremely basic ALUs, handling divison, multiplication, and even floating point maths for you.You are also probably right that it would be worth writing at least proof-of-concept code for the sensor interface to run on an Arduino. However if Lorenzo wants to return a borrowed item of equipment without a bodge-fix, he needs something pin-compatible, and short of designing and ordering an interposer board to allow a SMD ATtiny85 running an Arduino core to be used, there isn't really any alternative in pin-compatible 5V 8 pin MCUs other than PICs. At least I'm not encouraging the use of baseline or standard midrange parts!Embedded C skills are IMHO highly transferable between different manufacturers processors. I initially learnt C with an integer only compiler for the Z80, back before ANSI C, and had no particular issues transitioning to coding for M68K, PICs, AVRs and various others as I encountered them. You just need to sit down with the datasheet, family reference manual, printout of the peripheral register definition headers, and implementation specific sections of the compiler manual and work your way through bringing up whatever on-chip peripherals you need, annotating the datasheet with the C register and bit names used as you go. A ready to run 'hello world' LED blinky can be a considerable timesaver if you are unfamiliar with the toolchain, especially as its likely to have stuff like disabling conflicting on-chip peripherals that you may not be aware of.Of course that wont get you in the door for paid development for a specific processor family (e.g. STM32 ARM), until you've got a decent sized, reasonably complex, well written up, successful project on the processor family in question in your portfolio as an interview talking point.@Lorenzo,Apologies for going a bit O.T. with Fcb. If you can pull together a C proof of concept on Arduino, or just about any 8 bit MCU, subject to my availability, I should be able to help you get a PIC port up and running.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: February 08, 2021, 10:18:37 am
content: This is something of a hobby/passion for me, but one I'm quite happy to invest time in. Not looking to develop marketable skills as I'm retired. I've done, and still do, lots of coding but mostly in higher level languages. Spent a bit of time on assembler in the early 80s writing a bunch of stats modules in CPM FORTRAN80 for an Apple IIe with a Zilog Z80 card fitted. Bit of a challenge with 64K RAM and a 140K floppy drive. Did get a bit into code optimisation, compiling executables and, of course, lots of debugging. Since then have done a good deal of scientific/statistical coding in higher level languages. Not what I'd call 'quality' code but fit for purpose if the gives me the results I need in a timely fashion.I lean towards using C if that will do the job as it'll be an easier step from the type of coding I've done lots of before. Another advantage is that C skills can be useful in R and geospatial work that I spend quite a lot of time on. Have thought about learning it quite often over the years. Given the ubiquity of microcontrollers these days I do need to know more about their internal and external workings.Thanks for the help. Much reading to do.

author: Lorenzo_1
author_rank: Regular Contributor
timestamp: March 11, 2021, 09:46:45 am
content: Found time to remove and socket the suspected faulty ADC and lift the digital output pin. That made no difference to the apparent leakage/cross-talk between analogue input and digital output. So looks like replacing the microcontroller is what's needed. I've invested in a PICKit4 and a MicroChip Explorer 8 development board plus a handful of 12LF1840s so I can make a start on learning microcontroller coding. Unfortunately it's going to be some time before I get to it as I have some big work commitments at present. So I will come back to this project, but not till I have time to get stuck into it properly. Looks like my pile of dismantled kit will not get any smaller for a while...