Choosing a MCU - Page 1
Forum section: electronics / general

author: Hawaka
author_rank: Regular Contributor
timestamp: April 24, 2022, 01:10:45 pm
content: Hello,In the past I have used some PIC or TI C2000 MCU, but I never had to choose it as I would simply used what the company has.For a personnal project, I now have this opportunity and I don't really now how to choose a processor.Here is what I need (absolute minimum):- 2x SPI interface- 1x I2C interface- 16x GPIO (included 3x SPI chip select) (1x quadrature decoder optionnal)In term of processing power, I don't really know how to evalute that. But the main task will be to read two SPI 24bit ADC at max 10ksps, and performing some calculation on these data. This include doing an FFT on both channel with a windows of 200ms.I can reduce to 5ksps if the memory requirement get out of hand. Adding external RAM is also possible as I am still developing the board.My past experience with a PIC18F and an ICD2 was not so good due to constant communication problem. Using CCS, a F28377 and a blackhawk programmer was much better.As I have nothing at home, I am willing to invest and get a programmer. The real question is more for which MCU??? I am open to get either a bare MCU from any supplier, a dev board or one of this board with a mcu and a few parts to make it easily usable.How do you guys choose your platform? Is there some kind of hobbyist "standard"?

author: Siwastaja
author_rank: Super Contributor
timestamp: April 24, 2022, 01:47:35 pm
content: Quote from: Hawaka on April 24, 2022, 01:10:45 pmIt's easier than ever: you buy what is available. Now you have maybe 1% of the choice you used to.It won't get any better at least in a year or so.Assuming ARM, being tool agnostic and knowing how to use standard backend (GNU) tools instead of manufacturer IDEs has proven more important than ever, as this makes jumping between manufacturers easier. This leaves only one variable: peripherals. You still have some learning curve with each and every documentation writing style etc.Really, if possible, pick ARM, because then you can re-use a significant part of the learning curve; same CPU, same compilers, same tools, same linker scripts, same interrupt controller. In your example, only the code related to SPI, I2C and GPIO would change between manufactures, but projects would be managed with exact same software, and even the same codebase could be compiled for different manufacturers.

author: dietert1
author_rank: Super Contributor
timestamp: April 24, 2022, 02:16:18 pm
content: If you can get a STM32H7xx demonstration board it's pretty easy to get started. The download and debugging interface is included and there is free software on the web. There are various offers, with TFT (Disco) or without (Nucleo). The processor is rather powerful. Arm Cortex architecture includes a DSP instruction set.Another choice would be a Raspberry PI. Those are cheap and even more powerful when used with a solid power supply, yet one needs to learn more to successfully develop and integrate the application with Linux and NEON. I think RPIs outperform any C2000. And you can develop and debug on the machine itself.Regards, Dieter

author: Doctorandus_P
author_rank: Super Contributor
timestamp: April 24, 2022, 02:33:33 pm
content: There are vastly different philsophies for choosing a microcontroller family.Some people like to hunt down cents on the hardware, while others find availability of tools and support more important.For me it's quite simple, It has to be able to run GCC (maybe SDCC is also acceptable) and tools must be available for Linux, and programmers have to cheap and easily obtainable. I won't pay EUR 100 for a programmer or debugger!I do not mind gross overkill. I'd be happy to use an STM32 @100MHz to blink a LED, that is, if it's possible to buy them at all.I started a long time ago with microcontrollers, long before "arduino" existed. I first dabbled a bit with PIC16F84, did not like assembly at all, and as soon as I found out that the AVR microcontrollers could be programmed in C, I switched to the AVR microcontrollers. I have a quite big dislike of Atmel (now Microchip) using a different programming protocol every 3 years, so for the AVR's I just stick to the old chips such as the ATMEGA8, ATMEGA32 and ATMEGA328 and similar chips. (I avoid all the "tinies" because of peripheral incompatibilities). and for some 15+ years I was quite content with those microcontrollers.Then came a time I wanted to try something new, and after lots of mind boggling complications I settled on the STM32.It fits the bill in that it works with GCC (so do many others), and at that time the "Blue Pills" were cheap and reliable (Now they are kaput, don't buy the "Blue Pills" anymore).STM32 IC's are also very popular in losts of other Chinese stuff. for example:* Gophert Power supplies.* JDS6600 function generator.* Drok / Juntek power supplies.* FN2 compatible PLC boards (Great buy, EUR25 for STM32 with hardened power supply and IO!!!)* Owon xxx1041 "benchtop" DMM.* Lots of PCB's for 3D printers.* Nextion TFT LCD's have an STM32 on their back (and can be repurposed if you want...).* Motor controllers such as VESC, O-drive and lots of small chinese ESC boards.* Lots of other stuff...Getting an STM32 to do something useful was an enormous struggle though. Those microcontrollers are indeed a bit more complex then the 8-bitters, but you can ignore a lot of it (such as DMA) if you don't need it. The most important thing to remember is that you have to enable clocks for almost each peripheral separately. Most of the complication with STM32 comes from ST which tries to force their configuration tools on you, and on a myriad of other choices you have to make (mbed, stm32duino, platformio, home brew, and 10+others)I do not agree completely wit Siwastaya.Availability of microcontrollers is probably more then an order of magnitude lower.Last time I checked the "available" checkbox, my choice went from 600+ devices to zero.So at the moment it's really anything you can get your hands on.If you can get a handfull of microcontollers (and a programmer) via your job, then go for it.For hobby level it's not so bad though.Prices of breadboard compatible uC' development boards have also gone up from "China Direct", but they are still available.The "Blue Pill" is dead because of a myriad (at least 8 different) clones, which all have their own little quircks, and the Chinese erase the partnumbers and print "stm32" on it, and I have no intention on wasting my time in those incompatibilities.Before it got as bad as it is now I bought a bunch of WeAct STM32F411 boards. I've got about 20 of them for EUR 7.5 each so I have enough headroom to sit out the shortage. (It's just hobby for me). I just checked, and these have currently also doubled in price, but are still available.Teensies are also going out of stock now.ESP32 and ESP8266 have also doubled or tripled in price, but are apparently still available.I expect this chip shortage to get a lot worse before it gets better.It seems people are now getting desperate to get anything at whatever price.Doing a bit of hoarding yourself is probably the only ting you can do.Think of some uC that ticks most of your boxes, looks reasonable and is still available, and then buy 10+ of them before stock runs out to sit out the shortage for the next one or two years.Lots of new chip factories are being built now, but they take 2 to 5 year before production starts.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 24, 2022, 02:37:47 pm
content: I’ll echo others responses and say “go with what you can find”. One option might be the dual-core RP2040 from Raspberry Pi, it seems to fulfill your requirements for SPI, I2C & GPIO, andthis guyseems to be running a 50khz FFT on it. It also comes with a fair amount (250k or so) of RAM, and the chips are $1at digikey, or $5 atat adafruitfor the dev board.You don’t really need a programmer, though you can use JTAG if you want, just hold down “boot’ when you reset and it turns into a USB drive, copy your firmware to that ‘usb drive’ and reset again. As long as you’re willing to use ‘printf debugging’ (and it lets you direct serial out to a USB serial port with a few lines in CMakefile.txt) you’re good. Comes with an SDK and reasonable documentation, and has hardware state-machines on all the GPIO, so you can do clever bus-style things without incurring an interrupt cost.If you do need single-step / stop / inspect type of debugging (and it *is* very useful), you can use two of them toget it working in VScodeAt the moment it’s my go-to micro. Cheap, available, capable, and easy to use.

author: nctnico
author_rank: Super Contributor
timestamp: April 24, 2022, 03:38:45 pm
content: As usual many people recommend ST ARM controllers but I strongly recommend to look at NXP's LPC series as well. IMHO these are much better where it comes to portability across series, ease of programming using a serial bootloader, easy to use peripherals which are also well documented and very few silicon bugs. Overall these are a well polished product. The more modern NXP controllers come with peripheral APIs in their rom software so getting the peripherals going is easy without needing to link / compile in external libraries.Having an ARM CPU core or not doesn't really matter when using GCC as the compiler. The real difference is in the peripherals and how easy / difficult it is to get these going.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 24, 2022, 05:12:18 pm
content: As said, any current MCU will be able to do what you want, so pick whatever you're most comfortable with.A RP2040 will definitely fit those requirements and is very cheap, and relatively available at the moment, at least for hobbyist use.But almost anything will do.

author: dietert1
author_rank: Super Contributor
timestamp: April 24, 2022, 06:17:50 pm
content: Quote from: nctnico on April 24, 2022, 03:38:45 pmWhen looking for this, i found LPC81x and LPC83x. Would you write a sentence about which ones are "modern" in the sense of including peripheral driver firmware in ROM?Regards, Dieter

author: nctnico
author_rank: Super Contributor
timestamp: April 24, 2022, 06:49:47 pm
content: Quote from: dietert1 on April 24, 2022, 06:17:50 pmThat information is in the datasheet. The LPC81x has a peripheral rom API

author: Hawaka
author_rank: Regular Contributor
timestamp: April 24, 2022, 07:16:54 pm
content: Thanks for all the suggestion, it will take a bit of time to go through everything.I do not plan to do production, at most I would buy 5 MCU and that's it. Price is not a big concern, I would say around 15USD would be a good price for the processor. One thing I forgot to mention is that my whole system runs on 3V3. But I think that's pretty standard anyway.Quote from: evb149 on April 24, 2022, 01:58:51 pmI'm not sure yet. As of now I don't really see a difference as if I use integer I can simply say all the value are 10*1e6 times bigger (or another factor) than what it is. I guess it will depend on the MCU.The RP2040 and the NXP looks very interesting. Availability will definitely play a role in my choice.

author: hans
author_rank: Super Contributor
timestamp: April 24, 2022, 07:27:29 pm
content: The "get what's in stock" advice holds up. Early last year I got some stock STM32 MCUs, and glad I did. Now you can't get almost anything.. most chips have 1 year lead time at Mouser.. (or doesn't even mention it)But if you re not interested in soldering QFP packages yourself, then getting a Nucleo board (and building your own "shield" on top) is also OK. They are still around plenty last time I looked, and have an onboard ST-link debugger. This works fine with ST's own IDE (obviously), but also with open source tools like OpenOCD+GDB, and open source toolchains. Those Nucleo boards are not expensive, in the order of 20-30 euro for the "big" boards. (If buying a board for general experimentation, I tend to get the most powreful MCU inside a particular series, since you basically pay per "MCU package size"-variant of the Nucleo. So a simple Cortex-m0+ or m3 Nucleo board can be as expensive as the most overkill Cortex-m7 powerhouse chip with tons of memory and peripheral options) I think the cheapest/smallest ones are even lower priced, and can fit in a breadboard similar to Arduino Mini's.ARM Cortex-m0+, m3 and m4 in the STM32 series is a pretty popular mainstream MCU in the community. Obviously there are many good alternatives out there. Atmel, NXP, Silicon Labs, Texas instruments, and even Raspberry Pi, also make ARM Cortex-mX chips.. but not all have received as much attention (perhaps because most of them tailor to their own niche, such as low-power battery operation for many SiLabs Gecko chips, or industrial applications such as NXP LPC).Now if you do plan on building your own boards anytime soon, then I suggest broadening your view..Some PIC32 have reasonable stock (still).. but as you mentioned.. the tools from Microchip are not the best. I do use them from time to time now, but also because I have a reasonable backlog of them when I was still sampling ICs when I was a poor student.Another popular MCU is the ESP32. It's mostly popular because it has onboard WiFi/BLE and reasonable software support. But above all, it's cheap: you can get easy to solder modules for 2-4$ each, which contain a pretty powerful microcontroller. After all.. you don't have to use the WiFi.. The downside is that these chips have relatively few I/O pins (in the order of 20 IO pins or so), and also a very poor on-chip ADC (it's not very linear nor very well calibrated). And AFAIK "nobody" really programs these chips at a RTL (most use ESP-IDF library), which can be a good or a bad thing.Now ESP32 tends to use a Xtensa CPU core, but there are also some new RISC-V MCUs around. IME the software support is reasonably well, although, I have only worked with ESP32 through PlatformIO/Arduino. And I must confess that both "IDE's" don't really impress me. But I do believe you can program ESP32s through JTAG using OpenOCD and a FTDI cable.. but I haven't tried yet.

author: MarkF
author_rank: Super Contributor
timestamp: April 24, 2022, 07:37:19 pm
content: I don't know if they will meet all your requirements and stay in the PIC world?Look at the PIC32MX170F256B 32-bit 50MHz micro-controllers.With 4 DMA channels, you should be able to do ALL your I/O without any processor intervention (just setup code needed).I may have missed it, but you didn't say what your FFT size would be or the sample rate. No doubt you will be doing fixed point math. I've been able to easily do a 256 point spectrum analyzer covering the audio range. According to the lectures, they have been able to reach a 900KHz sampling rate.I made my own breakout board with a 2 channel DAC, 1.5" display and serial channel to experiment with the PIC32.The PIC32 micro-controller lectures from Cornell Univ. may be helpful:https://www.youtube.com/playlist?list=PLDqMkB5cbBA6FEJuj94gl-9vw8xcHu9Gp

author: nctnico
author_rank: Super Contributor
timestamp: April 24, 2022, 08:07:19 pm
content: Quote from: hans on April 24, 2022, 07:27:29 pmJust buying what is in stock may get you stuck with something that just isn't ideal long term. There are still development boards out there for various microcontrollers. IMHO those are a good start for a hobby project.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 24, 2022, 08:20:45 pm
content: Always start from the most limiting requirement, which, if anything, is FFT. Figure out how much memory you need and how much time it takes to calculate the FFT. The CPU you select must have enough memory and processing power for that. Most likely, all the other requirements will be met automatically.

author: hans
author_rank: Super Contributor
timestamp: April 24, 2022, 09:17:06 pm
content: Quote from: nctnico on April 24, 2022, 08:07:19 pmAgreed. But beggars also can't be choosers. If you want to build a diy board today, either pick something in stock, or be willing to transplant a chip from a devboard.Ideally you would like to survey parts from a dozen manufacturers, do a design space exploration, find Pareto optima, etc. But engineering is also constrained to resource/time, and although you could order today a part youwantto use (along with the devboard), and hope it ships in 'due time', I personally don't really like the idea of having to wait either 2 weeks or 2 years before I can really finish my project.I also understand where you're coming from: choosing a MCU series that you want to stick to long-term also makes sense. In this scheme (for hobby use in particular), stick to the parts that have great community support and knowledge, and generally good availability/features.For that reason I was a bit hesitant to mention PIC32, in particular because I abandoned MCP because of the toolchain years ago, but purely looking at the MCU silicon compared to competition they are pretty decent parts. (Except for the errata of the MZ series.. that's a minefield.) But if they are available today, and you are able to setup the toolchain in a way that works with you (which I personally did to a similar level of sophistication, or lack thereof, as compared to Arduino), then thatcouldbe an acceptable middle ground.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 24, 2022, 11:28:42 pm
content: Quote from: hans on April 24, 2022, 09:17:06 pmIt doesn't. By the time the "long-term" arrives you will have much more experience, and also there will be lot more new MCUs with new features. The things that you're stuck to will be obsolete and you'll be living in the past. Instead, use what you please at the moment and don't hesitate to change.

author: nctnico
author_rank: Super Contributor
timestamp: April 24, 2022, 11:52:12 pm
content: Quote from: NorthGuy on April 24, 2022, 11:28:42 pmThat makes no sense at all because you keep throwing work away if you are not carefull.For example: I have been using NXP's LPC series ARM devices for about 15 years already. Due to the peripherals being (mostly) the same I have been able to re-use existing code that I wrote for devices that are now obsolete or end of life on devices that just came out. Especially in a commercial environment it is extremely important to be able to re-use software due to the time & effort that went into writing and testing it. I can basically choose any microcontroller from the LPC series (the one that fits the project at hand best) and copy & paste a new project together in very little time.

author: uer166
author_rank: Super Contributor
timestamp: April 24, 2022, 11:55:46 pm
content: Quote from: NorthGuy on April 24, 2022, 11:28:42 pm+1, although I would add that it would be good to stick to thing that have very large families to choose from, so at least you don't have to re-learn the documentation format, quirks, toolchains, etc.E.g. STM32F/G, LPC series, PIC32MX/MM, etc are all good candidates since those families have huge variety, are a known element, and you can bet your $ they will be still in existence 10+ years from now. I would tend to avoid curiosities and new/obscure stuff such as RP2040/Automotive-exclusive stuff such as SPC5-series/PowerPC stuff, as well as weirdos like Infinion TriCore (well, any Infineon MCUs really), Xmos, etc etc.Point is, if you stay in the mainstream ARM (or the PIC MIPS as an exception) families, you'll do well. Before I get drawn and quartered for this: above doesnotmean you can't use other stuff with success, it's just more work in the long run and more uncertainty if you do.

author: uer166
author_rank: Super Contributor
timestamp: April 24, 2022, 11:58:35 pm
content: Quote from: nctnico on April 24, 2022, 11:52:12 pmThat maybe the case for you, but in my mind that just means that you're doing the same product over and over. Very rarely have I found that I need to re-use large swaths of code across multi-year projects.I think being familiar with the documentation, tools, quirks of the silicon, HW layout, are much more valuable, than the nebulous "code reuse" requirement that management types like to push for no good reason..

author: hans
author_rank: Super Contributor
timestamp: April 25, 2022, 07:07:59 am
content: Doesn't have to be. Seeing answers in 2 camps, I would say: it depends. If you're dealing with protocols like CAN, Ethernet or USB, you'll be very glad you have once debugged all the fiddly code/errata, and then you can re-use it over and over and over again.And is that the same product? Not at all. At an agriculture company I used to work at, we copy-paste the LPC1768 into any project that connects to our CAN bus. We'd bring over a RS232/CAN bootloader, have QA tools in production ready to program these devices, and for development have our CAN protocol stack ready to go to implement a new function group, and start coding away the specifics of that busnode. This an incredible investment to keep refilling if you switch MCU family every other week, and this is not a matter of only code: it's also a piece of validation, hardware tools and production manuals.In contrast, my manager (a software guy) asked why Ididn'tuse the LPC1768 for a smart relay box I had built using a PIC12 device (the user interface was 1 button and feedback signal). I told him: cost, package size and complexity: this box doesn't connect to CAN, so carrying all that baggage is useless. I've chosen a PIC device because the program was 1 C file, and I would flash the image into a PICKIT3 with programmer-to-go, and hand them over to the production guys to tell them "press red button, device does magic"On the other hand, I think there are also bad reasons to marry a particular MCU family, such as if your favorite MCU has e.g. a 16850 UART implementation that you really don't want to say goodbye to. Do you still need all those additional control signals? Moreover, an UART driver is so straightforward to implement, it will probably take less than 100 lines of code to make a buffered Tx/Rx interrupt driver on most MCUs. The same goes for other simple peripherals. Sure some projects may use some niche features of the hardware, but if you (tend to) use them, you're probably in for some custom driver anyway, so there is no point in jumping through a thousand hoops for code reuse.

author: nctnico
author_rank: Super Contributor
timestamp: April 25, 2022, 09:32:59 am
content: Quote from: uer166 on April 24, 2022, 11:58:35 pmThink peripheral drivers and (generic) code that sits on top of vendor specific libraries / ROM APIs. Over the years I have also created my own API standards that sit between low level drivers and higher level code. In many of my projects most of the C files deal with low level stuff and there are one or two C files that are project specific (more or less shuffle data around between peripherals to implement the application).

author: brucehoult
author_rank: Super Contributor
timestamp: April 25, 2022, 10:05:19 am
content: Quote from: hans on April 24, 2022, 07:27:29 pmA representative of Espressif said on twitter a couple of days ago that ALL new models will be RISC-V.It doesn't really make any difference if you're programming in C anyway. Their IDE pretty much just hides what the CPU really is from you. Xtensa isn't horrible or anything, it's just not so well known. Historically it was the easiest ISA to add custom instructions to (and more importantly to get permission to do it), and Cadence have good tools support for doing that. RISC-V of course supports custom instructions too.

author: DiTBho
author_rank: Super Contributor
timestamp: April 25, 2022, 03:11:53 pm
content: Quote from: Hawaka on April 24, 2022, 01:10:45 pmis there an MPU with an i2chardware interfaceor is bit-banging used to mimic i2c?

author: DiTBho
author_rank: Super Contributor
timestamp: April 25, 2022, 03:17:43 pm
content: Personally, I have never used any MPU with built-in I2C, but rather I have always connected a SPI line to to an SPI<==>I2C bridge like the good SC18IS602B by NXP.

author: nctnico
author_rank: Super Contributor
timestamp: April 25, 2022, 03:51:44 pm
content: Quote from: DiTBho on April 25, 2022, 03:17:43 pmHow is that possible?A local hardware I2C interface makes life a lot easier. Some microcontrollers even have 2 or more and SoCs have many (6 or more isn't unheard of).

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 25, 2022, 04:23:31 pm
content: Quote from: DiTBho on April 25, 2022, 03:17:43 pmWait, really ?I'm not sure I've ever come across an MCU that *doesn't* have I2C in hardware - even 8-bit AVR's had that IIRC. I mean it's sometimes called 'TWI' to get around licensing, or you might have an 'SIO' module that can be configured for I2C, SPI, UART etc. But I don't think I've ever come across something that doesn't have itat all.I'm curious now - which MCU's were you using. There could be a fantastic undiscovered country out there, for all I know

author: DiTBho
author_rank: Super Contributor
timestamp: April 25, 2022, 04:30:05 pm
content: Quote from: nctnico on April 25, 2022, 03:51:44 pmDunno, but - thinking about what I usually use- m683xx, has 1xSPI line, no-i2c -> i2c is implemented by two TPU-pins for bit-banging- m68hc11 has 1xSPI line, no-i2c -> i2c is implemented by two PORT-pins for bits-banging- the Ath5k (Linux/MIPS SoC) used in Fonera2 has 1xSPI line, no-i2c, -> i2c by SPI-I2C bridge- the Ath9k (Linux/MIPS SoC) used in the RSP has 1xSPI line, no-i2c, -> i2c by SPI-I2C bridge- the Ath9k (Linux/MIPS SoC) used in the WL703 has 1xSPI line, no-i2c, -> i2c by SPI-I2C bridge- my fpga SoftCore uses 3 digital pins to implement SPI -> i2c is implemented by SPI-I2C bridgeI think ... I am using weird things

author: DiTBho
author_rank: Super Contributor
timestamp: April 25, 2022, 04:46:27 pm
content: (OK, it probably doesn't count, but ... even my calculators don't have itmy TI89 and TI92 have a SIO module used by TI for the TI-link port. Those things before USB we used to upload and download files over an RS232 serial link.The TI-link cable is a TTL3.3V to RS232 adapter, while inside the graphing calculator there is basically a UART module combined with a GPIO, and you can configure the two pins of the Ti-link port as {uart.RX, uart.TX} or as {GPIO0, GPIO1}On my TI92 there is also an SPI link inside the calculator, but it is not exported outside the motherboard, so on both of them the I2C functionality(1) is implemented on my graphing calculator by bit-banging two GPIO pins(1) is useful for directly interfacing MEMS accelerometers, gyroscopes, and magnetometers, and acquiring data for later processing)

author: Bassman59
author_rank: Super Contributor
timestamp: April 25, 2022, 05:09:54 pm
content: Quote from: SpacedCowboy on April 25, 2022, 04:23:31 pmI thought the same thing until I noticed they wrote "MPU" and not "MCU."

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 25, 2022, 05:22:59 pm
content: This. DiTBho talked about "MPUs". (Not that it was fully on-topic, since the OP asked for MCUs.)And since I noticed DiTBho tended to talk about rather "vintage" stuff, I'm assuming they are also refering to somewhat oldish MPUs, which indeed rarely had any I2C interface.Still, a number of them have some kind of SMBus interface, which is very close to I2C.But certainly, if you're talking about any Z80/68k/8088/86 or derivatives, I2C will be hard to find.

author: DiTBho
author_rank: Super Contributor
timestamp: April 25, 2022, 05:44:49 pm
content: Quote from: SpacedCowboy on April 25, 2022, 04:23:31 pmout of curiosity I checked among the laboratory equipment and with the nameTWIthere is a module that has it: theADSP-BF537moduleThe chip has a built-in I2C! WOW! Unfortunately theSDAandSCLpins are routed to any connectors on the final board, but it's good to know!(irony, CAN an Ethernet are both in use)

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: April 25, 2022, 06:03:08 pm
content: I missed the MPU/MCU difference - though a lot of more-modern MPU's also have i2c.You mentioned an FPGA soc with SPI on it - SPI is one of the most trivial interfaces for an FPGA to provide, so that makes some sense, but it reminded me of a meeting I had with the FPGA folks on a project a few years back. They had a task of interfacing a whole bunch of custom hardware to a computer, and a lot of it was repeated modules, to be used one per DUT. They just duplicated everything for each module, so I ended up with 48 i2c busses per FPGA... That burnt a fair amount of PCI BAR space....

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 25, 2022, 06:17:31 pm
content: And speaking of FPGAs, a number of them, even without any hard or soft core, have embedded hardware SPI and I2C modules (often qualified 'hardened') that you can use in your designs. For instance Lattice parts.

author: DiTBho
author_rank: Super Contributor
timestamp: April 25, 2022, 06:37:13 pm
content: FPGA with open-collector pins?

author: nctnico
author_rank: Super Contributor
timestamp: April 25, 2022, 08:00:50 pm
content: Quote from: DiTBho on April 25, 2022, 06:37:13 pmThat is very easy to emulate: disable the output when the lines needs to be pulled-up. Oldest trick in the book; bit-banged I2C does the same.

author: DiTBho
author_rank: Super Contributor
timestamp: April 25, 2022, 08:52:46 pm
content: Ah, ok, so it's the same trick I'm using.

author: Simon
author_rank: Unknown
timestamp: May 07, 2022, 09:15:45 pm
content: Quote from: Siwastaja on April 24, 2022, 01:47:35 pmSpot on, I picked a part for work, not STM as they are less available than rocking horse shit, but I was willing to use anything I could get as it was a fresh start with my first ARM chip, a new job and several relatively simple products to develop in low volumes.

author: Hawaka
author_rank: Regular Contributor
timestamp: May 17, 2022, 04:56:54 pm
content: Hi All,Thanks for all the suggestion. I went with a LPC55S69JBD100. Probably a bit oversize for what I want to do, but the Powerquad feature looks really interesting.Also I found it on a very cheap dev board on OKdo and bought 2 directly. Get what you can was the best advise for sure.https://www.okdo.com/us/p/okdo-e1-development-board/